5 ms·

> 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 diffi

> 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.
- copsarebastards 12y ago
  > 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. Okay, so ignoring the fact that this definition is so vague it could apply to C, C++, and Objective-C, can we agree that this is entirely your opinion and is obviously not shared by Scheme users? Can we agree that the meaning of words is determined by usage and not everyone uses the word your way? > Time moves mostly in one direction. Thank you obviousman. Look, the core of what I'm saying is that words can mean more than one thing. The fact is, the word "Lisp" is overloaded. Maybe it isn't overloaded in your little insular community, but that doesn't mean other people's usage of the term is wrong, and there's it's both pointless and rude to try to force other people to use your jargon.
  - lispm 12y ago
    > C, C++, and Objective-C Notice the use of 'C' in the names of the languages? Its because they all belong to a C family which shares code. Just like Lisp languages. Wikipedia: "Objective-C is a thin layer on top of C, and is often called a "strict superset" of C" "The C and C++ programming languages are closely related. C++ grew out of C, as it was designed to be source-and-link compatible with C" Emacs Lisp contains many Common Lisp functions and there is even an implementation of Common Lisp integrated into Emacs Lisp: http://www.emacswiki.org/emacs/EmacsCommonLisp http://www.emacswiki.org/emacs/EmacsCommonLisp Emacs Lisp grew out of Maclisp, just like Common Lisp. ISLisp is largely a subset of Common Lisp. For example the Gabriel benchmarks for Common Lisp have been used in ISLisp and they work with only minor changes.

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.

copsarebastards 12y ago
> 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. Okay, so ignoring the fact that this definition is so vague it could apply to C, C++, and Objective-C, can we agree that this is entirely your opinion and is obviously not shared by Scheme users? Can we agree that the meaning of words is determined by usage and not everyone uses the word your way? > Time moves mostly in one direction. Thank you obviousman. Look, the core of what I'm saying is that words can mean more than one thing. The fact is, the word "Lisp" is overloaded. Maybe it isn't overloaded in your little insular community, but that doesn't mean other people's usage of the term is wrong, and there's it's both pointless and rude to try to force other people to use your jargon.
- lispm 12y ago
  > C, C++, and Objective-C Notice the use of 'C' in the names of the languages? Its because they all belong to a C family which shares code. Just like Lisp languages. Wikipedia: "Objective-C is a thin layer on top of C, and is often called a "strict superset" of C" "The C and C++ programming languages are closely related. C++ grew out of C, as it was designed to be source-and-link compatible with C" Emacs Lisp contains many Common Lisp functions and there is even an implementation of Common Lisp integrated into Emacs Lisp: http://www.emacswiki.org/emacs/EmacsCommonLisp http://www.emacswiki.org/emacs/EmacsCommonLisp Emacs Lisp grew out of Maclisp, just like Common Lisp. ISLisp is largely a subset of Common Lisp. For example the Gabriel benchmarks for Common Lisp have been used in ISLisp and they work with only minor changes.