Let over Lambda – Common Lisp Book (2008)(letoverlambda.com)
letoverlambda.com
Let over Lambda – Common Lisp Book (2008)
https://letoverlambda.com/
98 comments
I enjoyed this book. I personally did not find it condescending. Additionally, the implementation of a Forth interpreter in this book is the best introduction to Forth I've seen (even after years spent playing with Forth and reading one or two books on Forth). But I don't recommend this book as an introduction to (Common) Lisp.
I recommend this order:
1. Practical Common Lisp
2. On Lisp (kind of a big jump, so maybe check out ANSI Common Lisp)
3. Let over Lambda
4. Lisp in Small Pieces (especially if you want to implement a Scheme or Common Lisp)
With Common Lisp the Language (Guy Steele) and ANSI Common Lisp (Paul Graham) somewhere in the mix.
These are all excellent books and must-reads for anyone interested in programming languages and/or the Lisp family.
I recommend this order:
1. Practical Common Lisp
2. On Lisp (kind of a big jump, so maybe check out ANSI Common Lisp)
3. Let over Lambda
4. Lisp in Small Pieces (especially if you want to implement a Scheme or Common Lisp)
With Common Lisp the Language (Guy Steele) and ANSI Common Lisp (Paul Graham) somewhere in the mix.
These are all excellent books and must-reads for anyone interested in programming languages and/or the Lisp family.
- COMMON LISP: A Gentle Introduction to Symbolic Computation (1990)
- Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp (1991)
- Common Lisp Recipes (2015)
- Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp (1991)
- Common Lisp Recipes (2015)
> COMMON LISP: A Gentle Introduction to Symbolic Computation (1990)
Its a great book for people coming out of non computing backgrounds!!!
Its a great book for people coming out of non computing backgrounds!!!
And it's also available as PDF from the author's site:
https://www.cs.cmu.edu/~dst/LispBook/index.html
https://www.cs.cmu.edu/~dst/LispBook/index.html
Good list. Practical Common Lisp deserves that spot at the top. It's very approachable and provides examples of all those features you keep hearing good things about. I remember running through the spam filter chapter and finding an email that SpamAssassin misclassified about four years prior.
I think my favorite Forth introduction comes at it from the other direction, though: https://github.com/nornagon/jonesforth/blob/master/jonesfort...
I think my favorite Forth introduction comes at it from the other direction, though: https://github.com/nornagon/jonesforth/blob/master/jonesfort...
That is a really impressive guide.
slightly related: the clasp/cando team has some news to share
Putting this here because I'm not aware of a lot of research done in/with lisp these days (only other thing I know is the quantum computer dsl)
https://old.reddit.com/r/lisp/comments/axu858/here_is_what_w...
> This our (thirdlaw.tech's) computational chemistry system Cando. Some might remember it from Lisp conferences or our previous videos. Here is a demo of going through a free energy perturbation calculation. FEP is very important in chemistry right now. https://www.youtube.com/watch?v=hZRuGt4TcD8&list=PLbl4KVdl9U...
Putting this here because I'm not aware of a lot of research done in/with lisp these days (only other thing I know is the quantum computer dsl)
https://old.reddit.com/r/lisp/comments/axu858/here_is_what_w...
> This our (thirdlaw.tech's) computational chemistry system Cando. Some might remember it from Lisp conferences or our previous videos. Here is a demo of going through a free energy perturbation calculation. FEP is very important in chemistry right now. https://www.youtube.com/watch?v=hZRuGt4TcD8&list=PLbl4KVdl9U...
That is me, I'm half of that team (Martin Cracauer).
If you have any questions I'd be happy to answer.
If you want to learn more about the programming side of our work (not so chemical), check out our other videos. They are from programming conferences: Longer talk: https://www.youtube.com/watch?v=8X69_42Mj-g&t=177s&index=3&l...
Shorter one from the LLVM meeting: https://www.youtube.com/watch?v=gYYH2zF41fc&list=PLbl4KVdl9U...
(yes, the whole system is a compiler using LLVM as the last stage to make machine code from abstract assembly. The thing I always missed in SBCL)
If you have any questions I'd be happy to answer.
If you want to learn more about the programming side of our work (not so chemical), check out our other videos. They are from programming conferences: Longer talk: https://www.youtube.com/watch?v=8X69_42Mj-g&t=177s&index=3&l...
Shorter one from the LLVM meeting: https://www.youtube.com/watch?v=gYYH2zF41fc&list=PLbl4KVdl9U...
(yes, the whole system is a compiler using LLVM as the last stage to make machine code from abstract assembly. The thing I always missed in SBCL)
It can be abrasive at times but is full of gems of knowledge. Well worth a read.
This nice book is a Lisp book but also a Forth book. Forth is great.
Is there a prominent open source project written in Common Lisp? Something like Pandoc for Haskell or RabbitMQ for Erlang?
There is StumpWM, a tiling Window Manager.
[0]: https://github.com/stumpwm/stumpwm
[0]: https://github.com/stumpwm/stumpwm
Allegro NFS is an NFS server for windows written in CL:
https://nfsforwindows.com/home
(It's open source but uses features of a proprietary CL implementation: https://github.com/franzinc/nfs )
https://nfsforwindows.com/home
(It's open source but uses features of a proprietary CL implementation: https://github.com/franzinc/nfs )
Common Lisp has a package manager/source repository called Quicklisp. https://www.cliki.net/Quicklisp%20tutorial
There are some web frameworks in there that are fairly impressive.
There is very little advertising going on. It goes a bit back to what your folks mentioned here, a bit of dejection and being condescending to other languages. Common Lisp is the only language with reasonable compile-time computing right now, and it is hard to bring that concept over to people who still think about writing software, as opposed to living with changing software for 30 years. So the Lisp community is a bit in the mindset that those who get it do so on their own, and software is distributed among those who already know they want.
The Cando chemical computation system (based on Clasp) in the video posted below/above is open source, BTW.
There are some web frameworks in there that are fairly impressive.
There is very little advertising going on. It goes a bit back to what your folks mentioned here, a bit of dejection and being condescending to other languages. Common Lisp is the only language with reasonable compile-time computing right now, and it is hard to bring that concept over to people who still think about writing software, as opposed to living with changing software for 30 years. So the Lisp community is a bit in the mindset that those who get it do so on their own, and software is distributed among those who already know they want.
The Cando chemical computation system (based on Clasp) in the video posted below/above is open source, BTW.
>Common Lisp is the only language with reasonable compile-time computing right now
How does D compare, with its CTFE (Compile-Time Function Evaluation/Execution)?
How does D compare, with its CTFE (Compile-Time Function Evaluation/Execution)?
Actually the whole cl-jupyter concept (used in the Cando demo) might also qualify. You can build really impressive blends of text-based statement and GUI in a webbrowser with Jupyter notebooks, and the CL version really kicks ass.
I need to get cracking on backporting the changes we made to cl-jupyter for Cando/Clasp to portable Common Lisp tho. Sigh. So little time.
I need to get cracking on backporting the changes we made to cl-jupyter for Cando/Clasp to portable Common Lisp tho. Sigh. So little time.
Thanks. As someone who is very much into Jupyter, this hits home! I don't know anything about chemistry, but the demo looks cool :)
pgloader [0] is one example.
Interestingly, it was originally written in Python, but the author decided to rewrite the entire thing in Common Lisp due mainly to Python's poor performance and the lack of native thread support. The result Common Lisp version is 30 times faster than the old Python one. More info can be found in the author's blog post [1].
[0] https://pgloader.io/
[1] https://tapoueh.org/blog/2014/05/why-is-pgloader-so-much-fas...
Interestingly, it was originally written in Python, but the author decided to rewrite the entire thing in Common Lisp due mainly to Python's poor performance and the lack of native thread support. The result Common Lisp version is 30 times faster than the old Python one. More info can be found in the author's blog post [1].
[0] https://pgloader.io/
[1] https://tapoueh.org/blog/2014/05/why-is-pgloader-so-much-fas...
Interesting and can actually come handy at work! Thanks
I bought Land of Lisp by Conrad Barski but never really read it due to procrastination. I really wanna read Lisp one day. Also, I didn't see Land of Lisp mentioned here. What do experience lispers think about it?
I have some experience with Common Lisp, although not too much. I have read Land of Lisp and enjoyed it very much. It may not adhere to software engineering best practices, such as avoiding mutating the global state, etc., but for learning CL without getting bored, this is the book.
I tried to read it as a first Lisp book, that was very theoretical. I just write Lisp these days while looking up what I need on-demand. Will probably give it another read when I have a better idea of what Lisp is.
letoverkappa(1)
>> it describes the most advanced features of the most advanced language: COMMON LISP
... really? the most advanced language (?), are we back in the 50ies again?
... really? the most advanced language (?), are we back in the 50ies again?
Common Lisp was finalized in the 90s. And it's not its fault that the other languages haven't caught up yet.
Still, its a trip to hell to maintain any lisp codebase -- especially if it contains macros. I think it is actively hostile to collaborative programming, and that is a structural problem where there is no remedy but obscure programming patterns (which are amplifying these problems in some instances). With that in mind -- boasting about 'the most advanced language' is a bit of a stretch -- to say the least...
Well, keep in mind that "macros" in Lisp are really compile-time computing.
In Lisp you have the same language at your disposal at runtime and at compile time. In C/C++ you have the preprocessor, which is a really lousy language. And in C++ templates. Remember the "template metaprogramming" hype about 10 years ago? How far did they go? Compute some prime numbers? I mean C++ templates are a compile-time language, but they are a language that has only one type - types and no real iterations over collection types. Wait, they have no collection types. The one and only type is types.
So, "macros" in Lisp are really a new capability, and they can make code very dense. But think about the alternative - rolling out all this code with generating it at compile time from a single point of origin. That is the real maintenance nightmare. Every time you make an assumption during programming you want to contain that assumption in a single place. So that when the assumption changes later (otherwise known as "always" when other people are involved in telling you what the program is supposed to do in the end) you change a single place, and the rest of the dependent code is generated at compile time - using the full programming language you chose.
I started a web series on compile-time computing. Didn't get as far as I wished for now, but here is some: https://medium.com/@MartinCracauer/a-gentle-introduction-to-...
I actually plan to use some of the chemical code I write (for the above mentioned Cando/Clasp chemical package) to make more parts of that series.
In Lisp you have the same language at your disposal at runtime and at compile time. In C/C++ you have the preprocessor, which is a really lousy language. And in C++ templates. Remember the "template metaprogramming" hype about 10 years ago? How far did they go? Compute some prime numbers? I mean C++ templates are a compile-time language, but they are a language that has only one type - types and no real iterations over collection types. Wait, they have no collection types. The one and only type is types.
So, "macros" in Lisp are really a new capability, and they can make code very dense. But think about the alternative - rolling out all this code with generating it at compile time from a single point of origin. That is the real maintenance nightmare. Every time you make an assumption during programming you want to contain that assumption in a single place. So that when the assumption changes later (otherwise known as "always" when other people are involved in telling you what the program is supposed to do in the end) you change a single place, and the rest of the dependent code is generated at compile time - using the full programming language you chose.
I started a web series on compile-time computing. Didn't get as far as I wished for now, but here is some: https://medium.com/@MartinCracauer/a-gentle-introduction-to-...
I actually plan to use some of the chemical code I write (for the above mentioned Cando/Clasp chemical package) to make more parts of that series.
> I mean C++ templates are a compile-time language, but they are a language that has only one type - types and no real iterations over collection types. Wait, they have no collection types. The one and only type is types.
There is Boost.Hana and the older Boost MPL and brigand.
C++20 will have more constexpr improvements.
Although I do conceed they require a C++ Wizard hat, and aren't not even close of Lisp's macros friendliness.
There is Boost.Hana and the older Boost MPL and brigand.
C++20 will have more constexpr improvements.
Although I do conceed they require a C++ Wizard hat, and aren't not even close of Lisp's macros friendliness.
They're looking at it from the point of one to a few coders and you're looking at it from an industrial view with larger teams. I think it probably shines more in the former. If macros aren't overused, it's probably not all that different from other dynamic languages like Python that work fine with larger teams.
It is very different than Python.
In Lisp, they say "here is a tool that can do anything. Have fun". In Python they say: "here are many tools that are specific and limited to that purpose. Also you gona take bad decisions, so we limited it some more".
The first approach is appealing to very good programmers. The second one, to anybody who had to work with the vast majority of normal programmers.
I prefer the second one. People abuse macros, make way to long lambdas, don't document their magic and indent poorly if they are not forced to.
Since tooling is something people always learn too late, I'm going with the language with sane defaults.
In Lisp, they say "here is a tool that can do anything. Have fun". In Python they say: "here are many tools that are specific and limited to that purpose. Also you gona take bad decisions, so we limited it some more".
The first approach is appealing to very good programmers. The second one, to anybody who had to work with the vast majority of normal programmers.
I prefer the second one. People abuse macros, make way to long lambdas, don't document their magic and indent poorly if they are not forced to.
Since tooling is something people always learn too late, I'm going with the language with sane defaults.
Yet Common Lisp nicely scales to very large programs, some which have been maintained for decades. MLOC range.
And I bet you $10k that mostly 10x programmers work on the code base. In fact, I've never seen an average Joe taking interest in Lisp, let alone learning it to the point of making a living with it.
And there is a limited pool of that.
We, humans, also have work to do.
And there is a limited pool of that.
We, humans, also have work to do.
> I've never seen an average Joe taking interest in Lisp, let alone learning it to the point of making a living with it.
Average Joe and Susi have been for 3+ decades nicely programming lots of extensions to AutoCAD and its various clones in Lisp.
Generally I agree that Lisp programming is a bit more challenging due to the slight mathematical nature (lambda, ...), code as data and meta-programming.
I don't think that one needs to be a 10x programmer to use Lisp - many of those 10x programmers are not programming in Lisp, since the 10x programmer gets hired because he/she might be able to cope with enterprise Java architectures.
Since Lisp is a programmer amplifier, you might think that these Lisp users are 10x programmers, when in fact they are not.
But there are domains where people are using Lisp, who are not focused on programming. For example there are various Lisp-based music apps + literature which are used by composers. Example: https://opusmodus.com
Average Joe and Susi have been for 3+ decades nicely programming lots of extensions to AutoCAD and its various clones in Lisp.
Generally I agree that Lisp programming is a bit more challenging due to the slight mathematical nature (lambda, ...), code as data and meta-programming.
I don't think that one needs to be a 10x programmer to use Lisp - many of those 10x programmers are not programming in Lisp, since the 10x programmer gets hired because he/she might be able to cope with enterprise Java architectures.
Since Lisp is a programmer amplifier, you might think that these Lisp users are 10x programmers, when in fact they are not.
But there are domains where people are using Lisp, who are not focused on programming. For example there are various Lisp-based music apps + literature which are used by composers. Example: https://opusmodus.com
>Average Joe and Susi have been for 3+ decades nicely programming lots of extensions to AutoCAD and its various clones in Lisp.
Ha ha, I read somewhere that years ago, in some org or the other, Emacs Lisp was programmed by secretaries to help them achieve their routine tasks. Apparently they were not told that it was "too difficult for them" :)
Ha ha, I read somewhere that years ago, in some org or the other, Emacs Lisp was programmed by secretaries to help them achieve their routine tasks. Apparently they were not told that it was "too difficult for them" :)
Bit late, but it was Multics Emacs and the language they were writing in was Maclisp.
Wow this opus modus tool looks super polished. I'd not mind paying for it, if it ran on windows!
I've heard about other tools like this before ([1] for composition, [2] for synthesis, [3] for mind-blowing :-p) but somehow never heard about opus modus before.
* Where did you learn about it?
* Are there other similar prog-lang music production tools with similar level of polish?
* Any cross-platform / Windows supported tools? -- unfortunately opus modus only runs on macs :-(
1: https://github.com/ctford/leipzig
2: https://github.com/overtone/overtone
3: https://extemporelang.github.io/
I've heard about other tools like this before ([1] for composition, [2] for synthesis, [3] for mind-blowing :-p) but somehow never heard about opus modus before.
* Where did you learn about it?
* Are there other similar prog-lang music production tools with similar level of polish?
* Any cross-platform / Windows supported tools? -- unfortunately opus modus only runs on macs :-(
1: https://github.com/ctford/leipzig
2: https://github.com/overtone/overtone
3: https://extemporelang.github.io/
There are a bunch of other tools written in Lisp or Scheme: OpenMusic, PWGL, Symbolic Composer (no longer available it seems), ScoreCloud, Common Music, Common Lisp Music, ...
Opusmodus was supposed to have a Windows version in 'the future', but I don't know what plans are currently.
Opusmodus was supposed to have a Windows version in 'the future', but I don't know what plans are currently.
Opus modus is listed as a lisp success story on a common lisp website somewhere.
The first approach is also appealing to very bad programmers who think they're good programmers.
Do you say that out of experience? That is certainly not my _experience_. Lisp codebases tend to be easily "appropiable"
It sounds more like someone's musing of why Lisp should be bad idea rather than anything practical. Doubly so when they don't seem to know what Common Lisp is.
I agree it _sounds_ like an armchair critic, but I prefer to give the benefit of the doubt. Maybe they had a bad experience involving Lisp?
The actively hostile to collaborative programming seems particularly misguided. Even an extreme case like the code from hu.dwim, which is written in practically a new language they built on top of CL and has barely any documentation is still fairly easy to understand.
The actively hostile to collaborative programming seems particularly misguided. Even an extreme case like the code from hu.dwim, which is written in practically a new language they built on top of CL and has barely any documentation is still fairly easy to understand.
Yeah, and the other thing is that the macrostep expander in slime makes it fairly straightforward to understand how an unfamiliar macro works: you just expand it a couple steps and see how its mapping the surface syntax to utilities you know. In fact, I often find function calls harder to grok now than custom macros :)
Yeah, Common Lisp is one of the few languages where I feel comfortable diving into a foreign code base and submitting patches.
http://www.greghendershott.com/fear-of-macros/fear-of-macros...
Which would easily make decades old and still maintained Lisp implementations unmaintainable, since they contain zillions of macros themselves.
Which would easily make decades old and still maintained Lisp implementations unmaintainable, since they contain zillions of macros themselves.
Macros are fine - 'creative' use of reader macros can result in something similar to C pre-processor abuse - opening a file and going "what language is this?".
Worth a read because it is one the most condescending computing books I have ever read. While reading I got the impression that I read the text of a really immature fanboy in a web forum of the 2000s.
I hope the author has matured by now. Seriously, don't buy this book.
I hope the author has matured by now. Seriously, don't buy this book.
I thought it was great, but I know it's not a book for snowflakes. When I hear someone say "this is right" or "this is wrong", I am able to effortlessly interpret this as "I believe this is right/wrong". It's just being efficient with language. I don't need people to add extra words for fear of offending me.
Maybe the author was immature. That's great. Let it remind you what it's like to be young and so excited about something that you'd write a book about it. This book is great.
Maybe the author was immature. That's great. Let it remind you what it's like to be young and so excited about something that you'd write a book about it. This book is great.
I'm a long time Lisper myself but also couldn't get through this book. Maybe it's because am a snowflake, but my eyes rolled so often I was scared they'll get stuck in the up position.
This is a big problem I have with books in general. Inevitably, the author drones on about some bullshit, and the book gets thrown across the room, never to be picked up again.
I agree.
Something that might be worth noting: two minutes of googling didn't turn up the author's age, but I recall seeing this photo on his website when I bought it some time after it was published in 2008: https://hcsw.org/contact.php
Here's a more up-to-date photo: https://hoytech.com/about
It's possible he was quite young when it was published. If that's the case, then I think the book is all the more a towering achievement. It's abrasive, and it smells a bit of 2000s forum fanboy discussions, but mature people should be able to read past the more opinionated parts and find the gems in the technical treatment.
Something that might be worth noting: two minutes of googling didn't turn up the author's age, but I recall seeing this photo on his website when I bought it some time after it was published in 2008: https://hcsw.org/contact.php
Here's a more up-to-date photo: https://hoytech.com/about
It's possible he was quite young when it was published. If that's the case, then I think the book is all the more a towering achievement. It's abrasive, and it smells a bit of 2000s forum fanboy discussions, but mature people should be able to read past the more opinionated parts and find the gems in the technical treatment.
>I thought it was great, but I know it's not a book for snowflakes. When I hear someone say "this is right" or "this is wrong", I am able to effortlessly interpret this as "I believe this is right/wrong". It's just being efficient with language.
Or, as we used to call it: "It's all about having had a few conversations with actual people in the actual world".
Or, as we used to call it: "It's all about having had a few conversations with actual people in the actual world".
Do you think it is useful for a Lisp noob?
No, it's not. Others have suggested other great books for beginners, like Practical Common Lisp. You'll get the most from Let Over Lambda after you've already got a bit of experience with Lisp.
Read On Lisp before Let Over Lambda, but after a beginner book like Practical Common Lisp.
I think it’s a great second book. For a first I’ve always recommended Practical Common Lisp. I don’t know if that recommendation is still up to date.
I would recommend it to a Lisp enthusiast as a third after On Lisp. That's how I read it, anyway.
Many things in LOL are quite opinionated. I don't think it's a distillation of knowledge (like On Lisp), but rather an exploration how far you can take some things (macros).
Many things in LOL are quite opinionated. I don't think it's a distillation of knowledge (like On Lisp), but rather an exploration how far you can take some things (macros).
As a reminder, Paul Graham's On Lisp is freely downloadable, in PDF or PostScript via links on this page at PaulGraham.com:
http://www.paulgraham.com/onlisptext.html
http://www.paulgraham.com/onlisptext.html
I'd simply give newbies this link http://stevelosh.com/blog/2018/08/a-road-to-common-lisp/
Yeah, that's an excellent — and modern — guide.
This book is sort of a trap because some of the macros it defines make assumptions that are not guaranteed by the language specification: every once in a while, you’ll find people on IRC or similar asking for help with some of the examples from this book.
Also, IMO, the defmacro/g macro defined in this book would have been better defined as a reader macro than as a codewalking macro.
Also, IMO, the defmacro/g macro defined in this book would have been better defined as a reader macro than as a codewalking macro.
If I recall somewhere around SBCL 1.2 they changed the way the backquote worked (totally fine for them to do that as it wasn't specified in the standard..) which broke the Let over Lambda macro.
I think CCL still works.
The code here should fix the problems : https://github.com/thephoeron/let-over-lambda
Note, it's been a while since I looked at it so I could have some of the details wrong. The book is still well worth reading to help you understand the possibilities with a programmable programming language, but just bear in mind the various caveats..
I think CCL still works.
The code here should fix the problems : https://github.com/thephoeron/let-over-lambda
Note, it's been a while since I looked at it so I could have some of the details wrong. The book is still well worth reading to help you understand the possibilities with a programmable programming language, but just bear in mind the various caveats..
> make assumptions that are not guaranteed by the language specification
I haven't read it, I have to confess. It would be useful if those assumptions were explicitly mentioned and explained in the book.
Some of the advanced macro stuff is easily outside of the standard and can be still useful, which for example lacks some of the environment features described in CLtL2.
I haven't read it, I have to confess. It would be useful if those assumptions were explicitly mentioned and explained in the book.
Some of the advanced macro stuff is easily outside of the standard and can be still useful, which for example lacks some of the environment features described in CLtL2.
Definitely not. The book expands on pg's books and a prior read is recommended.
https://letoverlambda.com/index.cl/guest/chap6.html
Yeah, the sixth chapter sure bashes on Scheme a lot. :/
Yeah, the sixth chapter sure bashes on Scheme a lot. :/
I always wonder if Common Lispers who bash Scheme know that Guy Steele (who also is the chairman of the Common Lisp standards committee) was the co-creator of Scheme.
I can't speak for others, but I know that, and I think that it is consistent, rather than inconsistent, with my points 1) that Scheme is fine as an academic language and 2) Common Lisp is preferable for real programs.
Scheme's simplicity is awesome if you're implementing it; it's awesome if you're learning it; it's not so awesome if you're trying to actually use it. As LoL notes, it's dumb to throw away information in conditionals. As LoL also notes, hygienic macros are toys and DEFMACRO is generally what you really want. I'll add that having only a single namespace for variables, classes, functions, types, packages & everything else means that you end up having to be extremely verbose: foo, fooClass, fooFunc, fooType, fooPackage. call/cc is incredibly cool & powerful, but also really hurts efficiency in a way that I don't think is acceptable in a production system (it's fine, of course, in a teaching language, because the experience of understanding it is really useful). dynamic-wind is broken compared to UNWIND-PROTECT.
And on & on & on.
Steele also wrote the Java spec, and he wasn't wrong when he said 'We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp,' but I don't think in 2019 anyone thinks that his involvement with Java means it is anywhere near as good, powerful or acceptable a language as Lisp.
Scheme's simplicity is awesome if you're implementing it; it's awesome if you're learning it; it's not so awesome if you're trying to actually use it. As LoL notes, it's dumb to throw away information in conditionals. As LoL also notes, hygienic macros are toys and DEFMACRO is generally what you really want. I'll add that having only a single namespace for variables, classes, functions, types, packages & everything else means that you end up having to be extremely verbose: foo, fooClass, fooFunc, fooType, fooPackage. call/cc is incredibly cool & powerful, but also really hurts efficiency in a way that I don't think is acceptable in a production system (it's fine, of course, in a teaching language, because the experience of understanding it is really useful). dynamic-wind is broken compared to UNWIND-PROTECT.
And on & on & on.
Steele also wrote the Java spec, and he wasn't wrong when he said 'We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp,' but I don't think in 2019 anyone thinks that his involvement with Java means it is anywhere near as good, powerful or acceptable a language as Lisp.
This is uninformed and wrong.
You can implement defmacro in 8 lines of syntax case. The opposite is not possible. Anything you can do with defmacro is possible using whatever lower level macro facility available in scheme (be it based on syntactic closures, implicit/explicit renaming or syntax case).
The extra complexity of dynamic-wind is required because scheme supports call/cc. You can easily limit dynamic wind to be comparable to unwind-protect, but that would render continuations useless for other things than escapes.
The single namespace has roughly one one common consequence: having to name your lists lst, which is easy. Types and classes are by convention <type>.
Continuations are cool and useful, although full blown ones are ugly. Delimited continuations are making their way into some schemes. In guile they are used to build guile-fibers, which are really cool.
The only thing common lisp really brings is cross-implementation compatibility. Compared to <your favourite scheme> it is mostly a matter of taste and, compared to some implementations, maturity.
You can implement defmacro in 8 lines of syntax case. The opposite is not possible. Anything you can do with defmacro is possible using whatever lower level macro facility available in scheme (be it based on syntactic closures, implicit/explicit renaming or syntax case).
The extra complexity of dynamic-wind is required because scheme supports call/cc. You can easily limit dynamic wind to be comparable to unwind-protect, but that would render continuations useless for other things than escapes.
The single namespace has roughly one one common consequence: having to name your lists lst, which is easy. Types and classes are by convention <type>.
Continuations are cool and useful, although full blown ones are ugly. Delimited continuations are making their way into some schemes. In guile they are used to build guile-fibers, which are really cool.
The only thing common lisp really brings is cross-implementation compatibility. Compared to <your favourite scheme> it is mostly a matter of taste and, compared to some implementations, maturity.
> You can implement defmacro in 8 lines of syntax case.
Even if that is so, that doesn't mean I want syntax-case. If I don't want syntax-case but do want defmacro, that requires a lot less code than implementing syntax-case (which I don't care for) and then eight more lines to get defmacro. (Are we talking with a defmacro that supports optional parameters, &environment? and how about macrolet? destructuring lambda lists)
Hygienic macros are basically wrong. A good way to express why they are wrong is by analogy. In visual art, as a joke, we can paint paintings that perpetrate deliberate errors of perspective: some feature obviously in a distant background reaches into the foreground in an incorrect way and overlaps or interacts with foreground objects.
There is precisely such an absurd situation between the lexical scope of a hygienic macro definition, and that of the macro call site.
The macro injects code into distant call sites, yet that code makes lexical references into the macro definition, like the silly character jumping out of an inner painting into an outer painting.
I don't ever want that; I don't want the code generating system (the macro) to be wrongly mixed up with the generated site. If the macro generates some symbol X, that should refer to an X definition that is lexically (or in any other manner) apparent at the call site, even if that is a bug. If I make that bug, I will own that bug.
I do want macro generated code to refer to a clearly defined set of run-time support symbols, if that is required, not coming from some random lexical scope enclosed in a macro definition, but from a global scope. Referring to a private scope of the macro definition is horribly wrong. That scope must completely die when the dust settles. It's not necessarily even on the same machine. When the macro is running and its scope is active, it's on some build farm. When the code is running, it's on a target system. Why would the target environment refer to the build environment?
No hacker interested in constructing practical systems from the ground up could have invented hygienic macros; they are an ironic joke coming from idle minds.
Even if that is so, that doesn't mean I want syntax-case. If I don't want syntax-case but do want defmacro, that requires a lot less code than implementing syntax-case (which I don't care for) and then eight more lines to get defmacro. (Are we talking with a defmacro that supports optional parameters, &environment? and how about macrolet? destructuring lambda lists)
Hygienic macros are basically wrong. A good way to express why they are wrong is by analogy. In visual art, as a joke, we can paint paintings that perpetrate deliberate errors of perspective: some feature obviously in a distant background reaches into the foreground in an incorrect way and overlaps or interacts with foreground objects.
There is precisely such an absurd situation between the lexical scope of a hygienic macro definition, and that of the macro call site.
The macro injects code into distant call sites, yet that code makes lexical references into the macro definition, like the silly character jumping out of an inner painting into an outer painting.
I don't ever want that; I don't want the code generating system (the macro) to be wrongly mixed up with the generated site. If the macro generates some symbol X, that should refer to an X definition that is lexically (or in any other manner) apparent at the call site, even if that is a bug. If I make that bug, I will own that bug.
I do want macro generated code to refer to a clearly defined set of run-time support symbols, if that is required, not coming from some random lexical scope enclosed in a macro definition, but from a global scope. Referring to a private scope of the macro definition is horribly wrong. That scope must completely die when the dust settles. It's not necessarily even on the same machine. When the macro is running and its scope is active, it's on some build farm. When the code is running, it's on a target system. Why would the target environment refer to the build environment?
No hacker interested in constructing practical systems from the ground up could have invented hygienic macros; they are an ironic joke coming from idle minds.
Having a macro in one module refer to bindings it has no idea about what they are seems nasty to me. I'd rather have hygiene and break it where I chose to. That seems less error prone.
That's just the thing. A macro calculates a datum. That datum doesn't refer; it's just a datum.
Of course, more usually we use a backquote, and insert interesting things into the template. The non-inserted template parts are data, just like in a quote.
We don't know whether b and c will ever refer. a will refer to some operator or function at the expansion site, which determines the meaning of b and c. In any case, none of them refer to anything while they are still inside the macro.
Hygienic macros implement a scheme whereby the quote is removed, and, wee, the datum does refer to the surrounding environment even though it's still supposedly a datum that will be inserted elsewhere where it becomes code. Although this has a touted benefit (the hygiene), it has a nasty implementation.
Just think about what it takes to have a (list ...) expression in a macro template still refer to the global list function that is in scope at the macro definition, even though the expansion site has defined a local list. Somehow we have to "wormhole" around the shadowing definition to reach that list. Now let's think about it in the context of separately compiled modules. How about the requirement for a macroexpand function for debugging macros: will the output be understandable?
There is an obvious down-side. While we have made the macro expansion immune to local shadowing definitions, the macro is now susceptible to its own. If we redefine list around the macro, it's referring to the wrong one.
A non-hygienic macro doesn't have this problem:
(defmacro foo()
'(a b c))
Of course, more usually we use a backquote, and insert interesting things into the template. The non-inserted template parts are data, just like in a quote.
We don't know whether b and c will ever refer. a will refer to some operator or function at the expansion site, which determines the meaning of b and c. In any case, none of them refer to anything while they are still inside the macro.
Hygienic macros implement a scheme whereby the quote is removed, and, wee, the datum does refer to the surrounding environment even though it's still supposedly a datum that will be inserted elsewhere where it becomes code. Although this has a touted benefit (the hygiene), it has a nasty implementation.
Just think about what it takes to have a (list ...) expression in a macro template still refer to the global list function that is in scope at the macro definition, even though the expansion site has defined a local list. Somehow we have to "wormhole" around the shadowing definition to reach that list. Now let's think about it in the context of separately compiled modules. How about the requirement for a macroexpand function for debugging macros: will the output be understandable?
There is an obvious down-side. While we have made the macro expansion immune to local shadowing definitions, the macro is now susceptible to its own. If we redefine list around the macro, it's referring to the wrong one.
A non-hygienic macro doesn't have this problem:
(defmacro foo ()
(labels ((list () ...)))
`(list ...,@(list ...))))
I understand what you mean, but I am not sure I agree. As a macro writer i either want to depend on the local definition explicitly (using datum->syntax in syntax case or not renaming in an er-macro-transformer). I also don't want to accidentally alter behaviour of macros if I happen to shadow a binding. I have made a version of racket's for loops that depends on expansion to other macros (to be able to split the complexity in smaller chunks). Having that expand unhygienically would open the macro up to subtle errors.
I also don't have to re-export bindings that I happen to use (like a specialised let from srfi-71 that supports multiple return values) and not changing let for whoever imports my library or polluting their namespace.
Expanding the macro in guile makes it clear in the generated code where things come from a (let ...) in the generated code gets expanded to ((@@ (loops for-loops) let) ...), Which is easily debuggable.
I just don't happen to see what you are describing about hygiene as a problem. It is the behaviour I want as a macro writer and the vast majority of time as a macro user.
The only big problems with it are 1. The Implementation sucks. The concepts are quite easy to grook, but hard to implement. 2. The hygiene has some edge cases where it might not protect you if you are writing very complex macros gluing quoted syntax objects together.
I also don't have to re-export bindings that I happen to use (like a specialised let from srfi-71 that supports multiple return values) and not changing let for whoever imports my library or polluting their namespace.
Expanding the macro in guile makes it clear in the generated code where things come from a (let ...) in the generated code gets expanded to ((@@ (loops for-loops) let) ...), Which is easily debuggable.
I just don't happen to see what you are describing about hygiene as a problem. It is the behaviour I want as a macro writer and the vast majority of time as a macro user.
The only big problems with it are 1. The Implementation sucks. The concepts are quite easy to grook, but hard to implement. 2. The hygiene has some edge cases where it might not protect you if you are writing very complex macros gluing quoted syntax objects together.
He was also heavily involved in Java.
"We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." -Guy Steele
https://news.ycombinator.com/item?id=2323963
"We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." -Guy Steele
https://news.ycombinator.com/item?id=2323963
I always wonder if Schemers who bash Common Lisp know that Guy Steele (the co-creator of Scheme) was also the chairman of the Common Lisp standards committee.
As others have noted its written in 'rant form' so its bound to happen. The weird thing is that it doesn't seem to bash on Perl at all! The Appendix on Editors bashes Emacs a lot too. Its an OK book _if_ you enjoy reading rants, but if you want to Learn Lisp, Practical Common Lisp or Land of Lisp are way better.
Or, you know, the author knows his stuff and is deservedly condescending in an industry of trends and cargo cults.
As in arts and politics, some curmudgeons are needed in every field, if not for anything else, to show that there's another way than the mainstream.
(They don't have to be perfectly right either -- it's having a strong perspective that counts, nobody is 100% right anyway).
As in arts and politics, some curmudgeons are needed in every field, if not for anything else, to show that there's another way than the mainstream.
(They don't have to be perfectly right either -- it's having a strong perspective that counts, nobody is 100% right anyway).
There are numerous great Lisp books by knowledgeable authors which have none of that attitude. Life is too short to read printouts of Usenet rants.
Well, to each their own. For me life's too short to read authors walking on eggshells.
Of course for a technical book it's the technical content that matters -- whether it's presented politely or not.
Of course for a technical book it's the technical content that matters -- whether it's presented politely or not.
In which way for example Siebel's PCL is "walking on eggshells"? On Lisp? PAIP? Am I super obtuse and missing some very obvious and important point they are tiptoeing around?
Even if one does really think it's important to convey they are presenting superior technology, it can be stated clearly and concisely without sounding corrosive.
Even if one does really think it's important to convey they are presenting superior technology, it can be stated clearly and concisely without sounding corrosive.
"Deservedly condescending" is not an actual thing that exists in the world.
The words you're looking for are "writes poorly."
The words you're looking for are "writes poorly."
>"Deservedly condescending" is not an actual thing that exists in the world.
There's absolutely no rational reason for it not to be a thing.
"Politely condescending" might be a contradiction in terms, but some people just lend themselves to being treated condescendingly.
Same thing with how some people might deserve a sarcastic response -- sarcasm is not that remote from condescension.
There's absolutely no rational reason for it not to be a thing.
"Politely condescending" might be a contradiction in terms, but some people just lend themselves to being treated condescendingly.
Same thing with how some people might deserve a sarcastic response -- sarcasm is not that remote from condescension.
This is an ironically condescending statement.
> it describes the most advanced features of the most advanced language: COMMON LISP.
I thought Haskell surpassed it a long time ago already.
I thought Haskell surpassed it a long time ago already.
So where's Haskell's advanced object system or the restart/condition system that Common Lisp has? Even its performance is hardly on par with CL for all the flexibility of the latter.
I'm not saying it has everything that Common Lisp has - it's different.
the world needs less objects, you know the koan `objects or closures: yes`
> So where's Haskell's advanced object system
Doesn't need one.
> restart/condition system that Common Lisp has
Utility is questionable, but you could build one in the continuation monad.
Doesn't need one.
> restart/condition system that Common Lisp has
Utility is questionable, but you could build one in the continuation monad.
Homoiconicity, Macro System, Battle Tested
Seibel's book is good, don't get me wrong; I just don't think its the proper pairing in the sense of culinary arts putting together a plate of well paired books.
The common lisp people and the clojure people fight viciously as only siblings can; this will infuriate those in the common lisp tribe but the ideal introductory lisp book in the general sense of the language is probably not Seibel's book its probably the comedic Clojure for the Brave and True. Not aware of anything quite like that, for common lisp.