3 ms·

That may be so. It's a weird stance to take, though. CL has as little in common with McCarthy's Lisp as any of the other variations that descend from McCarthy's

That may be so. It's a weird stance to take, though. CL has as little in common with McCarthy's Lisp as any of the other variations that descend from McCarthy's Lisp. So at this point it's just a name, and I'm not sure what's to be gained even if CL somehow got everyone to agree they had sole ownership of the name.

lispm 12y ago
> CL has as little in common with McCarthy's Lisp as any of the other variations that descend from McCarthy's Lisp. That's not true. http://www.informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/wang.html http://www.informatimago.com/develop/lisp/com/informatimago/... McCarthy's implementation of Wang's algorithm from 1960. Run's unchanged in Common Lisp, with only very little support code. > CL somehow got everyone to agree they had sole ownership of the name. CL does not have the ownership of the name Lisp. But for many Lisp is like "German", a family of dialects which share literature, speech and an audience. Common Lisp is the main "German" dialect. Others are Emacs Lisp, ISLisp, Eulisp, XLisp, Franz Lisp, ... all those are closely related. Then Lisp is not "Germanic", which for example included English and German. English and German are Germanic languages, but they don't share literature, speech and the audience. Languages like Logo, Clojure, Newlisp and several others are 'lispy'. But they are not in any way compatible to Lisp. Porting a program means a full rewrite and re-architecture.
- copsarebastards 12y ago
  > McCarthy's implementation of Wang's algorithm from 1960. > Run's unchanged in Common Lisp, with only very little support code. Riiiiight, okay, so how difficult would it really be to change `defun trace (functions)` to `define (trace functions)` and a few other minor syntactic so it runs in Scheme? What you're saying is basically tantamount to a claim that CL has stayed truer to the syntax of McCarthy's Lisp, but it would be easy to argue that Scheme is truer to the mathematical principles of McCarthy's Lisp. Looking at syntax is a very shallow way to look at it. >> CL somehow got everyone to agree they had sole ownership of the name. > CL does not have the ownership of the name Lisp. I said "So at this point it's just a name, and I'm not sure what's to be gained even if CL somehow got everyone to agree they had sole ownership of the name." Please don't quote me out of context. The rest of your post is incoherent because you've used the isolated word "Lisp" despite the fact that this conversation is about the very fact that the meaning of "Lisp" is unclear. > Languages like Logo, Clojure, Newlisp and several others are 'lispy'. But they are not in any way compatible to Lisp. Porting a program means a full rewrite and re-architecture. Porting almost any CL program from CL to McCarthy's Lisp would require dropping most features. Hopefully this highlights the problem with this whole debate.
  - lispm 12y ago
    > Riiiiight, okay, so how difficult would it really be to change `defun trace (functions)` to `define (trace functions)` and a few other minor syntactic so it runs in Scheme? You can try it. Report back. Try also Logo, Dylan, Clojure, Newlisp and a bunch of other languages. > What you're saying is basically tantamount to a claim that CL has stayed truer to the syntax of McCarthy's Lisp, but it would be easy to argue that Scheme is truer to the mathematical principles of McCarthy's Lisp. You can try to argue that, but it would be wrong. McCarthy's Lisp uses Symbols, Functions and even EVAL quite different from Scheme. Scheme has done everything to remove EVAL. Look at various Scheme reports where EVAL is not even part of the language or defined as a 'library' function. > Looking at syntax is a very shallow way to look at it. If we only need to provide a little bit of syntactic support to make Lisp 1.5 code run in Common Lisp. What does it say? Most of the other stuff is intact: 90% of the syntax and a lot of semantics, naming, APIs, core principles. > The rest of your post is incoherent because you've used the isolated word "Lisp" despite the fact that this conversation is about the very fact that the meaning of "Lisp" is unclear. Maybe it's unclear for you. I told you what Lisp is: a group of languages who, evolve over time, share literature, community and code. People wrote compatibility packages and translators to make porting across these languages easier. Today it makes no sense to share software between Racket, Clojure and SBCL (a Common Lisp implementation). They are fully incompatible: semantics, names, architectures, tools, ... literally nothing is shared. > Porting almost any CL program from CL to McCarthy's Lisp would require dropping most features. Hopefully this highlights the problem with this whole debate. Time moves mostly in one direction. People wrote math software in Lisp 1.5, ported it to Maclisp, then Lisp Machine Lisp, then to various Common Lisp variants. Lisp code was written sometimes to work in older dialects too, but that support was usually dropped when the older implementation was no longer used. For example some people wrote software in Interlisp and ported it to Lisp Machine Lisp. Then Common Lisp. Then the Interlisp support was dropped. The Computer Algebra system Macsyma for example has bits implemented in old Lisp implementations from the 60s. It was then ported to Maclisp, Franz Lisp, Lisp Machine Lisp, Common Lisp. Each time the Lisp dialect was improved and extended. But many of the core principles remained. Some code ran in multiple Lisp dialects and was maintained in one file. The LOOP macro was for example inspired by Interlisp's FOR, was then implemented in Maclisp and then ported to Lisp Machine Lisp, NIL and Common Lisp. For several years it was maintained in one master file. A really hairy piece of code with lots of macrology.

lispm 12y ago

> CL has as little in common with McCarthy's Lisp as any of the other variations that descend from McCarthy's Lisp. That's not true. http://www.informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/wang.html http://www.informatimago.com/develop/lisp/com/informatimago/... McCarthy's implementation of Wang's algorithm from 1960. Run's unchanged in Common Lisp, with only very little support code. > CL somehow got everyone to agree they had sole ownership of the name. CL does not have the ownership of the name Lisp. But for many Lisp is like "German", a family of dialects which share literature, speech and an audience. Common Lisp is the main "German" dialect. Others are Emacs Lisp, ISLisp, Eulisp, XLisp, Franz Lisp, ... all those are closely related. Then Lisp is not "Germanic", which for example included English and German. English and German are Germanic languages, but they don't share literature, speech and the audience. Languages like Logo, Clojure, Newlisp and several others are 'lispy'. But they are not in any way compatible to Lisp. Porting a program means a full rewrite and re-architecture.

copsarebastards 12y ago
> McCarthy's implementation of Wang's algorithm from 1960. > Run's unchanged in Common Lisp, with only very little support code. Riiiiight, okay, so how difficult would it really be to change `defun trace (functions)` to `define (trace functions)` and a few other minor syntactic so it runs in Scheme? What you're saying is basically tantamount to a claim that CL has stayed truer to the syntax of McCarthy's Lisp, but it would be easy to argue that Scheme is truer to the mathematical principles of McCarthy's Lisp. Looking at syntax is a very shallow way to look at it. >> CL somehow got everyone to agree they had sole ownership of the name. > CL does not have the ownership of the name Lisp. I said "So at this point it's just a name, and I'm not sure what's to be gained even if CL somehow got everyone to agree they had sole ownership of the name." Please don't quote me out of context. The rest of your post is incoherent because you've used the isolated word "Lisp" despite the fact that this conversation is about the very fact that the meaning of "Lisp" is unclear. > Languages like Logo, Clojure, Newlisp and several others are 'lispy'. But they are not in any way compatible to Lisp. Porting a program means a full rewrite and re-architecture. Porting almost any CL program from CL to McCarthy's Lisp would require dropping most features. Hopefully this highlights the problem with this whole debate.
- lispm 12y ago
  > Riiiiight, okay, so how difficult would it really be to change `defun trace (functions)` to `define (trace functions)` and a few other minor syntactic so it runs in Scheme? You can try it. Report back. Try also Logo, Dylan, Clojure, Newlisp and a bunch of other languages. > What you're saying is basically tantamount to a claim that CL has stayed truer to the syntax of McCarthy's Lisp, but it would be easy to argue that Scheme is truer to the mathematical principles of McCarthy's Lisp. You can try to argue that, but it would be wrong. McCarthy's Lisp uses Symbols, Functions and even EVAL quite different from Scheme. Scheme has done everything to remove EVAL. Look at various Scheme reports where EVAL is not even part of the language or defined as a 'library' function. > Looking at syntax is a very shallow way to look at it. If we only need to provide a little bit of syntactic support to make Lisp 1.5 code run in Common Lisp. What does it say? Most of the other stuff is intact: 90% of the syntax and a lot of semantics, naming, APIs, core principles. > The rest of your post is incoherent because you've used the isolated word "Lisp" despite the fact that this conversation is about the very fact that the meaning of "Lisp" is unclear. Maybe it's unclear for you. I told you what Lisp is: a group of languages who, evolve over time, share literature, community and code. People wrote compatibility packages and translators to make porting across these languages easier. Today it makes no sense to share software between Racket, Clojure and SBCL (a Common Lisp implementation). They are fully incompatible: semantics, names, architectures, tools, ... literally nothing is shared. > Porting almost any CL program from CL to McCarthy's Lisp would require dropping most features. Hopefully this highlights the problem with this whole debate. Time moves mostly in one direction. People wrote math software in Lisp 1.5, ported it to Maclisp, then Lisp Machine Lisp, then to various Common Lisp variants. Lisp code was written sometimes to work in older dialects too, but that support was usually dropped when the older implementation was no longer used. For example some people wrote software in Interlisp and ported it to Lisp Machine Lisp. Then Common Lisp. Then the Interlisp support was dropped. The Computer Algebra system Macsyma for example has bits implemented in old Lisp implementations from the 60s. It was then ported to Maclisp, Franz Lisp, Lisp Machine Lisp, Common Lisp. Each time the Lisp dialect was improved and extended. But many of the core principles remained. Some code ran in multiple Lisp dialects and was maintained in one file. The LOOP macro was for example inspired by Interlisp's FOR, was then implemented in Maclisp and then ported to Lisp Machine Lisp, NIL and Common Lisp. For several years it was maintained in one master file. A really hairy piece of code with lots of macrology.