4 ms·

Maclisp came from Lisp 1.5. Code was simply ported to Maclisp. Some Lisp 1.5 code runs mostly unchanged in CL. Maclisp shared code with Common Lisp. For a lot

by lispm 10y ago

Maclisp came from Lisp 1.5. Code was simply ported to Maclisp. Some Lisp 1.5 code runs mostly unchanged in CL. Maclisp shared code with Common Lisp. For a lot of stuff there was a single code base at MIT for several Lisp dialects, including Maclisp. After some time Maclisp development ended and sharing ended. For example the source code for the complex LOOP macro was at one time a single file for Maclisp, NIL, Lisp Machine Lisp and Common Lisp. People ported programs from Maclisp to CL by changing them or by translating them with tools, not by rewriting them. There were also code bases which worked both in early Scheme and CL. Emacs Lisp has a huge CL subset and even includes a version of CLOS. Since both Emacs Lisp and Common Lisp are coming from Maclisp, both languages are very similar anyway. Basic operators are the same, differing in various details - like dialects often do. Common Lisp had Interlisp compatibility packages, while Interlisp was still used. There were translators, too. Xerox had Interlisp and Common Lisp integrated in one Lisp. Kent Pitman wrote an ISLISP compatibility package for Common Lisp. There are compatibility packages for Portable Standard Lisp, which allow the unchanged use of PSL code in Common Lisp. etc etc There is zero code sharing between Lisp, Clojure and Racket. Compatibility with the Lisp 1, Lisp 1.5, Maclisp, Common Lisp, Emacs Lisp, CL, ISLISP, main line of Lisp wasn't a goal for Clojure and Racket. That's fine. They got rid of historical baggage and could design new languages. Basic rule: if a language has LISP in its name, there is some chance that it actually is a LISP. People usually name their language LISP something, to give the impression that the language is compatible with Lisp. They use different names, when the language is different: Scheme, Javascript, Logo, Dylan, Clojure, ... Take a Lisp 1.5 manual, look at the function index and check which functions and special forms are provided. If most of those are absent (or doing something different), it's not a Lisp: append, atom, car, cdr, cond, cons, eq, eval, intern, list, load, map, member, pair, print, read, prog, quote, reverse, return, set, setq, trace, ...

qwertyuiop924 10y ago
Most of those things appear in scheme. Slightly different naming, but the same, more or less. To say that there's compatability between Scheme and CL, and no compatability with Racket is ridiculus: Racket has Scheme compatability modes. As for the language being called Lisp if it's Lisp, two of the examples you list in the "non lisp" category do so: Clojure's website claims it is a "dialect of lisp," and AIM-349 describes scheme as "essentially a full-funarg LISP." As make no mistake, all of these languages, from Common Lisp to Clojure to Scheme, are dialects. They have the same origins, and they share many of the same ideas.
- lispm 10y ago
  > AIM-349 describes scheme as "essentially a full-funarg LISP That's long ago. That was kind of true in the mid 70s. > and no compatability with Racket is ridiculus CL has no Racket compatibility. Zero. Racket has no CL compatibility. Zero. Porting programs is a full rewrite. > Clojure's website claims it is a "dialect of lisp," Best it is a new language, derived from Lisp and influenced by C++, C#, Common Lisp, Erlang, Haskell, Mathematica, ML, Prolog, Scheme, Java, Racket, Ruby. 'Dialect' in this case is the euphemism for 'fully incompatible' with 'random operator renames and shuffling functionality' where it kind of looked compatible. > As make no mistake, all of these languages, from Common Lisp to Clojure to Scheme, are dialects. Sure, but not of Lisp. Of those three, only Common Lisp is a Lisp dialect. > They have the same origins, and they share many of the same ideas. Less and less. As a starter: Clojure has no Lisp lists as basic data structure.
  - qwertyuiop924 10y ago
    So scheme WAS a lisp, and now isn't? What changed that makes you think that? And it had better not be nil/false equality. Even McCarthy says that was, if not a mistake, then an accident. As for Clojure not having Lisp lists, its list implementation is... eccentric, but it DOES have lists. Actually, scratch that, its list implementation, from a Lisp perspective is broken. Psychotically broken. But it DOES have one. Even if it's insane. What, will you say the same about newlisp lists? For that matter, is Picolisp a Lisp?
    - kazinator 10y ago
      > So scheme WAS a lisp, and now isn't? EINE: Eine is not Emacs. ZWEI: Zwei was Eine, Initially. And, thus: SWALANI: Swalani Was A Lisp, And Now Isn't. A dialect waiting to be invented. :) What might be a recursive acronym for Scheme, though? Oh, oh ... I just got one: "Scheme Crams Hygiene into Every Macro Expansion."
      - qwertyuiop924 10y ago
        It doesn't, for the record. Not any implementation that you'd use. The acronym's good though, I just didn't want anybody else thinking that was true, given how many people already do.
gkya 10y ago
What is the point of this genealogy? What makes a language a Lisp is (i) natural and practical homoiconicity with sexps, (ii) automatic memory management and (iii) advanced interactive development features, including the REPL, the image, restarts and hot code loading. These are the features that distinguish it and make it an advanced tool. (i) is quite particular to it, (ii) is invented for it and (iii) is a big part of the power, and for me, Lisp means a language that has (i), (ii) and (iii) in one package. Otherwise whether or not it include code from Lisp 1.5 or allow effortless porting is not all that important. For the latter, most compilers are cross-platform anyways, so one can just grab a suitable binary tarball and get going. Clojure fails at (iii), as it just propagates Java exceptions, but I don't think that is impossible to fix, so not a fundamental flaw. JVM is too heavy, and that is a problem for some. Otherwise, it's a well thought-out Lisp with a thriving community and some cool guys and a BDFL (i.e. Hickey). Common Lisp excels at all the three of the items I listed, plus it's batteries included and has lots of libraries around. Also, it has a standard, so that you can develop on SBCL and deploy with Clozure CL or CMU CL. It's downside is there's some historical baggage and there are no DHH or Hickey or Torvalds in the community, which isn't a downside for me, even an upside.
- lispm 10y ago
  Clojure has a primitive repl by default with lots of Java shining through. It has no image dumping. No restarts. Hot code loading is limited. Clojure even has no interpreter.
  - qwertyuiop924 10y ago
    Need I mention that Lisp 1.5 had no restarts, and that image dumps are primarily a hack, and not at the core of lisp by a long shot?
    - lispm 10y ago
      Images are not a hack. They allow us to save the state of a program and use it later. My Lisp Machine at home would not even work without it. It's the software the machine boots into. Image dumps are also a useful way to create applications or use pre-assembled program state during development. Makes faster startup times, than loading objects during start each time. Even an editor like GNU Emacs boots up a Lisp image. Which makes it much faster than loading code at start.

by lispm 10y ago

qwertyuiop924 10y ago

Most of those things appear in scheme. Slightly different naming, but the same, more or less. To say that there's compatability between Scheme and CL, and no compatability with Racket is ridiculus: Racket has Scheme compatability modes. As for the language being called Lisp if it's Lisp, two of the examples you list in the "non lisp" category do so: Clojure's website claims it is a "dialect of lisp," and AIM-349 describes scheme as "essentially a full-funarg LISP." As make no mistake, all of these languages, from Common Lisp to Clojure to Scheme, are dialects. They have the same origins, and they share many of the same ideas.

lispm 10y ago
> AIM-349 describes scheme as "essentially a full-funarg LISP That's long ago. That was kind of true in the mid 70s. > and no compatability with Racket is ridiculus CL has no Racket compatibility. Zero. Racket has no CL compatibility. Zero. Porting programs is a full rewrite. > Clojure's website claims it is a "dialect of lisp," Best it is a new language, derived from Lisp and influenced by C++, C#, Common Lisp, Erlang, Haskell, Mathematica, ML, Prolog, Scheme, Java, Racket, Ruby. 'Dialect' in this case is the euphemism for 'fully incompatible' with 'random operator renames and shuffling functionality' where it kind of looked compatible. > As make no mistake, all of these languages, from Common Lisp to Clojure to Scheme, are dialects. Sure, but not of Lisp. Of those three, only Common Lisp is a Lisp dialect. > They have the same origins, and they share many of the same ideas. Less and less. As a starter: Clojure has no Lisp lists as basic data structure.
- qwertyuiop924 10y ago
  So scheme WAS a lisp, and now isn't? What changed that makes you think that? And it had better not be nil/false equality. Even McCarthy says that was, if not a mistake, then an accident. As for Clojure not having Lisp lists, its list implementation is... eccentric, but it DOES have lists. Actually, scratch that, its list implementation, from a Lisp perspective is broken. Psychotically broken. But it DOES have one. Even if it's insane. What, will you say the same about newlisp lists? For that matter, is Picolisp a Lisp?
  - kazinator 10y ago
    > So scheme WAS a lisp, and now isn't? EINE: Eine is not Emacs. ZWEI: Zwei was Eine, Initially. And, thus: SWALANI: Swalani Was A Lisp, And Now Isn't. A dialect waiting to be invented. :) What might be a recursive acronym for Scheme, though? Oh, oh ... I just got one: "Scheme Crams Hygiene into Every Macro Expansion."
    - qwertyuiop924 10y ago
      It doesn't, for the record. Not any implementation that you'd use. The acronym's good though, I just didn't want anybody else thinking that was true, given how many people already do.

gkya 10y ago

What is the point of this genealogy? What makes a language a Lisp is (i) natural and practical homoiconicity with sexps, (ii) automatic memory management and (iii) advanced interactive development features, including the REPL, the image, restarts and hot code loading. These are the features that distinguish it and make it an advanced tool. (i) is quite particular to it, (ii) is invented for it and (iii) is a big part of the power, and for me, Lisp means a language that has (i), (ii) and (iii) in one package. Otherwise whether or not it include code from Lisp 1.5 or allow effortless porting is not all that important. For the latter, most compilers are cross-platform anyways, so one can just grab a suitable binary tarball and get going. Clojure fails at (iii), as it just propagates Java exceptions, but I don't think that is impossible to fix, so not a fundamental flaw. JVM is too heavy, and that is a problem for some. Otherwise, it's a well thought-out Lisp with a thriving community and some cool guys and a BDFL (i.e. Hickey). Common Lisp excels at all the three of the items I listed, plus it's batteries included and has lots of libraries around. Also, it has a standard, so that you can develop on SBCL and deploy with Clozure CL or CMU CL. It's downside is there's some historical baggage and there are no DHH or Hickey or Torvalds in the community, which isn't a downside for me, even an upside.

lispm 10y ago
Clojure has a primitive repl by default with lots of Java shining through. It has no image dumping. No restarts. Hot code loading is limited. Clojure even has no interpreter.
- qwertyuiop924 10y ago
  Need I mention that Lisp 1.5 had no restarts, and that image dumps are primarily a hack, and not at the core of lisp by a long shot?
  - lispm 10y ago
    Images are not a hack. They allow us to save the state of a program and use it later. My Lisp Machine at home would not even work without it. It's the software the machine boots into. Image dumps are also a useful way to create applications or use pre-assembled program state during development. Makes faster startup times, than loading objects during start each time. Even an editor like GNU Emacs boots up a Lisp image. Which makes it much faster than loading code at start.