
Common Lisp Standard Draft - tosh
http://cvberry.com/tech_writings/notes/common_lisp_standard_draft.html
======
jlarocco
I'm downloading and may use this, but I've actually come to like the
hyperspec.

It was overwhelming at first, and the formatting isn't great, but I got used
to it, and can actually find things pretty quick now. My biggest complaint
would be the lack of examples.

I also don't know if I'd call $60 for the official spec expensive, but the
fact it's a scan is inexcusable.

~~~
michaelmrose
When plenty of other languages have zero cost associated ANY cost is too much
unless you want people to read about and adopt alternative choices in the time
required for someone to justify the company making a purchase.

~~~
pubby
I think you're misunderstanding the point and confusing standards with
documentation.

Standards are for one very narrow group of people: compiler writers. If you're
not a compiler writer, you have zero reason to buy the official standard
document. And if you are a compiler writer, well, it would be very bizarre to
choose your target language based on the price of its spec!

Please note that the final draft of the standard is published for free on that
website.

~~~
mycl
ISO Prolog (ISO/IEC 13211) doesn't have a free standard and it has hurt the
Prolog language immeasurably. In this case the last freely available draft is
quite different from the final standard, which makes the situation worse
because not everyone is aware of this.

I have noticed a lot of Prolog programmers don't know what's in the standard
and what's not - you routinely see answers given on SO that are implementation
dependent when they could easily have been expressed in strictly conforming
ISO Prolog.

Of course, you can get pirated versions of ISO/IEC 13211-1 and 13211-2 but
even saying these exist probably makes me complicit in piracy, let alone
suggesting they should be widely shared in the Prolog community. The 3
technical corrigenda that update 13211-1 are freely available[0], or at least
ISO allows you to "Preview" the whole document in each case.

[0]
[https://www.iso.org/standard/21413.html](https://www.iso.org/standard/21413.html)

~~~
stonemetal
I would put that on the implementations not following the standard rather than
the availability of the standard. How many C# devs out there have read their
ISO standard?

~~~
setr
not sure about Prolog, but afaik compiler writers are usually very good about
following the standards (and they reference the standards consistently when
discussing (potentially) semantic bugs). In general I think its safe to trust
that any given compiler (tries to) follows the standards strictly; and then
implement extensions on top.

And extensions are fine. They might be syntactic sugar, or specific hacks, or
strange DSLs or whatever. Convenient, if you know you're targetting a single
compiler. But you can still write standards-compliant code, when necessary.

But if the compiler doesn't make it explicitly clear, and the standards aren't
easily available, then you now have people using extensions without realizing
it, and if you tell them you're using an extension, there's nowhere to point
to as proof. If you're trying to write code successfully against two different
compilers, and get different results, there's nowhere to point to to show that
compiler A has the incorrect response. Instead you file against both and
assume they have access to the standard.

Also afaik C# only really runs against a single compiler (mono, i think?),
doesn't it? So it makes sense that community doesn't bother with the standard;
you're not writing cross-compiler-compatible code, so whatever works on mono
_is_ the standard (in practice).

The same is true for python, ruby, haskell, etc. There's practically only one
compiler in existence (that you care about); those implementations _are_ the
standard, regardless of any ISO standard.

But you look at the C and C++ community, and half the SO answers directly
reference the standard, despite presumably being mere "users" of the language.
Because when many compiler implementations exist (and used), then extensions
are much less viable, and the standards are extremely important

And afaik, CL is one of those languages with multiple major compilers, and
thus an easily available standard is important.

------
hydandata
Common Lisp UltraSpec [0][1] is another awesome resource

[0] [http://phoe.tymoon.eu/clus/doku.php](http://phoe.tymoon.eu/clus/doku.php)
[1] [https://github.com/UltraSpec](https://github.com/UltraSpec)

~~~
aidenn0
And the Ultraspec is generated from the same tex sources as the PDFs in TFA.
The HyperSpec is copyrighted with a license that only permits distribution if
not modified, so it cannot be used as a basis for an improved version.

------
TurboHaskal
I got excited for a moment and thought there's a new revision in the works.

~~~
ghettoimp
Me too. It’s too bad how stale the language has gotten.

~~~
peatmoss
I think for people who want to be able to have a bit of lisp into their daily
lives, Clojure is where the majority of the current industry-focused mindshare
is going. At least as far as new development of language features is
concerned.

For people who are less industry focused, and more interested in the evolution
of lisp from a CS perspective, Racket has gobbled up that mindshare.

Common Lisp, in spite of its strengths, multiple standard implementations, and
historical pedigree, seems at risk of fading more if there isn't some new
lifeblood injected. The problem if I understand it, is that the Common Lisp
spec is so gigantic, and was itself the product of a tenuous truce between
many warring tribes of lisps long forgotten. I wonder how possible a new spec
even is?

~~~
kazinator
The Common Lisp spec came to under 1100 pages.

That's not a lot.

I made a small scripting language starting in 2009. The reference manual is
close to 640 pages now if turned into a PDF (with no cover pages, table of
contents or index). You go bit by bit, document everything, and you'll be
surprised at how the pages stack up over the years.

I think Steele's ClTl ( _Common Lisp, The Language_ ), a major base document,
is already at > 1000.

ECMAScript (i.e. JavaScript) 2017 is 885 pages.

C11 draft: 696 pages. C hardly does anything! Just compiles some Von-Neumann-
style word-pushing computation to machine code, and supplies a bare-bones
library.

(The K&R2 book is 288 pages and the C90 standard is around that size also. In
that K&R2 book, the authors state: "C is not a big language, and it is not
well served by a big book." Ha!)

C++ ... let's not go there.

~~~
lispm
CLtL1 had around 470 pages.

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

~~~
lispm
Well said.

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

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

------
rogerb
nice. whenever i am in between jobs, and are plotting the next thing to do - i
turn to lisp :|

