Putting postforth-1 and postforth-2 on hold while a third, related, idea
percolates to consciousness. I've been experimenting in <A
HREF="../postforth-0/experimentation/">../postforth-0/experimentation/</A>
with the ELF file format, and building guaranteed-unique entries for each new
word. This will totally eliminate the collision problem in postforth-0 (other
Forths have this problem too, including colorForth 2001).
<P>
The current plan is to write the core of the language in postFORTH itself,
and use a Python script to compile it. When the language has reached a certain
stage of development, it will then be able to compile itself.
<P>
Some ideas are presented here, in no particular order.
<P>
Some of the goals: Easy to understand quickly how the system is built and how
it runs: transparency. Well commented, self-documenting. Very small core,
easy to port. Easy to disassemble/decompile. Good as a student language and
for serious applications. Use C operators where possible, to attract C
programmers into the Forth fold; Forth operators are no more and no less
inscrutable as those of C, so why have two completely different sets of
obscure gobbledygook?
<P>
Put a back-pointer in front of each block of code to its symbol table entry.
That way, even if a word is redefined, its old embodiments can be located.
Maybe a version number for each word can be stored there too. I was thinking
of storing the elf_hash of each word before the code block too but that would
be wasted space; it should be in only one location. Calculating the hash is
not an expensive operation, and this might be unnecessary anyway.