It might be as it started, however since 1970 that the various dialects support all common data structures.
They Called It LISP for a Reason: List Processing (2005)
21–30 of 125 posts
Re: They Called It LISP for a Reason: List Processing (2005)
#22Earlier quoted context omitted.
> Shared structure is overrated. Every MMU running a Unix with mmap probably disagrees!
You're right, I was imprecise. I meant specifically shared list structure in Lisp contexts, not shared structures in general. There's a fascination in the Lisp world for cons cells. Specifically the cell aspect. If you represent lists as: l = [x, [y, [z]]] Then you can implement car as l[0] and cdr as l[1]. If you require mutable cons cells, that's pretty much the only way to do it. Because if you want to set the car…
Without having any idea of this, right now I'm facing the problem of making a PDDL compiler (which is basically Lisp) in C++ , and this was the way I took. Lists are just std::vectors> and the variant can be a function, number (literal) or a variable.
Re: They Called It LISP for a Reason: List Processing (2005)
#23Earlier quoted context omitted.
Yes, but cdr(vector(1, 2, 3)) throws an error in almost all lisp implementations. Which means you can’t use the classic algorithms on them, like map. It’s worth considering carefully why you feel cons cells are so important for lisp code. Nested vectors are trees. Why not represent (define (foo x) x) as [define, [foo, x], x] ?
> Yes, but cdr(vector(1, 2, 3)) throws an error in almost all lisp implementations. Which means you can’t use the classic algorithms on them, like map. What? MAP[1] works just fine with vectors and other sequence types. Are you somehow surprised that MAPCAR doesn't? The name makes it pretty obvious I'd think. I'm starting to think you just lack familiarity with the language that you're criticizing. [1] http://clhs.li…
Suppose Lisp were forced to abandon cons cells and could only use vectors to represent code. What's the disadvantage?
My retort to you would be "I'm starting to think you like complexity for the sake of it," but debates are much more fun when we're both genuinely interested in the other's perspective.
Re: They Called It LISP for a Reason: List Processing (2005)
#24One of the best programming books (for any language) ever written IMO. Seibel has a knack for clear, readable but still technical prose that's all too rare unfortunately.
I’ve been meaning to read Practical Common Lisp for some time. Would you recommend this even for complete beginners to Lisp?
Practical Common Lisp is a fantastic read, but Common Lisp: A Gentle Introduction to Symbolic Computation gets my vote as the best book for Common Lisp beginners. Working through it was a joy.
Re: They Called It LISP for a Reason: List Processing (2005)
#25Earlier quoted context omitted.
You're right, I was imprecise. I meant specifically shared list structure in Lisp contexts, not shared structures in general. There's a fascination in the Lisp world for cons cells. Specifically the cell aspect. If you represent lists as: l = [x, [y, [z]]] Then you can implement car as l[0] and cdr as l[1]. If you require mutable cons cells, that's pretty much the only way to do it. Because if you want to set the car…
Without having any idea of this, right now I'm facing the problem of making a PDDL compiler (which is basically Lisp) in C++ , and this was the way I took. Lists are just std::vectors > and the variant can be a function, number (literal) or a variable.
No way! Is the code available anywhere? I was messing around with this idea too but didn't have the time. That's fantastic. :)
std::variant is really tricky, mostly because of C++'s type system. I went with std::any. My attempt is here: https://gist.github.com/shawwn/63e0f010479efd95ebffdf2108645...
I'd love to see your code and compare notes! Mine is pretty crummy; I'm not sure there are any worthwhile ideas in it. Did you have much trouble with the std::variant route?
Re: They Called It LISP for a Reason: List Processing (2005)
#26It might be as it started, however since 1970 that the various dialects support all common data structures.
I think the point to take home here is that LISP has a rich set of functions and building blocks around lists. Indeed, if you have something you want to do to a list, that function probably already exists.
Contrasted with many other languages that are catching up, but sometimes have surprising amount of boilerplate to process data.
Re: They Called It LISP for a Reason: List Processing (2005)
#27Shared structure is overrated. The cases where you need a tree-like mutable structure are vanishingly small in modern times. Mostly it boils down to "just use hash tables." This isn't just a dismissive observation. It's the heart of why Lisp is so hard to implement. When I ignored mutable cons cells, I realized I could just implement bel in Python by using actual Python lists. t = True nil = None def car(l): if l: re…
Shared mutable state is an odd focus here. The point isn't that a cons cell is some magical thing. The point is that LISP gives you a ton of things that it already knows how to do.
Other languages have started catching up with massive standard libraries. But... LISP has been there for a long time.
Re: They Called It LISP for a Reason: List Processing (2005)
#28Earlier quoted context omitted.
I’ve been meaning to read Practical Common Lisp for some time. Would you recommend this even for complete beginners to Lisp?
I recommend the gentle introduction to Lisp book for the complete beginner. The chapter on files in the Practical Common Lisp book wasn't complete enough for me to read a one line file of 800MB which is part of the Harvard Library Open Metadata archived set.
I'm assuming you mean Touretzky's Common Lisp: A Gentle Introduction to Symbolic Computation —
http://www.cs.cmu.edu/~dst/LispBook/index.html
— which, yes, is a wonderful book for a complete beginner.
Re: They Called It LISP for a Reason: List Processing (2005)
#29Earlier quoted context omitted.
I fail to see why mutable cons cells has anything to do with the difficulty of implementing Lisp. @dataclass class Cons: car: Any cdr: Any You can define a nice printer or reader for it if you want, but mutability doesn't seem to be a hindrance in implementation.
You can, but then none of the Python libraries that expect Python lists can use your Cons as a list. I tried. It sucks. The conversion becomes a problem all over the place. isinstance(Cons(nil, nil), list) will fail, for example. I posted a more thorough answer here: https://news.ycombinator.com/item?id=33194570
This isn't a case of Lisp being hard to implement, this is a case of trying to make your Lisp work with Python language idiosyncrasies. These two issues have close to nothing to do with one another.
Re: They Called It LISP for a Reason: List Processing (2005)
#30Shared structure is overrated. The cases where you need a tree-like mutable structure are vanishingly small in modern times. Mostly it boils down to "just use hash tables." This isn't just a dismissive observation. It's the heart of why Lisp is so hard to implement. When I ignored mutable cons cells, I realized I could just implement bel in Python by using actual Python lists. t = True nil = None def car(l): if l: re…
> It's the heart of why Lisp is so hard to implement.
Lisp is hard to implement? The list processing core is very small and relatively easy to implement.