Peculiarities of "of" syntax

Peculiarities of "of" syntax

[Alejandro R. Mosteo]

Apologies if I asked this in the past. Sometimes I compose posts in my 
head and later forget to actually do anything about it.

The following GNAT 2019-rejected examples of iterating with the new "of" 
are giving me some pause if this is an oversight in the feature, a bug 
in the compiler, or actually intended for some good reason:

procedure Pro is
    type Int_Array is array (Positive range <>) of Integer;
    Arr : Int_Array := (others => 0);
begin

    -- 1)
    for Z of Arr loop -- of course valid
       null;
    end loop;

    -- 2)
    for Z of Int_Array'(Arr & Arr) loop -- also works
       null;
    end loop;

    -- INVALID

    -- 3)
    for Z of Arr & Arr loop
      --  Error is "missing loop"
      null;
    end loop;

    -- 4)
    for Z of (Arr & Arr) loop
       --  Error is "name expected"
       null;
    end loop;

end Pro;

The crux of the matter might be in 5.5.2, where an "iterator_name" appears:

iterator_specification ::=
     defining_identifier in [reverse] iterator_name
   | defining_identifier [: subtype_indication] of [reverse] iterable_name

http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-5-5-2.html

I get lost there; iterator_name links to "name" and stops there. In the 
AARM I was unable to find any obvious help and the original AI [0] 
actually says:

"The second [grammar production] requires an expression returning an 
array, or an object of a type which has aspects Default_Iterator and 
Iterator_Element specified"

and

"the expected type for the /array_/name is any array type."

A note here: these examples are with arrays for simplicity but I'm 
finding the problem with a custom "&" that returns iterable types, so 
the wording that applies is just after the previous phrase:

"the expected type for the /iterable_/name is any iterable type"

(I don't think that makes any difference anyway, but just in case).

 From some other related question [1] I need to review the master rules 
in 7.6, but my first instinct is that 3) and 4) could be legal if the 
loop is the master of the expression.

In conclusion: any insight on what's going on with 3) and 4)? Thanks!

[0] 
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0139-2.txt?rev=1.22&raw=N
[1] https://groups.google.com/d/msg/comp.lang.ada/veW6BNBGBfo/gDFwEsyyAgAJ

Re: Peculiarities of "of" syntax

[Jeffrey R. Carter]

On 1/11/20 7:05 PM, Alejandro R. Mosteo wrote:
> 
> procedure Pro is
>     type Int_Array is array (Positive range <>) of Integer;
>     Arr : Int_Array := (others => 0);
> begin
> 
>     -- 1)
>     for Z of Arr loop -- of course valid
>        null;
>     end loop;
> 
>     -- 2)
>     for Z of Int_Array'(Arr & Arr) loop -- also works
>        null;
>     end loop;
> 
>     -- INVALID
> 
>     -- 3)
>     for Z of Arr & Arr loop
>       --  Error is "missing loop"
>       null;
>     end loop;
> 
>     -- 4)
>     for Z of (Arr & Arr) loop
>        --  Error is "name expected"
>        null;
>     end loop;
> 
> end Pro;

There is clearly a compiler error (I get the same errors with GNAT 9.2.1). If I 
comment out the rejected cases, I get

$ gnatmake pro.adb
x86_64-linux-gnu-gcc-9 -c pro.adb
pro.adb:3:24: "others" choice not allowed here
gnatmake: "pro.adb" compilation error

as I expected. The declaration of Arr is invalid. The compiler should have 
reported that error even if some of the loops are invalid.

If I change line 3 to

    Arr : Int_Array (1 .. 10) := (others => 0);

then it still complains about the last 2 loops. I'm not familiar enough with the 
"of" syntax to know if that's expected or another compiler error.

-- 
Jeff Carter
"Friends don't let friends program in C++"
Zalman Stern
114

Re: Peculiarities of "of" syntax

[Robert A Duff]

"Alejandro R. Mosteo" <alejandro@mosteo.com> writes:

> The following GNAT 2019-rejected examples of iterating with the new "of"
> are giving me some pause if this is an oversight in the feature, a bug
> in the compiler, or actually intended for some good reason:

The syntax rules require a name after "of", and neither "Arr & Arr"
nor "(Arr & Arr)" are names.  The reason it didn't catch the incorrect
"others" is that GNAT doesn't run semantic analysis if there are syntax
errors (but there's a switch to make it do so).

- Bob

Re: Peculiarities of "of" syntax

[Alejandro R. Mosteo]

Yes, apologies about the array declaration error. That was part of an early attempt at an example, I tested it but then forgot to fix it when finishing the post. 

Fixing the array will give the errors I mention, and as you point out the grammar specifies a name. 

So the question would be, with a correct array, why a name is required instead of an expression, or why a qualified expression is good enough but an unambiguous plain expression is not.

A normal function call will work there too, so why not the poor infix operator... 

Re: Peculiarities of "of" syntax

[Robert A Duff]

"Alejandro R. Mosteo" <amosteo@unizar.es> writes:

> So the question would be, with a correct array, why a name is required
> instead of an expression, or why a qualified expression is good enough
> but an unambiguous plain expression is not.

The real question is, why are "name" and "expression" distinguished at
all in the syntax?  You're right: there's really no good reason
for this.  (Not specific to for/of.)

- Bob

Re: Peculiarities of "of" syntax

[Simon Wright]

"Alejandro R. Mosteo" <amosteo@unizar.es> writes:

> A normal function call will work there too, so why not the poor infix
> operator...

This is OK too:

   -- 3a)
   for Z of "&" (Arr, Arr) loop
     null;
   end loop;

(the switch Bob Duff mentioned, to do semantic analysis even if syntax
fails, is -gnatq)

Re: Peculiarities of "of" syntax

[Randy Brukardt]

"Alejandro R. Mosteo" <amosteo@unizar.es> wrote in message 
news:56cb7bc3-b966-4708-8cc7-657712d77047@googlegroups.com...
> Yes, apologies about the array declaration error. That was part of an 
> early attempt at an example, I tested it but then forgot to fix it when 
> finishing the post.
>
> Fixing the array will give the errors I mention, and as you point out the 
> grammar specifies a name.
>
> So the question would be, with a correct array, why a name is required 
> instead of an expression,
>or why a qualified expression is good enough but an unambiguous plain 
>expression is not.

A qualified expression, a type conversion, and a function call are all 
"names". You can always use a qualified expression to turn any "expression" 
into a "name".

> A normal function call will work there too, so why not the poor infix 
> operator...

The usual reason is that infix operators would make the grammar ambigious; 
that depends on what follows them. There are cases where that isn't a 
problem (this might be one of them). I don't think anyone was thinking about 
using expressions in this context, the intent was to iterate over an object.

Of course, Bob is right that the difference between "name" and "expression" 
(and similarly "value" and "object") are minor enough that it would be nice 
to eliminate them. (But it's also a lot of work, and we decided not to try 
for Ada 202x.)

                              Randy.