4 ms·

I don't get the point... ANSI Common Lisp is a standard. Of which there are many implementations. I was expecting a post about how far the different implementat

I don't get the point... ANSI Common Lisp is a standard. Of which there are many implementations. I was expecting a post about how far the different implementations have diverged from the standard. Perhaps some of them have begun to create their own language. But no, this post is enumerating different features of the standard? And how you can write the same program different ways using them? And then Clojure? Is the point that the language standard has too many ways of writing programs? Interesting pull-quote about C++ at the beginning. I do wonder if there are compliant implementations of the standard across different compilers that behave the same way but are semantically different (or the other way around). The standard is about 1.2k pages longer than ANSI CL or there about. Hard work proving your compiler is compliant across the whole spec.

Guthur 2y ago
I think the point, the author maybe didn't intend it as such, is that Lisp generally encourages the creation of many domain specific languages. You have the tools to fundamental define completely new language abstractions that feel very much like first class constructs both syntactic and procedural. The comment about C++ is probably mostly for the edge factor but if i was to try to delineate what is different about C++ melting pot vs Common Lisp it would probably be the homoiconicity of CL which for the most part allows far more seamless integration at the syntactic level whereas C++ is required to include an ever increasing and bewildering array of differing syntax constructs.
veqq 2y ago
CL has many DSLs built in like the loop macro's language. Language oriented programming's the key lispy approach (e.g. in PAIP or Beautiful Racket), and this is already seen in the standard itself (for better or for worse.)
aartaka 2y ago
> I was expecting a post about how far the different implementations have diverged from the standard. Perhaps some of them have begun to create their own language. That would be a boring one, actually. Most implementations stick to the standard (and for good), only adding features clearly missing from the standard. And these features are also quite community-approved, with something like Trivial Gray Streams, Bordeaux Threads and other portability libraries being de-facto standard libraries working on almost all implementations. One exception to this would be Allegro CL. It has such a huge ecosystem that one can easily lock themselves in there and write the kind of Allegro Lisp dialect. But that's rather and exception than the rule.
- lispm 2y ago
  The "standard" has a huge amount of undefined behavior and also defined unspecified behavior. For example for everything "system class" it is undefined how this thing is implemented - there is an API specified. An example is the condition system: it is not required that a condition is a CLOS object. There is also a bunch of things which can be implemented or ignored. It is fully standards conforming to ignore all type declarations. About some central Lisp features, there is nothing in the standard. Garbage Collection is such a thing. The standard does not even mention it, thus it is also not requiring it. It says nothing about invoking a GC or an interface to the GC. It's also not forbidden to define subsets of the standard. For example there were several implementations of CL to C compilers developed, which lack a lot of dynamic behavior at runtime. L is a subset for embedded systems. SubL is a variant used to program Cyc. CLICC was used to compile the applications of the expert system shell Babylon to C. Then there are implementations with large sets of extensions to the standard: streams in CLOS, conditions in CLOS, hash tables with various extensions, various extensions to TRACE and STEP, MOP for CLOS, ... So there is a range from a primitive CL (implementing only the minimum requirements) to a fully CLOS-based CL with lots of extensions. In between are exotic & large implementations like Genera, where parts are written in Flavors, for example there are several dozen PATHNAME (for UNIX, Mac, DOS, VMS, ... pathnames) classes, which are implemented in Flavors and where (pathname ...) has parsers for various filesystems. SBCL devs have also experimented with extensions like extensible sequences.

Guthur 2y ago

I think the point, the author maybe didn't intend it as such, is that Lisp generally encourages the creation of many domain specific languages. You have the tools to fundamental define completely new language abstractions that feel very much like first class constructs both syntactic and procedural. The comment about C++ is probably mostly for the edge factor but if i was to try to delineate what is different about C++ melting pot vs Common Lisp it would probably be the homoiconicity of CL which for the most part allows far more seamless integration at the syntactic level whereas C++ is required to include an ever increasing and bewildering array of differing syntax constructs.

veqq 2y ago

CL has many DSLs built in like the loop macro's language. Language oriented programming's the key lispy approach (e.g. in PAIP or Beautiful Racket), and this is already seen in the standard itself (for better or for worse.)

aartaka 2y ago

> I was expecting a post about how far the different implementations have diverged from the standard. Perhaps some of them have begun to create their own language. That would be a boring one, actually. Most implementations stick to the standard (and for good), only adding features clearly missing from the standard. And these features are also quite community-approved, with something like Trivial Gray Streams, Bordeaux Threads and other portability libraries being de-facto standard libraries working on almost all implementations. One exception to this would be Allegro CL. It has such a huge ecosystem that one can easily lock themselves in there and write the kind of Allegro Lisp dialect. But that's rather and exception than the rule.

lispm 2y ago
The "standard" has a huge amount of undefined behavior and also defined unspecified behavior. For example for everything "system class" it is undefined how this thing is implemented - there is an API specified. An example is the condition system: it is not required that a condition is a CLOS object. There is also a bunch of things which can be implemented or ignored. It is fully standards conforming to ignore all type declarations. About some central Lisp features, there is nothing in the standard. Garbage Collection is such a thing. The standard does not even mention it, thus it is also not requiring it. It says nothing about invoking a GC or an interface to the GC. It's also not forbidden to define subsets of the standard. For example there were several implementations of CL to C compilers developed, which lack a lot of dynamic behavior at runtime. L is a subset for embedded systems. SubL is a variant used to program Cyc. CLICC was used to compile the applications of the expert system shell Babylon to C. Then there are implementations with large sets of extensions to the standard: streams in CLOS, conditions in CLOS, hash tables with various extensions, various extensions to TRACE and STEP, MOP for CLOS, ... So there is a range from a primitive CL (implementing only the minimum requirements) to a fully CLOS-based CL with lots of extensions. In between are exotic & large implementations like Genera, where parts are written in Flavors, for example there are several dozen PATHNAME (for UNIX, Mac, DOS, VMS, ... pathnames) classes, which are implemented in Flavors and where (pathname ...) has parsers for various filesystems. SBCL devs have also experimented with extensions like extensible sequences.