That is true, but to engage in a bit of semiotics: those cores are hardly the most appealing part of Lisp for most of the uses cases it's found. It certainly was one way to enable the interactivity and homoiconicty and metacircularity, but, as Clojure and Janet demonstrate, there are a lot of other aspects of Lisp that have value. And while one could (and some have, IIRC) built a Lisp on those minimal data structures that doesn't have parens, most people associate Lips with them being in the strange place.
Cons/car/cdr are far less important, IMO, than eval.
Read, on the other hand, is also technically missing from Janet, and I personally don't mind a great deal, but I could see that being argued.
One of the inventions of McCarthy (and team) was that EVAL can be defined in the core language itself (!) and thus serve as a relatively simple model of computation. Thus the particular EVAL is important, not that source code can be executed at runtime by some api call to execute code.
That's part of the core of the language.
Sure: Many other aspects from Lisp can be found also in Lisp-derived languages and other languages. Like all or some of runtime code loading, symbolic expressions, using symbolic expressions to encode source code, saving and starting heap images, garbage collection, managed memory, source level interpreters/debuggers, self-hosted compilers, read-eval-print-loops, macros, fexprs, integrated interactive development environments, ...
That specific formalism is only specific to McCarthy's implementation though, not even CL counts, as it greatly expands and derives beyond it.
Even McCarthy's lisp had iterations of itself.
Personally, I think the second paper actually points to the essential component for me:
LISP data are symbolic expressions that can be either atoms or lists. Atoms are strings of letters and digits and other characters not otherwise used in LISP. A list consists of a left parenthesis followed by zero or more atoms or lists separated by spaces and ending with a right parenthesis. The LISP programming language is defined by rules
whereby certain LISP expressions have other LISP expressions as
values.
I would use that to generalize to a family of languages like so:
"""
A Lisp language consists of:
1) Some data representation which are symbolic expressions that can be either atoms or lists. Atoms are strings of letters and digits and other characters not otherwise used in the given Lisp language. A list consists of a starting character (commonly left parentheses) followed by zero or more atoms or lists separated by seperator characters (commonly spaces) and ending with a terminating character (commonly right parenthesis).
2) A programming language whose code uses that data representation and is defined by rules
whereby certain Lisp expressions have other Lisp expressions as
values.
"""
Personally I think that's the key aspect, the characteristics of what those rules are, and what the chosen characters are is what creates the family of language, they are the parameters you're allowed to change and must change for it to be a dialect and not just an alternate implementation of the same language.
That specific formalism is only specific to McCarthy's implementation though,
Not even that. It's the programmatic definition of the core of Lisp. McCarthy's real Lisp implementation was much more featureful.
I would also think the Lisp program in the second paper is 'Lisp Program Zero'. ;-) If your language can run it, it is Lisp. The amount of modifications necessary (syntactic, operators, semantics, ...) gives an indication how far another language is away from it.
Comments
What's a list though? Why should it refer specifically to the concrete implementation?
Lists in a conceptual sense are an ordered collection of heterogeneous elements with nestings.
In that sense, code in Janet is very much represented as such and processed as such. Which in my mind makes it a LISt Processing language :p
Lisp is does not stand for generic 'List Processing', but for 'List Processor' -> a specific formalism to process lists.
There is a specific minimal core of Lisp, which consists of a certain minimal set of data structures, operations and an evaluation mechanism.
An early version is described here:
https://dspace.mit.edu/bitstream/handle/1721.1/6096/AIM-008....
Another one is described here:
https://www.ee.ryerson.ca/~elf/pub/misc/micromanualLISP.pdf
That is true, but to engage in a bit of semiotics: those cores are hardly the most appealing part of Lisp for most of the uses cases it's found. It certainly was one way to enable the interactivity and homoiconicty and metacircularity, but, as Clojure and Janet demonstrate, there are a lot of other aspects of Lisp that have value. And while one could (and some have, IIRC) built a Lisp on those minimal data structures that doesn't have parens, most people associate Lips with them being in the strange place.
Cons/car/cdr are far less important, IMO, than eval.
Read, on the other hand, is also technically missing from Janet, and I personally don't mind a great deal, but I could see that being argued.
One of the inventions of McCarthy (and team) was that EVAL can be defined in the core language itself (!) and thus serve as a relatively simple model of computation. Thus the particular EVAL is important, not that source code can be executed at runtime by some api call to execute code.
That's part of the core of the language.
Sure: Many other aspects from Lisp can be found also in Lisp-derived languages and other languages. Like all or some of runtime code loading, symbolic expressions, using symbolic expressions to encode source code, saving and starting heap images, garbage collection, managed memory, source level interpreters/debuggers, self-hosted compilers, read-eval-print-loops, macros, fexprs, integrated interactive development environments, ...
That specific formalism is only specific to McCarthy's implementation though, not even CL counts, as it greatly expands and derives beyond it.
Even McCarthy's lisp had iterations of itself.
Personally, I think the second paper actually points to the essential component for me:
I would use that to generalize to a family of languages like so:
""" A Lisp language consists of:
1) Some data representation which are symbolic expressions that can be either atoms or lists. Atoms are strings of letters and digits and other characters not otherwise used in the given Lisp language. A list consists of a starting character (commonly left parentheses) followed by zero or more atoms or lists separated by seperator characters (commonly spaces) and ending with a terminating character (commonly right parenthesis).
2) A programming language whose code uses that data representation and is defined by rules whereby certain Lisp expressions have other Lisp expressions as values. """
Personally I think that's the key aspect, the characteristics of what those rules are, and what the chosen characters are is what creates the family of language, they are the parameters you're allowed to change and must change for it to be a dialect and not just an alternate implementation of the same language.
Not even that. It's the programmatic definition of the core of Lisp. McCarthy's real Lisp implementation was much more featureful.
I would also think the Lisp program in the second paper is 'Lisp Program Zero'. ;-) If your language can run it, it is Lisp. The amount of modifications necessary (syntactic, operators, semantics, ...) gives an indication how far another language is away from it.
Here is a version in Common Lisp:
https://gist.github.com/lispm/d752d5761f7078de4041d4e453e70c...