Talk:Scheme (programming language)

This is an old revision of this page, as edited by Donhalcon (talk | contribs) at 04:01, 3 March 2006 (implementation cleanup). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Latest comment: 19 years ago by Donhalcon in topic Implementations links

Hygienic macros

Hi. The following text was found in Hygienic macro, but I don't know enough about Scheme to integrate properly. Please could someone else handle this:

Scheme macros:

  • Transforms derived expression types into primitive expression types.
  • During expansion, no evaluation ? rewrites one pattern of code into another.
  • May use macros if we want to ommit Scheme?s call by value evaluation

--DJ Clayworth 15:28, 21 Nov 2003 (UTC)

It is unfortunate that hygienic macro redirects to Scheme programming language where there's only little information on the subject. --MH 15:29, 16 Mar 2004 (UTC)


Scheme advantages

Most of the advantages listed stem from more general design decisions than that of Scheme in particular:

  • Concerning syntax it's a feature of all Lisps (well, except for the very first design of Lisp which did not use S-exprs)
  • Concerning the functional aspect, it is as the name suggests common to all functional languages.

I've therefore added in the section what these advantages stem from. --Sam 00:15, 11 Aug 2004 (UTC)


Evolution of scheme

Two sections, Disadvantages of Scheme and Standards, talk about official and community standards, but in a rather unenlightening way. A brief history of scheme should be written, covering the nature of the RnRS process, the status of the IEEE standard, the reasons for doubting there will ever be an R6RS, and why the SRFI process was created and what has been going on with it.

I propose a rewrite of these two sections, with a new section "Evolution of Scheme" as the first numbered section that covers the above. Any objections to me diving in and doing that? --Charles Stewart 09:01, 12 Aug 2004 (UTC)

That's fine with me. Make sure that you do describe the percieved advantages and drawbacks of Scheme, especially compared to other dialects of Lisp (since its advantages and drawbacks as a whole are largely those of Lisp). It may also be interesting to explain how the drawbacks are addressed. --Sam 20:42, 13 Aug 2004 (UTC)


Toki Pona?

I am not the one who originally deleted the link to Toki Pona, but after checking it, there is no Scheme code on that page contrary to what the section title claims. In fact it does not have anything to do with Scheme. Therefore I have removed the link. Is there any good reason to link to that article that I have missed? --Sam 04:47, 27 Aug 2004 (UTC)


Disjointness of types

A point: while the current scheme standards assert that the types are disjoint, and in particular that #f and '() are distinct, this has only been the case since the IEEE standard and R4RS. R3RS permitted these two to be the same, and MIT scheme had this equality. This comment is provoked by this edit. --Charles Stewart 14:54, 15 Oct 2004 (UTC)


Outdated?

"The Scheme community is highly fragmented, with dozens and dozens of implementations, and without a dominant implementation it has proven difficult to focus developer support on providing adequate libraries for practical work. (For example, Python has over 100 extension libraries written in C, and many more in pure Python.)"
"For this reason, Scheme is often considered to be a "toy" language, unsuited for production use since too much time is needed to re-invent the wheels, though one very well suited for educational purposes. A dominant, open source implementation is badly needed to remove this stigma."

Really? There's PLT and Chicken, among others very high quality free implementations. I'd pick Chicken over Python any day of the week. "filesystem access, a socket interface, HTML processing," all these are readily available these days.

I can agree that there needs to be some disadvantages listed but all of the listed things are things that are currently false, since:

  • The SRFI's have been successful
  • There are adequate libraries for practical work
  • Scheme isn't just a toy language (even though it's often viewed as one)

The namespace thing.. yes, some people do see that as a disadvantage; others see it as a huge advantage. A short note should be made that these two sides exist, with discussion moved to another page.

Real disadvantages:

  • has a reputation as a toy language - even if it's not one, that's the reputation
  • is very different from mainstream algol-like languages (it's imho easier, but opinions differ on that)
  • is popular with academia and cs and other hopeless geeks

Maybe CL-folks could list some disadvantages that scheme has? otoh I've never seen any CL folks with a good understanding of scheme.

I dropped the latter offending paragraph, since it was accusatory, POV, and not in encyclopedic style. (It is not Wikipedia's business to tell other people what is "badly needed".) Please feel free to contribute accurate information directly to the article -- be bold in editing. :) --FOo 01:33, 7 Mar 2005 (UTC)
This article should mention SIOD.


Cryptic tail-recursive factorial example

Hi, I was just reading the article out of curiosity. I really liked most of the article and actually became interested in learning the language. I don't know how to program in scheme or any lisp dialect for that mater. I am not a CS major, but am not computer illiterate either. I program in other languages like C, Objective-C, perl, and php just for fun. I was trying to follow the tail-recursive example and was completely unable to do it and I don't feel is my fault. I believe that a few comments on the code and perhaps explaining what do the "let loop" expression and the "do statement" do instead of vaguely mentioning that they are "syntactic sugar" could help. I would write them myself but as I said, unfortunately I don't know how to program in scheme.

I don't know the specifics of the rest of the discussion, but I really liked the article aside from these rough edges, Good Job!!

The "named let" form sets up a local subroutine, here called loop. This routine has two local variables, called fact and n. (I'd call them total and iter or some such, but whatever.) Inside this subroutine, you can think of a tail-call to loop as just a GOTO back up to the top of the named let, only with these variables modified.
One of the lessons to learn from Scheme is that if you can assume tail-call optimization, then a tail-recursive call is just a GOTO with arguments, and is just as efficient (while still being a lot more readable). --FOo 05:23, 21 Jun 2005 (UTC)
I just cleaned up (IMHO!) the examples a little. What do you think now? --FOo 05:41, 21 Jun 2005 (UTC)


Historical revisionism

Isn't the following claim in the 1st paragraph of the article (boldface mine) revisionist?

"Scheme is a functional programming language and a dialect of Lisp. It was developed by Guy L. Steele and Gerald Jay Sussman in the 1970s initially as an attempt to understand the Actor model and introduced to the academic world via a series of papers now referred to as Sussman and Steele's Lambda Papers."

From Structure and Interpretation of Computer Programs, available online [1] the most complete historical account that I was able to find on a moment's notice follows:

"Scheme, the dialect of Lisp that we use, is an attempt to bring together the power and elegance of Lisp and Algol. From Lisp we take the metalinguistic power that derives from the simple syntax, the uniform representation of programs as data objects, and the garbage-collected heap-allocated data. From Algol we take lexical scoping and block structure, which are gifts from the pioneers of programming-language design who were on the Algol committee. We wish to cite John Reynolds and Peter Landin for their insights into the relationship of Church's lambda calculus to the structure of programming languages. We also recognize our debt to the mathematicians who scouted out this territory decades before computers appeared on the scene. These pioneers include Alonzo Church, Barkley Rosser, Stephen Kleene, and Haskell Curry."

I have been unable to document the claim that Scheme is in some way indebted to the Actor model (I have two refereneces Kent Dybvig's book and Abelson and Sussman. I find the claim strange, since I have used scheme and T and recognize its heritage, but the actor model I didn't think was one of the predecessors, particularly of such prominence. I will believe the claim, however, if someone provides a reference. --CSTAR 21:19, 10 July 2005 (UTC)Reply

The review paper The Evolution of Lisp by Guy L. Steele, Jr. himself and Richard P. Gabriel claims
"The dialect of Lisp known as Scheme was originally an attempt by Gerald Jay Sussman and Steele during Autumn 1975 to explicate for themselves some aspects of Carl Hewitt's theory of actors as a model of computation."
(From section 2.8 Scheme 1975–1985.) -- Tobias Bergemann 13:17, July 11, 2005 (UTC)
This statement is indeed correct, but nevertheless, I still think it is misleading (and revisionist) to mention the actor model in the second sentence. It's fine to mention it, but in a more nuanced history section further down, where other relevant ancestors are also mentioned. Particularly, since no mention is made in the intro on continuations, which is really the essential point of why scheme was developed to understand actors, as is evident a few lines down from the quote you provided:
"Functional interactions were modeled with the use of continuations; one might send the actor named “factorial” the number 5 and another actor to which to send the eventually computed value (presumably 120)."
Continuations as first-class objects is one of the distinguishing characteristics of scheme. --CSTAR 15:01, 21 July 2005 (UTC)Reply
Hm, "misleading" and "revisionist" are strong words, but I agree that the goals driving the original conception of Scheme (understanding the actors model) are far removed from the goals driving the later development of Scheme, and the very first paragraph of an entry on Scheme in an encyclopedia should probably describe the status quo of Scheme rather than the reasons for its creation. That being said I think that the first five paragraphs of this entry taken together already provide a quite balanced overview of the features and roots of Scheme.
(I also agree that continuations as first-class objects is an important characteristic of Scheme, but its inclusion in Standard Scheme was and remains a topic that is controversially discussed amongst the editors of RnRS. First-class continuations are mentioned in the third paragraph right after the lexical scoping that was adopted from Algol. Algol was probably as strong an influence in the early development of Scheme as the actor model.) --Tobias Bergemann 09:53, 22 July 2005 (UTC)Reply
(I finally found the reference I was originally looking for w/r/t Scheme's original conception and its relation to the actor model. In his 2002 essay Objects have not failed, Guy L. Steele, Jr. writes:
"The Scheme programming language was born from an attempt in 1975 to explicate object-oriented programming in terms that Gerry Sussman and I could understand. In particular, we wanted to restate Carl Hewitt's theory of actors in words of one syllable, so to speak. One of the conclusions that we reached was that "object" need not be a primitive notion in a programming language; one can build objects and their behavior from little more than assignable value cells and good old lambda expressions. Moreover, most of the objects in Hewitt's theory were stateless and unchanging once created; for those, lambda expressions alone were sufficient."
This was the reference I had originally wanted to provide, but could not find at the time, so I quoted the Evolution paper above. Another reference more relevant to the later development of Scheme is the archives of the RnRS authors' mailing list from 1984 onwards.) --Tobias Bergemann 12:39, 22 July 2005 (UTC)Reply


Introduction

The intro currently reads:

"Scheme is a functional programming language and a dialect of Lisp. It was developed by Guy L. Steele and Gerald Jay Sussman in the 1970s initially as an attempt to understand the Actor model and introduced to the academic world via a series of papers now referred to as Sussman and Steele's Lambda Papers."
"Scheme's philosophy is unashamedly minimalist. Its goal is not to pile feature upon feature, but to remove weaknesses and restrictions that make new features appear necessary. Therefore, Scheme provides as few primitive notions as possible, and lets everything else be provided by libraries that are built on top of them (or using extra functionality in various implementations). For example, the main mechanism for governing control flow is tail recursion. (Some people refer to Scheme as a family of related languages, each defined by some implementation.)"

I'd like to rewrite this to remove the necessity for the two parenthetical statements. Here's my first draft for a rewrite:

"Scheme is a functional programming language and a dialect of Lisp. It was developed by Guy L. Steele and Gerald Jay Sussman in the 1970s initially as an attempt to understand the Actor model and introduced to the academic world via a series of papers now referred to as Sussman and Steele's Lambda Papers. Minor implementation details tend to differ slightly, so sometimes Scheme is referred to as a family of closely related programming languages."
"Scheme's philosophy is unashamedly minimalist. Its goal is not to pile feature upon feature, but to remove weaknesses and restrictions that make new features appear necessary. Therefore, Scheme provides as few primitive notions as possible, and where this is practical in an implementation, tends to let everything else be provided by libraries that are built on top of them. For example, the main mechanism for governing control flow is tail recursion." --Tony SidawayTalk 12:21, 29 August 2005 (UTC)Reply
Please add *some* text instead that makes it clear that Scheme programmers do not start every project by writing the things that you get for free elsewhere. This is exactly how the paragraph sounds, and a very common (and very stale) anti-CL propaganda line.
Goodness, no they don't! I'm writing my current project using seven scheme modules. What *is* true is that implementations differ somewhat. For instance, I would have to (and probably will) do a considerable amount of work to make my code work on most widely used implementations of scheme. --Tony SidawayTalk 19:33, 30 August 2005 (UTC)Reply


Explanation of Tony Sidaway's revert of an edit by 24.128.49.163

In an edit at 20:34, 2 October 2005, 24.128.49.163 (talk · contribs) made the following changes:

1. "Some people are at first put off by all the parentheses used in Scheme notation." -> "Many people are put off by all the parentheses used in Scheme notation.

2. "after a short period of accommodation the parentheses become unobtrusive" -> "after a period of accommodation the parentheses supposedly become unobtrusive"

3. Addition of two paragraphs describing the syntax of Scheme as "cryptic and unintuitive...therefore relatively hard to learn" Claiming that Scheme program execution speed is limited to "a fraction of the speed of programs written in a modern compiler language." by the mode of implementation. Claiming that the use of Scheme as a good introductory language for computer science is "a myth [that] has been debunked."

Point 1 seems incorrect and ignores the learning curve.

Point 2 is weaseling, "supposedly".

The syntax of Scheme is as a matter of fact on of the simplest of any programming language. The assumption that Scheme cannot be compiled is simply incorrect. No support is given for the claim that the utility of Scheme for introductory computer science has been "debunked."

I have therefore reverted. --Tony SidawayTalk 21:21, 2 October 2005 (UTC)Reply

Yeah, the anon user's edit is an obvious troll. --Neilc 22:30, 2 October 2005 (UTC)Reply

Advantages/Disadvantages

These sections are POV, not to mention unsourced and very subjective. It reads like point->counter-point, where the last counter-point ends up being pro-scheme and in some cases anti-lisp. The disadvantage section itself is more like a "debunking disadvantages" section and it's funny that it's tiny in comparison to the advantages section anyway. I'm not even sure how things like curly/square brackets are an "advantage" over anything. Plus I question adding an "advantages" section in general to any programming language article. Most don't have a "advantages" section and for good reason, because you're not actually comparing it to anything except "every other programming language in existence," which isn't helpful. Nathan J. Yoder 05:42, 19 October 2005 (UTC)Reply

"Always built on"

The hygienic macro system is always built on some low-level facility which provides the full power of non-hygienic macros, including arbitrary syntax-time computations.

What does this mean? That every single Scheme implementation provides unhygienic macros in some way?

good catch, I'll change it to "usually". Sunnan 07:28, 18 December 2005 (UTC)Reply

Scheme tools on Wikipedia

As I enjoy programming in Scheme I'm employing that language in writing tools for Wikipedia. The first tool is one that measures the degree of vandalism on popular articles on various Wikipedias by examining edit summaries to recognise probable reverts of vandalism. At the time of writing it recognises vandalism reverts on the English, German, French and Spanish Wikipedias. --Tony Sidaway|Talk 02:49, 27 December 2005 (UTC)Reply

A lot of the links in the Implementations section seem more like ads than encyclopedia citations. That section looks a bit like a WP:SPAMHOLE; cleanup would be good. —donhalcon 04:01, 3 March 2006 (UTC)Reply