Re: LR(1) grammar/parser and lookahead-restrictions

[Waldemar Horwat]

On 02/07/2017 06:39, Michael Dyck 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?


It's something else — it's directly tied into the generation of the automaton 
states.  Each automaton state contains a collection of possible places in the 
expansions of grammar rules that the state can represent.  Following a terminal 
symbol T from a state A leads to a state B.  A lookahead restriction prevents 
state B's collection from including expansions that would have been prohibited 
by the lookahead restriction on T.  If that generates an inconsistency (for 
example, if there are two ways to get to an identical state, one with a 
lookahead restriction and one without), the grammar validation fails.

Waldemar

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array Comprehensions

[kdex]

AFAIK, only TC39 members can champion a proposal.

If you're not a member, you could still write a proposal and hope that
some TC39 member is interested in championing it.

On Tuesday, February 7, 2017 5:05:49 PM CET Ryan Birmingham wrote:
> It wasn't clear from the documentation; who can or cannot be a champion?
> 
> -Ryan Birmingham
> 
> On 7 February 2017 at 10:49, Bob Myers  wrote:
> 
> > On Tue, Feb 7, 2017 at 6:58 PM, David Bruant  wrote:
> >
> >> At the very least, the proposal will be listed in the stage 0 proposals
> >> list [3].
> >
> >
> > My understanding is that a champion is required even to become stage 0.
> >
> 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array Comprehensions

[Ryan Birmingham]

It wasn't clear from the documentation; who can or cannot be a champion?

-Ryan Birmingham

On 7 February 2017 at 10:49, Bob Myers  wrote:

> On Tue, Feb 7, 2017 at 6:58 PM, David Bruant  wrote:
>
>> At the very least, the proposal will be listed in the stage 0 proposals
>> list [3].
>
>
> My understanding is that a champion is required even to become stage 0.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: LR(1) grammar/parser and lookahead-restrictions

[Isiah Meadows]

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  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

Re: Array Comprehensions

[Bob Myers]

On Tue, Feb 7, 2017 at 6:58 PM, David Bruant  wrote:

> At the very least, the proposal will be listed in the stage 0 proposals
> list [3].


My understanding is that a champion is required even to become stage 0.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: LR(1) grammar/parser and lookahead-restrictions

[Michael Dyck]

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

Re: Array Comprehensions

[David Bruant]

Le 06/02/2017 à 17:59, Ryan Birmingham a écrit :

Hello all,

I frequently find myself desiring a short array or generator 
comprehension syntax. I'm aware that there are functional ways around 
use of comprehension syntax, but I personally (at least) love the 
syntax in the ES reference 
(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Array_comprehensions).


The best previous discussion on this that I found was six years old 
(https://esdiscuss.org/topic/array-comprehensions-shorter-syntax) and 
answers some of my questions, raising others. That said, I wanted to ask:


  * Why is the Comprehension Syntax in the reference yet not more
standard? It feels almost like a tease.


Proposals to change the standard are listed here :
https://github.com/tc39/proposals
The process for a feature to become standard is described here :
https://tc39.github.io/process-document/


  * How do you usually approach or avoid this issue?
  * Do you think we should look at improving and standardizing the
comprehension syntax?

Some might argue it is yet another instance of "superficial sugar 
obsession" [1] :-p I don't know where I stand personally.


In any case, if you want to start, write down a proposal (can be 20 
lines in a gist [2]) including programs that are hard to express in 
JavaScript and which readability would significantly be improved with 
the new syntax.
Perhaps submit it to the mailing-list and try to find a "TC39 champion" 
(criterion to enter stage 1).
At the very least, the proposal will be listed in the stage 0 proposals 
list [3].


David

[1] https://twitter.com/mikeal/status/828674319651786754
[2] http://gist.github.com/
[3] https://github.com/tc39/proposals/blob/master/stage-0-proposals.md
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss