5 ms·

New Common Lisp book announced, bills itself as a sequel to On Lisp.

53 points by dfranke 18y ago

deleted 18y ago
[deleted]
st3fan 18y ago
I'm reading the available chapters and I like it! It is well written. Can't wait to have the dead tree copy!
misuba 18y ago
Is it awesome or just unfortunate that the book's title abbreviates to LOL?
- deleted 18y ago
  [deleted]
- dfranke 18y ago
  If it were a Haskell book then clearly they'd need one of these on the cover: http://arcanux.org/lambdacats.html http://arcanux.org/lambdacats.html
- Hexstream 18y ago
  It's certainly deliberate in either case.
gruseom 18y ago
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 18y ago
  I don't think there's any automatic credibility here. It's a book by an unknown author published by a vanity press.
  - gruseom 18y ago
    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.
Hexstream 18y ago
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 18y ago
  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 18y ago
    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?
Hexstream 18y ago
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 18y ago

53 points by dfranke 18y ago

deleted 18y ago

[deleted]

st3fan 18y ago

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

misuba 18y ago

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

deleted 18y ago
[deleted]
dfranke 18y ago
If it were a Haskell book then clearly they'd need one of these on the cover: http://arcanux.org/lambdacats.html http://arcanux.org/lambdacats.html
Hexstream 18y ago
It's certainly deliberate in either case.

gruseom 18y ago

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 18y ago
I don't think there's any automatic credibility here. It's a book by an unknown author published by a vanity press.
- gruseom 18y ago
  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.

Hexstream 18y ago

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 18y ago
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 18y ago
  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?

Hexstream 18y ago

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 18y ago