Index of /src/postforth-3

[ICO]NameLast modifiedSizeDescription

[DIR]Parent Directory  -  
[TXT]pf.py01-Mar-2004 04:05 3.1K 
[   ]pe.pyc03-Aug-2007 14:36 8.1K 
[TXT]pe.py15-Aug-2007 22:20 9.8K 
[TXT]pe.c29-Aug-2002 15:48 62  
[   ]pe28-Jul-2007 15:41 181  
[   ]min_pe06-Aug-2007 02:47 608  
[TXT]elf.py06-Feb-2006 11:34 3.2K 
[TXT]README.html19-Apr-2006 04:05 1.6K 
[   ]Makefile25-Aug-2007 09:25 132  
[DIR]FORTH/04-Mar-2016 16:53 -  

Putting postforth-1 and postforth-2 on hold while a third, related, idea percolates to consciousness. I've been experimenting in ../postforth-0/experimentation/ 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).

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.

Some ideas are presented here, in no particular order.

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?

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.