Just out of curiosity, what's the best way to handle async arrow function arguments vs `async` function calls? Is it term rewriting, or is there a better way of handling that? I'm much more familiar with recursive-descent and LL parsers than LR or shift-reduce ones, so I'm not as readily familiar with how to handle these cases. -----
Isiah Meadows m...@isiahmeadows.com On Tue, Feb 7, 2017 at 9:39 AM, Michael Dyck <jmd...@ibiblio.org> wrote: > On 17-02-06 07:32 PM, Waldemar Horwat wrote: >> >> On 02/04/2017 07:20, Michael Dyck wrote: >>> >>> On 17-02-03 05:32 PM, Waldemar Horwat wrote: >>>> >>>> On 02/03/2017 08:17, Michael Dyck wrote: >>>>> >>>>> On 17-02-02 06:23 PM, Waldemar Horwat wrote: >>>>>> >>>>>> >>>>>> Lookahead restrictions fit very well into an LR(1) engine >>>>> >>>>> >>>>> Again: Great, but how? E.g., do you pre-process the grammar, modify the >>>>> construction of the automaton, and/or modify the operation of the >>>>> parser? >>>> >>>> >>>> For each state × token combination, the automaton describes what happens >>>> when you're in state S and see a token T. The lookahead restrictions >>>> remove >>>> possible transitions; without them there would be ambiguities where a >>>> given >>>> state × token combination would want to do two incompatible things. >>> >>> >>> Okay, so do you generate the automaton (ignoring lookahead restrictions) >>> and then remove transitions (using lookahead restrictions)? Or do you >>> integrate the lookahead-restrictions into the generation of the >>> automaton? >> >> >> It's integrated. You can't generate a valid automaton without the >> lookahead >> restrictions. > > > So, when you're making LR items for a production with a > lookahead-restriction (l-r), do you: > > -- treat the l-r as a (nullable) symbol, so that you get an item with the > dot before the l-r, and one with the dot after, or > > -- treat the l-r as occurring between two adjacent symbols, so that you get > an item where the dot is "at" the l-r, or > > -- something else? > > > -Michael > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
