Lisp Family

Originally, the term Lisp referred to the language which was the brainchild of JohnMcCarthy.

Nowadays, when unspecified, the term Lisp either refers to CommonLisp (a language), or the Lisp family of languages, all of which share the LambdaNature (see LanguageFamilies).

A less strict criterion for inclusion of a language into the LispFamily is the use of parenthesized lists to represent a program, and manipulation of lists made of two-field cells that can be manufactured and connected by a function called CONS (see ConsCells). It's somewhat of a custom that whenever someone writes a one-weekend interpreter for such a language, it is given a name that includes the word "Lisp". (Never heard of that - where is that?) Much newbie confusion arises from all of the different things that are called Lisp but have nothing to do with the mature, complex, super-powerful CommonLisp, which, as the result of the combined efforts of the dominating lisp communities, is seen by many as the only thing that should be called Lisp (see TheEvolutionOfLisp).

'SEXP-Syntax is neither sufficient nor necessary' for a Lisp dialect.

The sharing of the CONS function is something I borrowed from a paper by KentPitman? in which he tries to pin down what exactly makes something Lisp. (See http://www.nhplace.com/kent/PS/Lambda.html. Also see ParentheticallySpeaking.) There, he also argues that there is no lambda commonality among things calling themselves Lisp; the syntax varies - some things don't have lexical closures, others closures that can only be passed down, not returned, etc. LambdaNature cannot exist without lexical scoping, so that the LambdaExpression creates a function-object that has captured the lexical bindings.

But note that I disagree with this paper on the whole; Pitman believes that there is a LispFamily, but that it arises out of some vague cultural connections rather than any specific language features. I view myself strictly as a CommonLisp user, and nothing more. I stay away from anything else that resembles Lisp, and don't feel that I belong to any broader community. Communities based on sharing a programming language are a fiction. Two people who don't know each other at all, but just happen to use the same programming language, text editor, operating system or whatever, are not automatically a community! That they can be is just some touchy-feely thinking thinking that might be called TechnoCollectivism?. Or maybe it's a spinoff idea from BrandIdentification? that westerners grow up with. If you drive a certain make of car, you are suddenly a member of the group of people who drive that car, and somehow this is more than just a dry mathematical observation that places you in a set. But really, to have a community, you must have a group of individuals who identify together in some concrete way, and actually know and recognize each other. I might form a community with some CL users, but not all of them at once!

PaulGraham provides another reasoning what defines Lisp. See http://www.paulgraham.com/diff.html

GeraldSussman and GuySteele named their dialect Scheme at a time when it was fashionable to give each Lisp dialect their own name (MDL, T, NIL, Conniver, and so on). Note that in the original papers about Scheme, Scheme is always described as a Lisp dialect. Further note that today's Scheme looks remarkably different to the original Scheme. Further further note, that the original Lisp didn't have lexical closures but that they were introduced in a clean way in Scheme. The CommonLisp designers have taken the LexicalClosure concept from Scheme. (In turn, lexical closures were first defined in AlgolLanguage.)

There are many reasons why to prefer CommonLisp over SchemeLanguage (see LispSchemeDifferences), and vice-versa, but to describe Scheme as not being a Lisp is as simplistic as to say that Scheme and Lisp are more or less the same. The truth is somewhere in between.

I wouldn't care if the Scheme people take over the word Lisp, and the CommonLisp people then rename their language and stop using the word. The point is that the term is simply too diluted when it takes on too many meanings, and as such it has little value. We can't even agree on what Lisp means; so maybe there is no point in using this word? Yet somehow it seems so coveted that people get ruffled when someone dares suggest that their pet language is not Lisp. Maybe "Lisp" is just a synonym for "cool". So if you say that some language is not Lisp, you are really saying that it's not cool. Also, because "cool" is hard to define, "Lisp" is hard to define. Moreover, things that are obviously not Lisp at all are clearly uncool. I can't think of a single counterexample when "Lisp" does not mean "cool", except when it's used in the name of some concrete language or implementation. AutoLISP doesn't mean AutoCOOL, and Common Lisp doesn't mean Common Cool. But as an adjective, to say that something is Lisp simply means that it has hacker approval.

Okay, so how about this: Lisp as an adjective means "cool". Lisp as a noun that is part of a noun phrase designating a programming language adds the semantic attribute "language derived from cool ideas". And used entirely by itself, in the absence of historic context, it means "ANSI Common Lisp", where this second occurrence of Lisp is not subject to the cool-substitution, but simply stands for itself. In some proper historic context it means "the language invented by JohnMcCarthy and peers". There, it's settled!

So, Lisp == cool? I thought that CsharpLanguage == cool! By transitivity, this implies that Lisp == C#

Amazing. And all this time I had thought that C#/DotNet was little more than a blatant ripoff of Java (both the language and the platform)! Now we find it's really Lisp in disguise!

So, then why doesn't C# have EssExpressions?

Ah, I think your "==" operator means, in this context, "is a member of the set".

No, "==" means equality. The development codename for the C# project at Microsoft was "Cool", one of the worst-kept secrets of the past couple years. The rest of the above section is tongue-in-cheek

So... when do you think we will see MicrosoftVisualLisp? (or, for that matter, VisualLispDotNet??????) What will the LispHippies do if their favorite language is taken over by the EvilEmpire?? I guess it would make writing macros in MicrosoftExcel more fun!

-- ScottJohnson

Well, long, long ago, there was already an MS Lisp... http://groups.google.com/groups?q=microsoft+lisp&ie=ISO-8859-1&hl=en

There is a Visual Lisp product from Autodesk for use with its popular AutoCAD software. Not surprisingly, the appearance of Visual Lisp coincided with the full-scale conversion of AutoCAD from a cross-platform tool into an application deeply rooted in, and heavily dependent on, the Windows environment (with ActiveX, etc.). -- JeffRead

A few things that might define some core of Lisp dialects and their typical implementation:

Scheme extends this list by: Common Lisp extends the list by too many things to list: Let's look at Dylan (the later Dylan): Dylan lacks (despite its name) as a language the dynamic nature of the environment (though implementations are providing it as an addition): no read-eval-print-loop, no image-based development, no runtime code generation and no loading, ... Dylan also lacks the S-Expression syntax (the earlier Dylan version had it).

What do you consider the boundary between early-Dylan and late-Dylan? The switch to misfix syntax, or the demise of AppleDylan?? AFAIK, the original AppleDylan? had image-based development and a REPL loop. GwydionDylan lacked it because the Gwydion implementation was incomplete (funding pulled), but the original intent of the Gwydion project was to develop a state-of-the-art IDE that most likely would've included those features. Recent versions (2.3.10 and up) have added a REPL anyway. -- JonathanTang

Generally I see Dylan as a language with several implementations. There were implementations of both versions of the language (early Dylan was more Lisp-like, late Dylan was more static with a different syntax).

Early Dylan was a OODL (Object-oriented dynamic language). Basically, it was Scheme-like with the CLOS object-system (plus conditions, ...). The later Dylan was more concerned with efficient compilation and a mixfix (infix/prefix) syntax. It was also in many respects quite similar in spirit to EuLisp? (an European attempt at an efficient and modern Lisp). Though I would say that Dylan is smaller and more monolithic than EuLisp?. But EuLisp? was the much better Lisp - compared to Dylan. As a Lisp programmer I liked the earlier version more - but Lisp programmers were not the target audience.

The AppleDylan? development environment was a bit unusual for an integrated Lisp system. (btw., It was not written in Dylan, but Common Lisp) Typically it had the source stored in a database and had remote connections to running Dylan applications. Though the GUI builder was written in Dylan and was running inside the remote Dylan application. So it is a bit similar in spirit (remote Lisp controlled by a foreign IDE) with Emacs-based IDEs for Common Lisp. Many Common Lisp IDEs are running inside the same image like the applications they are used to develop. One exception is CMUCL/Hemlock. There also is the idea of some 'slave' Lisp. I would say that the AppleDylan? environment was not very typical for a Lisp-based development environment - though it was a logical step from earlier systems.

The Gwydion team start with bold ideas of a novel programming environment. But they never got far in that direction. They were mostly busy implementing the language. For quite some time.

CategoryLisp

EditText of this page (last edited July 21, 2014) or FindPage with title or text search