Name | Last modified | Size | Description | |
---|---|---|---|---|
Parent Directory | - | |||
FORTH/ | 04-Mar-2016 16:53 | - | ||
min_pe | 06-Aug-2007 02:47 | 608 | ||
pe.pyc | 03-Aug-2007 14:36 | 8.1K | ||
pe | 28-Jul-2007 15:41 | 181 | ||
README.html | 19-Apr-2006 04:05 | 1.6K | ||
elf.py | 06-Feb-2006 11:34 | 3.2K | ||
Makefile | 28-Jan-2006 17:55 | 132 | ||
pf.py | 01-Mar-2004 04:05 | 3.1K | ||
pe.py | 05-Sep-2002 03:33 | 9.8K | ||
pe.c | 29-Aug-2002 15:48 | 62 | ||
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.