[<<][staapl][>>][..]
Fri May 30 10:11:18 CEST 2008

the parser again

the problem is that parser macros defined in an .f file should have
immediate effect. can this be local-expanded or something?

i ran into this deeper problem: parsing isn't really factored when
being inside a single rpn macro: big reliance on dynamic
variables. can this be replaced by something else? probably not so
easy..

lets re-iterate over the expansion algorithm in PLT
Scheme. done.. basicly, it can fish out 'define-syntax' before
expanding the value expressions in 'define'.

so, maybe it should be a true preprocessing step like it was
before. one that converts the forth language to 'compositions' forms.

the thing is, inside a 'macro:' you really don't want any forth prefix
syntax. this should be s-expression syntax only. the only exception is
locals. -> probably best to separate the changes into those that
introduce new global names, and those that don't.

EDIT: not necessary. both data and code quotations are expressible in
s-expressions and part of the RPN syntax. local variables can be added
by using definitions like ((name param ...) body ...) instead of (name
body ...)

(locals are really special: they make sense only when parameterizing
bigger code chunks, with lots of parameter reuse..)


hmm... some things are not really very well disentangled yet.. maybe i
should accept that 1. macro is clean == enough,  2. the forth on top
of that has some hacks to support standard forth syntax on a system
that doesnt have forth's kind of reflection..

damn, this is complicated..

one remark about my method though: forth-tx is too complicated. i find
it difficult to make modifications because it is a hack on top of rpn
body creation. at this moment i don't really see how to change that
without introducing more than one abstraction layer..

maybe it needs a couple of days rest, i'm not coming up with anything
exciting here..



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