| HN Mirror

Oh, you think there should be an actual counterargument to the proposition that Scheme is "not a Lisp"? Well, okay.

This is of course a purely semantic discussion, about the meaning of the word "Lisp" (and "Scheme", if you like). Words are defined by their community of users, and you are of course free to use them however you like, at the risk of talking nonsense and tricking yourself into logical fallacies if you adopt an inconsistent meaning, or failing to communicate if you adopt a non-mainstream meaning. So let's consider whether the mainstream meaning of the word "Lisp", that is, the usage of the word among Lisp experts, includes or excludes Scheme.

This runs into the difficulty of determining who "Lisp experts" are, since that depends on what "Lisp" means; we could run into a schism like the Protestant/Catholic schism, in which each side considered themselves to be the guardians of, and experts on, the true meaning of Christianity. To avoid this problem, presumably we can all agree that at least the people who wrote the Common Lisp specification or major contributions to it, who are credited as major contributors to "Lisp" in the Common Lisp standard, and who have published well-regarded books about Common Lisp, are "Lisp experts", independent of the results of our inquiry about Scheme. (I am taking the liberty of supposing that your comment above implies that Common Lisp is a Lisp, despite its departure from traditional Lisp features such as fexprs, fsubrs, and purely dynamic scoping, which were present in the first version of Lisp I learned.)

I assert that it includes Scheme, because Lisp experts almost always use the word "Lisp" in the sense of a family of related languages including Scheme, only occasionally deviating from this use, mostly in informal discourse. Evidence:

The preface for R3RS http://people.csail.mit.edu/jaffer/r3rs_1.html#SEC1 says, "Scheme is a statically scoped and properly tail-recursive dialect of the Lisp programming language invented by Guy Lewis Steele Jr. and Gerald Jay Sussman." This is signed Jonathan Rees and William Clinger (Editors), Hal Abelson, R. Kent Dybvig, Christopher T. Haynes, Guillermo J. Rozas, Norman I. Adams IV, Daniel P. Friedman, Eugene Kohlbecker, Gerald Jay Sussman, David H. Bartley, Robert Halstead, Don Oxley, Mitchell Wand, Gary Brooks, Chris Hanson, and Kent M. Pitman, who chaired the error-handling subcommittee of the ANSI Common Lisp committee, was the Project Editor, and prepared the Common Lisp HyperSpec. R4RS and R5RS have the same summary statement and add Guy Steele, who wrote Common Lisp, the Language and was originally the vice-chair of the ANSI Common Lisp committee, as signatory. R6RS has the same statement but a different committee: Michael Sperber (Mr. Preprocessor), Dybvig, Matthew Flatt, Anton van Straaten, Richard Kelsey, Clinger, Rees, Robert Bruce Findler, and Jacob Matthews. R7RS-small has the same summary statement; its signatories are Alex Shinn, John Cowan, and Arthur A. Gleckler (Editors), Steven Ganz, Alexey Radul, Olin Shivers, Aaron W. Hsu, Jeffrey T. Read, Alaric Snell-Pym, Bradley Lucier, David Rush, Sussman, Emmanuel Medernach, and Benjamin L. Russel.

Moreover, the Common Lisp HyperSpec itself calls Scheme a dialect of Lisp:

> Lisp is a family of languages with a long history. … One of the most important developments in Lisp occurred during the second half of the 1970’s: Scheme. Scheme, designed by Gerald J. Sussman and Guy L. Steele Jr., is a simple dialect of Lisp whose design brought to Lisp some of the ideas from programming language semantics developed in the 1960’s. Sussman was one of the prime innovators behind many other advances in Lisp technology from the late 1960’s through the 1970’s. The major contributions of Scheme were lexical scoping, lexical closures, first-class continuations, and simplified syntax (no separation of value cells and function cells). Some of these contributions made a large impact on the design of Common Lisp.

Similarly, Richard P. Gabriel's (and Pitman's) seminal "Technical Issues of Separation in Function Cells and Value Cells" https://www.dreamsongs.com/Separation.html explains:

> In this paper, we shall refer to two abstract dialects of Lisp called Lisp₁ and Lisp₂.

> Lisp₁ has a single namespace that serves a dual role as the function namespace and value namespace; that is, its function namespace and value namespace are not distinct. In Lisp₁, the functional position of a form and the argument positions of forms are evaluated according to the same rules. Scheme [Rees 1986] and the language being designed by the EuLisp group [Padget 1986] are Lisp₁ dialects.

> Lisp₂ has distinct function and value namespaces. In Lisp₂, the rules for evaluation in the functional position of a form are distinct from those for evaluation in the argument positions of the form. Common Lisp is a Lisp₂ dialect.

Gabriel is nowadays perhaps better known for writing "Worse is Better", but he also wrote the book on Lisp benchmarking and was a major contributor to the Common Lisp committee, the above-excerpted essay being only one of his contributions.

Paul Graham, who wrote On Lisp (recommended by the manual of SBCL, currently the most popular implementation of Common Lisp) and the Prentice Hall ANSI Common Lisp book, wrote a Lisp FAQ http://www.paulgraham.com/lispfaq1.html which says:

> What is Lisp?

> Lisp is a family of programming languages descended from a language John McCarthy invented (or more accurately, discovered) in the late 1950s. The two main dialects now are Common Lisp and Scheme. We're working on a new dialect called Arc.

So, in arguing that Scheme is not a Lisp, you are opposing yourself to not only every version of the Scheme standard (written by many Lisp luminaries) but also every version of the Common Lisp standard, and to Gabriel, Graham, Steele, Sussman, and — mostly — Pitman.

But consider this position paper by Pitman from 1994, some years after the Common Lisp spec, http://nhplace.com/kent/PS/Lambda.html where he deeply considers what it means for a language to be "a Lisp":

> I learned Lisp as merely a programming language.

> But as I watched, it began to evolve. And I came to view it more as a space of languages, unified by a set of common design principles--a terrain upon which one could move freely among certain camps and still be within the warm and friendly confines of a larger community called Lisp.

> Lately, however, that terrain seems rougher than I once had thought--perhaps indeed rougher than it once actually was.

...

> “If they're all Lisps, presumably they're all built around some common core. Right?”

> Not necessarily. ...

> IF and COND? Well, some Lisps offer only one or the other and they differ as to which is primitive. And in dialects where IF exists, there is disagreement about whether it takes one, two, or many arguments--or whether the alternative starts in the third position or is introduced by a keyword. In some dialects of Scheme, COND takes the unusual but popular “=>” syntax.

...

> The Dylan language, which some (myself included) might say is in the Lisp family--or at least descended from it--chose to abandon Lisp's traditional heavily parenthesized notation in favor of a more traditional syntax. ...but probably no one would deny that there are aspects of Lisp more important than parentheses...

> It is a mistake to assume that a naming similarity (in this case ``purple'' and ``light purple'') automatically implies a close functional relationship, or that an absence of naming similarity implies no such close relationship...

> In standardization efforts for Common Lisp (by ANSI's X3J13 in the US) and ISLISP (worldwide, through ISO's SC22 working group, WG16), explicit decisions were made not to attempt to standardize ``Lisp.'' By informal agreement among these parties, ``Lisp'' is considered the language family, not of any particular language. ...

> Sometimes it's best for us all to act as a single body--when we have a common need or when we can help each other on our separate needs by acting as one body. On those occasions, it might be to the advantage of some or all of us to view Scheme and Dylan as members of the Lisp family. At other times, it's best for us to act independently, to avoid stepping on each other's toes. On those occasions, not only might Scheme and Dylan not be Lisps, but it might be important even to say that Common Lisp and ISLISP are sufficiently distinct that it is better to treat them as non-overlapping languages.

I've also found exceptions in, for example, the Racket documentation, even though it shares a couple of authors with R7RS; at best its use equivocates between describing Scheme (and Racket) as being a Lisp and setting them up as alternatives; first, it implicitly describes Scheme as a Lisp:

> We thought Scheme’s macro system would help us experiment with language designs. The language also appeared to be a perfect match for constructing a simple interactive development environment (IDE); after all, many Lisp courses taught how to create a read-eval-print loop, and a lot of emacs was written in Lisp.

-- https://felleisen.org/matthias/manifesto/Racket__Historicall...

But then, later, it describes Racket, Scheme, and "Lisp" as three separate languages (and of course Racket, Scheme, Common Lisp, NewLisp, ISLISP, Lush, and so on are all separate languages):

> Racket is also a member of the Lisp family, ... Like Lisp, a Racket function application is just a pair of parentheses around the function and its arguments[.] ... In sum, Racket’s toolbox empowers programmers to create new languages quickly and thus enables language-oriented program design. The key to this achievement is to improve over Lisp and Scheme’s approaches: Racket carefully stages syntax elaboration (Flatt 2002), eliminating Lisp’s problematic eval-when-where approach...

-- https://felleisen.org/matthias/manifesto/sec_pl-pl.html

The comp.lang.lisp FAQ clarifies that the newsgroup has been taken over specifically by Common Lisp users, carefully distinguishing the Common Lisp language from the larger family of Lisps:

> 1.1 What is the purpose of comp.lang.lisp?

> The charter… states that the purpose of comp.lang.lisp is "Discussion about LISP". …newsgroups' purposes evolve, as do names. Firstly, the newsgroup has evolved such that the main topic of discussion is ANSI Common Lisp, though discussion about other lisp variants is welcome within reasonable bounds.…

> 1.2. What is on-topic on comp.lang.lisp?

> Discussion of the language defined by the ANSI Common Lisp standard is definitely on-topic on comp.lang.lisp. ...

> Since the Lisp community is remarkably long-lived, discussion of the history and evolution of Lisp tends also to be welcomed, or at least tolerated; discussion of non-standard lisps (though generally not Scheme or Emacs Lisp) is also accepted. …

> 1.3. What is off-topic on comp.lang.lisp?

> Questions about Scheme, Emacs Lisp and AutoLisp tend not to be terribly welcome, as they have their own fora in the comp.lang.scheme, comp.emacs and comp.cad.autocad newsgroups. …

> 1.4. Is Scheme a lisp?

> Scheme is a member of the greater family of Lisp languages, assuming that is considered to include others like Dylan and Emacs Lisp. The design of Scheme predates the ANSI Common Lisp standard, and some CL features such as lexical scoping may be considered to have been derived from Scheme.

In conclusion, in most contexts and most places, Lisp experts describe Scheme without further comment as just another Lisp dialect, just like Common Lisp, Emacs Lisp, AutoLISP, or ISLISP. But, in the same paper where he uses Scheme as an example of the nonuniformity of COND semantics across Lisp dialects, Pitman points out that sometimes it's useful to emphasize that Common Lisp, Scheme, and ISLISP are two different programming languages, in order to discourage people from trying to unify them under a single standard; and so occasionally Lisp experts do use the term "Lisp" in a way that excludes Scheme, either through carelessness or, as Pitman says, for political reasons.

(And the vicious band of aggressive lowlifes led by Erik Naggum drove discussion of non-Common-Lisp variants out of comp.lang.lisp by harassing into submission anyone who disagreed with them, largely destroying the Common Lisp community in the process; but they are careful to clarify that Scheme is just as much a Lisp as Emacs Lisp and Dylan are.)

Given that your opinion on what "a Lisp dialect" is differs so manifestly from the consensus of experts in the field, I think we should give your opinion no weight whatsoever when considering my arguments above about why most modern programming languages should be considered dialects of Lisp.