Re: "&" for array versus "&" for Strings

Re: "&" for array versus "&" for Strings

[Grein, Christoph]

> > Has the OP reported this to ACT? I think he was using Gnat.
> 
> No I haven't. I don't know how to do it. Does anybody have a link to a
> document on reporting bugs? But if the bug I see has been changed from
> Gnat 3.14p to 3.16w then I think that one need to report the new bug in
> Gnat 3.16w?

The address to report bugs is
  report@gnat.com
but do not expect reactions if you're not a supported user.

But since even in 3.16w it's possibley not OK, send it in anyway. In the program 
below, only the qualified expressions and array aggregates compile.

procedure Preben is

  type String_Array is array (1 .. 2) of String (1 .. 3);

  procedure P (X: String_Array) is
  begin
    null;
  end P;

  S1: String_Array := "Ada" & "C++";                    -- not OK
  S2: String_Array := String'("Ada") & String'("C++");  -- OK
  S3: String_Array := ("Ada", "C++");                   -- OK

begin

  P ("Ada" & "C++");                    -- not OK
  P (String'("Ada") & String'("C++"));  -- OK
  P (("Ada", "C++"));                   -- OK

end Preben;

Re: "&" for array versus "&" for Strings

[Preben Randhol]

Grein, Christoph wrote:
> 
> The address to report bugs is
>   report@gnat.com
> but do not expect reactions if you're not a supported user.

I won't :-), but I guess they would like to recieve these reports so
they can improve GNAT :-)

> But since even in 3.16w it's possibley not OK, send it in anyway. In the program 
> below, only the qualified expressions and array aggregates compile.

OK sent it. Second time it seemed to get through (didn't know I had to
put GNAT in the subject :-) )

Preben
-- 
Ada95 is good for you.
http://libre.act-europe.fr/Software_Matters/02-C_pitfalls.pdf

Re: "&" for array versus "&" for Strings

[Grein, Christoph]

> There is no aggregate in this example.


Oops, you'r right, I thought a string literal was a short form of a character 
array aggregate. But the RM treats is separately and allows to replace array 
aggregates by string literals in certain circumstances.

So I think the unqualified Print_Names ("Ada   " & "Babbel"); should resolve OK. 
so Gnat is in error here.

Has the OP reported this to ACT? I think he was using Gnat.

Re: "&" for array versus "&" for Strings

[Preben Randhol]

Grein, Christoph wrote:

> Oops, you'r right, I thought a string literal was a short form of a
> character array aggregate. But the RM treats is separately and allows
> to replace array aggregates by string literals in certain
> circumstances.
> 
> So I think the unqualified Print_Names ("Ada   " & "Babbel"); should
> resolve OK.  so Gnat is in error here.
> 
> Has the OP reported this to ACT? I think he was using Gnat.

No I haven't. I don't know how to do it. Does anybody have a link to a
document on reporting bugs? But if the bug I see has been changed from
Gnat 3.14p to 3.16w then I think that one need to report the new bug in
Gnat 3.16w?

Preben
-- 
Ada95 is good for you.
http://libre.act-europe.fr/Software_Matters/02-C_pitfalls.pdf

Re: "&" for array versus "&" for Strings

[Grein, Christoph]

If you are interested in problems with unexpected ambiguities of this sort, see 
my paper

http://home.T-Online.de/home/Christ-Usch.Grein/AdaMagica/Invitation.html

Re: "&" for array versus "&" for Strings

[Grein, Christoph]

procedure Array_Test is

  type Name_Array is array (Positive range <>) of String (1..6);

  procedure Print_Names (Names : Name_Array) is separate;

begin

  Print_Names ("Ada   " & "Babbel");
  Print_Names (string'("Ada   ") & string'("Babbel"));

end Array_Test;

> It seems to me that the "&" should resolve to the
> (string, string)-->Name_Array one, even without the "String'(...)"
> qualifications.  Apparently, the older compiler resolved it to the wrong
> one, and the newer one can't resolve it (which is an improvement, but
> still a bug).
> 
> I'm not surprised that such a bug has never been noticed before.  Most
> people don't write code that uses "&" to concatenate two Strings to
> produce something other than String!  First, it's confusing (to humans,
> I mean, in addition to compilers).  Second, it requires fixed-length
> strings, which is almost never what you want in an array.

I think only the first statement is ambiguous since the compiler is not allowed 
to lookk inside the aggregate to see what is is, a string or an array of 
strings.

With the second statment, it's clear the aggregates are strings, so it can 
resolve the "&" operator to the correct one returning Name_Array. The one 
returning String is out because Print_Names does not accept String.

Re: "&" for array versus "&" for Strings

[Robert A Duff]

"Grein, Christoph" <christoph.grein@eurocopter.com> writes:

> procedure Array_Test is
> 
>   type Name_Array is array (Positive range <>) of String (1..6);
> 
>   procedure Print_Names (Names : Name_Array) is separate;
> 
> begin
> 
>   Print_Names ("Ada   " & "Babbel");
>   Print_Names (string'("Ada   ") & string'("Babbel"));
> 
> end Array_Test;
> 
> > It seems to me that the "&" should resolve to the
> > (string, string)-->Name_Array one, even without the "String'(...)"
> > qualifications.  Apparently, the older compiler resolved it to the wrong
> > one, and the newer one can't resolve it (which is an improvement, but
> > still a bug).
> > 
> > I'm not surprised that such a bug has never been noticed before.  Most
> > people don't write code that uses "&" to concatenate two Strings to
> > produce something other than String!  First, it's confusing (to humans,
> > I mean, in addition to compilers).  Second, it requires fixed-length
> > strings, which is almost never what you want in an array.
> 
> I think only the first statement is ambiguous since the compiler is not allowed 
> to lookk inside the aggregate to see what is is, a string or an array of 
> strings.

There is no aggregate in this example.

There are two string_literals, and RM-4.2(4) says "...single string
type".  So I think this one should resolve OK.

> With the second statment, it's clear the aggregates are strings, so it can 
> resolve the "&" operator to the correct one returning Name_Array. The one 
> returning String is out because Print_Names does not accept String.

- Bob

RE: "&" for array versus "&" for Strings

[Steven Deller]

> There is no aggregate in this example.
> 
> There are two string_literals, and RM-4.2(4) says "...single 
> string type".  So I think this one should resolve OK.

Yep.  FYI, Apex 4.2 yields the expected result:

---- execute of /home/ctdellsr/apex/testpp.ss/prime.wrk/array_test

 1: Ada   
 2: Babbel

Re: "&" for array versus "&" for Strings

[Robert A Duff]

"Steven Deller" <deller@smsail.com> writes:

> > There is no aggregate in this example.
> > 
> > There are two string_literals, and RM-4.2(4) says "...single 
> > string type".  So I think this one should resolve OK.
> 
> Yep.  FYI, Apex 4.2 yields the expected result:
> 
> ---- execute of /home/ctdellsr/apex/testpp.ss/prime.wrk/array_test
> 
>  1: Ada   
>  2: Babbel

Cool.  Compilers don't "define" the language, but the fact this one
particular compiler agrees with my interpretation is some evidence
indicating I wasn't totally off the wall.  ;-)

- Bob

P.S. I haven't tried this example with our own (SofCheck's) AdaMagic
compilers.

Re: "&" for array versus "&" for Strings

[David C. Hoos, Sr.]

----- Original Message ----- 
From: "Grein, Christoph" <christoph.grein@eurocopter.com>
To: <comp.lang.ada@ada.eu.org>
Sent: October 08, 2002 6:53 AM
Subject: Re: "&" for array versus "&" for Strings


<snip>
> 
> Gnat 3.16w produces an error for this:
> 
> preben.adb:15:17: expected type "Name_Array" defined at line 4
> preben.adb:15:17: found a string type
> 
> With qualification, it works.
With gnat-3.14p and qualification it still fails, so it would appear that this
is a "bug" fixed in 3.16w.  Clearly, from a language standpoint, it is
necessary to disambiguate the & operator in the call to Print_Names, and
qualification of its operands does just that.
<snip>

Re: "&" for array versus "&" for Strings

[Sergey Koshcheyev]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message
news:mailman.1034079721.26410.comp.lang.ada@ada.eu.org...
>
> With gnat-3.14p and qualification it still fails, so it would appear that
this
> is a "bug" fixed in 3.16w.  Clearly, from a language standpoint, it is
> necessary to disambiguate the & operator in the call to Print_Names, and
> qualification of its operands does just that.
> <snip>

How does it disambiguate the "&"? I would understand if it selected function
"&" (Left, Right : String) return String, but from what you say, it seems
like it made the compiler select function "&" (Left, Right : "String (1 ..
6)") return Name_Array.

Sergey.

Re: "&" for array versus "&" for Strings

[David C. Hoos]

----- Original Message -----
From: "Sergey Koshcheyev" <serko84@hotmail.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Tuesday, October 08, 2002 8:56 AM
Subject: Re: "&" for array versus "&" for Strings


>
> "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message
> news:mailman.1034079721.26410.comp.lang.ada@ada.eu.org...
> >
> > With gnat-3.14p and qualification it still fails, so it would appear
that
> this
> > is a "bug" fixed in 3.16w.  Clearly, from a language standpoint, it is
> > necessary to disambiguate the & operator in the call to Print_Names, and
> > qualification of its operands does just that.
> > <snip>
>
> How does it disambiguate the "&"? I would understand if it selected
function
> "&" (Left, Right : String) return String, but from what you say, it seems
> like it made the compiler select function "&" (Left, Right : "String (1 ..
> 6)") return Name_Array.
That's correct.  Without the qualification of its operands, the compiler
selects
"&" (Left, Right : String) return String, which (correctly) returns an error
in
3.16w, but is erroneously accepted by 3.14p.
With  the qualification of its operands, the compiler selects
"&" (Left, Right : String (1 .. 6)) return Name_Array.

Re: "&" for array versus "&" for Strings

[Preben Randhol]

On Tue, 8 Oct 2002 10:46:39 -0500, David C. Hoos wrote:

> That's correct.  Without the qualification of its operands, the
> compiler selects "&" (Left, Right : String) return String, which
> (correctly) returns an error in 3.16w, but is erroneously accepted by
> 3.14p.  With  the qualification of its operands, the compiler selects
> "&" (Left, Right : String (1 .. 6)) return Name_Array.

Why is "&" (Left, Right : String) return String chosen over the "&"
(Left, Right : String (1 .. 6)) return Name_Array in this case?

-- 
Ada95 is good for you.
http://libre.act-europe.fr/Software_Matters/02-C_pitfalls.pdf

Re: "&" for array versus "&" for Strings

[Grein, Christoph]

> ------------------------------------------------------------------
> with Ada.Text_IO; use Ada.Text_IO;
> procedure Array_Test is
> 
>    type Name_Array is array (Positive range <>) of String (1..6);
> 
>    procedure Print_Names (Names : Name_Array) is
>    begin
>       for No in Names'First .. Names'Last loop
>          Put_Line (Integer'Image(No) & ": " & Names (No));
>       end loop;
>    end;
> 
> begin
> 
>    Print_Names ("Ada   " & "Babbel");
> 
> end Array_Test;
> ------------------------------------------------------------------
> 
> Then the result becomes:
> 
>  1: A 2: d 3: a 4:   5:   6:   7: B 8: a 9: b 10: b 11: e 12: l
> Why is this happening.

Which compiler do you use?

Gnat 3.16w produces an error for this:

preben.adb:15:17: expected type "Name_Array" defined at line 4
preben.adb:15:17: found a string type

With qualification, it works.

   Print_Names (string'("Ada   ") & string'("Babbel"));

The problem cause needs an intensive RM exegesis, which I have just not the time 
for. Could be a compiler error.

Re: "&" for array versus "&" for Strings

[Preben Randhol]

On Tue, 8 Oct 2002 13:53:47 +0200 (MET DST), Grein, Christoph wrote:

> Which compiler do you use?

Gnat 3.14p from Debian

-- 
Ada95 is good for you.
http://libre.act-europe.fr/Software_Matters/02-C_pitfalls.pdf

Re: "&" for array versus "&" for Strings

[Preben Randhol]

On Tue, 8 Oct 2002 13:53:47 +0200 (MET DST), Grein, Christoph wrote:
> 
> Gnat 3.16w produces an error for this:
> 
> The problem cause needs an intensive RM exegesis, which I have just
> not the time for. Could be a compiler error.
                    ^^^^^^^^^^^^^^^^^^^^^^^^^
                    I think so.

-- 
Ada95 is good for you.
http://libre.act-europe.fr/Software_Matters/02-C_pitfalls.pdf

Re: "&" for array versus "&" for Strings

[Robert A Duff]

"Grein, Christoph" <christoph.grein@eurocopter.com> writes:

> > ------------------------------------------------------------------
> > with Ada.Text_IO; use Ada.Text_IO;
> > procedure Array_Test is
> > 
> >    type Name_Array is array (Positive range <>) of String (1..6);
> > 
> >    procedure Print_Names (Names : Name_Array) is
> >    begin
> >       for No in Names'First .. Names'Last loop
> >          Put_Line (Integer'Image(No) & ": " & Names (No));
> >       end loop;
> >    end;
> > 
> > begin
> > 
> >    Print_Names ("Ada   " & "Babbel");
> > 
> > end Array_Test;
> > ------------------------------------------------------------------
> > 
> > Then the result becomes:
> > 
> >  1: A 2: d 3: a 4:   5:   6:   7: B 8: a 9: b 10: b 11: e 12: l
> > Why is this happening.

Sounds like a compiler bug.

> Which compiler do you use?
> 
> Gnat 3.16w produces an error for this:
> 
> preben.adb:15:17: expected type "Name_Array" defined at line 4
> preben.adb:15:17: found a string type
> 
> With qualification, it works.
> 
>    Print_Names (string'("Ada   ") & string'("Babbel"));
> 
> The problem cause needs an intensive RM exegesis, which I have just not the time 
> for. Could be a compiler error.

That sounds like a different compiler bug.

It seems to me that the "&" should resolve to the
(string, string)-->Name_Array one, even without the "String'(...)"
qualifications.  Apparently, the older compiler resolved it to the wrong
one, and the newer one can't resolve it (which is an improvement, but
still a bug).

I'm not surprised that such a bug has never been noticed before.  Most
people don't write code that uses "&" to concatenate two Strings to
produce something other than String!  First, it's confusing (to humans,
I mean, in addition to compilers).  Second, it requires fixed-length
strings, which is almost never what you want in an array.

- Bob

Re: "&" for array versus "&" for Strings

[Preben Randhol]

On Tue, 8 Oct 2002 16:41:43 GMT, Robert A Duff wrote:
> 
> I'm not surprised that such a bug has never been noticed before.  Most
> people don't write code that uses "&" to concatenate two Strings to
> produce something other than String!  First, it's confusing (to humans,
> I mean, in addition to compilers).  

I have already changed my code (the actual code that I posted was an
example) to use "and" instead so that it is write:

Authors => "Ada" and "Babbel"

Preben
-- 
Ada95 is good for you.
http://libre.act-europe.fr/Software_Matters/02-C_pitfalls.pdf

"&" for array versus "&" for Strings

[Preben Randhol]

According to the ARM 4.5.3:

  3. The concatenation operators & are predefined for every nonlimited,
     one-dimensional array type T with component type C. They have the
     following specifications:

  4.      function "&"(Left : T; Right : T) return T
          function "&"(Left : T; Right : C) return T
          function "&"(Left : C; Right : T) return T
          function "&"(Left : C; Right : C) return T

If I use this in this way:

------------------------------------------------------------------
with Ada.Text_IO; use Ada.Text_IO;
procedure Array_Test is

   type Name_Array is array (Positive range <>) of String (1..6);

   procedure Print_Names (Names : Name_Array) is
   begin
      for No in Names'First .. Names'Last loop
         Put_Line (Integer'Image(No) & ": " & Names (No));
      end loop;
   end;

begin

   Print_Names ("Ada   " & "Babbel");

end Array_Test;
------------------------------------------------------------------

Then the result becomes:


 1: A 2: d 3: a 4:   5:   6:   7: B 8: a 9: b 10: b 11: e 12: l
Why is this happening.

If I do :

Print_Names ("Ada   " & "Babbel" & "Odin  ");

gnatmake array_test.adb 
gnatgcc -c array_test.adb
array_test.adb:15:26: ambiguous operand for concatenation
array_test.adb:15:26: possible interpretation at line 4
array_test.adb:15:26: possible interpretation in package Standard
gnatmake: "array_test.adb" compilation error

which is expected.

and 

Print_Names ("Ada   Babbel");

gnatmake array_test.adb 
gnatgcc -c array_test.adb
array_test.adb:15:17: expected type "Name_Array" defined at line 4
array_test.adb:15:17: found a string type
gnatmake: "array_test.adb" compilation error

which is also expected.


-- 
Ada95 is good for you.
http://libre.act-europe.fr/Software_Matters/02-C_pitfalls.pdf

Re: "&" for array versus "&" for Strings

[Eric G. Miller]

In <slrnaq5ehk.5c6.randhol+news@kiuk0152.chembio.ntnu.no>, Preben Randhol wrote:

> According to the ARM 4.5.3:
> 
>   3. The concatenation operators & are predefined for every nonlimited,
>      one-dimensional array type T with component type C. They have the
>      following specifications:
> 
>   4.      function "&"(Left : T; Right : T) return T
>           function "&"(Left : T; Right : C) return T
>           function "&"(Left : C; Right : T) return T
>           function "&"(Left : C; Right : C) return T
> 
> If I use this in this way:
> 
> ------------------------------------------------------------------
> with Ada.Text_IO; use Ada.Text_IO;
> procedure Array_Test is
> 
>    type Name_Array is array (Positive range <>) of String (1..6);
>
>    procedure Print_Names (Names : Name_Array) is
>    begin
>       for No in Names'First .. Names'Last loop
>          Put_Line (Integer'Image(No) & ": " & Names (No));
>       end loop;
>    end;
> 
> begin
> 
>    Print_Names ("Ada   " & "Babbel");

ITYM,
     Print_Names (Name_Array'("Ada   ", "Babbel"));
  OR
     declare
         First : Name_Array := Name_Array'("Ada   ", "Babbel");
         Second: String(1..6) := "Odin  ";
     begin
         Print_Names(First & Second);
     end;

AFAIK, "Ada   " & "Babbel"  is type String(1..12) not Name_Array(1..2).

> end Array_Test;
> ------------------------------------------------------------------
> 
> Then the result becomes:
> 
> 
>  1: A 2: d 3: a 4:   5:   6:   7: B 8: a 9: b 10: b 11: e 12: l
> Why is this happening.

It should even compile (didn't w/ gcc-3.1 (gnat)).
 

Re: "&" for array versus "&" for Strings

[Robert A Duff]

"Eric G. Miller" <egm2@jps-nospam.net> writes:

> In <slrnaq5ehk.5c6.randhol+news@kiuk0152.chembio.ntnu.no>, Preben Randhol wrote:
> >    Print_Names ("Ada   " & "Babbel");

> AFAIK, "Ada   " & "Babbel"  is type String(1..12) not Name_Array(1..2).

The expression "Ada   " & "Babbel" could be of various types, depending
on context.  You can't say it "is" of type String all by itself.
In the context of Print_Names ("Ada   " & "Babbel");,
the type is determined (in part) by the type of the formal parameter.

- Bob