4 ms·

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-locati

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 https://github.com/stylewarning/cl-locatives

quotemstr 2y ago
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]."
- amszmidt 2y ago
  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 :-) )
  - quotemstr 2y ago
    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.
- lmm 2y ago
  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.
kazinator 2y ago
This looks like an almost expression-by-expression clone of: https://www.kylheku.com/cgit/lisp-snippets/tree/refs.lisp https://www.kylheku.com/cgit/lisp-snippets/tree/refs.lisp [2012-01]

quotemstr 2y ago

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]."

amszmidt 2y ago
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 :-) )
- quotemstr 2y ago
  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.
lmm 2y ago
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.

kazinator 2y ago

This looks like an almost expression-by-expression clone of: https://www.kylheku.com/cgit/lisp-snippets/tree/refs.lisp https://www.kylheku.com/cgit/lisp-snippets/tree/refs.lisp [2012-01]