Hi,
Ian Piumarta <[EMAIL PROTECTED]> writes:
> Jolt3 will also use a single framework for top-down parsing of
> source, intermeditate AST-to-AST
> analysis/transformation/optimisation, and bottom-up tree rewriting
> for concrete instruction selection.
I think this is one of the more exciting things happening in jolt3!
After staring at function/jolt3, I think I finally am grasping some of
the design you are working on. Here are some notes that I've made to
help other people understand, as well as to raise some questions I
have:
* "%" signs introduce end-of-line comments
* The first line of a grammar is an object declaration. Since
productions become methods on an object, grammars can inherit from
other grammars and thereby extend or override the parent's
productions.
* Grammars that don't inherit from other grammars should inherit from
Parser, which provides the infrastructure used by the generated .st
file.
* The "start" production/method is called by Parser>>parse:, so it's
the default production.
* "<SomeProduction>" matches a production against the current token
stream, and saves its results back into the front of the input
stream for further rules to process. So, you can build up a
pipeline with stuff like "<compile <optimise <parse>>>"
* "#(...)" in a rule matches a sequenceable collection (i.e. a Jolt
expression or a vector, or whatever)
* "#ident" matches a symbol
* The value of a production follows "->". "{ ... }" is an idst block
to evaluate. "`(...)", "(...)", or "VARNAME" are jolt values.
* Elements of a production can be captured in a variable by writing
":VARNAME" after them. If you want to capture a string of the
match instead of its value, write "$:VARNAME".
* QUESTION: "!" and "&" are predicates. For "&", if the element it
precedes evaluates to true, it matches, otherwise its clause fails
to match. "!" is the reverse: if the result is true it fails,
otherwise succeeds. (Is this accurate??)
* GrammarParser.g reduces a grammar to an AST
* g2st converts a .g file into an idst .st source file. It does its
work with PepsiGrammarGenerator.g, which inherits from GrammarParser
and walks the AST to print idst source code
Do you forsee any major changes to the grammar syntax? Once you have
it nailed down I'm eager to continue working on my C preprocessor
(I've been taking a break from it to enjoy the summer, as well as stop
investing in the jolt2 cul-de-sac).
function/jolt3/model.c also looks pretty appetizing. For those of you
on the list unfamiliar with it (I had the good fortune of witnessing
the whiteboard explanations), it's the beginnings of a new libid that
uses alists instead of vectors for vtables. This allows even more
sharing of implementation and insertion of methods in interesting
places. It also reduces the number of bootstrap objects.
BTW, I have been doing my homework and now have some promising ideas
for extensions to the object model (namely parameterisable garbage
collection compatible with thread-safe coroutines) that will probably
make the core simpler and more flexible. I think I'll wait to do
those experiments until after it's possible to write libid in Coke
syntax.
Ian, if there is anything that could be done to help expedite the work
you're doing, would you be able to describe that to the mailing list?
Hope all is well with you,
--
Michael FIG <[EMAIL PROTECTED]> //\
http://michael.fig.org/ \//
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
