Hacker News Reader

Comment by QuesnayJr | Hacker News Reader

I have sometimes wished that "locations" in Common Lisp were real lvalues, rather than an illusion made possible by macros.

View on HN

CL-LOCATIVES [1] make these first-class values. It essentially turns any setf-able place into a mutable pointer.

[1]: https://github.com/stylewarning/cl-locatives

You know, what's wild is that Lisp machines had kernels and garbage collectors implemented in Lisp too, making heavy use of locatives as raw pointers to implement basic system functions like writing to IO devices and doing garbage collection. It's wild that we all think the primitive -> managed stack (ASM, then C/Rust/C++/etc., then Java/C#/Python on top) is somehow an intrinsic property of computation, but there are multiple existence proofs (of which the lisp machine is one) of whole computing stacks implemented in managed code and working just fine.

Conventional wisdom: "No... no... no... you can't implement an OS kernel in managed code" Lisp machine OS authors: "Hold me beer. [Laughs in 1970s]."

Most Lisp systems, be it Lisp Machines, or modern Common Lisp implementations do the same. The Lisp Machine didn't really have a kernel though, unless you call the microcode that implemented the Lisp Machine macrocode "engine". As for I/O, that was just memory mapped .. you write/read to some magic number.

What is wild was invisible pointers ...

    A forwarding pointer specifies that a reference to the location containing it should be redirected to another memory location, just as in postal forwarding. These are also called invisible pointers.

(Not a member of the "we wall think we can't implement systems in managed code" club -- there are plenty of such systems dating back to before Unix :-) )

Yep. That era was like the Ediacaran biota of operating systems design -- tons of weird and wonderful forms we struggle to even classify in contemporary terms.

I mean yes up to a point, but how do you even maintain such a thing? Like, if your garbage collector was written by a bunch of really smart guys who made sure that it would never allocate during collection by just knowing the internals of your system really well, sure that's great, but then how would you even know when you'd broken that property? And the failure mode isn't great (you presumably get a very occasional deadlock when you just happen to run down exactly the wrong codepath during GC).

Most languages will let you bypass their layering if you want to. But it's usually ultimately a bad idea.

This looks like an almost expression-by-expression clone of:

https://www.kylheku.com/cgit/lisp-snippets/tree/refs.lisp [2012-01]

But that would be a language with completely different semantics.

CL still tries to preserve something from lambda calculus.

No, why? Earlier Lisps had locatives while preserving their semantics, and https://github.com/stylewarning/cl-locatives emulates this behavior (albeit with a slight performance hit).

What in Lisp exactly is similar to lambda calculus, though? Lisp isn't even a pure language.

And lambda calculus isn't even a programming language. The argument was like saying "C still tries to preserve something from Touring machine".

Reply on news.ycombinator.com