Hi,
I am curious how many of you reference CLHS more than Steele's CLTL2 or
vise visa in your common lisp programming. I am just about to give up
on CLHS because I found Steele's text was much more accessible. For
example, on the treatment of ASSOC, the CLHS says:
"assoc, assoc-if, and assoc-if-not return the first cons in alist whose
car satisfies the test, or nil if no such cons is found."
But Steele says this:
"Each of these searches the association list a-list. The value is the
first pair in the a-list such that the car of the pair satisfies the
test, or nil if there is no such pair in the a-list."
Admittedly, I liked Steele's use of "first pair" better than the
pedantic "first cons" used in CLHS. I also feel that Steele's
description is more English than that in the CLHS.
In your experience, how much content in the CLTL2 is still as current
and correct as in the CLHS? I may just use the CLTL2 as my primary CL
reference if it is, say, 90% current.
Doug
doug wrote:
> Hi,
>
> I am curious how many of you reference CLHS more than Steele's CLTL2 or
> vise visa in your common lisp programming. I am just about to give up
> on CLHS because I found Steele's text was much more accessible. For
> example, on the treatment of ASSOC, the CLHS says:
>
> "assoc, assoc-if, and assoc-if-not return the first cons in alist whose
> car satisfies the test, or nil if no such cons is found."
>
> But Steele says this:
>
> "Each of these searches the association list a-list. The value is the
> first pair in the a-list such that the car of the pair satisfies the
> test, or nil if there is no such pair in the a-list."
I like CLHSs version better; there is no question about what a `cons'
is. In some ways one could think of a `cons' as a pair but in other
ways one could think of a pair as a `list' (the Lisp data-type) with
two elements, but really two conses with two "slots" in each cons.
> (car '(a . b)) ;; first element in pair (`cons')
a
> (cdr '(a . b)) ;; second element in pair (`cons')
b
> (first '(a b)) ;; first element in pair (`list')
a
> (second '(a b)) ;; second element in pair (`list')
b
How you'd _like_ to think or model this in your head all depends on
what functions or abstractions you choose to use (or create) with this
data, but IMHO it's better to get the details when reading a reference
so you see what choices and pitfalls exist.
Check out http://www.gigamonkeys.com/book/ (
http://www.gigamonkeys.com/book/they-called-it-lisp-for-a-reason-list-processing.html
) for a good tutorial-style resource.
--
mvh,
Lars Rune Nøstdal
http://lars.nostdal.org/
"Lars Rune N�stdal" <···········@gmail.com> writes:
> doug wrote:
> > Hi,
> >
> > I am curious how many of you reference CLHS more than Steele's CLTL2 or
> > vise visa in your common lisp programming. I am just about to give up
> > on CLHS because I found Steele's text was much more accessible. For
> > example, on the treatment of ASSOC, the CLHS says:
> >
> > "assoc, assoc-if, and assoc-if-not return the first cons in alist whose
> > car satisfies the test, or nil if no such cons is found."
> >
> > But Steele says this:
> >
> > "Each of these searches the association list a-list. The value is the
> > first pair in the a-list such that the car of the pair satisfies the
> > test, or nil if there is no such pair in the a-list."
>
> I like CLHSs version better; there is no question about what a `cons'
> is. In some ways one could think of a `cons' as a pair but in other
> ways one could think of a pair as a `list' (the Lisp data-type) with
> two elements, but really two conses with two "slots" in each cons.
One major decision I made during the presentation of ANSI CL (and
consequently inherited by CLHS) was to centralize the definitions of
things rather than repeat them all over the place. I felt it would
not only make the spec better, but it would serve as a repository
for a huge wealth of terminology that those "in the know" about
Lisp would ordinarily use but that I wasn't sure was known "in the field",
away from the places that the design was occurring. I wanted people
to be able to talk about Lisp out loud and exchange notes on hastily
scrawled notes on napkins at dinner, and not have to write long explanations
of what the terms meant on a case-by-case basis. Lisp is not just a
language but a cultural movement, and almost all of what went into the
glossary (with a few notable exceptions) was standard terminology that
people already used and I just wrote down and used.
Lisp largely did not use the term "pair", and if it did, it led to a
sense of worry in people that it was different than a "cons". Hence
the use of italic to denote which are glossary terms is important to
understanding the information content. We wanted it to read well when
quoted out of context without typographical elements, as happened
above, but the spec was richer. I used to sometimes refer to those
terms as hyperlinks and was pleased when I was able to make CLHS be
hypertext so that some people would have a better idea what I meant.
(I wrote my first hypertext editor in 1984, so was quite ready to
embrace hypertext when it came along for the web.)
My theory was that if we just explained once in one place what a cons
was, then we could use it more simply.
There were a few terms I needed to make this consolidation complete.
Designators were one that I made up out of whole cloth--they weren't
there before I made them. I got tired of having phrases all over like
"a symbol or a string or a mixed list of symbols and strings" so writing
"a designator for a list of symbol designators" or
"a designator for a list of string designators" or something like that
seemed both immensely clearer and easier to join into paragraphs already
containing "and", "or" or even just commas. Whenever you have big long
phrases like "a symbol or a string or a mixed list of symbols and strings"
you have th eproblem that it's hard to conjoin or disjoin with some
other concept without the reader being confused.
So I'm very sympathetic to the claim that Steele's style is easier to read
than mine, but I'm surprised at this particular choice to illustrate it.
This phrase cited above seems an example of success, where the presence
of the glossary provided a 50% reduction in text with no substantial loss
of meaning.
Overall, of course, the document grew from CLTL to ANSI CL. But some
of that was due to extra information and examples, and some was due to
typography. But had I not taken the steps to consolidate info into
the glossary and to assume you didn't have to be reminded all the
time, it would have probably been larger. Also, it's hard to talk
about size at this point because some is just an issue of
sectionized-presentation ("Arguments:", "Description:", etc.) vs
"chatty" presentation. And the document was so large that in the last
phase before publication, I was able to squeeze 200 pages out (going
from about 1350 to about 1150 pages) merely by controlling the amount
of vertical whitespace in between paragraphs and sections, so even
just counting words still gives a substantial degree of variance
depending on how the layout is arranged.
- - - -
For grins, try to find where in CLTL (or CLTL2) it says that the order of
evaluation is left to right. There are three places, as far as I know.
And I'm sure you can find them by search in this newsgroup, so don't cheat.
But that's the example I usually cite of how things were listed in the
wrong place in CLTL2's chatty style (which I agree, incidentally, is
an easier read). The only disadvantage of CLTL2 is that it's not correct
any more. :)
I've probably told this story, too, but it bears repeating: Once at an
ANSI CL meeting, we were voting on some change and someone objected saying
"No, we can't do that! It will break my ability to still use CLTL as a
reference." If memory serves me, it was the name change of DEFINE-SETF-METHOD,
which did ultimately pass. I was shocked that this person would think
that it was reasonable to still use CLTL, since we had already changed
numerous things about the semantics and CLTL was already an inappropriate
reference. But the person explained (I'm paraphrasing, of course, after
more than a dozen years now) "yes, but you haven't changed the names".
Apparently, to this person, as long as the names didn't change, the book
was still a good reference, but as soon as they did, he couldn't use it
any more, regardless of what changes we'd made to the meaning. Steele was
there and was just as weirded out by this as I was and insisted that if
it took an incompatible change to get people to stop using the old book as
a reference when the semantics had already changed, then we should vote for
name change on that basis alone. :) The issue did ultimately pass, and that
may have been the deciding argument, but I don't recall.
Incidentally, some readers may not know that CLHS is a pretty true
rendering of ANSI CL. Except for some frontmatter, and some issues of
typography that didn't render well onto the web, and a few sentences I
added to introduce the glossary better for the web, it's precisely the
text of the standard. In turn, and even less well known, CLHS began
as literally CLTL. Steele donated the sources to CLTL (1, not 2) and
my predecessor--Kathy Chapman, then of Digital Equipment Corporation
(DEC)--did a couple years of work rearranging the book into a reading
order similar to the final order. When It was further morphed by me
to add a glossary and to repair, in qualitative terms, the number of
errors per page from "many" to "few". Kathy had also begun the
process of breaking out entries into sections like
arguments/description/etc. and I finished that process. But it's
always funny to me when people compare CLHS and CLTL2 because really
they are half-siblings, sharing a common parent. CLTL2, unlike CLTL1,
was not a committee document, even though it shared an author with
CLTL1. The committee asked Steele only to do CLTL1 and he did CLTL2
somewhat over the objections of some committee members (and to some
degree against his own self-professed better judgment--see his own
preface).
Not by way of apology, but at least by way of explanation, the
situation was this: I tried to make CLHS as approachable to ordinary
readers as possible, but ultimately that was not its first goal.
Plus, it was such a large document that it was a simple matter of time
and budget. I could have changed it faster, as could many of you out
there, I suspect, if only we didn't have a compatibility constraint.
For as much as I was free to change the format in many ways, I was
contually encumbered by an ethical obligation never to change the
meaning of anything even as I reshuffled things. And that meant that
sometimes even when it was rearranged to put things in better places,
I had to leave ambiguities in place unless I could assure myself that,
at minimum, no implementations would be broken by any "clarification"
I might make ... it was a dreadful responsibility. The task was not
"write a better spec for a language" but rather "write a better spec
for this language with this semantics, changing only those
consequences of the text that have been approved by vote".
I'm not in the least defensive if anyone wants to criticize ANSI CL or
CLHS. There are MANY things there to criticize: technical judgments
(some mine, some of others) and editing errors (many mine, a few due
to others). But I do like it if people keep the historical context
and technical goals and practicalities of budget in mind when
discussing it.
Kent,
We in the community don't thank you often enough for the extraordinary
job you did on ANSI CL and CLHS. I use CLHS nearly everyday I'm
programming CL and my programs are much better because of it. So
thank you, for providing us with such an extremely useful document and
presentation.
Of course a big thank you also goes to LispWorks for making it
available.
Glenn
Kent M Pitman wrote:
> One major decision I made during the presentation of ANSI CL (and
> consequently inherited by CLHS) was to centralize the definitions of
> things rather than repeat them all over the place. I felt it would
> not only make the spec better, but it would serve as a repository
> for a huge wealth of terminology that those "in the know" about
> Lisp would ordinarily use but that I wasn't sure was known "in the field",
> away from the places that the design was occurring. I wanted people
> to be able to talk about Lisp out loud and exchange notes on hastily
> scrawled notes on napkins at dinner, and not have to write long explanations
> of what the terms meant on a case-by-case basis. Lisp is not just a
> language but a cultural movement, and almost all of what went into the
> glossary (with a few notable exceptions) was standard terminology that
> people already used and I just wrote down and used.
>
Kent M Pitman <······@nhplace.com> wrote:
> I felt it would not only make the spec better, but it would serve as a
> repository for a huge wealth of terminology that those "in the know"
> about Lisp would ordinarily use but that I wasn't sure was known "in
> the field", away from the places that the design was occurring.
I'm a relative newcomer to Lisp, but I seem to osmose programming
language culture and idioms very quickly. The CLHS has been a great
help in letting me do that with Lisp, so I owe you, and the many others
involved in its creation, a pile of gratitude.
You did, however, miss out one little bit of terminology it took me a
while to track down: the note at the bottom of the page about the LAMBDA
macro uses the name `bvl-decls-and-body'; I've also noticed the
abbreviation `bvl' cropping up throughout MIT Scheme and in other
places. I eventually found the expansion, `bound variable list', in
TEACH; LESSON LAMBDA with your by-line at the top. So I suppose I
should still thank you for putting the information somewhere I could
find it. ;-)
-- [mdw]
doug wrote:
> I am curious how many of you reference CLHS more than Steele's CLTL2 or
> vise visa in your common lisp programming. I am just about to give up
> on CLHS because I found Steele's text was much more accessible. For
> example, on the treatment of ASSOC, the CLHS says:
I think one effective thing is to combine something like Graham's
appendix at the end of _ANSI CL_, with a hyperspec-lookup of some sort.
In terms of learning, CLTL2 is great, if you keep in mind it's not a
serious reference.
Tayssir
doug wrote:
> Hi,
>
> I am curious how many of you reference CLHS more than Steele's CLTL2 or
> vise visa in your common lisp programming. I am just about to give up
> on CLHS because I found Steele's text was much more accessible. For
> example, on the treatment of ASSOC, the CLHS says:
>
> "assoc, assoc-if, and assoc-if-not return the first cons in alist whose
> car satisfies the test, or nil if no such cons is found."
>
> But Steele says this:
>
> "Each of these searches the association list a-list. The value is the
> first pair in the a-list such that the car of the pair satisfies the
> test, or nil if there is no such pair in the a-list."
>
> Admittedly, I liked Steele's use of "first pair" better than the
> pedantic "first cons" used in CLHS. I also feel that Steele's
> description is more English than that in the CLHS.
>
> In your experience, how much content in the CLTL2 is still as current
> and correct as in the CLHS? I may just use the CLTL2 as my primary CL
> reference if it is, say, 90% current.
See http://bc.tech.coop/cltl2-ansi.htm
I agree that CLtL2 is better for learning, but CLHS works better, and is
more accurate, as a reference. CLHS is based on the ANSI Common Lisp
specification, and the goal of that specification is to guide
implementors of Common Lisp, not necessarily to ease learning.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza <··@p-cos.net> wrote:
+---------------
| doug wrote:
| > I am curious how many of you reference CLHS more than Steele's CLTL2
| > or vise visa in your common lisp programming. I am just about to give
| > up on CLHS because I found Steele's text was much more accessible.
...
| See http://bc.tech.coop/cltl2-ansi.htm
|
| I agree that CLtL2 is better for learning, but CLHS works better, and is
| more accurate, as a reference. CLHS is based on the ANSI Common Lisp
| specification, and the goal of that specification is to guide
| implementors of Common Lisp, not necessarily to ease learning.
+---------------
To hammer Pascal's point in a bit further, his phrase "based on" should
be taken as being *much* stronger than in normal everyday usage. While
it is true that the CLHS is not the ANSI Common Lisp standard, the CLHS
*was* mechanically transformed into HTML from the same TeX input source
code that the final published ANSI Common Lisp standard was generated from,
so it's about as close as it's possible to be for something "based on but
not identical". [Even the known typos were left alone!]
Personally, while I do own both CLtL1 & CLtL2, I really learned CL
from a whirlwind tour through Norvig's PAIP and Graham's "ANSI Common
Lisp" & "On Lisp" to get the basics, and then further learning has
been mostly from the CLHS itself (where I *continue* to learn things
on an almost-daily basis) and this newsgroup. [Thanks, guys!]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
doug wrote:
> Hi,
>
> I am curious how many of you reference CLHS more than Steele's CLTL2 or
> vise visa in your common lisp programming.
I always hated CLtL2. It is a mess. I really would liked CLtL2 without
all
the changed/modified stuff from CLtL1.
Take CLtL1 and destroy the text by adding changes, marking outdated
stuff and so on.
The you have CLtL2.
CLtL2 has lots of old CLtL1 descriptions, some of them which are
outdated/modified in CLtL2. So the book describes not one language
version, but two.
It also describes some language version that was probably nowhere
really implemented.
Some stuff was more experimental (like the environment functionality).
The ANSI CL spec is atleast a text that describes just one language.