Greenspun's tenth rule is a trap: to admit you follow it, you must evince dangerous lispish tendencies. But to deny you follow it, you must point to all your code and say, "Inquisitors! I defy you to find the tiniest spot of lisp in my unblemished codebase!"
Really, though, "Lisp" in this context means "Lisp at its best." Take a few months off your job, stay away from romance and fun, and just read the Common Lisp manuals and The Art of the Metaobject Protocol, and you too will understand Lisp At Its Best. And you will realize why List At Its Best probably can't be yours.
And if you start hassling other languages for not being Lisp At Its Best... why, is that really Lisp's fault? really?
Really, though, "Lisp" in this context means "Lisp at its best."
I'm not sure it does, so much as an ideal Lisp which Common Lisp and historical Lisp practice only imperfectly embody. For example, I think Clojure only recently discovered how Lisp macros are really supposed to be done -- I suspect the use of namespaces for hygene represents almost as much of a watershed moment as the switch to predominantly lexical scoping. Now that we've got about a century of art in terms of the design of turing-complete languages (counting the programs written for the Analytical Engine), it's become fairly evident that ideal-Lisp is a very significant attractor in language design. Probably not the only one -- ML/Prolog hint at another attractor out there. But in any case we can get closer to it than "Lisp at its best".
I was going to say no, but I'm not entirely sure. The two are weak attractors individually themselves. However, type specifications in ML dialects like Haskell are getting rather prolog-ish. There seems to be a certain synergy there. That might be my Haskell-bias showing though.
Well, what they have in common is that you can write a function in terms of pattern-matching on cases, as long as you sacrifice data representation abstraction; and they share an allergy to side effects. But Prolog is dynamically-typed and constraint-oriented/bidirectional, while ML (and Haskell) are statically-typed and functional. I think they're different enough that they belong to different families.
Think about the type domain in ML dialects. Hindley-Milner type inference -- particularly with the introduction of type class constraints as in Haskell -- starts to look a LOT like value-domain Prolog.
Say what? You can do a lot of interesting things with decidable languages. Sure, you can't do everything, but there's a lot you can express with linear-bounded automata.
When I posted that comment I thought someone might respond this way.
The extent to which HM type inference falls short of Turing-completeness is a bigger difference between it and Prolog than almost any other conceivable language feature. I'm pretty sure you can't emulate an LBA with HM type inference. You can't emulate a PDA or even a DPDA, as far as I know. You don't even have definite iteration (for i = 1 to 10).
I'd be on pretty shaky ground saying you can't emulate a FSM with HM type inference, but I also don't see how to do it.
This is the part where my knowledge of type systems falls down, and where I'd go dig out my copy of Pierce's Types and Programming Languages if I knew which box it was in, because I know Pierce gets into the decidability of the simply typed lambda calculus and what you can do with it, but I don't remember much of that chapter. It's one of those books I need to read five or six times before I really understand it.
Or rather, the two are near weak attractors individually. I don't think SML or the various flavors of Prolog approach ideal-ML or ideal-Prolog much more closely than Common Lisp does ideal-Lisp.
no subject
Really, though, "Lisp" in this context means "Lisp at its best." Take a few months off your job, stay away from romance and fun, and just read the Common Lisp manuals and The Art of the Metaobject Protocol, and you too will understand Lisp At Its Best. And you will realize why List At Its Best probably can't be yours.
And if you start hassling other languages for not being Lisp At Its Best... why, is that really Lisp's fault? really?
no subject
no subject
I'm not sure it does, so much as an ideal Lisp which Common Lisp and historical Lisp practice only imperfectly embody. For example, I think Clojure only recently discovered how Lisp macros are really supposed to be done -- I suspect the use of namespaces for hygene represents almost as much of a watershed moment as the switch to predominantly lexical scoping. Now that we've got about a century of art in terms of the design of turing-complete languages (counting the programs written for the Analytical Engine), it's become fairly evident that ideal-Lisp is a very significant attractor in language design. Probably not the only one -- ML/Prolog hint at another attractor out there. But in any case we can get closer to it than "Lisp at its best".
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
The extent to which HM type inference falls short of Turing-completeness is a bigger difference between it and Prolog than almost any other conceivable language feature. I'm pretty sure you can't emulate an LBA with HM type inference. You can't emulate a PDA or even a DPDA, as far as I know. You don't even have definite iteration (for i = 1 to 10).
I'd be on pretty shaky ground saying you can't emulate a FSM with HM type inference, but I also don't see how to do it.
no subject
no subject