librelist archives

« back to archive

Different shared scope -> different parsers?

Different shared scope -> different parsers?

From:
Johannes Emerich
Date:
2010-10-20 @ 16:37
Hi Zach, hi all,

I am planning to write a Java (subset) interpreter in JavaScript and was 
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.

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.

I'd be grateful for any input on this. Thanks for your time!

Best,
Johannes

Re: [jison] Different shared scope -> different parsers?

From:
Zachary Carter
Date:
2010-10-21 @ 18:40
Hey Johannes,

On Wed, Oct 20, 2010 at 12:37 PM, Johannes Emerich <johannes@emerich.de>wrote:

> Hi Zach, hi all,
>
> I am planning to write a Java (subset) interpreter in JavaScript and was
> 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
on.


>
> >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!
>
> Best,
> Johannes
>



-- 
Zach Carter