They Called It LISP for a Reason: List Processing (2005) • Hacker News Board

Re: They Called It LISP for a Reason: List Processing (2005)

#11

Post by sillysaurusx » Thu, Oct 13, 2022, 6:23 PM UTC

reikonomusha wrote: post #9

sillysaurusx wrote: post #7

Shared 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…

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

Re: They Called It LISP for a Reason: List Processing (2005)

#12

Post by dan-robertson » Thu, Oct 13, 2022, 6:35 PM UTC

cepher wrote: post #3

georgeoliver wrote: post #2

One 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?

I read it around 10 years ago without knowing any lisp and got on ok.

Re: They Called It LISP for a Reason: List Processing (2005)

#13

Post by jjtheblunt » Thu, Oct 13, 2022, 6:42 PM UTC

sillysaurusx wrote: post #10

jjtheblunt wrote: post #8

Earlier 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…

Great write-up (and that's from someone first doing Lisp in 1987, then lots of Scheme and tons of Mathematica, as well as all the compiled things)

Re: They Called It LISP for a Reason: List Processing (2005)

#14

Post by cnasc » Thu, Oct 13, 2022, 6:45 PM UTC

sillysaurusx wrote: post #10

jjtheblunt wrote: post #8

Earlier 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…

> if Lisp had been implemented using vectors and hash tables instead

Sounds a lot like Clojure

Re: They Called It LISP for a Reason: List Processing (2005)

#15

Post by User23 » Thu, Oct 13, 2022, 6:45 PM UTC

sillysaurusx wrote: post #10

jjtheblunt wrote: post #8

Earlier 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…

Lisp has had vectors and hash tables considerably longer than Python has existed.

It's a general purpose language, and any competent Lisper uses the right data structure for the job. As it happens, the cons tree (not a list, a tree!) is the right data structure for representing Lisp code. It's not necessarily the right data structure for representing other non-code data that Lisp code is working with.

Re: They Called It LISP for a Reason: List Processing (2005)

#16

Post by sillysaurusx » Thu, Oct 13, 2022, 6:46 PM UTC

jjtheblunt wrote: post #13

sillysaurusx wrote: post #10

Earlier 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…

Great write-up (and that's from someone first doing Lisp in 1987, then lots of Scheme and tons of Mathematica, as well as all the compiled things)

Incidentally, it wasn’t my idea. It was Scott Bell’s. I’m not sure if he thought of it or got it from somewhere else, but it’s wonderfully effective.

If you want to try it out for yourself, give Lumen a spin: https://github.com/sctb/lumen

His Postgres FFI is the prettiest lisp FFI you’ll ever see. https://github.com/sctb/motor/blob/master/pq.l

Re: They Called It LISP for a Reason: List Processing (2005)

#17

Post by G3rn0ti » Thu, Oct 13, 2022, 6:47 PM UTC

cepher wrote: post #3

georgeoliver wrote: post #2

One 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?

Two prehensile toes up! ;)

Re: They Called It LISP for a Reason: List Processing (2005)

#18

Post by sillysaurusx » Thu, Oct 13, 2022, 6:51 PM UTC

User23 wrote: post #15

sillysaurusx wrote: post #10

Earlier 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…

Lisp has had vectors and hash tables considerably longer than Python has existed. It's a general purpose language, and any competent Lisper uses the right data structure for the job. As it happens, the cons tree (not a list, a tree!) is the right data structure for representing Lisp code. It's not necessarily the right data structure for representing other non-code data that Lisp code is working with.

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]

?

Re: They Called It LISP for a Reason: List Processing (2005)

#19

Post by f1shy » Thu, Oct 13, 2022, 6:52 PM UTC

cepher wrote: post #3

georgeoliver wrote: post #2

One 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?

That is THE book I would recommend for beginners.

Re: They Called It LISP for a Reason: List Processing (2005)

#20

Post by User23 » Thu, Oct 13, 2022, 6:55 PM UTC

sillysaurusx wrote: post #18

User23 wrote: post #15

Earlier quoted context omitted.

Lisp has had vectors and hash tables considerably longer than Python has existed. It's a general purpose language, and any competent Lisper uses the right data structure for the job. As it happens, the cons tree (not a list, a tree!) is the right data structure for representing Lisp code. It's not necessarily the right data structure for representing other non-code data that Lisp code is working with.

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.lisp.se/Body/f_map.htm