3 ms·

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

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

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.