MakerLisp Machine
cpmaker.com
cpmaker.com
I would say that the main feature of a Lisp Machine is that you do everything from within Lisp.
I don't know of any papers on the Symbolics hardware that are not behind the ACM paywall, how much did it really differ from the other Lisp Machines ?
Lisp is good as a language for humans, and it used to be used in hardware because that was necessary to run lisp code fast. That hasn't been the case for ages.
Hipsters?
What modification or addition to the CPU (or wider computer architecture) would be most effective in making typical lisp programs run faster?
Or does it need hardware parenthesis support too? ;)
http://pages.cs.wisc.edu/~markhill/papers/computer86_spur.pd...
The basic instructions (Table 3) are close enough to RISC-V but it also had a few Lisp specific instructions (Table 4). Though the name J Extension for RISC-V might lead you to think it is only about Java or Javascript, the group working on it is also interested in making it as good as possible for Lisp.
Not too unrelated: I have an unused HP Stream 11 and I have had good intentions of having Mezzano boot directly in it. So far, I just have run Mezzano (Common Lisp directly on hardware) with VirtualBox.
Here's a HN thread from 2016: https://news.ycombinator.com/item?id=12358177
I want to give Mezzano a shot once I (finally) get through SICP.
1. Boots directly into the REPL.
2. Built-in drawing commands, but no GUI.
3. Memory mapped screen / sprites (with multiple graphics modes). With peek and poke like functions.
4. Has an enclosure / keyboard similar to a C64. A simple all-in-one look may make the device more approachable.
5. Simple/constant CPU to provide a path to learning assembly. The reason I'd want to avoid an FPGA is that it'll eventually lead to fragmentation, which means that peer-based learning becomes more difficult.
6. Socketted COTS chips that are well documented and will likely be available for a long time.
7. Open source, with all code available on the machine. I'd like to encourage curiosity as much as possible (and not being able to read the source is an instant blocker).
8. HDMI output.
9. Included joystick with a potentially non-standard port (x2). This is to permit the sharing of games with minimal fuss. Alternatively, use the port from the first xbox.
10. A similar environment / emulator on regular computers, to help the student transition to regular programming.
11. A good manual that explains how the machine works, gives examples, and provides possible avenues of exploration for the curious.
[0] Like many on this forum, basic was my first programming language. But I recognize it is only a matter of time until a programmer needs to abandon it. Any argument to use it as a teaching language has two factors: how simple is it to learn, and how much can be carried with the student. I think lisp would be slightly more difficult to learn, but I think it offers more long term value.
Programmers who are just starting out tend to have an incomplete picture of their environment. While we should encourage them to build up an understanding of it, we should recognize that doing so takes effort, and should ultimately be a positive learning experience.
Some of the best lessons come from trying to push hardware/software boundaries. But the lesson "version 1 didn't do that, only version 2+ does" isn't great. If we're talking about children or teenagers they may just conclude "mine's broken" and stop exploring. Worse still, blame themselves for problems they don't fully understand.
Without persistent storage, it was quite liberating to know that I couldn't really "break" things, since the default state would be restored by a reboot.
Maybe it's an advantage for a learning machine to have the system/OS be read-only (maybe with a physical switch to allow writes) and have data saved to removable media (e.g. microSD)? There's no way to mess up someone's data if it's kept outside the machine.
Smalltalk environments try to capture some of this spirit. If you do something really bad, you just re-start the image and replay the change log, leaving off the last entry.
But I'd also want saving to be through an external card that can be modified by a regular computer.
For the moment, I believe the ideal amount of RAM for an environment like this is one where the user doesn't hit the limit until they are attempting to do something ambitious (like a game). When that point hits, hopefully the RAM constraint is perceived as a challenge to be overcome, rather than a frustration.
For a lisp with an HDMI display, the amount of RAM would likely need to be in the megabyte range.
This gave me a crazy idea, cross-compiling one of the Lisps using CUDA to run accelerated directly on the GPU... Hmmm...
I don't and never will do bytecode on a virtual machine!