Re: [jison] Different shared scope -> different parsers?
- Zachary Carter
- 2010-10-21 @ 18:40
On Wed, Oct 20, 2010 at 12:37 PM, Johannes Emerich <firstname.lastname@example.org>wrote:
> Hi Zach, hi all,
> thrilled when I found out about Jison!
> The interpreter is going to be rather basic, implementing the core
> language, no threading, no generics and only doing basic CLI-style IO.
> Because the interpreter is supposed to work in the browser (as well as the
> CLI) and support several instances of simulated CLIs on one page, I intend
> to give each instance its own scope.
> For example, a Java source fragment like `System.out.println("str")` could
> be translated to `yy.System.out.println("str")` (ignoring types here for
> simplicity), with `yy.System` being an object with a reference to a DOM
> element that its output methods append to.
I use the yy variable to hang common functions I will need during parsing,
to process token strings or build the AST. It is also shared with your
tokenizer so state can be shared between tokenizer and parser actions.
From your example, it seems like you want to interpret the code during the
parsing phase, similar to the calculator example, yes? The traditional way
to implement an interpreter would be to build an AST during the parse and
then use that for interpreting and/or type checking and semantic analysis.
That is probably the most clean way to do it as well. Interpreting directly
in the parsing phase is simpler, though you may run into limitations later
> >From my understanding of Jison's structure this would require separate
> parser instances to be used, correct? I just want to check if there was
> maybe a more "proper" way to do this.
> It just occurs to me, that it might be enough to change the `parser.yy`
> reference before each call to `parser.parse`, given that there is no
> concurrency in my approach. I intuitively would prefer a cleaner approach,
> with parser instances being bound to their respective scope objects, though.
> Yes, using separate parser instances would be the best way. The yy variable
was not intended to be swapped like that. Perhaps a scheme where it becomes
read only after initialization would remove doubts.
> I'd be grateful for any input on this. Thanks for your time!