

New Common Lisp book announced, bills itself as a sequel to On Lisp. - dfranke
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/d7ca047957f84399#

======
Hexstream
In chapter 2:

"Some programmers follow a convention of prefixing and postfixing special
variable names with asterisks, like _temp-special_. This is called the earmuff
convention. For reasons explained in section 3.7, Duality of Syntax, this book
does not use earmuffs so our special variable declarations look like this:

(defvar temp-special)"

Double-U Tee Eff!! I challenge you to find 5 serious lispers that don't use
the __convention and/or justify going against said convention convincingly.

edit: In chapter 3:

"So lexical and dynamic variables are _actually completely different_ ,
deservedly _distinct concepts_ that _just happen to share the same syntax_ in
COMMON LISP code. Why on earth would we want this so-called duality of
syntax?"

What?! You're asking why we want this duality of syntax just after saying it's
because they're completely different concepts that just happen to have the
same syntax... (edit: oh, I misread that. You confused me because you said
there was a duality of _syntax_ when you probably meant there's a duality of
_semantics_ (edit: wait, I reread it a couple times and I think I may not have
misread it after all. It simply doesn't seem to make any sense.))

And you seem to imply using the stars convention reduces the power of macros,
while this is absolutely not the case.

"A traditional convention in COMMON LISP code is to prefix and postfix the
names of special variables with asterisk characters. For example, we might've
chosen to name our temp-special variable _temp-special_. Since this convention
is almost like having another namespace for dynamic variables, diminishing
their duality with lexical variables, this book does not follow it exactly."

 _Diminishing_ duality? That's diminishing _unity_ and increasing duality. The
stars convention establishes a duality of syntax where there is a duality of
semantics and that's a good thing. Removing the stars only makes things more
confusing because you're conflating two, in your words, " _actually completely
different_ " concepts.

* (function '(lambda (x) (+ 1 x)))

That looks wrong... Let's see what my REPL thinks:

    
    
      Execution of a form compiled with errors.
     Form:
       #''(LAMBDA (X) (+ 1 X))
     Compile-time error:
       '(LAMBDA (X) (+ 1 X)) is not a legal function name.
        [Condition of type SB-INT:COMPILED-PROGRAM-ERROR]
    

I thought so.

"Which is a lesser fashion crime: lexical variables with asterisks or special
variables without? I tend to think the less verbose of the two."

Why not lexical variables without asterisks and dynamic variables with them,
then? Lexical scope is used pretty much everywhere while special scope is used
seldom in comparison (it's even hidden in expansions of "with-" style macros a
lot).

~~~
gibsonf1
We use the "earmuff" convention with good results and no plans to change it.

~~~
gruseom
Incidentally, it's _not_ called the "earmuff" convention, if Google is to be
believed:

<http://www.google.com/search?q=earmuff+convention+lisp>

... other, that is, than in the book _Let Over Lambda_.

Edit: I agree with you about the convention - I find it valuable in my code
(along with special variables in general, which are a great example of how CL
is optimized for building working systems).

~~~
lst
(You know, Canada is kind of an 'Island', and many Canadiens are, too.)

------
Hexstream
This book won't be a very strong ally against the stereotype of the elitist
Lisper...

"Notice how the text we enter is in lower-case but the text returned from lisp
is in upper-case. This is a feature of COMMON LISP that allows us to easily
scan a REPL print-out and know which expressions we entered versus which were
printed out by lisp."

Ah, I always thought it was a bug graciously bestowed by our ancestors.

~~~
coffeemug
Not to mention that CL reader can be configured to have any kind of case
behavior you want, and turning symbols to upper case just happens to be the
default.

~~~
Hexstream
I'm aware of that but I've always been wary of doing (setf _print-case_
:downcase) globally because it can break code. Consider this example:

    
    
      (let ((*print-case* :downcase)
            (my-symbol 'mine))
        (intern (format nil "IT-IS-~A" my-symbol)))
      => |IT-IS-mine|, :INTERNAL
    

Let's say _print-case_ has been setf'd globally and my-symbol is an argument
to a macro. The macro wants to derive a new symbol from my-symbol. But the
result is ugly because the macro assumed _print-case_ :upcase. There are many
such examples in my and other people's code.

edit: How do I prevent asterisked variable names from indicating _italics_?

------
misuba
Is it awesome or just unfortunate that the book's title abbreviates to LOL?

~~~
dfranke
If it were a Haskell book then clearly they'd need one of these on the cover:
<http://arcanux.org/lambdacats.html>

------
st3fan
I'm reading the available chapters and I like it! It is well written. Can't
wait to have the dead tree copy!

------
gruseom
I just ordered it. I'm a little skeptical, but if the book is half as good as
its stated goal, it'll be worth a lot.

Actually, I'd probably buy any credible new Lisp book at this point.

~~~
dfranke
I don't think there's any automatic credibility here. It's a book by an
unknown author published by a vanity press.

~~~
gruseom
You're quite right, and I see that my comment was unclear. What I meant by
"credible" was "not obviously not credible"; in other words, I read the first
chapter and it didn't obviously suck. It's basically an expected value calc:
the probability of the book being very good is low, but my interest in the
topic is so high that it's worth the bet.

After I saw the author's blog (which could be described as a poster child for
the "Bipolar Lisp Programmer") my probability estimate got a little lower.

