[<<][staapl][>>][..]
Thu Mar 27 08:27:14 EDT 2008

forth-tx.ss and macro-lang.ss

note that 'macro:' is really for brood style macros (postponed target
words) but the forth-tx in itself is more general. maybe move it to
separate directories? in short: those 2 need to be bound, at the
forth-lang.ss level, (which should be purrr), because they are
orthogonal upto there.

yes, it's a good time to decide how to make behaviour pluggable. for
microcontroller targets, most of the forth code can be shared.

forth uses 'compile' and 'literal' from the underlying target. so
should it be a unit? it's only 2 names, let's first pass them in
through function/macro.

let's reach for the bottle: dynamic binding. it solves all your
problems! ;)

but, in this case it might make sense. units are really overkill, and
to have some default is interesting for testing. i guess if the
bindings themselves are isolated, they are easy to change later.

so what to separate:
   - macro    (representation of postponed code + pattern matcher)
   - forth    (forth syntax on top of macro)
   - purrr18  (code specific for PIC18)

so.. got macro separated. now trying to make a Forth layer on top of
SCAT. note that here 'imperative' code should be possible! that's
something to fix later. until then only declarative code.

OK. scat-forth.ss is working!




[Reply][About]
[<<][staapl][>>][..]