|
Up till now I've had three different virtual machines which is not a good sign; there really isn't any hard-coded rule that says you have to stick to one platform, but having three different VM but zero significant software to run on them is just plain stupid. I think it's mainly because a) instead of committing to one VM I kept on trying to make the “perfect” VM and b) I'm trying way too hard to imitate the people I look up to, which is almost never a good idea - especially in this case the situation and tolerance of things are way different.
To fully design implement a virtual machine (that's similar to a conventional physical machine) one would:
Design the machine;
Design the instruction set of the machine;
Write a simulator for the machine;
Design the assembly mnemonics for the instruction set;
Write an assembler for the mnemonics;
Implement higher-level languages or subsets of higher-level languages for this machine (e.g. PL/0 to make things simple);
Write new software or port existing software onto your machine;
And also there's this pipeline:
You designed the machine;
You designed the assembly language;
You implemented the assembler;
Just when you're about to implement higher-level languages you found some “improvements” of the original design of the machine that require you to change the instruction set/assembly language;
And thus the assembly language takes a long time to become stable; or maybe it never did before you give up the project.
I say this is too much hassle for too little benefit. Even if (I think) I have made the perfect tradeoff when designing SRH CHAI, by the end of completing the assembler I was entirely worn out. This isn't the way I wanted.
I had this idea when reading (once again) about Lispkit Lisp. Lispkit
Lisp is a tiny subset derived from the original LISP described in
With this new approach to computing basis I'm envisioning I'll design a subset of R4RS Scheme that one can implement with relatively little hassle; to preserve this subset there will be a language report fully specified with as-formal-as-possible semantics. This new basis I'll be working on shall from now on be called “Basis Nova”, and everything that happened before shall from now on be called “Basis Antiqua”.
So does implementing Chifir (remember, to develop for Chifir I had to implement the whole toolchain as well); it's hard to say which takes more effort.
I'm thinking that to make a proper basis I need to make:
A relatively small language (somewhere between Lispkit Lisp and R4RS
Scheme) with good module system (very important!); the module system
should be at least better than the whole #ifndef BLAH #define
BLAH #endif
nonsense in C.
A bigger language that has more built-in stuff and a few syntax sugar; this language shall be entirely implemented with the small language mentioned above and directly uses its infrastructure (e.g. it could just be a parser on top of the small language)
You know how the Smalltalk people do their development and publish their changes within the Smalltalk environment itself? I would like to adopt that with straight-forward way to get changes out and into the environment so:
One could track the change using conventional version control
tools like
One could edit the code outside as well with
conventional editors like
SRH Chifir isn't going to be deprecated because the original goal was only to preserve Smalltalk-72; this will be done but it will probably take years before it's done. I'm probably going to completely deprecate SRH Oberon & SRH CHAI in favor of Basis Nova.
2023.6.18 |