[<<][packetforth][>>][..]
Mon Oct 29 22:47:15 CET 2007

next refactoring run

were i to change PF for the better, what needs to change? rewriting is
not an option: too much knowledge encoded, and things depending on
it. same goes for PDP.

* it needs a new inner interpreter. i doubt i can make this change
  without messing up a lot, but i do need:
    - proper tail calls
    - a single quoting (literal) mechanism

* get rid of most preprocessor macros, or write macros in a fixed
  style so they can be parsed: i'd like to move the code base into
  s-expressions and try some automatic refactoring. PF is large enough
  to make this process non-trivial, but there are quite a lot of points
  where some automatic refactoring would be a good idea: i.e. to make
  atom and list structure accesses abstract. simply replacing every
  atom->t by type(atom) is already quite a challenge.

maybe i should use some specific C refactoring tools first to clean it
up some.

gulp @ verbosity. i just looked at libpf/forth.c and it's not going to
be easy!



[Reply][About]
[<<][packetforth][>>][..]