Some questions about the CL

[Scott L. Burson]

Agreed.  Common Lisp is extremely extensible; almost any language feature
you could want can be layered on as a library.  I'll offer FSet, my
functional collections library, as an example.  Functional collections were
hardly known at the time of CL's creation -- SETL is the only language I
know of that had them back then -- but I was able to graft them onto CL.
Admittedly it took some thought and a few compromises, but the result is
entirely usable.

(A functional collection type is one where each instance is immutable, but
there are efficient operators to produce new instances from existing ones,
e.g. by adding a new element to a set.)

>From time to time I have thought that it would be nice to have a new
version of CL without the historical warts (why is there no 'e' in
'makunbound'?), but that line of thinking inevitably leads to the
conclusion that if I really want that, I should just make it a CL library.
If it were a new, incompatible language, it wouldn't be able to run
existing CL code, which would make it fairly useless even to me.  And if it
were CL-compatible, it wouldn't be any different from just a library on top
of CL.

The only exceptions would be features that require deep implementation
support.  Multithreading is the most obvious example; it's not in the spec,
but the major implementations added it years ago, and although their APIs
aren't the same, there's a library that papers over the differences.
High-performance firstclass continuations are the only such feature I can
think of that hasn't been implemented, and there are very few applications
that need those -- the only one I know of is a theorem prover I'm working
on.

-- Scott


On Mon, Feb 20, 2023, 4:44 AM Michał "phoe" Herda <phoe at disroot.org> wrote:

> 1a) If you mean the implementations, these get regular maintenance,
> releases, and support.
>
> 1b) If you mean the standard/specification, there's no one to update it
> - writing a new specification like that would mean a lot of time and
> costs and people.
>
> 1c) But updating the spec is still the *easy* part - getting *adoption*
> is the hard part. And there is very little practical need to adopt a new
> version of Common Lisp, since ANSI CL survived the test of time rather
> well. Adopting a new language revision would mean updating all the CL
> code for a new version, and that would take a lot of work that hardly
> anyone would be willing to perform.
>
> 2) Both of these are "unofficial" websites since there is no one entity
> to "own" the language. One is a website of the Common Lisp Foundation, a
> non-profit who serves as a body for organizing Lisp stuff and hosting
> some common infrastructure; another is a "fan" website describing the
> basics.
>
> 3) Clojure is a completely different language. It's inspired by CL, it's
> also a Lisp, but it's wildly different in lots of places.
>
> 4) There's none that gained practical significance while also being
> similar enough to CL to be called an updated CL rather than its own
> dialect (like Clojure or Carp or Janet or Racket). The language is
> perfectly usable as it is and many people claim it simply doesn't need
> an upgrade.
>
> On 19.02.2023 06:49, Jason Long wrote:
> > Hello all,
> > I have some questions about the CL and I'm thankful if anyone replies to
> them based on the question number:
> >
> > 1- Why isn't Lisp updated anymore?
> > 2- Why are there two websites? https://common-lisp.net and
> https://lisp-lang.org/
> > 3- Is Clojure an enhanced version of the CL?
> > 4- What is the updated version of CL?
> >
> >
> > Thank you.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/clo-devel/attachments/20230220/779d5465/attachment.html>