Of particular interest to me is the loop facility reference. It appears to be terse, understandable, and relatively complete. I also like the notation. A subscript f to tell me it's not a macro is incredibly helpful.
Friendly reminder about printing services like this one[1] that will print and ship a PDF to you.
Another fun option is to print the folios and bind them yourself. A serviceable job can be done in an afternoon with little more than a sewing kit. It’s easy, using a ruler, an awl or something similar, and a stiff piece of cardboard, to make a guide template for punching holes in the folios. After that it’s just a matter of stitching.
Whenever I see things like this I wish CL was available by default in more environments. It would have been the ultimate glue language also capable of growing software into medium-to-large size projects with some care.
Instead we have Perl. It's not bad and fulfills many of the same criteria, but it's also not quite as elegant.
SBCL is available to install on MacOS with brew, with apt or yum on Linux, etc. You can make small standalone applications easily. I have used it for command line utilities (I have some simple examples in my CL book that you can read online https://leanpub.com/lovinglisp/read)
I also recently updated the Mac install docs for Portacle for anyone looking for anyone looking to tinker with CL on newer Macs! https://portacle.github.io/
Interesting. Why particularly a glue language? Just because it's the ultimate language and thus by definition also the ultimate glue language or is there something more specific?
I would argue perl has a superior practical elegance
so you can write perl in a kinda-sexp style if you really want to (no one does, which tells you something)...but you get a kinda-sexp built-in syntax for hashes whereas lisps make you construct them with bolted on functions
People who publish programming material online in PDF format should really take notice of this and the formatting. The half A4 version is skinny enough that you can stick it next to your editor/IDE window and still see the entire page even on small screens.
Common Lisp is huge because libraries were not a big thing when it was designed, so it included lots of kitchen sinks.
This has some advantages:
1. The built in functions generally are very efficient and don't have many edge-case gotchas.
2. You don't have to worry about which version of a library function to use, i.e. no dependency hell.
3. The above is true for every CL implementation, from any supplier.
It also has some disadvantages: When designing a language you can never predict all the functionality people will need. Useful things like networking and multithreading and package management were not included in the CL standard. Libraries for the missing pieces now exist to fix those shortcomings.
we need to keep in mind that many things were still emerging when the core language was designed - 1982 specs appeared with the first language book published in 1984. CLOS (the Common Lisp Object System) for example was mostly a research project, whose first spec was published in 1988, the Meta-object Protocol book was published in 1991 - which was unusual, since one would standardize on common practice. Stuff like networking and multithreading existed in very different ways or only very primitive. Networking usually meant to interface to the local platform network stacks and multithreading was still largely unsolved - parallel Lisp was still a research subject, even though thread/concurrency/parallelism support existed in very different ways - often 'green threads' (cooperatively scheduled) or for experimental machines (like the massive parallel connection machine). Now even my watch has two cpu cores and smartphones have even more cores.
Having the functions built in also allows them to be specialized at compile time. For example, if we have an operation on sequences, and we know the sequence is a particular kind (say, a list), we can invoke the method for that sequence.
It would be nice if such advantages could be ported to user defined libraries, or if built in functions could be extended (by making them generic and adding methods, say) without losing these advantages. Many of the features in Common Lisp are there because they helped implement things in the standard; it would be nice if that principle could be extended. The ultimate goal would be (in some standardized way) to expose to a library writer all the mechanisms that could make the built ins particularly effective.
define-compiler-macro handles many of the cases you describe in your first paragraph. But I agree it would be nice if more of the functions in CL were generic. I think the issue is that those functions were standardized before CLOS was added and made defgeneric/defmethod a normal mechanism for writing functions.
Compiler macros are an example of something added to make built-in functions more efficient, but they aren't going as far as I'd like. I mean, SBCL doesn't use them for specializing built-ins based on type information; it uses its own nonstandard mechanism, defknown.
I've mentioned this before, but I'd really like to see Strandh's Call-site optimization implemented, so generic functions could be both highly locally optimizable, yet retain their dynamicity.
I've always felt that Common Lisp was the Lisp family incarnation of PL/I; include everything you think might be helpful to offer a warm welcome to folks coming from FORTRAN or COBOL.
Who knows? Currently there is no one working on a new standard. Maybe an AI will publish one in 2094, hundred years after the first standard.
For now with CL we can program in the past and reuse some code from 30 years ago. Changes will need to reflected in implementations, libraries and community standards. Some stuff would need changing the existing, others not so much. Example: Due to meta-programmability something like the Common Lisp Object System was implemented 95% in the language itself - the remaining 5% largely needed to be implementation specific things like changing the type system. Other stuff like 'threading' or 'foreign function interface' would need more work - but they exist already in implementations and libraries.
they don't call it Lisp because it came from Scheme but they wisely realized the first step to making changes is to stop calling it Scheme otherwise purists will just rain fire on it and insist on living in the past
from a practical perspective it seems perfectly safe and reasonable to say Racket is Lisp2023
otherwise maybe elisp? it is by far the most important thing with "lisp" in its name in 2023
Friendly reminder about printing services like this one[1] that will print and ship a PDF to you.
https://www.printme1.com/