4 ms·

It is amusing that the quick reference is a densely packed "52 pages".

inimino 4y ago
It's CL, what are you gonna do...
1bent 4y ago
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.
dreamcompiler 4y ago
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.
- lispm 4y ago
  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.
- pfdietz 4y ago
  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.
  - dreamcompiler 4y ago
    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.
    - pfdietz 4y ago
      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.

It's CL, what are you gonna do...

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.

dreamcompiler 4y ago

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.

lispm 4y ago
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.
pfdietz 4y ago
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.
- dreamcompiler 4y ago
  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.
  - pfdietz 4y ago
    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.