I don't have a copy of CLtL1 myself (though I vaguely recall checking it out from the university library a few times many moons ago). I'm replying to you because your post was the last stop for my train of thought, but this isn't a rebuttal by any means.
CLtL2 has 1053 pages if you count the front- and back-matter, 975 if you don't.
For comparison, the ANSI C11 standard comes to 683 pages, but I think it's worth mentioning that CL leaves far fewer things unspecified, is much more "powerful", and is written in such a way that it can reasonably serve as an introduction and a reference in addition to a definition, compared to the C11 standard which, imo, doesn't serve particularly well for any use other than definition (I'm far more likely to reach for Harbison & Steele than for ANSI C if I need a C reference, and if a handful of programmers trying to learn C given only the standard were broadcast on TV, I'd set my DVR, because that would be very entertaining).
The Emacs Lisp reference manual weighs in at 1077 pages. Nobody really cares.
Standard ML (revised) comes to 583 pages between the Definition and the Basis Library, but its succinctness comes at the cost of being nigh incomprehensible to mere mortals, since the ~100 pages of the Definition are largely occupied by formal semantics; this is both a good thing (formal semantics are nice to have) and a bad thing (to understand it you have to learn the formal language first... I don't consider this a huge deal, but my experience has been that most people can't be arsed).
IEEE Scheme comes to 73 pages, but it omits a lot of things that would be considered essential for "programming in the large": modules, records, macros, &c. While I don't think it could serve as an introduction for anyone not already versed in a Lisp dialect or at least some applicative language, it does function rather well as a reference, except that 80% of the time you're better off checking your implementation's documentation (for example, the 895 pages of the Guile 2.0 reference manual).
ISLISP is 127 pages (the "official" ISO ISLISP standard is also the most expensive of all of these documents by far, but fortunately Kent did us all a solid), and suffers from some of the same "problems"[1] as IEEE Scheme.
BCPL punches at the featherweight class, containing the language definition, tutorial, examples, reference, virtual machine specification, and a source listing of a self-hosted reference compiler, all in a mere 183 pages. Despite its admirable simplicity, so few people seem to be writing any serious software in BCPL these days. I wonder why that is...
Die-hard Wirth fans like to champion the fact that the Oberon-07 report is small enough to keep in your wallet, so you can drunkenly show it to strangers at the pub and proudly tell them all about your wee little language that you haven't seen since your Wirth left you 10 years ago. It's only 17 pages, but it deals almost exclusively with matters of syntax, including only the bare minimum informal, imprecise descriptions of semantics interleaved therewith. The library reference consists of a couple lists of procedure names without even an afterthought mentioning what they actually do, all the while making even the IEEE Scheme standard library look luxurious and capacious in comparison.
The point of mentioning all this is that even after a language has been designed and documented, the act of writing it down comes with all kinds of tradeoffs. Pages numbering in the quadruple digits can be intimidating and perhaps tedious at times, but pages numbering in the double digits can be rather frustrating and just as tedious at times, too: when you find that some aspect of the language is only vaguely specified or communicated, and you have to take your best guess (which is probably wrong, as a rule of thumb); or when your program grows beyond the original intent and suddenly packages and CLOS really start looking like they're worth their weight in paper. The complexity of a programming language is many-dimensional, and there are many possible functions that can map that complexity into the single dimension of page count; some of those functions might result in standards that are great for neophytes but aggravating for professionals, others might yield results that are brilliant for implementors but absolute rubbish for students.
All things considered, I think ANSI CL (and CLtL, for that matter) approximate a sweetspot in the language standard space, not even just in terms of how they're designed but in how they're written: they're immanently accessible to regular programmers, provide thorough coverage of the language and libraries in a format that also serves as a handy reference, and (usually) offer enough detail that implementors don't have to roll any dice. They're not absolutely perfect, but having read so many language standards from so many different perspectives (learner, practitioner, implementor, and once-upon-a-time author), I've really developed an admiration for those in particular. It's not an easy task to write a language definition, especially with a language as featureful as CL, and yet they still manage to do it in a way that I consider exemplary.
—
[1]: Depending on your use case, they're features rather than problems. Everything would be so much better if only we could all agree on a damn use case.
> CLtL2 has 1053 pages if you count the front- and back-matter, 975 if you don't.
Actually CLtL2 is not a book describing the standard, but a book describing a specific state during the standardization. Thus it includes lots of superseded material (plus the reasoning why it was superseded) and also material which was not part of the language (like Series) or later has been removed again (like environment access for macros). Probably (just an estimate) 1/3 of the book is not actual language documentation, but there because this special nature of the book.
Yeah. I quite like the way the second edition was conveyed, though, with additions and amendments indicated by typographic conventions, because the result is that when you have the second edition, you also kinda have the first edition. It's also cool from a historical perspective, since it is very much an intermediate "development snapshot" between CLtL1 and the ANSI standard, and the votes and discussion topics are meticulously catalogued.
But despite CLtL2 not being a standard per se, I think the ANSI standard as published retains a lot of the "spirit" of CLtL, in that it defines things precisely without resorting to obtuse formalisms or overly-dry description, and in that it is organized in a similarly versatile way.
CLtL2 has 1053 pages if you count the front- and back-matter, 975 if you don't.
For comparison, the ANSI C11 standard comes to 683 pages, but I think it's worth mentioning that CL leaves far fewer things unspecified, is much more "powerful", and is written in such a way that it can reasonably serve as an introduction and a reference in addition to a definition, compared to the C11 standard which, imo, doesn't serve particularly well for any use other than definition (I'm far more likely to reach for Harbison & Steele than for ANSI C if I need a C reference, and if a handful of programmers trying to learn C given only the standard were broadcast on TV, I'd set my DVR, because that would be very entertaining).
The Emacs Lisp reference manual weighs in at 1077 pages. Nobody really cares.
Standard ML (revised) comes to 583 pages between the Definition and the Basis Library, but its succinctness comes at the cost of being nigh incomprehensible to mere mortals, since the ~100 pages of the Definition are largely occupied by formal semantics; this is both a good thing (formal semantics are nice to have) and a bad thing (to understand it you have to learn the formal language first... I don't consider this a huge deal, but my experience has been that most people can't be arsed).
IEEE Scheme comes to 73 pages, but it omits a lot of things that would be considered essential for "programming in the large": modules, records, macros, &c. While I don't think it could serve as an introduction for anyone not already versed in a Lisp dialect or at least some applicative language, it does function rather well as a reference, except that 80% of the time you're better off checking your implementation's documentation (for example, the 895 pages of the Guile 2.0 reference manual).
ISLISP is 127 pages (the "official" ISO ISLISP standard is also the most expensive of all of these documents by far, but fortunately Kent did us all a solid), and suffers from some of the same "problems"[1] as IEEE Scheme.
BCPL punches at the featherweight class, containing the language definition, tutorial, examples, reference, virtual machine specification, and a source listing of a self-hosted reference compiler, all in a mere 183 pages. Despite its admirable simplicity, so few people seem to be writing any serious software in BCPL these days. I wonder why that is...
Die-hard Wirth fans like to champion the fact that the Oberon-07 report is small enough to keep in your wallet, so you can drunkenly show it to strangers at the pub and proudly tell them all about your wee little language that you haven't seen since your Wirth left you 10 years ago. It's only 17 pages, but it deals almost exclusively with matters of syntax, including only the bare minimum informal, imprecise descriptions of semantics interleaved therewith. The library reference consists of a couple lists of procedure names without even an afterthought mentioning what they actually do, all the while making even the IEEE Scheme standard library look luxurious and capacious in comparison.
The point of mentioning all this is that even after a language has been designed and documented, the act of writing it down comes with all kinds of tradeoffs. Pages numbering in the quadruple digits can be intimidating and perhaps tedious at times, but pages numbering in the double digits can be rather frustrating and just as tedious at times, too: when you find that some aspect of the language is only vaguely specified or communicated, and you have to take your best guess (which is probably wrong, as a rule of thumb); or when your program grows beyond the original intent and suddenly packages and CLOS really start looking like they're worth their weight in paper. The complexity of a programming language is many-dimensional, and there are many possible functions that can map that complexity into the single dimension of page count; some of those functions might result in standards that are great for neophytes but aggravating for professionals, others might yield results that are brilliant for implementors but absolute rubbish for students.
All things considered, I think ANSI CL (and CLtL, for that matter) approximate a sweetspot in the language standard space, not even just in terms of how they're designed but in how they're written: they're immanently accessible to regular programmers, provide thorough coverage of the language and libraries in a format that also serves as a handy reference, and (usually) offer enough detail that implementors don't have to roll any dice. They're not absolutely perfect, but having read so many language standards from so many different perspectives (learner, practitioner, implementor, and once-upon-a-time author), I've really developed an admiration for those in particular. It's not an easy task to write a language definition, especially with a language as featureful as CL, and yet they still manage to do it in a way that I consider exemplary.
—
[1]: Depending on your use case, they're features rather than problems. Everything would be so much better if only we could all agree on a damn use case.