It's just interesting that in theory a CPU could be designed that didn't have the concept of memory as a sequential array of bytes.
In fact, in the future this will probably rear its head again. Managing storage at a higher level could make things like massively parallel computing, caching schemes and virtual memory more powerful.
Perhaps one day the elaborate hoops current CPUs and OSs have to jump through to maintain performance in the face of memory latency limitations will be surpassed by something like this, and just as C is best suited as a systems programming language for a flat memory model, so a language like lisp will be best suited to low-level programming for this new architecture.
https://en.wikipedia.org/wiki/Lisp_machine
It would be interesting to see how to implement a Lisp machine for the modern day. For it to be useful, it should support some sorts of parallel-processing capabilities that conventional CPUs don't have. Perhaps pmap and preduce as SIMD instructions.
> For it to be useful, it should support some sorts of parallel-processing capabilities that conventional CPUs don't have. Perhaps pmap and preduce as SIMD instructions.
A Lisp Machine can be useful without that or with different architectures. In those days there were quite a few attempts to speed up Lisp. Thinking Machines sold the ultimate Lisp accelerator: the Connection Machine. Stuff like that was mind-blowing and mind-blowing expensive.
Remember, a useful Lisp Machine in the early 90s had a 40 Mhz cpu with 40bit architecture, a graphics accelerator for a second screen, 40 or more megabytes of memory, a 400 MB disk, 10Mbit/sec Ethernet, 5 Mbit/sec SCSI, ...
Today we get already multiples of those numbers for tiny money and a 64bit processor. Lisp runs nicely when implemented natively.
