One 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)''' * Both are dynamically-typed, strict FunctionalProgrammingLanguage''''''s (more or less--both languages readily allow SideEffects) with markedly similar syntax (EssExpressions, similar special forms/keywords) * Both uses lists (chains of ConsCell''''''s) as a fundamental data structure; much of the programming culture of both languages derives from this. (Both languages support more complex data structures as well). * SchemeLanguage is based in part on early Lisps, in part on AlgolLanguage. CommonLisp, in turn, is based on many early Lisps (MacLisp, InterLisp, etc.)...and SchemeLanguage. * Many idioms are similar (if not identical) between the two languages. * If you learn one, learning the other is simple. '''Arguments why Scheme is not a Lisp''' 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.) * The technical LispSchemeDifferences are sufficiently large that the two languages cannot be considered parts of the same family (to say so is tantamount to saying that C++ and Java are part of the same "family"--extended family, perhaps). * The purpose of CommonLisp is to ''unite'' the Lisp community; portions of SchemeLanguage went into the formulation of CommonLisp. Now that CommonLisp exists (and has existed for many years), continued use of any other Lisp dialect, other than in research or in legacy applications (such as use of EmacsLisp in EmacsEditor), undermines that unity and fractures the community. In other words, CommonLisp ought to subsume further development on other Lisp dialects--including Scheme. Nobody uses MacLisp any more for production code; nobody should use Scheme anymore either. If the Scheme community wishes to develop separately from the Lisp community and continue to be an actively-supported production language, they should do so without enjoying the benefits of association with Lisp, as they aren't contributing anymore. In other words, this argument is saying that "Lisp" is exactly "Common Lisp", anything else is excluded. (And since Common Lisp is unlikely to evolve in any substantial way, this means that Lisp is forever frozen at what CL is now.) ** The above might be the most fascist statement I have read on this wiki. --RobMandeville. * Conversely, SchemeLanguage is a better language foundation going forward--it's a cleaner, more orthogonal design, spared from the need to be compatible with now-archaic early dialects of LispLanguage. * The philosophies of the Lisp and Scheme communities have diverged quite a bit. SchemeLanguage focuses much more on FunctionalProgramming; CommonLisp on metaprogramming and multi-paradigm programming (especially OO with CommonLispObjectSystem). * The confusion between the two is mainly in the minds of laypersons, who think Lisp/Scheme is all about application of functions on lists, and little else. '''Arguments why it doesn't matter''' * The whole IsSchemeLisp argument is a pointless distraction, an unfortunate HolyWar waged by a small set of tool-worshippers, and a silly spat over who has "rights" to a coveted and desirable brand name. (Much like the debate over the DefinitionsForOo). Both CommonLisp and SchemeLanguage are excellent languages, insistence that one is deserving of the name "lisp" and the other is not (or insistence that both have equal rights to be called "lisp") is childish behavior. * It doesn't matter because having two high-quality, production-grade descendents of LispLanguage is ''better'' than having only one. There are problems more easily solved in CommonLisp than in SchemeLanguage and vice versa; the benefits of choice far outweigh the disadvantages of redundant/wasted development work on two incompatible platforms, and the associated splitting of mind and market share. ---- '''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 See LispSchemeDifferences. ---- [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