Thu Sep 6 00:25:26 CEST 2007

linear parser

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:
- pattern
- template
- transformer namespace