Re: Interesting article on ARG work

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 18-04-08 22:48 , Dan'l Miller wrote:
> On Sunday, April 8, 2018 at 2:46:15 AM UTC-5, Dmitry A. Kazakov wrote:
>>     if Foo then
>> @     Bar;
>> @  end if;
>> @  if Boo then
>>        Baz;
>>     end if;
>>
>> would not be legal either.
>
> Where ␠ is the ASCII/ISO646 space character (presented as
> a graphical character for visualization herein),
>
>     if Foo then
> ␠     Bar;
> ␠  end if;
> ␠  if Boo then
>        Baz;
>     end if;
>
> and
>
>     if Foo then
> --     Bar;
> --  end if;
> --  if Boo then
>        Baz;
>     end if;
>
> both are legal Ada statements, spurious and non sequitur
> evocations of the ARM notwithstanding.

I'm sure that Dmitry understands fully how the "@" mechanism currently 
works in Janus/Ada: as a lexical marker that either makes the line 
visible to the parser and compiler, or makes it into a comment line that 
is essentially invisible (white space) to the parser and compiler.

As Randy showed, it is then easy to make editing mistakes that make one 
of the two resulting source-code forms grammatically incorrect.

I think Dmitry is suggesting that to avoid such problems, the inclusion 
or exclusion of code parts should not be done on the lexical level, line 
by line, but should be better integrated into the grammatical structure 
so that the included or excluded pieces of code would be whole 
grammatical structures, with grammatically defined boundaries.

> In general, Dmitry, you seem to not understand that a generalized
> left-right (GLR) parser would parse both sides of the @ concurrently.
> Your entire premise is that it is impossible to parse both presence
> and absence of @ at the same time.  In GLR, you are incorrect.

I don't think that GLR parsing solves this problem. Firstly, I assume 
that you are thinking of non-deterministic grammar rules in which  "@ 
<construct>" could be parsed either into "<construct>", understanding 
the "@" option as "enabled", or into whitespace, understanding the "@" 
option as "disabled". Well and good, but the GLR parser would apply this 
nondeterministic choice separately at each occurrence of a "@", so there 
would be an exponentially large set of alternative parse attempts.

For example, the text

     if Foo then
        Bar;
@   else
@      Baz;
     end if;

would be parsed in four ways, according to the four combinations of 
choices (enabled/disabled) for the two @ signs:

First way (disabled - disabled):

    if Foo then
       Bar;
    end if;

Second way (enabled - disabled):

    if Foo then
       Bar;
    else
    end if;

Third way (disabled - enabled):

    if Foo then
       Bar;
       Baz;
    end if;

Fourth way (enabled - enabled):

    if Foo then
       Bar;
    else
       Baz;
    end if;

Only the first and fourth ways correspond to how "@" works in Janus/Ada. 
The second way is even syntactically illegal, but an error message from 
a GLR parser would be quite confusing to a Janus/Ada user.

For GLR to work for this problem, you would have to extend it with some 
kind of "uniform choice" rule, by which all non-determinism depending on 
the use of "@" should follow a single, global, non-deterministic choice.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .