Talk:Scheme (programming language)

This is an old revision of this page, as edited by Tarquin (talk | contribs) at 17:45, 7 May 2005 (This article should mention SIOD.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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)


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 unenligtening 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.