AST = Abstract Syntax Tree?
On 7/22/08, Michael FIG <[EMAIL PROTECTED]> wrote:
> 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
>
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
