Shame it didn't keep the coolest part of colorForth - the colors!
You change the meaning of word by changing their colors (is it a a 'runtime' function, macro or number? green, cyan or yellow), and the when you input the colors you also let the editor in a sense pre-compile the code so the interpreter becomes insanely fast.
The colors are in reality a byte prefix that acts as an index into a jump table so hardly any interpreting needs to happen, almost like a half-jit'ed language.
Also uses a weird encoding for text instead of ascii - it's a variable sized shannon encoding to make the most frequent english characters take fewer bits, from 4 to 7 bits.
This is imo the real spirit of Forth - simplify, simplify, simplify, make it an exact custom fit for your needs, screw standards.
not the author but afaiu r3 uses the "color" concept:
tokens are tagged by type via 8bits (number literal, string, word call, word address, base word, …)
and the interpreter dispatches using these bits
it just doesn't use the colors visually in the editor and uses prefixes instead (" for string, : for code definition, ' for address of a word, …) which also means the representation in the editor matches that of the r3 source in files.
Shame it didn't keep the coolest part of colorForth - the colors! You change the meaning of word by changing their colors (is it a a 'runtime' function, macro or number? green, cyan or yellow), and the when you input the colors you also let the editor in a sense pre-compile the code so the interpreter becomes insanely fast.
The colors are in reality a byte prefix that acts as an index into a jump table so hardly any interpreting needs to happen, almost like a half-jit'ed language.
Also uses a weird encoding for text instead of ascii - it's a variable sized shannon encoding to make the most frequent english characters take fewer bits, from 4 to 7 bits.
This is imo the real spirit of Forth - simplify, simplify, simplify, make it an exact custom fit for your needs, screw standards.