Let Over Lambda (2008)(letoverlambda.com)
letoverlambda.com
Let Over Lambda (2008)
http://letoverlambda.com/index.cl/toc
2 comments
Christian Queinnec's website is also full of Lisp related research. http://pagesperso-systeme.lip6.fr/Christian.Queinnec/WWW/Que...
http://pagesperso-systeme.lip6.fr/Christian.Queinnec/WWW/Des...
also:
http://cs.brown.edu/~sk/Publications/Papers/Published/sk-aut...
http://docs.racket-lang.org/guide/macros.html
http://pagesperso-systeme.lip6.fr/Christian.Queinnec/WWW/Des...
also:
http://cs.brown.edu/~sk/Publications/Papers/Published/sk-aut...
http://docs.racket-lang.org/guide/macros.html
LoL's author has a collection of references at http://letoverlambda.com/references.lisp
Many of the references are not for learning CL, but are interesting reads (such as Henry Baker's papers).
Also there are references to particular pages of books (noting something important, interesting or funny):
Many of the references are not for learning CL, but are interesting reads (such as Henry Baker's papers).
Also there are references to particular pages of books (noting something important, interesting or funny):
(cltl2 :a guy-steele :y 1990
:n "Common Lisp the Language 2nd Ed.")
(cltl2-p153 :i "Chevrolet!")
(cltl2-p260
:i "Can't define compiler macros over CL forms")
From the wikibooks page: "At this time, Clojure does not allow you to define your own reader macros, but this may change in the future."
Rich Hickey has been pretty adamant about not wanting to provide user-defined reader macros, so I do not expect this to change, wikibooks' optimism notwithstanding.
Rich Hickey has been pretty adamant about not wanting to provide user-defined reader macros, so I do not expect this to change, wikibooks' optimism notwithstanding.
> Clojure does not allow you to define your own reader macros
Yeah, the reader macros on that wikibooks page are built into the language. The best the Clojure offers are tagged literals[1] but these run after the code is read (so they're not reader macros).
[1] http://clojure.org/reader?responseToken=08f63df34820f8da967f...
Yeah, the reader macros on that wikibooks page are built into the language. The best the Clojure offers are tagged literals[1] but these run after the code is read (so they're not reader macros).
[1] http://clojure.org/reader?responseToken=08f63df34820f8da967f...
Interesting, I've read Let over Lambda cover to cover 2-3 years ago and I don't even remember a chapter on reader macros.
I wonder how many of the concepts of let surrounding a lambda et al would work in Clojure since it uses immutability?
I wonder how many of the concepts of let surrounding a lambda et al would work in Clojure since it uses immutability?
There is a lot less of the unrestrained use of mutability in Clojure, but you can still have shared mutable references via atoms and refs.
EDIT:
As an example, here is the block-scanner in Clojure:
EDIT:
As an example, here is the block-scanner in Clojure:
(defn block-scanner [trig]
(let [curr (atom trig)]
(fn [data]
(doseq [c data]
(if (not (empty? @curr))
(reset! curr
(if (= (first @curr) c)
(rest @curr)
trig))))
(empty? @curr))))Hi, thank you for the list.
I'm now learning Clojure and simplicity and power of lisp just blows my mind, really happy to write on it. But I wonder what of these books do you recommend to read to those people who are using Clojure?
I'm now learning Clojure and simplicity and power of lisp just blows my mind, really happy to write on it. But I wonder what of these books do you recommend to read to those people who are using Clojure?
If you ever wondered why Lispers were considered condescending, arrogant, self-absorbed dorks back in the old ways reading LoL might give you a few hints.
I can't recommend that Clojure people read Hoyte's masterpiece, because Clojure is the first "larger" Lisp without a completely horrible community and I'd like to keep it that way.
I can't recommend that Clojure people read Hoyte's masterpiece, because Clojure is the first "larger" Lisp without a completely horrible community and I'd like to keep it that way.
Oh, I didn't know about such "good" reputations of the lispers. Will check LoL just to get an idea why. Thanks
As a relatively recent user I can only add that the community around common lisp, while being fairly distributed, are a great bunch. I have found on average no more douches than occupy any community.
[deleted]
[deleted]
Let Over Lambda is opinionated, and at times, contrarian, which is the exactly kind of tech manual I enjoy reading.
The author's stance against Emacs in the appendix is surprising to find in a lisp book and resonated with me: "Emacs causes you to think about ways to write programs to do editing rather than write programs that write programs for you. You only need to script the process of editing when the code you are editing was redundantly written [...] Emacs has extension after extension, toy after toy, gimmick after gimmick for programmers to endlessly play with, be confused by, and get trapped in [...] The problem with emacs is its backwards philosophy. It treats editing as an end rather than a means. Editing itself is not an interesting process; it is what we edit that is interesting". The author prefers, not vim, but the simpler nvi. As a vi user that spent a great deal of time setting up slime and emacs, I wish I'd found more common lisp introductions that took an editor-neutral stance.
The author spends time disassembling CL code into assembly, replicating C's pointer arithmetic in lisp, jumping hurdles with macros, implementing a forth in CL, and in general, performing many other common lisp stunts which "blub" languages inefficiently handle.
The author's stance against Emacs in the appendix is surprising to find in a lisp book and resonated with me: "Emacs causes you to think about ways to write programs to do editing rather than write programs that write programs for you. You only need to script the process of editing when the code you are editing was redundantly written [...] Emacs has extension after extension, toy after toy, gimmick after gimmick for programmers to endlessly play with, be confused by, and get trapped in [...] The problem with emacs is its backwards philosophy. It treats editing as an end rather than a means. Editing itself is not an interesting process; it is what we edit that is interesting". The author prefers, not vim, but the simpler nvi. As a vi user that spent a great deal of time setting up slime and emacs, I wish I'd found more common lisp introductions that took an editor-neutral stance.
The author spends time disassembling CL code into assembly, replicating C's pointer arithmetic in lisp, jumping hurdles with macros, implementing a forth in CL, and in general, performing many other common lisp stunts which "blub" languages inefficiently handle.
> The author spends time disassembling CL code into assembly, replicating C's pointer arithmetic in lisp, jumping hurdles with macros, implementing a forth in CL, and in general, performing many other common lisp stunts which "blub" languages inefficiently handle.
Let Over Lambda is a great counter-example to the "Lisp is a very high-level language" myth, and IMO should be viewed and read as the successor to pg's On Lisp. The techniques and style of the code in LoL are a great example of what modern Common Lisp code looks like. It's a huge change from the Common Lisp code you read from the 1980s and 90s, and really different from code you see in any other language other than Racket and Scheme. The reader-macro/macro/closure DSL style of programming has just started to emerge over the last 15 years and I am excited about what other techniques come out of this style of coding.
Let Over Lambda is a great counter-example to the "Lisp is a very high-level language" myth, and IMO should be viewed and read as the successor to pg's On Lisp. The techniques and style of the code in LoL are a great example of what modern Common Lisp code looks like. It's a huge change from the Common Lisp code you read from the 1980s and 90s, and really different from code you see in any other language other than Racket and Scheme. The reader-macro/macro/closure DSL style of programming has just started to emerge over the last 15 years and I am excited about what other techniques come out of this style of coding.
> "Lisp is a very high-level language" myth
Lisp is as high-level as a fundamentally procedural language can go; it even kind of looks functional, and it's closer to being functional than procedural language styles which scatter globals everywhere and don't use abstraction very well (IOW, the kind of code assembly language programmers and/or EEs tend to write).
However, compared to Haskell or even OCaml, it sits firmly in the procedural world.
Lisp is as high-level as a fundamentally procedural language can go; it even kind of looks functional, and it's closer to being functional than procedural language styles which scatter globals everywhere and don't use abstraction very well (IOW, the kind of code assembly language programmers and/or EEs tend to write).
However, compared to Haskell or even OCaml, it sits firmly in the procedural world.
I really enjoyed this book as well. As a self taught lisp programmer it was like looking over the shoulder of the seasoned, expert lisp programmer I've always wanted to work with but have never had the chance to do so.
I agree with the anti-Emacs sentiment for the reasons he mentions even though I do use Emacs for lisp development and think it's pretty fabulous. I don't use any of the fancy lisp editing toys, like paredit etc, and I cringe when I see developers use Emacs or IDEs to write reams of boilerplate code for them.
I've found that I need to start manually typing out code that could potentially be automatically generated so that I have the time to come to the realization that I really shouldn't be writing that code at all.
I agree with the anti-Emacs sentiment for the reasons he mentions even though I do use Emacs for lisp development and think it's pretty fabulous. I don't use any of the fancy lisp editing toys, like paredit etc, and I cringe when I see developers use Emacs or IDEs to write reams of boilerplate code for them.
I've found that I need to start manually typing out code that could potentially be automatically generated so that I have the time to come to the realization that I really shouldn't be writing that code at all.
This book goes into some of the more advanced uses of macros and I don't believe most carries over to other "lisps".
I really loved the section on reader macros!! That's a topic that doesn't get enough attention from people coming to common lisp.
I don't believe clojure, for example, supports user defined reader macros, atleast I can't remember it having them the last time I used it(circa 2011).
EDIT, it looks like clojure does have reader macros now. Clojure just keeps getting better:)
http://en.wikibooks.org/wiki/Learning_Clojure/Reader_Macros
In addition to Let over Lambda, my common lisp reading list includes:
http://www.amazon.ca/Lisp-Small-Pieces-Christian-Queinnec-eb...
http://www.amazon.ca/Compiling-Continuations-Andrew-W-Appel-...
and http://www.amazon.ca/Paradigms-Artificial-Intelligence-Progr...
I'd love to hear if anyone else has book recommendations in a similar vein. I'm in the middle of a month off to read books and research papers so this is pretty timely for me:)