casecrash: language lawyers: C'mon!

casecrash: language lawyers: C'mon!

[Peter Hermann]

                      with ada.text_io;use ada.text_io;
procedure casecrash is
 type record_type is (A,B,C,D,E,F,G,H,I,J,K,L,unknown);
 type header is record
    id_letter : record_type := unknown;
 end record; 
 H : Header; 
begin
 case h.id_letter is
  when A => put("a");
  when H => put("h"); -- H conflict, name clash?
                      -- no context resolution?
  when others => put("*");
 end case; 
end casecrash;--20010717ph+frehrmann

LRM:8.3(26), illegal homograph of H
LRM:8.6(28)

Why on earth should I accept this rule in this case?
Topic for Ada2005?


-- 
Peter Hermann Tel+49-711-685-3611 Fax3758 ica2ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
http://www.csv.ica.uni-stuttgart.de/homes/ph/
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: casecrash: language lawyers: C'mon!

[John R. Strohm]

Without digging out my long-buried LRM, I seem to recall that Ada is NOT, I
say again NOT, case-sensitive.

That being the case,

    H : Header;

hides the enumeration literal H where you defined record_type, and your
"when H =>" clause tried to resolve against the instance of Header, which is
obviously bogus.

You MIGHT try changing that to

    when record_type'(H) =>

and see what happens.  I would not bet on it working.

Peter Hermann <ica2ph@iris16.csv.ica.uni-stuttgart.de> wrote in message
news:9j1cpn$bis$1@infosun2.rus.uni-stuttgart.de...
>                       with ada.text_io;use ada.text_io;
> procedure casecrash is
>  type record_type is (A,B,C,D,E,F,G,H,I,J,K,L,unknown);
>  type header is record
>     id_letter : record_type := unknown;
>  end record;
>  H : Header;
> begin
>  case h.id_letter is
>   when A => put("a");
>   when H => put("h"); -- H conflict, name clash?
>                       -- no context resolution?
>   when others => put("*");
>  end case;
> end casecrash;--20010717ph+frehrmann
>
> LRM:8.3(26), illegal homograph of H
> LRM:8.6(28)
>
> Why on earth should I accept this rule in this case?
> Topic for Ada2005?
>
>
> --
> Peter Hermann Tel+49-711-685-3611 Fax3758 ica2ph@csv.ica.uni-stuttgart.de
> Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
> http://www.csv.ica.uni-stuttgart.de/homes/ph/
> Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: casecrash: language lawyers: C'mon!

[Martin Dowie]

I think what the original poster is getting at is that it
would seem perfectly obvious that the case statement is
referring to the data object called 'H' rather than the
enumerate 'H', so why can't the language be defined to
spot this case?


John R. Strohm <strohm@airmail.net> wrote in message
news:AF90BB90E03E608D.447DE4CBCE9D9148.37FD9A43DA8A1090@lp.airnews.net...
> Without digging out my long-buried LRM, I seem to recall that Ada is NOT,
I
> say again NOT, case-sensitive.
>
> That being the case,
>
>     H : Header;
>
> hides the enumeration literal H where you defined record_type, and your
> "when H =>" clause tried to resolve against the instance of Header, which
is
> obviously bogus.
[snip]

Re: casecrash: language lawyers: C'mon!

[Philip Anderson]

Martin Dowie wrote:
> 
> I think what the original poster is getting at is that it
> would seem perfectly obvious that the case statement is
> referring to the data object called 'H' rather than the
> enumerate 'H', so why can't the language be defined to
> spot this case?

That I think was his question.  But it's not actually the problem the
compiler found, which was the illegal declaration of the object H
(because it is a homograph of the enumeration H).

And that rule is IMHO well-founded, since there are contexts when
writing H would be ambiguous.


Nearer to the original question would be the following:

with Ada.Text_Io; use Ada.Text_Io;
procedure Casecrash is

   package Local is
      type Record_Type is (A, B, C, D, E, F, G, H, I, J, K, L, Unknown);
   end Local;

   use Local;

   type Header is
      record
         Id_Letter : Record_Type := Unknown;
      end record;

   H : Header;

begin
   case H.Id_Letter is
      when A =>
         Put ("a");
      when H =>
--H is not static [RM_95 3.8.1(8); 5.4(5)]
--H is not a value of Record_Type
         Put ("h"); -- H conflict, name clash?
                    -- no context resolution?
      when others =>
         Put ("*");
      end case;
end Casecrash;

since H the enumeration literal has been overriden by the H the object,
although the (Rational Apex) compiler is happy with A in this context. 
RM 8.4(10) seems to apply here.


-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

Re: casecrash: language lawyers: C'mon!

[Robert Dewar]

"John R. Strohm" <strohm@airmail.net> wrote in message news:<AF90BB90E03E608D.447DE4CBCE9D9148.37FD9A43DA8A1090@lp.airnews.net

> You MIGHT try changing that to
> 
>     when record_type'(H) =>
> 
> and see what happens.  I would not bet on it working.

Please avoid guesswork and gambling in CLA :-)

If you post Ada code, or suggestions for improving previously posted
code, please take the trouble to check it out by running it through
a compiler.

The above is obviously wrong

Re: casecrash: language lawyers: C'mon!

[Robert Dewar]

Peter Hermann <ica2ph@iris16.csv.ica.uni-stuttgart.de> wrote in message 
news:<9j1cpn$bis$1@infosun2.rus.uni-stuttgart.de>...

GNAT says here:

casecrash.adb:6:02: "H" conflicts with declaration at line 2
 
> Why on earth should I accept this rule in this case?

Because, very deliberately, obverloading is restricted to function
and procedure names (enumeration literals are function names from
the point of view of this rule). We definitely do NOT want to allow
overloading of variable names, since it is impossible to see how this
could improve readability of programs. There is no excuse for reusing
H in the sample program you gave.

> Topic for Ada2005?

Nope. I see no reason for changing a well designed and well founded
rule here. This rule is clearly stated, and well understood by Ada
programmers. There is no basis for change.

casecrash: language lawyers: C'mon!

[Peter Hermann]

short clarification:
my code clearly shows that I unintentionally overloaded identifier h
and I am wondering why Ada is not smart enough for context resolution.
My question still remains whether Ada2005 could be pushed forward
for such clearly obvious circumstances.

-- 
Peter Hermann Tel+49-711-685-3611 Fax3758 ica2ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
http://www.csv.ica.uni-stuttgart.de/homes/ph/
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: casecrash: language lawyers: C'mon!

[Tucker Taft]

Peter Hermann wrote:
> 
> short clarification:
> my code clearly shows that I unintentionally overloaded identifier h
> and I am wondering why Ada is not smart enough for context resolution.
> My question still remains whether Ada2005 could be pushed forward
> for such clearly obvious circumstances.

Highly unlikely.  Ada makes a strong distinction
between overloadable declarations (subprograms, entries, and enumerals)
and non-overloadable declarations (everything else).
Allowing more general overloading would dramatically affect
a very delicate part of existing compilers (overload resolution)
and would require a major new benefit to justify it.

In other words, don't hold your breath ;-).

> 
> --
> Peter Hermann Tel+49-711-685-3611 Fax3758 ica2ph@csv.ica.uni-stuttgart.de
> Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
> http://www.csv.ica.uni-stuttgart.de/homes/ph/
> Team Ada: "C'mon people let the world begin" (Paul McCartney)

-- 
-Tucker Taft   stt@avercom.net   http://www.avercom.net
Chief Technology Officer, AverCom Corporation (A Titan Company) 
Bedford, MA  USA (AverCom was formerly the Commercial Division of AverStar:
http://www.averstar.com/~stt)

Re: casecrash: language lawyers: C'mon!

[Peter Hermann]

Tucker Taft <stt@avercom.net> wrote:
> Highly unlikely.  Ada makes a strong distinction
> between overloadable declarations (subprograms, entries, and enumerals)
> and non-overloadable declarations (everything else).
> Allowing more general overloading would dramatically affect
> a very delicate part of existing compilers (overload resolution)
> and would require a major new benefit to justify it.

> In other words, don't hold your breath ;-).

As average Joe Ada Programer I simply guessed there may be
no great effort for a compiler to resolve ambiguity under
very clear conditions: on the one side a choice between
two objects and on the other side a unique request for the
one and only one thing (guess what may be meant in a 
"when"-branch condition of a case statement? mmh).
Of course, you have the deepest insight into compiler
construction and the effort involved in "advanced" ;-)
context resolution.

BTW, we have changed our header h into hdr and are happy
with it because this is even more readable. :-)

thank you.

> -- 
> -Tucker Taft   stt@avercom.net   http://www.avercom.net
> Chief Technology Officer, AverCom Corporation (A Titan Company) 
> Bedford, MA  USA (AverCom was formerly the Commercial Division of AverStar:
> http://www.averstar.com/~stt)

-- 
Peter Hermann Tel+49-711-685-3611 Fax3758 ica2ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
http://www.csv.ica.uni-stuttgart.de/homes/ph/
Team Ada: "C'mon people let the world begin" (Paul McCartney)