In case you are wondering where I am going with Tachyon, and if I am going, then yes, Tachyon is an active project. So here are some plans and ideas for a new version to round out 2020.
There are a few idiosyncrasies I'd like to clean up in V5 NEON and also other improvements I'd make including making it more compatible with TAQOZ etc. For instance I have some weird stuff that happens on user input where you need to hit the enter twice but that's more to do with the experimental input method that was used. Then there are the different types of constants, and there is the INTERCOM that needs to be checked and upgraded. As I look at how I use the H and L I/O words using a pin mask from the stack I think that this should be more like TAQOZ where the mask/pin is specified by PIN etc. There are probably dozens of things I have forgotten but I'm sure you remember them so how about we work together on a version that has as few quirks as possible, is more compatible with TAQOZ, has proper signed/unsigned operations etc. Perhaps we can find "the most useless function" and show it the door while ushering some fresh faces in. This is everyone's chance to have some input, and hopefully some output. I might even github it if necessary.
I can't do much with the dictionary and in the past I moved most of it into EEPROM but even with the smart caching methods it still slowed down compilation a bit much for my liking. The way it is now it takes up about 7k with EXTEND and EASYFILE which isn't too bad. Moving it out of hub makes it nigh impossible to distribute an easy to use single binary. Logically, if we were using EASYFILE then at this point it is a larger more complex system and we would want to optimize RAM as much as possible. This is where the bulk of the dictionary could end up in a file and SD is so much faster to access than EEPROM. I could cache dictionary entries in a small buffer in RAM that is searched first and indeed new entries would be added there and the entry marked dirty for processing at some point, and certainly when a BACKUP is executed.
Bear in mind too that Tachyon was not developed for Forth's sake, but for using the Prop effectively, which is why it is not so standard as some would like. But if it were then it wouldn't be as compact and fast as it is and while you could play with standard Forth on it, it wouldn't be as useful in real projects. So don't think like an ANSI committee, think like hackers and come up with the tools that get the job done. So it helps if you have a real project you are working on and you can see how it can work better which is how I have developed Tachyon so far.
The upgrade scope includes not just the kernel, but also EXTEND and EASYFILE as well. Current V5 code name is NEON. Since V3 I normally pick a 4-letter NASA mission but I'm not tied to that so let's see what we can call V6. Maybe ZOOM seeing it is an aspect of the year of covid19, and Tachyon is fast, although I am busy enough and in no hurry to upgrade it myself. I will let users set the pace and help document it at the same time.
Tachyon is not just a language, it is a whole development and runtime system that maximizes the usefulness of the Prop beyond what is normally possible.