ObjectAda vs Gnat -- bugs

ObjectAda vs Gnat -- bugs

[granger]

Here is a shortened version of a package that I wrote.

It compiles without any error with ObjectAda.
With gnat3.09, I have the following errors:

rgbcolor.ads:18:41: expect object name in renaming
rgbcolor.ads:19:49: expect object name in renaming

Which of the compilers is correct ?

If gnat is correct ( probably gnat!!!), the internal package RGB_Value does
 not have any influence, how can I have the enumeration values Gray* and
 Grey* of the same type or subtype with the same internal value ?

Thank in advance for any suggestion.

package rgbcolor is
	package RGB_Value is
		type Color3  is
		record
			red, green, blue : Float;
		end record;
		Gray0	: constant Color3 := ( 0.000, 0.000, 0.000 );
		Grey0	: Color3 renames Gray0;
		Gray1	: constant Color3 := ( 0.012, 0.012, 0.012 );
		Grey1	: Color3 renames Gray1;
	end RGB_Value;
	
	type Color_Type is ( Gray0, Gray1 );
	
	subtype Grey_Color_Type is Color_Type range Gray0 .. Gray1;
	
	Grey0	: Color_Type renames	Gray0;	-- line in error---------------
	Grey1	: Color_Type renames	Gray1;	-- line in error---------------
end rgbcolor;

Re: ObjectAda vs Gnat -- bugs

[Stephen Leake]

granger wrote:
> 
> Here is a shortened version of a package that I wrote.
> 
> It compiles without any error with ObjectAda.
> With gnat3.09, I have the following errors:
> 
> rgbcolor.ads:18:41: expect object name in renaming
> rgbcolor.ads:19:49: expect object name in renaming
> 
> Which of the compilers is correct ?

gnat; see below

> 
> If gnat is correct ( probably gnat!!!), the internal package RGB_Value does
>  not have any influence, 

Since you did not do "use RGB_Value" nor "RGB_Value.", this is true;
RGB_Value has no influence.

>          how can I have the enumeration values Gray* and
>  Grey* of the same type or subtype with the same internal value ?

you can't have two distinct enumeration values of the same type with the
same internal value, but you can get the effect of renaming; see below.

> 
> Thank in advance for any suggestion.
> 
> package rgbcolor is
>         package RGB_Value is
>                 type Color3  is
>                 record
>                         red, green, blue : Float;
>                 end record;
>                 Gray0   : constant Color3 := ( 0.000, 0.000, 0.000 );
>                 Grey0   : Color3 renames Gray0;
>                 Gray1   : constant Color3 := ( 0.012, 0.012, 0.012 );
>                 Grey1   : Color3 renames Gray1;
>         end RGB_Value;
> 
>         type Color_Type is ( Gray0, Gray1 );
> 
>         subtype Grey_Color_Type is Color_Type range Gray0 .. Gray1;
> 
>         Grey0   : Color_Type renames    Gray0;  -- line in error---------------
>         Grey1   : Color_Type renames    Gray1;  -- line in error---------------

replace the error lines with:

        function Grey0 return Color_Type renames Gray0;
        function Grey1 return Color_Type renames Gray1;

> end rgbcolor;

An enumeration literal acts like a function with no parameters, so you
can rename it as a function. Your original renaming was trying to
declare an object, which GNAT correctly forbids; submit an error report
to Aonix!

However, if you are expecting rbbcolor.Grey0 to return the same value as
rgbcolor.RBG_Value.Grey0, you are confused; one is a scalar enumeration
type, the other is a record type with three components. You could add
the declarations:

        Grey0 : RGB_Value.Color3 renames RGB_Value.Gray0;
        Grey1 : RGB_Value.Color3 renames RGB_Value.Gray1;

But I'm not clear what you are after.

-- 
- Stephe

Re: ObjectAda vs Gnat -- bugs

[Tucker Taft]

Stephen Leake (Stephen.Leake@gsfc.nasa.gov) wrote:

: granger wrote:
: > 
: > Here is a shortened version of a package that I wrote.
: > 
: > It compiles without any error with ObjectAda.
: > With gnat3.09, I have the following errors:
: > 
: > rgbcolor.ads:18:41: expect object name in renaming
: > rgbcolor.ads:19:49: expect object name in renaming
: > 
: > Which of the compilers is correct ?

: gnat; see below

Actually, Gnat is wrong and Object Ada is correct ;-).  In Ada 95,
the result of calling a function is a constant object (per RM95 3.3(10,21)), 
and it may be renamed (8.5.1(4)).  This fact is mentioned in AARM 3.3(26.b).

: > package rgbcolor is
: >         package RGB_Value is
: >                 type Color3  is
: >                 record
: >                         red, green, blue : Float;
: >                 end record;
: >                 Gray0   : constant Color3 := ( 0.000, 0.000, 0.000 );
: >                 Grey0   : Color3 renames Gray0;
: >                 Gray1   : constant Color3 := ( 0.012, 0.012, 0.012 );
: >                 Grey1   : Color3 renames Gray1;
: >         end RGB_Value;
: > 
: >         type Color_Type is ( Gray0, Gray1 );
: > 
: >         subtype Grey_Color_Type is Color_Type range Gray0 .. Gray1;
: > 
: >         Grey0   : Color_Type renames    Gray0;  -- line in error---------------
: >         Grey1   : Color_Type renames    Gray1;  -- line in error---------------

: replace the error lines with:

:         function Grey0 return Color_Type renames Gray0;
:         function Grey1 return Color_Type renames Gray1;

This will also work, but it is not required in Ada 95.

One advantage of this approach is that these new declarations
are parameterless functions, which allows them to be overloaded
and inherited by derived type.

: > end rgbcolor;

: An enumeration literal acts like a function with no parameters, so you
: can rename it as a function. Your original renaming was trying to
: declare an object, which GNAT correctly forbids; submit an error report
: to Aonix!

No, don't bother.  GNAT should interpret the renaming as a renaming
of the result of calling the parameterless "function."

: However, if you are expecting rbbcolor.Grey0 to return the same value as
: rgbcolor.RBG_Value.Grey0, you are confused; one is a scalar enumeration
: type, the other is a record type with three components. You could add
: the declarations:

:         Grey0 : RGB_Value.Color3 renames RGB_Value.Gray0;
:         Grey1 : RGB_Value.Color3 renames RGB_Value.Gray1;

: But I'm not clear what you are after.

: -- 
: - Stephe

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: ObjectAda vs Gnat -- bugs

[Jon S Anthony]

In article <EAA25I.9nn.0.-s@inmet.camb.inmet.com> stt@houdini.camb.inmet.com (Tucker Taft) writes:

> : > Which of the compilers is correct ?
> 
> : gnat; see below
> 
> Actually, Gnat is wrong and Object Ada is correct ;-).  In Ada 95,
> the result of calling a function is a constant object (per RM95 3.3(10,21)), 
> and it may be renamed (8.5.1(4)).  This fact is mentioned in AARM 3.3(26.b).

And, what is more, this is a _very_ useful thing.  Several nice
examples are in the Rationale!


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: ObjectAda vs Gnat -- bugs

[Robert Dewar]

Jon says

<<And, what is more, this is a _very_ useful thing.  Several nice
examples are in the Rationale!>>

(talking about renaming the results of function calls)

Most certainly! But I don't think this particular use (providing an entirely
redundant way of renaming enumeration literals) is one of these _very_ useful
thinks :-)

Note that the two forms of renaming are not quite equivalent:

   type x is (a1, a2);
   type y is (a3, a4);

   function z return x renames a1;
   function z return y renames a3;
   --  legal

   z : x renames a1;
   z : y renames z3;
   --  illegal

Re: ObjectAda vs Gnat -- bugs

[Jon S Anthony]

In article <dewar.863817409@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Jon says
> 
> <<And, what is more, this is a _very_ useful thing.  Several nice
> examples are in the Rationale!>>
> 
> (talking about renaming the results of function calls)
> 
> Most certainly! But I don't think this particular use (providing an entirely
> redundant way of renaming enumeration literals) is one of these _very_ useful
> thinks :-)

Good Point! ;-)

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: ObjectAda vs Gnat -- bugs

[Tom Moran]

>  Several nice examples are in the Rationale!
Where?

Re: ObjectAda vs Gnat -- bugs

[Jon S Anthony]

In article <337B65FC.98D@gsfc.nasa.gov> Stephen Leake <Stephen.Leake@gsfc.nasa.gov> writes:

> > It compiles without any error with ObjectAda.
> > With gnat3.09, I have the following errors:
> > 
> > rgbcolor.ads:18:41: expect object name in renaming
> > rgbcolor.ads:19:49: expect object name in renaming
> > 
> > Which of the compilers is correct ?
> 
> gnat; see below

Not true, mon ami!

> An enumeration literal acts like a function with no parameters, so you
> can rename it as a function. Your original renaming was trying to
> declare an object, which GNAT correctly forbids; submit an error report
> to Aonix!

Change "Anonix" to "ACT"...

Ada95 sez that function results are "constant objects" and so can be
renamed.  This is really useful when you are dealing with limited
types which can be returned from functions - but not assigned!

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: ObjectAda vs Gnat -- bugs

[Robert Dewar]

granger said

<<If gnat is correct ( probably gnat!!!), the internal package RGB_Value does
 not have any influence, how can I have the enumeration values Gray* and
 Grey* of the same type or subtype with the same internal value ?>>

Well I am not sure where you get the "probably gnat" from, but in this case
it seems obvious that GNAT is right, unless I am missing something. You
have an object renaming declaration and you are trying to rename a functoin.
The GNAT message seems correct (I suppose that it would be nice if it would
remind you that an enumeration literal is a function and not an object, since
it is true that this can be a bit of a surprise!

Re: ObjectAda vs Gnat -- bugs

[David L Brown]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Well I am not sure where you get the "probably gnat" from, but in this case
> it seems obvious that GNAT is right, unless I am missing something. You
> have an object renaming declaration and you are trying to rename a functoin.
> The GNAT message seems correct (I suppose that it would be nice if it would
> remind you that an enumeration literal is a function and not an object, since
> it is true that this can be a bit of a surprise!

Actually, this shows an inconsistency with GNAT between enumeration
literals, and actual functions.

     1. procedure T1 is
     2.    type Items is (Item);
     3. 
     4.    Item_2 : Items renames Item;
                                  |
        >>> expect object name in renaming

     5.    function Item_3 return Items renames Item;
     6.    Item_4 : Items renames Item_3;
     7. 
     8.    function Hoo_Haa return Items is
     9.    begin
    10.       return Item;
    11.    end Hoo_Haa;
    12. 
    13.    Hoo_2 : Items renames Hoo_Haa;
    14. 
    15. begin
    16.    null;
    17. end T1;

GNAT correctly renames the "real" function "Item_3", but is not able
to rename the enumeration literal.

Dave Brown

Re: ObjectAda vs Gnat -- bugs

[Robert Dewar]

David Brown says

<<Actually, this shows an inconsistency with GNAT between enumeration
literals, and actual functions.

     1. procedure T1 is
     2.    type Items is (Item);
     3.
     4.    Item_2 : Items renames Item;
                                  |
        >>> expect object name in renaming

     5.    function Item_3 return Items renames Item;
     6.    Item_4 : Items renames Item_3;>>


Yes, indeed. This is a change from Ada 83 to Ada 95 that keeps escaping
me (entertaining that it escaped RR too :-) Anyway, easily fixed once
pointed out. I must say in a way it is a bit odd that enumeration
literals are functions at all ... although I am used to it by now.

Re: ObjectAda vs Gnat -- bugs

[Tom Moran]

I'm a little confused by this renaming of function return values.  If T
is a limited type and F is a function returning T, then I understand one
can:
  X:T renames F(...);
and one cannot
  X:T := F(...);
Is that correct?
If T is not limited, then what are the differences between
  X : T renames F(...);
  Y : T := F(...);

Re: ObjectAda vs Gnat -- bugs

[Jon S Anthony]

In article <337E5357.7FBA@bix.com> Tom Moran <tmoran@bix.com> writes:

> I'm a little confused by this renaming of function return values.  If T
> is a limited type and F is a function returning T, then I understand one
> can:
>   X:T renames F(...);
> and one cannot
>   X:T := F(...);
> Is that correct?

Yes.


> If T is not limited, then what are the differences between
>   X : T renames F(...);
>   Y : T := F(...);

X is constant, Y is not.  OTOH, if you said Y : constant T := F(...),
I'm not sure there is a difference...

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: ObjectAda vs Gnat -- bugs

[Tucker Taft]

Tom Moran (tmoran@bix.com) wrote:

: I'm a little confused by this renaming of function return values.  If T
: is a limited type and F is a function returning T, then I understand one
: can:
:   X:T renames F(...);
: and one cannot
:   X:T := F(...);
: Is that correct?

Correct.

: If T is not limited, then what are the differences between
:   X : T renames F(...);
:   Y : T := F(...);

In the first case, X inherits the "constant"ness of the object
being renamed, which in this case, means that X is a constant.
In the second case, we have a new object, and since you left
off the word "constant" it is not a constant.

If you had written "Y : constant T := F(...);" then they would
be almost indistinguishable (though you wouldn't be able
to apply representation clauses to the rename, since you haven't
really declared a new object).

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

P.S. For what its worth, enumeration literals really are treated
as functions in our Ada 95 front end symbol table.  It is just 
their "body" which is a bit funny -- it is intrinsic and all calls
are "expanded" inline. -TT

Re: ObjectAda vs Gnat -- bugs

[Tom Moran]

Robert Dewar said:
> This is a change from Ada 83 to Ada 95 that keeps escaping
> me (entertaining that it escaped RR too :-)
  Actually, I sent a copy of Tucker Taft's comment to RR and they 
responded not that it had escaped them, but that is was on their
"not yet implemented" list.  A fine point, perhaps, to a user who
wants to use the feature.

Re: ObjectAda vs Gnat -- bugs

[Samuel A. Mize]

granger wrote:
>how can I have the enumeration values Gray* and
>  Grey* of the same type or subtype with the same internal value ?

I noted in another message that enumeration literals are functions,
so he can rename them.

Another, possibly simpler option is to define constant objects with
the values you want:

   type Color_Type is (Gray0);
   Gray1: constant Color_Type := Gray0;

Sam Mize


-- Samuel Mize           (817) 619-8622               "Team Ada"
-- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005

Re: ObjectAda vs Gnat -- bugs

[Samuel A. Mize]

granger wrote:
> 
> Here is a shortened version of a package that I wrote.
> 
> It compiles without any error with ObjectAda.
> With gnat3.09, I have the following errors:
> 
> rgbcolor.ads:18:41: expect object name in renaming
> rgbcolor.ads:19:49: expect object name in renaming
> 
> Which of the compilers is correct ?
> 
> If gnat is correct ( probably gnat!!!), 

Good guess!

>the internal package RGB_Value does
>  not have any influence,

Also correct.

>how can I have the enumeration values Gray* and
>  Grey* of the same type or subtype with the same internal value ?

You can't, but you can come close.  An enumeration literal is a function
that returns a value of the enumeration type.  For instance, this works:
    function Fred return character renames 'A';

So, you CAN define your own functions that rename enumeration literals.
For instance, this program compiles and works with GNAT:

   with Text_Io;
   procedure Fred is
      type Color_Type is (Gray0);
      function Grey0 return Color_Type renames Gray0;
   begin
      Text_Io.Put_Line (Color_Type'Image ( Grey0 ));
      -- outputs GRAY0, not GREY0
   end fred;

Whether or not this is a good idea I leave to the engineer on the scene.

Sam Mize

> Thank in advance for any suggestion.
> 
> package rgbcolor is
>         package RGB_Value is
>                 type Color3  is
>                 record
>                         red, green, blue : Float;
>                 end record;
>                 Gray0   : constant Color3 := ( 0.000, 0.000, 0.000 );
>                 Grey0   : Color3 renames Gray0;
>                 Gray1   : constant Color3 := ( 0.012, 0.012, 0.012 );
>                 Grey1   : Color3 renames Gray1;
>         end RGB_Value;
> 
>         type Color_Type is ( Gray0, Gray1 );
> 
>         subtype Grey_Color_Type is Color_Type range Gray0 .. Gray1;
> 
>         Grey0   : Color_Type renames    Gray0;  -- line in error---------------
>         Grey1   : Color_Type renames    Gray1;  -- line in error---------------
> end rgbcolor;

-- Samuel Mize           (817) 619-8622               "Team Ada"
-- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005

Re: ObjectAda vs Gnat -- bugs

[Robert A Duff]

In article <5lf6ka$nbg@service.polymtl.ca>,
granger <louis.granger@mail.polymtl.ca> wrote:
>Here is a shortened version of a package that I wrote.

Is this supposed to be the obfuscated Ada contest?
I mean, grey vs. bray makes my brain hurt.
                 ^^^^ Of course, I meant to type "gray", but I like the
typo, so I'll leave it in.  ;-)

>It compiles without any error with ObjectAda.
>With gnat3.09, I have the following errors:
>
>rgbcolor.ads:18:41: expect object name in renaming
>rgbcolor.ads:19:49: expect object name in renaming
>
>Which of the compilers is correct ?
>
>If gnat is correct ( probably gnat!!!),

Why do you say "probably gnat"?

>... the internal package RGB_Value does
> not have any influence, how can I have the enumeration values Gray* and
> Grey* of the same type or subtype with the same internal value ?
>
>Thank in advance for any suggestion.
>
>package rgbcolor is
>	package RGB_Value is
>		type Color3  is
>		record
>			red, green, blue : Float;
>		end record;
>		Gray0	: constant Color3 := ( 0.000, 0.000, 0.000 );
>		Grey0	: Color3 renames Gray0;
>		Gray1	: constant Color3 := ( 0.012, 0.012, 0.012 );
>		Grey1	: Color3 renames Gray1;
>	end RGB_Value;
>	
>	type Color_Type is ( Gray0, Gray1 );
>	
>	subtype Grey_Color_Type is Color_Type range Gray0 .. Gray1;
>	
>	Grey0	: Color_Type renames	Gray0;	-- line in error---------------
>	Grey1	: Color_Type renames	Gray1;	-- line in error---------------

This looks legal, to me.  You're renaming calls to the enum lits (which
are like functions, in Ada).  Perhaps you meant to say:

    function Grey0 return Color_Type renames Gray0;
    ... and similarly for gr[ea]y1.

;-)  But either way, it should be legal.

Package RGB_Value has nothing to do with this, as far as I can tell.

- Bob

Re: ObjectAda vs Gnat -- bugs

[Robert Dewar]

Bob Duff says

<<This looks legal, to me.  You're renaming calls to the enum lits (which
are like functions, in Ada).  Perhaps you meant to say:

    function Grey0 return Color_Type renames Gray0;
    ... and similarly for gr[ea]y1.

;-)  But either way, it should be legal.>>

Ah, interesting, so what Bob is saying is that since the functoin call
returns an object, it is legal to rename the object that it returns.
OK, if so, that's a surprise (to several people here), but that seems
right to me, though a bit odd.

Re: ObjectAda vs Gnat -- bugs

[Keith Thompson]

louis.granger@MAIL.POLYMTL.CA (granger) wrote:
> Here is a shortened version of a package that I wrote.
>  
> It compiles without any error with ObjectAda.
> With gnat3.09, I have the following errors:
>  
> rgbcolor.ads:18:41: expect object name in renaming
> rgbcolor.ads:19:49: expect object name in renaming
>  
> Which of the compilers is correct ?
>  
> If gnat is correct ( probably gnat!!!), the internal package RGB_Value does
>  not have any influence, how can I have the enumeration values Gray* and
>  Grey* of the same type or subtype with the same internal value ?
>  
> Thank in advance for any suggestion.
>  
> package rgbcolor is
>         package RGB_Value is
>                 type Color3  is
>                 record
>                         red, green, blue : Float;
>                 end record;
>                 Gray0   : constant Color3 := ( 0.000, 0.000, 0.000 );
>                 Grey0   : Color3 renames Gray0;
>                 Gray1   : constant Color3 := ( 0.012, 0.012, 0.012 );
>                 Grey1   : Color3 renames Gray1;
>         end RGB_Value;
>  
>         type Color_Type is ( Gray0, Gray1 );
>  
>         subtype Grey_Color_Type is Color_Type range Gray0 .. Gray1;
>  
>         Grey0   : Color_Type renames    Gray0;  -- line in error---------------
>         Grey1   : Color_Type renames    Gray1;  -- line in error---------------
> end rgbcolor;

Actually, I believe ObjectAda is correct on this one -- but the reasons
are rather obscure.  By the way, the contents of the package RGB_Value
are irrelevant here.

Here's a simpler example:

    package RGBColor is
        type Color_Type is ( Gray0, Gray1 );
        Grey0 : Color_Type renames Gray0;
        Grey1 : Color_Type renames Gray1;
    end RGBColor;

By RM95-8.5.1(4), the renamed entity in an object renaming must be an object.

By RM95-3.5.1(6), an enumeration literal specification declares a
parameterless function, so an occurrence of an enumeration literal
in an expression is a function call.  This rule may seem strange;
it's defined that way so that enumeration literals can be overloaded
in the same manner as functions.  In practice, you can be sure that
enumeration literals will not be implemented as actual function calls.

By RM95-6.4(12) and 6.5(21), a function call denotes a (constant)
object.  (This rule is new to Ada 95.)

So, it is legal in Ada 95 (but illegal in Ada 83) to use an object
renaming declaration to rename an enumeration literal.

However, the more traditional way to rename an enumeration literal
is as a function:

    package RGBColor is
	type Color_Type is ( Gray0, Gray1 );
	function Grey0 return Color_Type renames Gray0;
	function Grey1 return Color_Type renames Gray1;
    end RGBColor;

Or, if you aren't worried about overloading, just declare some constants:

    package RGBColor is
	type Color_Type is ( Gray0, Gray1 );
	Grey0 : constant Color_Type := Gray0;
	Grey1 : constant Color_Type := Gray1;
    end RGBColor;

-- 
Keith Thompson (The_Other_Keith) kst@sd.aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
5040 Shoreham Place, San Diego, CA, USA, 92122-5989
"Zathras warn Zathras, but Zathras never listen to Zathras." -- Zathras

Re: ObjectAda vs Gnat -- bugs

[Robert A Duff]

In article <EA93C3.CF4@thomsoft.com>, Keith Thompson <kst@sd.aonix.com> wrote:
>Actually, I believe ObjectAda is correct on this one -- but the reasons
>are rather obscure. ...
>...
>So, it is legal in Ada 95 (but illegal in Ada 83) to use an object
>renaming declaration to rename an enumeration literal.

Ah, at least *somebody* knows the right answer.  ;-)

It seems to me that when so many people get the *wrong* answer (see
below) ...

Various people wrote:

> Janus gives:
> *ERROR* Renamed object must be a variable or a constant (6.4.3) [RM
> 8.5.1(4)]
> 
> Enumeration literals like Gray0 are actually parameterless functions
> so what you need is: ...

> > If gnat is correct ( probably gnat!!!), 
> 
> Good guess! ...


> > Which of the compilers is correct ?
> 
> gnat; see below ...


> <<If gnat is correct ( probably gnat!!!), the internal package RGB_Value does
>  not have any influence, how can I have the enumeration values Gray* and
>  Grey* of the same type or subtype with the same internal value ?>>
> 
> Well I am not sure where you get the "probably gnat" from, but in this case
> it seems obvious that GNAT is right, unless I am missing something.  ...

When so many are wrong, including at least one compiler writer, it's
probably a problem with the language, not with all those people.  The
problem here, I think, is that enumeration literals are functions, in
Ada, which is completely weird, given that string_literals and
numeric_literals and null literals are just values.

Perhaps the reasoning was: (1) Language Design Principle: Subprograms,
and only subprograms, should be overloadable.  (2) We want enum lits to
be overloadable.  (3) Therefore, we have to pretend that enum lits are
functions.

Instead, it would be better to replace step (3) in the reasoning with
(3) Oops, I guess we were wrong about step (1); let's modify our
Principle.

I guess it's not quite *that* simple -- entries are also overloadable.
But entries really *are* like procedures in a lot of ways, so it's
natural to make the connection between subprograms and entries.  But
enum lits are not "naturally" anything at all like functions -- they're
more like constant objects.

Maybe I'm completely wrong about the chain of reasoning, since, I
believe, that in early versions of Ada, integer literals were overloaded
on all integer types.  Then named numbers and universal_integer were
invented, and the rules about literals were changed...

- Bob

Re: ObjectAda vs Gnat -- bugs

[Robert Dewar]

<<When so many are wrong, including at least one compiler writer, it's
probably a problem with the language, not with all those people.  The
problem here, I think, is that enumeration literals are functions, in
Ada, which is completely weird, given that string_literals and
numeric_literals and null literals are just values.
>>

I agree with Bob here. The trouble is that although it makes moderately
consistent semantic sense to declare that enumeration literals are
functions, it does not make much sense from a programmer's point of view,
and it does not make much sense from an implementation point of view.
In GNAT, we find that we need special handling for enumeration literals
all over the place as a result of this rule. For example, look at the
code for handling object renamings:

      elsif not Is_Object_Reference (Nam)
        and then Nkind (Nam) /= N_Function_Call
        and then (Nkind (Nam) /= N_Type_Conversion
                    or else not Is_Tagged_Type (Entity (Subtype_Mark (Nam))))
      then
         if Nkind (Nam) = N_Type_Conversion then
            Error_Msg_N
              ("renaming of conversion only allowed for tagged types", Nam);
         else
            Error_Msg_N ("expect object name in renaming", Nam);
         end if;

The fix is clear, we just need to add an explicit check for
E_Enumeration_Literal, and it got forgotten (because it is easy
to forget, and of course because out of the thousands of people using
GNAT, no one noticed it yet :-)

Now we could have made all enumeration literal references look like
real function calls, but they we would have another set of special
casing.

Oh well, this is by no means the oddest corner in the language :-)

Re: ObjectAda vs Gnat -- bugs

[Nick Roberts]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.863824104@merv>...
> <<When so many are wrong, including at least one compiler writer, it's
> probably a problem with the language, not with all those people.  The
> problem here, I think, is that enumeration literals are functions, in
> Ada, which is completely weird, given that string_literals and
> numeric_literals and null literals are just values.
> >>
> 
> I agree with Bob here. The trouble is that although it makes moderately
> consistent semantic sense to declare that enumeration literals are
> functions, it does not make much sense from a programmer's point of view,
> and it does not make much sense from an implementation point of view.
> In GNAT, we find that we need special handling for enumeration literals
> all over the place as a result of this rule. For example, look at the
> code for handling object renamings:
> 
>       elsif not Is_Object_Reference (Nam)
>         and then Nkind (Nam) /= N_Function_Call
>         and then (Nkind (Nam) /= N_Type_Conversion
>                     or else not Is_Tagged_Type (Entity (Subtype_Mark
(Nam))))
>       then
>          if Nkind (Nam) = N_Type_Conversion then
>             Error_Msg_N
>               ("renaming of conversion only allowed for tagged types",
Nam);
>          else
>             Error_Msg_N ("expect object name in renaming", Nam);
>          end if;
> 
> The fix is clear, we just need to add an explicit check for
> E_Enumeration_Literal, and it got forgotten (because it is easy
> to forget, and of course because out of the thousands of people using
> GNAT, no one noticed it yet :-)
> 
> Now we could have made all enumeration literal references look like
> real function calls, but they we would have another set of special
> casing.
> 
> Oh well, this is by no means the oddest corner in the language :-)


On the other hand, it seems to me to be sensible to have the compiler
'implement' enumeration literals as function calls, and then simply have it
_optimise_ the calls into immediate values (pretty near the end of the
optimisation process).

This way, you get the overloading behaviour of enumeration literals 'for
free', and without any danger of getting it wrong (a la GNAT), and you also
get the bonus of optimising genuine parameterless functions which are
defined to return an (effectively) static value into immediate values as
well. I would argue that this is an optimisation which most compilers ought
to provide, anyway (anybody disagree?).

For example,

   type ET is (EV1, EV2);

would initially be compiled as if

   type ET is BYTE_INT;
   function EV1 return ET is begin return ET'Val(0); end;
   function EV2 return ET is begin return ET'Val(1); end;

and a call to EV2, say, as in

   Ob1 := EV2;

would eventually get optimised into an immediate, e.g.

   movi Ob1, #1


Is my reasoning wrong here? Please reply!

Nick.

Re: ObjectAda vs Gnat -- bugs

[Robert Dewar]

Nick says

<<On the other hand, it seems to me to be sensible to have the compiler
'implement' enumeration literals as function calls, and then simply have it
_optimise_ the calls into immediate values (pretty near the end of the
optimisation process).

This way, you get the overloading behaviour of enumeration literals 'for
free', and without any danger of getting it wrong (a la GNAT), and you also
get the bonus of optimising genuine parameterless functions which are
defined to return an (effectively) static value into immediate values as
well. I would argue that this is an optimisation which most compilers ought
to provide, anyway (anybody disagree?).>>

Well you have to dig in to the front end of a compiler a bit more to see
why thiings are more complicated. The trouble is that enumeration literals
are different from functions in some important ways, for example, they
are static constants, and also they can be used as selectors in te
aggregate for an enumeration rep clause -- there are many other subtleties.
So if you tried to implement them this way, apart from the significant
inefficiency for large enumeration types, you would simply swap one set of
special cases for another. It would not help at all, and in fact I think
would likely make things much worse. We find that when you distort the 
RM this way, you usually live to regret it :-)

Re: ObjectAda vs Gnat -- bugs

[Nick Roberts]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.864017071@merv>...
> Nick says
> 
> <<On the other hand, it seems to me to be sensible to have the compiler
> 'implement' enumeration literals as function calls, and then simply have
it
> _optimise_ the calls into immediate values (pretty near the end of the
> optimisation process).
> 
> This way, you get the overloading behaviour of enumeration literals 'for
> free', and without any danger of getting it wrong (a la GNAT), and you
also
> get the bonus of optimising genuine parameterless functions which are
> defined to return an (effectively) static value into immediate values as
> well. I would argue that this is an optimisation which most compilers
ought
> to provide, anyway (anybody disagree?).>>
> 
> Well you have to dig in to the front end of a compiler a bit more to see
> why thiings are more complicated. The trouble is that enumeration
literals
> are different from functions in some important ways, for example, they
> are static constants, and also they can be used as selectors in te
> aggregate for an enumeration rep clause -- there are many other
subtleties.
> So if you tried to implement them this way, apart from the significant
> inefficiency for large enumeration types, you would simply swap one set
of
> special cases for another. It would not help at all, and in fact I think
> would likely make things much worse. We find that when you distort the 
> RM this way, you usually live to regret it :-)


I am convinced.

I need to wait for my brain to finish all its passes before emitting code
:-)

However, one could perhaps define a nifty little function such as:

   function Is_Parameterless_Function (Entity: Ada_Entity'Class) return
Boolean is
   begin
      return (Entity in Ada_Function and then
Parameter_Count(Ada_Subprogram(Entity)) = 0) or
             Entity in Ada_Enumeration_Literal;
   end;

It may still have to be used judiciously!

Nick.

Re: ObjectAda vs Gnat -- bugs

[Robert Dewar]

iNick said

<<However, one could perhaps define a nifty little function such as:

   function Is_Parameterless_Function (Entity: Ada_Entity'Class) return
Boolean is
   begin
      return (Entity in Ada_Function and then
Parameter_Count(Ada_Subprogram(Entity)) = 0) or
             Entity in Ada_Enumeration_Literal;
   end;

It may still have to be used judiciously!

Nick.>>


Nifty indeed, but unfortunately totally irrelevant to the case that started
the discussion, since of course you can rename functions with parameters
anyway. So this does not unify anything. 

Remember that the fix is absolutely trivial here, it is just a matter of
remembering to do it! The point is though, going back to Bob Duff's
original comment, that making enumeration literals be functions for some
purposes and not others (at the implementation level, and even at the
semantic level, because these are not ordinary functions, they are for
example static), means that you have specialization to do whatever you
try. 

Just for interest, here is the fix that is now in the current version of GNAT:

         elsif Is_Entity_Name (Nam)
           and then Ekind (Entity (Nam)) = E_Enumeration_Literal
         then
            --  weird but legal, equivalent to renaming a function call.
            null;


not a big deal certainly -- interesting that no one ever ran into this
in several years of use :-)

Re: ObjectAda vs Gnat -- bugs

[Stephen Leake]

Robert A Duff wrote:
> 
> Keith Thompson wrote:
> >...
> >So, it is legal in Ada 95 (but illegal in Ada 83) to use an object
> >renaming declaration to rename an enumeration literal.
> 
> Ah, at least *somebody* knows the right answer.  ;-)
> 
> It seems to me that when so many people get the *wrong* answer (see
> below) ...

As one of the people who gave a wrong answer, perhaps I can contribute
(hopefully in a positive way :)

> When so many are wrong, including at least one compiler writer, it's
> probably a problem with the language, not with all those people.  The
> problem here, I think, is that enumeration literals are functions, in
> Ada, which is completely weird, given that string_literals and
> numeric_literals and null literals are just values.

Nope. My problem is that I knew the Ada 83 rule about enumeration
literals being functions, but missed the added capability of Ada 95 to
treat function results as objects (which was precisely GNAT's problem).
I've read Cohen's book, but either this particular issue isn't covered,
or I forgot it. I haven't read the whole rationale yet.

This is one reason why it is important to give references (to the
reference manual, and/or the rationale) when you say "Ada 95 lets you do
X". Those of us still learning need to go read the RM, to get more
familiar with it. Or provide a reference to a popular book.

I guess I should have qualified my post with "unless there's something
in Ada 95 I've missed" :)

-- 
- Stephe

Re: ObjectAda vs Gnat -- bugs

[Robert A Duff]

In article <3385E9F1.2915@gsfc.nasa.gov>,
Stephen Leake  <Stephen.Leake@gsfc.nasa.gov> wrote:
>This is one reason why it is important to give references (to the
>reference manual, and/or the rationale) when you say "Ada 95 lets you do
>X". Those of us still learning need to go read the RM, to get more
>familiar with it. Or provide a reference to a popular book.

OK.  See RM-6.4(12) and 6.5(21).  And AARM-6.5(24.d) explains why.  The
fact that you can rename function results is just a side-effect -- it
wasn't the original purpose of the change.

Probably the language would be cleaner if every expression denoted an
object, and if the syntactic distinction between 'name' and 'expression'
were removed.  We considered doing that, but it seemed like a lot of
change for little benefit.

It would also be *useful*, in at least one case: I've sometimes wanted
to use a qualified_expression as an object name -- the purpose was to
resolve some otherwise-ambiguous name, but I couldn't do it, because I
didn't want the *value* of that object.

- Bob

Re: ObjectAda vs Gnat -- bugs

[Stephen Leake]

Robert A Duff wrote:
> 
> OK.  See RM-6.4(12) and 6.5(21).  And AARM-6.5(24.d) explains why.  The
> fact that you can rename function results is just a side-effect -- it
> wasn't the original purpose of the change.

Thanks, but where, exactly, do I find the "AARM"? I assume this is the
"Annotated Ada Reference Manual", but I cannot find it at AdaHome or
AdaIC. I assume this is NOT the Rationale.

-- 
- Stephe

Re: ObjectAda vs Gnat -- bugs

[Robert A Duff]

In article <338C6563.2679@gsfc.nasa.gov>,
Stephen Leake  <Stephen.Leake@gsfc.nasa.gov> wrote:
>Robert A Duff wrote:
>> 
>> OK.  See RM-6.4(12) and 6.5(21).  And AARM-6.5(24.d) explains why.  The
>> fact that you can rename function results is just a side-effect -- it
>> wasn't the original purpose of the change.
>
>Thanks, but where, exactly, do I find the "AARM"?

It's at sw-eng.falls-church.va.us in directory
public/adaic/docs/standard/95lrm_rat/v6.0.

>... I assume this is the
>"Annotated Ada Reference Manual",

Yes.

>... but I cannot find it at AdaHome or
>AdaIC. I assume this is NOT the Rationale.

Correct.  It is not the Rationale.

AARM-6.5(24.d) just says:

        24.d   A function now creates an anonymous object.  This is necessary
        so that controlled types will work.

I.e. it wasn't intended as a "big deal" and the fact that you can rename
function results as constant objects was a handy side effect, but not
the original purpose.

The AARM is boring and useless for most folks.  But if you want to know
in detail why Ada 95 is the way it is, or if you're a compiler writer,
the AARM is useful.  It's filled with arcane trivia.

- Bob

Re: ObjectAda vs Gnat -- bugs

[Matthew Heaney]

In article <EAywJp.4uA@world.std.com>, bobduff@world.std.com (Robert A
Duff) wrote:


>The AARM is boring and useless for most folks.  But if you want to know
>in detail why Ada 95 is the way it is, or if you're a compiler writer,
>the AARM is useful.  It's filled with arcane trivia.

"Arcane trivia" and funny tidbits, like:

package Ada.Streams is
   pragma Pure (Streams); {unpolluted}

The evaluation of an allocator creates an object and yields an access value
that designates the object.  {heap management: see also alligator}

Funny, Bob...

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: ObjectAda vs Gnat -- bugs

[Robert A Duff]

In article <mheaney-ya023680003005972308580001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>"Arcane trivia" and funny tidbits, like:

Well, it's hard to write 800 pages of arcane trivia without getting
silly once in a while.

By the way, one can find "unpolluted" and "heap management" in the RM
index.  Alligator comes from an early (pre-1983) Ada compiler written by
Intermetrics (in Simula 67), in which there was a node in the abstract
syntax tree whose type (class, actually!) was called Alligator_Exp.
Alligators might lurk in the RM, but only the AARM has squirrels (thanks
to Dave Emery, who, if I remember correctly, argued for fairness on this
point).

- Bob

Re: ObjectAda vs Gnat -- bugs

[Samuel Mize]

In article <338C6563.2679@gsfc.nasa.gov>,
Stephen Leake  <Stephen.Leake@gsfc.nasa.gov> wrote:
>Thanks, but where, exactly, do I find the "AARM"? I assume this is the
>"Annotated Ada Reference Manual", but I cannot find it at AdaHome or
>AdaIC. I assume this is NOT the Rationale.

No, it isn't.  It's the Language Reference Manual, with annotations that
tell you what the design team was dr^H^H thinking when they made each
decision.

AdaIC has copies available in PostScript and ASCII text, but you have to
hunt around -- they're under a directory named "95lrm_rat".  The URL is:

  ftp://sw-eng.falls-church.va.us/public/AdaIC/standards/95lrm_rat/v6.0

You want either aarm.ps or aarm.txt.

Either is one big hummer of a file.  The postscript version is  5277 Kb.
The ASCII version is a svelte 2737 Kb.

Note that the example code in the ASCII version can be hard to read.  The
file was apparently run through a text formatter, and many lines of code
were longer than the line length, so you get artifacts like:

     type Whatever is (a, b, c,       <--- line wrap
   d, e);
     subtype     Fred        is       <--- spaces added to justify line
   Whatever range b..c;

Following is a chunk of the README_lrm file from this directory.

: This directory contains version 6.0 of the Ada 95 Reference Manual.
: This version is the same as the International Standard, except for minor
: formatting differences, such as the fact that this version has paragraph
: numbers, whereas the International Standard does not.  All differences
: between this version are listed in the introduction.
:  
: The files in ../v6.0.compressed were compressed by the "zip" program.
:  
:     aarm.txt -- Annotated Ada 95 Reference Manual, plain Ascii format
:     aarm.ps -- Annotated Ada 95 Reference Manual, postscript
:     chg83.doc -- Changes from Ada 83 to Ada 95, plain Ascii format
:     chg83.ps -- Changes from Ada 83 to Ada 95, postscript
:     rm.txt -- Ada 95 Reference Manual, plain Ascii format
:     rm.ps -- Ada 95 Reference Manual, postscript
:     rm_a4.ps -- Ada 95 Reference Manual, A4 format, postscript
:  
:     rmsource.ada -- Source for Language-Defined Library Units
:  
: The file rm.doc was split into files with names of the form "rmsplit.a?"
: using the Unix split program.  Each piece is 2200 lines, and less
: than 100kbytes, for ease of transfer.
:  
: See README_rat.txt for info on the Ada 95 rationale.

Samuel Mize

-- 
Samuel Mize -- smize@imagin.net -- Team Ada
(personal net account)

Re: ObjectAda vs Gnat -- bugs

[tmoran]

So if I wanted to make some reusable object with the characteristics:
  constant once created
  creation requires info not conveniently done with discriminants
  limited
one approach would be to make the type T limited and tell users to declare
  X : T renames Create(...);
Right?

Re: ObjectAda vs Gnat -- bugs

[Jon S Anthony]

In article <5loibn$qek@lotho.delphi.com> tmoran@bix.com writes:

> So if I wanted to make some reusable object with the characteristics:
>   constant once created
>   creation requires info not conveniently done with discriminants
>   limited
> one approach would be to make the type T limited and tell users to declare
>   X : T renames Create(...);
> Right?

Works for me...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: ObjectAda vs Gnat -- bugs

[Jeff Carter]

Jon S Anthony wrote:
> 
> In article <5loibn$qek@lotho.delphi.com> tmoran@bix.com writes:
> 
> > So if I wanted to make some reusable object with the characteristics:
> >   constant once created
> >   creation requires info not conveniently done with discriminants
> >   limited
> > one approach would be to make the type T limited and tell users to declare
> >   X : T renames Create(...);
> > Right?
> 
> Works for me...
> 
> /Jon
> --
> Jon Anthony
> Organon Motives, Inc.
> Belmont, MA 02178
> 617.484.3383
> jsa@organon.com

I'd want to put "constant" in there, just to remind me:

   X : constant T renames Create (...);
-- 
Jeff Carter  PGP:1024/440FBE21
Auntie-spam reply-to; try ( carter @ innocon . com )
"Now go away, or I shall taunt you a second time."
Monty Python & the Holy Grail

Re: ObjectAda vs Gnat -- bugs

[Nick Roberts]

Jon S Anthony <jsa@alexandria> wrote in article
<JSA.97May19145513@alexandria>...
> In article <5loibn$qek@lotho.delphi.com> tmoran@bix.com writes:
> 
> > So if I wanted to make some reusable object with the characteristics:
> >   constant once created
> >   creation requires info not conveniently done with discriminants
> >   limited
> > one approach would be to make the type T limited and tell users to
declare
> >   X : T renames Create(...);
> > Right?
> 
> Works for me...
> 


No, I don't agree. I think the "renames" is potentially misleading. An
alternative approach would be:

      X: T; -- X initialised to an unusable status
   begin
      Init(X,...); -- X now set up as required

The first parameter of procedure X would be of type "in out T". This may be
uglier than the above solution, but it would be less misleading, and it
might be more flexible in some situations (as arbitrary processing can
precede the call to Init). Any attempt to use X before it had been properly
set up could be detected and raise an exception. If X needs to be constant
once set up, any attempt to call Init again on X could also be detected and
raise and exception.

Nick.

Re: ObjectAda vs Gnat -- bugs

[Tom Moran]

>   X : T renames Create(...);
vs.
>       X: T; -- X initialised to an unusable status
>    begin
>       Init(X,...); -- X now set up as required
> ... If X needs to be constant
> once set up, any attempt to call Init again on X could also be detected and
> raise and exception.
  The "renames" has the advantage that any attempt to modify or
re-create X would show us as a compile time, rather than a (possibly
path-dependent) run time, error.  OTOH, the "renames" might get some
later maintenance programmer into a tizzy. ;)

Re: ObjectAda vs Gnat -- bugs

[John Walker]

This may already have been answered, but ...

On Wed, 28 May 1997 13:03:31 -0400
  Stephen Leake <Stephen.Leake@GSFC.NASA.GOV> asked:

>Thanks, but where, exactly, do I find the "AARM"? I assume this is the
>"Annotated Ada Reference Manual", but I cannot find it at AdaHome or
>AdaIC. I assume this is NOT the Rationale.

go to http://sw-eng.falls-church.va.us/AdaIC/standards/

and there's a link to a choice of .txt, .ps, and .zip files:

http://sw-eng.falls-church.va.us/AdaIC/standards/95lrm/LRMascii/
http://sw-eng.falls-church.va.us/AdaIC/standards/95lrm/LRMps/
http://sw-eng.falls-church.va.us/AdaIC/standards/95lrm/LRMzip/

take care,

John
         ---------------------------------------------------
           John Walker, walkerj@sw-eng.falls-church.va.us
              ---Assembler is a high-level language.---
 .GET DSCLAIMR.STD   ; & consider the effect of the insertion point
         ---------------------------------------------------