patterns.txt

[needs update - see doc/ramblings.txt for some more info]

an attempt to gather all the 'patterns' in pf. 

pf is evolved software, started from a vague idea, and designed by
implementation, in other words: a genuine mess :) this file tries to
present the ideas emerging from the mess.


FEATURES
* multimethod dispatch (polywords)
* simple object system (extensible in C, not in forth)
* linear data tree: containers = lists. 2 views: list = message (fixed
  length), while sequence of atoms = stream ("lazy list")
* reference count based memory management for packets: DUP increment
  refcount (packets = leaf nodes: cannot contain other things)
* containers (list) are always copied on DUP


* several interpretation levels, with runtime access to compilation
  and interpretation (reflection?)
  - strings (parse -> atom stream)
  - lists of atoms (unbound symbols)
  - internally: lists of bound pointers & data: only write accessible
    in forth (can't read compiled code, can only compile code)
  - native code (currently hand written C plugins, possibly later
    have this generated from PF)


THINGS THAT ARE NOT AS THEY SHOULD BE:
MISFEATURES (bit rot)
* too much handmade C code
  - lot of forth code is very redundant (i.e. stack.c), and C
    code generation (iterators) should be automated.
  - interpreter/parser could be made accessible from forth
* need a genuine object system:
  - multimethod dispatch could be improved. very naive atm.
  - type info spread over atom_t and packet_t: scalar/packet ambiguity
    (this can be left like it is: optimization relic which prevents
    the necessity of float/symbol/int/pointer objects.
* exception system (debug backtrace) is too ad-hoc


CONCRETE QUESTIONS

* object system:
  - how to implement multimethods?
  - how to improve backtrace and debug task support