Thu Sep 6 00:25:26 CEST 2007
the parser can definitely be moved to streams. the fact that it
contains syntax streams is not really relevant to the structure of the
algorithms.. for example: i'm using 'match' in forth.ss
it changes a lot: the prototype of the parsers now is @stx ->
@stx. but the code should be a lot easier.
due to the linearity of forth / compositional code, writing a macro
transformer as a stream processor instead of a tree rewriter makes a
lot of sense actually..
the preprocessor will translate a token stream -> s-expressions.
occurances of syntax-case can be replaced by @match. which is exactly
what i avoided in a previous attempt.. maybe i should just create a
@syntax-case macro that's similar to the @match macro, taking
partially unrolled syntax streams.
hmm.. pure syntax-case is a bit clumsy.. but the 'no rest' parser
macro i'm using does fit pretty well.
something i've been talking about before:
syntax-case: matcher for compilation: merge 2 namespaces (pattern var + template)
match: matcher for execution: only a single lexical namespace
i don't know how to make the pattern more explicit, but it boils down
to something like this: if you're match together with quasiquote,
you're actually COMPILING something, not computing something.
in that case, pattern matching using syntax-case might be more
appropriate, even if you're not using scheme macros, because of the
merging of template and pattern namespaces. (which have to be mixed
explicitly using quasiquoting).
actually: syntax-case matches 3 namespaces:
- transformer namespace