Is Scheme Lisp
Is Scheme LispOne of the interesting debates in Lisp circles is the question of whether or not SchemeLanguage should be considered part of the LispLanguage family. There are more than a few Lispers (and perhaps a few schemers) who think that the LispSchemeDifferences are sufficiently large that Scheme should not be considered to be a "Lisp". This topic has spread across many pages, so this page has been created to quarantine this particular HolyWar.
The LispSchemeDifferences page should be limited to discussion of observable differences between Lisp (particularly CommonLisp) and SchemeLanguage; not commentary on the topic of IsSchemeLisp or not.
Naturally, this topic gets at the heart of WhatIsaLisp?--what does it mean, precisely, to be part of the Lisp family of languages.
Note that the fact that CommonLisp (and other Lisp dialects) is a different language than SchemeLanguage should be beyond dispute--non-trivial Scheme programs won't run on CommonLisp implementations and vice-versa. And the differences between the two languages in many cases are fundamental - neither language can be turned into the other with clever macros or other application of SyntacticSugar.
Arguments why Scheme is a Lisp (should be considered part of the Lisp family)
Note that this section does not (necessarily) argue that SchemeLanguage is bad or inferior (or superior for that matter), just that it's different enough from other Lisps that it should be considered a wholly separate language (though specific arguments may advance such claims.)
Discussion
ThreadMess moved from elsewhere
[moved from LispSchemeDifferences]
SchemeLanguage and CommonLisp (CL) are about as similar as Java and C++.
I would argue that Scheme and CL are further apart than Java and C++. Not on the language level per se, but by the "psychological distance" of their user communities (if you see what I mean). I think most Java and C++ programmers could switch languages without much trauma, which is not true of lispers and schemers. This is competently exposed in ParentheticallySpeaking. -- AlainPicard
I am a Common Lisp programmer and I switch between both languages easily. And I like to use Scheme, too. The differences are overrated. The distance of the user communities are mostly in the heads of a few people.
A certain subset of the older CommonLisp community goes absolutely BatshIt? anytime someone so much as mentions Scheme, and tries to claim that the languages have nothing to do with each other based on strained sociological arguments. Sadly, this includes some prominent people. The reverse does not seem to be the case. -- AnonymousDonor
The difference is: schemers effectively act like a community. The Common Lisp community has a bad track record on sharing stuff. Many great softwares done in CL just disappeared into oblivion. That's why you have a bunch of wonderful useful stuff on Scheme (GUI toolkits, top-class profilers like in Bigloo, web stuff, etc) that you only get in proprietary Common Lisp environments (and the unexplainable fact that you still don't have that stuff in the FreeSoftware Common Lisp implementations). I guess this explains the much smaller mindshare Common Lisp has wrt to Perl (and Python, and Java, and C++, and...).
So what? I can switch between C++ and Bourne Shell programming easily.
"So what? I write the same style in Scheme and Common Lisp. Easily. Without bending my mind. Good luck with C++ and bsh."
If you write the same style in Scheme and CL, you are abusing both of them. Regarding C++ and bsh: you'd be surprised. ;)
"I'm not abusing them. I like to use a heavy functional programming style. That's nicely supported by both languages."
I agree with Alain in that I think Scheme and CL are on opposite ends of the scale when it comes to abstract similarity. I tend to compare Scheme to C and CL to Java, which has its own set of problems, but seems more correct to my mind. However, I disagree with the notion that switching between Scheme and CL is hard. I use both Scheme and CL and like them both as Lisps. They have different areas of applicability and particular traits that are unique from one another, but I find this only enhances my appreciation of each. Indeed, in many cases, I write Scheme and CL code together in a given application for different tasks and abstractions. -- DanMoniz
Further, I get the impression that most Schemers could use CommonLisp with no problem, but that a lot of common lispers have trouble with Scheme. Thus, I'm banging my head on scheme to I learn it well before I go back to CL, but maybe I'm just being excessive here.
That's because Lisp is more forgiving; the Scheme design is to disallow things for no good reason other than just to be a bitch to the user. Like accessing the nonexistent portions of an empty list gives good defaults (FIRST NIL) -> NIL, etc. So the Scheme programmer can write a naive program in Lisp which will just work, but if he had written it in Scheme, she would have to go back and debug all those cases where empty lists are not dealt with properly, list is used as a variable name instead of lst, etc. On the other hand, she will probably have to add a liberal sprinkling of funcalls to get her code working. ;)
[Well, most Schemers can use CL to write Scheme code. Schemers who can write CL code that looks like CL, rather than Scheme, are the rarest of creatures. On the other hand, I suspect most CLers can write Scheme indistinguishable from a Schemer's Scheme]
Once you start thinking in tail recursion, going to CL can be a *real* pain. On the other hand, CL-ers going to Scheme can still use `do'.
But CL-ers want to use LOOP and all of the other advanced CL idioms
Besides which, Scheme's `do' and CL's `do' really aren't the same. Scheme's is really recursion, not iteration - try capturing closures over some loop variable for several "iterations" and looking at the values afterwards.
The difference you observe is correct. However, it is not really a result of iteration vs. recursion, since a Scheme version of CL's do can easily be written, as follows. Observe that this version explicitly uses (tail) recursion to perform the iteration.
(define-syntax parallel-set! (syntax-rules () ((_) (if #f #f)) ((_ (var value) rest ...) (let ((temp value)) (parallel-set! rest ...) (set! var temp))))) (define-syntax cl-do (syntax-rules () ((_ ((var init update) ...) (stop-condition final ...) body ...) (let ((var init) ...) (let loop () (begin body ...) (if (not stop-condition) (begin (parallel-set! (var update) ...) (loop)))) final ...))))
[moved from WhatIsNull]
This (suggestion that the different meanings of "null" ought to be broken up into different values) is a strange position to take, given that the Lisp community has happily, and without any problems whatsoever, been punning on the multiple meanings of NIL for forty years. Perhaps the real problem lies elsewhere? -- AlainPicard
It bugged enough Lispers that SchemeLanguage finally completely split the boolean concept and list concept. Then there's the oddity of CommonLisp GETHASH, which has to return two values to tell apart "NIL-as-undefined" from any other use of NIL. Overloading NIL seems to indicate an inadequate type system.
This is the standard disingenuous position of a schemer, who wants to be associated with the lisp label, but then wants to also be able to condemn it. Lisp and scheme may have historical ancestry, but they are not the same language. To wit: Lispers are (still) very happy punning on NIL, Schemers think that's ugly. In other words, the it bugged enough lispers... means it bugged those people who didn't want to be lispers. Fine. So they created their own language. Fine. How does this affect how lispers see NIL? (Hint: it doesn't.) -- AlainPicard
Not only that, GETHASH returning two values is not an example of punning NIL so much as it is an example of returning false instead of throwing an exception. Most Schemes I've seen choose the latter, but if they didn't, they would be forced to return two values just like CL. It'd be the only way for #f to be both a return value and a valid atom for storing in a hash table. You might argue that not raising an exception is ugly and impure, but that's a whole other story that has nothing to do with an "inadequate type system" or punning NIL as false and empty list. -- A anonymous schemer.
[moved from SocialProblemsOfLisp]
Re "I think Lisp suffers from.... eternal confusion with the Scheme community (as demonstrated, yet again, on this page). Lisp, in real life, has very little to do with Scheme. Much less than, say, Java has to do with C. To outsiders, both languages look the same (lots of parens) but the goals of the communities are almost completely at odds." (from AlainPicard):
I think the Scheme/Lisp dichotomy is one of the social problems of Lisp. Saying that Scheme has less to do with Lisp than Java with C strikes me as a bit preposterous. Interesting stuff is happening in the Scheme world that doesn't get into the Common Lisp world (module systems and hygenic macros are two good examples). There seems to be a violent reaction against Scheme from some members of the Lisp community; I haven't observed the reverse in the Scheme community. -- NoelWelsh
Although there's quite likely some interesting stuff happening in Scheme that a Common Lisp-like language might benefit from, I think you may be missing the essential point that Alain is making - or at least that I believe he's making: it's not about the languages as much as it is the communities. Yer average CL programmer has a package system which is usable with a bit of care, two namespaces which largely does away with the need for hygenic macros, and is more likely to want to get on with writing an application program using Common Lisp than he is to take the entire language implementation apart again for an incremental gain which is unlikely to outweigh the cost of rewriting all his previous applications. The average Scheme programmer is (my impression only) far more likely to be interested in incompatible development of the language itself - because after all, it's probably not incompatible with the core standard Scheme itself, just with whatever his favourite implementations previously did. There is a big gap for a community somewhere that could be playing with new language features for "big" Lisps, but welding together the existing Scheme and CL communities is not going to produce it. They have different priorities.
Personally, I think that "disdain for easy problems" is a much bigger issue for CL: CLiki is all about code that solves the easy problems. After all, just because you can build and manage an entire country's rail system in a quarter the time in Common Lisp doesn't mean you have to start by inventing the wheel every single time.
On the other hand, as a contributor to and original author of the CommonLispWiki referred to above, I am not only clearly too obnoxious to contribute to this debate, but also too thick-skinned to realize it. So, YMMV -- DanBarlow
[moved from LispLanguage]
The notion of LanguageFamilies and especially of such a thing as the LispFamily of tools may be tricky for beginners at best, and perhaps useless to mainstream discourse.
Take for example the IsSchemeLisp question which sometimes generates too many boring, useless words. In many general discussions on Lisp, it is trivial to find people tripped up believing CommonLisp is only about lists and FunctionalProgramming, without macros. Because Scheme is always taught that way, which they learn in school. But without macros, CommonLisp increasingly becomes a silly language with way too many (((parentheses))). So clearly, we encounter evidence of unfortunate misunderstandings generated by this taxonomy.
Of course, people should create taxonomies which suit their particular situations, so mindlessly going the other extreme (Scheme can never be a Lisp) is certainly an authoritarian overreaction.
To some extent, the anti-scientific worldview of computer "science" (ComputerScienceIsaSoftScience) can be blamed. People are encouraged to make hazy (and lazy) handwavings, they don't check their sources, and come down hard on one side or the other like pro wrestling. Just for the sake of some tool. So flamewar circuses result, and thoughtfulness is punished.
Scheme and Lisp are like two biological populations that are in the midst of the evolutionary process of speciation. Whether "total speciation" has occurred is debatable, but I think in making that determination, one must look at the languages themselves and not the intentions or goals or even opinions of the communities WRT each other (us versus them). As trivial as this may seem, I think that one of the big psychological reasons that people feel justified in saying that Scheme is not a Lisp is that it was named "Scheme" and not "SchemeLisp?". Somehow that naming distinction seems to make it possible for CommonLispers? to deny Scheme's place as a Lisp dialect despite its obvious similarities, its historical legacy, and the aspects of each other that each has taken for itself. It's the latter that suggests that the two have not completely "speciated" (to continue extending that metaphor), because in a sense they are still exchanging genes. -- MikeStone?
Asking the question , to me, at least, is a bit silly: we just need to look at definitions. Paul Graham wrote an essay (I can't remember its title) where he lists eight or nine core elements of the LISP ideal, and then points out that, once a language has all these elements, it is a LISP. It doesn't matter what people call the lanuguage, or what the commiunity's goals are, or even what the origin of the language is! Python, for example, has six or seven elements, and once it obtains the last couple, it will be just as much a LISP as Common Lisp, or Scheme, or MacLisp, or Dylan, or even LISP 1.5. Of course, since one of the requirements is macros, and Python's syntax tree is a pain to use, Python almost certainly won't become a LISP (and even if it did, it will likely be like Dylan, where macros are so darn difficult to use, they are used rarely)...but that is irrelevant to the definition! --Alpheus
EditText of this page
(last edited March 11, 2013)
or FindPage with title or text search