Enumeration literals and their associated functions

Enumeration literals and their associated functions

[Maciej Sobczak]

Hi,

<http://www.adaic.org/standards/95aarm/html/AA-3-5-1.html>, paragraph 6 
states that for each enumeration literal specification there is an 
appropriate parameterless function declated.

    type Color is (RED, GREEN, BLUE);

    type Function_Access is access function return Color;

    Fa : Function_Access := RED'Access;

The compiler reports an error in the last line:

"prefix of "Access" attribute cannot be enumeration literal"

I understand that the use of "RED" in this line is not resolved to be a 
name of the function. If that is the case, then how can I use this function?

Another example:

Some_Function_That_Expects_Color(RED);

Is the use of "RED" above considered to be a function call? If yes, then 
why in RED'Access it is resolved to be a literal?
If instead "RED" above is considered to be a literal, then what's the 
sense of having an associated function at all?


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Enumeration literals and their associated functions

[Frank J. Lhota]

Maciej Sobczak wrote:
> Hi,
> 
> <http://www.adaic.org/standards/95aarm/html/AA-3-5-1.html>, paragraph 6 
> states that for each enumeration literal specification there is an 
> appropriate parameterless function declated.
 >
>    type Color is (RED, GREEN, BLUE);
> 
>    type Function_Access is access function return Color;
> 
>    Fa : Function_Access := RED'Access;
> 
> The compiler reports an error in the last line:
> 
> "prefix of "Access" attribute cannot be enumeration literal"

The problem here is that enumeration literals are Intrinsic functions 
(See ARM 6.3.1). Intrinsic subprograms are "built in" to the compiler. 
When an intrinsic subprogram is called, the compiler will typically 
in-line some pre-defined code for the call. In other words, Intrinsic 
subprograms are always inlined.

The basic arithmetic operations declared in Standard, e.g.

	function "+" (Left : Integer; Right : Integer) return Integer;

are intrinsic functions. The compiler simply uses the one assembler 
instruction for calls to these functions. Enumeration literals are 
always intrinsic functions: the compiler simply uses the internal 
representation value as the result of the call.

The 'Access attribute, when applied to a subprogram, returns the 
location of the code for that subprogram in memory. For intrinsic 
subprograms, however, this code does not exist! Therefore, the 'Access 
attribute cannot be applied to an intrinsic function. If I declare

    function Add (Left, Right : in Integer) return Integer
       renames Standard."+";

then I cannot use Add'Access either.

If you really do need a pointer to a function that always returns a 
certain enumeration value, you can always write you own function, as follows

    function Always_Red return Color is
    begin
       return RED;
    end Always_Red;

    Fa : Function_Access := Always_Red'Access;

> I understand that the use of "RED" in this line is not resolved to be a 
> name of the function. If that is the case, then how can I use this 
> function?

Basically, the only use of the function notation for enumeration 
literals is in renaming declarations.

> Another example:
> 
> Some_Function_That_Expects_Color(RED);
> 
> Is the use of "RED" above considered to be a function call? If yes, then 
> why in RED'Access it is resolved to be a literal?
> If instead "RED" above is considered to be a literal, then what's the 
> sense of having an associated function at all?
> 
> 


-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for the this one to come home!"
- Mr. Lizard from "Tutor Turtle"

Re: Enumeration literals and their associated functions

[Dmitry A. Kazakov]

On Thu, 20 Oct 2005 16:21:26 +0200, Maciej Sobczak wrote:

> If instead "RED" above is considered to be a literal, then what's the 
> sense of having an associated function at all?

Literal = function. So the following is legal:

   type Color is (RED, GREEN, BLUE);
   function Get_Red return Color renames RED;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Enumeration literals and their associated functions

[Niklas Holsti]

Maciej Sobczak wrote:
> Hi,
> 
> <http://www.adaic.org/standards/95aarm/html/AA-3-5-1.html>, paragraph 6 
> states that for each enumeration literal specification there is an 
> appropriate parameterless function declated.
> 
>    type Color is (RED, GREEN, BLUE);
> 
> ...
> If instead "RED" above is considered to be a literal, then what's the 
> sense of having an associated function at all?

I believe that the LRM defines enumeration literals as functions 
because this automatically defines their overloading. That is, you 
can have another enumeration type that also has the literal RED (a 
synonym), yet overloading lets the compiler resolve which RED is 
meant, by the context.

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

Re: Enumeration literals and their associated functions

[Simon Wright]

"Frank J. Lhota" <NOSPAM.lhota@adarose.com> writes:

> Basically, the only use of the function notation for enumeration
> literals is in renaming declarations.

I'm not sure whether you would regard it as different .. but you can
use an enumeration literal to satisfy a generic formal:

   generic
      with function Control return Boolean;
   package Foo is

   package Bar is new Foo (Control => True);

Re: Enumeration literals and their associated functions

[Randy Brukardt]

"Niklas Holsti" <nobody@nowhere.fi> wrote in message
news:D6Q5f.3855$Yx5.800@reader1.news.jippii.net...
> Maciej Sobczak wrote:
> > Hi,
> >
> > <http://www.adaic.org/standards/95aarm/html/AA-3-5-1.html>, paragraph 6
> > states that for each enumeration literal specification there is an
> > appropriate parameterless function declated.
> >
> >    type Color is (RED, GREEN, BLUE);
> >
> > ...
> > If instead "RED" above is considered to be a literal, then what's the
> > sense of having an associated function at all?
>
> I believe that the LRM defines enumeration literals as functions
> because this automatically defines their overloading. That is, you
> can have another enumeration type that also has the literal RED (a
> synonym), yet overloading lets the compiler resolve which RED is
> meant, by the context.

Right. The classic example is:

    type Base is (Bin, Oct, Dec, Hex);
    type Month is (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov,
Dec);

Both enumerations have literals Oct and Dec. If these were treated as
objects, that would be illegal. So the language treats them as intrinsic
functions instead. Then
   This_Month : Month := Oct;
works, because the standard overloading rules apply.

Practically, you can just think of them as overloaded literals. It probably
makes more sense that way. The definition as a function is primarily to make
the language rules more consistent (and simpler); it's not some sort of
important feature.

                         Randy.

Re: Enumeration literals and their associated functions

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Right. The classic example is:
> 
>     type Base is (Bin, Oct, Dec, Hex);
>     type Month is (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov,
> Dec);

I thought the classic example was Rainbow_Color and Traffic_Light,
both of which have a Red.  ;-)

> Both enumerations have literals Oct and Dec. If these were treated as
> objects, that would be illegal. So the language treats them as intrinsic
> functions instead. Then
>    This_Month : Month := Oct;
> works, because the standard overloading rules apply.

Yeah, that's probably the reason.  The reasoning seems to be:

1. Only subprograms should be overloadable.
2. But it would sure be nice if enumeration literals were overloadable.
3. Therefore, we had better pretend that enum lits are functions.

It seems to me it would be better, after recognizing (2), to say:

3. Therefore, (1) must be wrong.  It should be replaced by "Only
   subprograms and enumeration literals should be overloadable."

Pretending enum lits are functions is just plain confusing,
and provides no important functionality.

And, perhaps:

4. If enum lits are overloadable, then constants should be overloadable,
   too.

After all, one might want to change type Base above (for various good
reasons) to:

    package ... is
        type Base is private;
        Bin: constant Base;
        Oct: constant Base;
        ...
    private
        ...
    end ...;

But now any place that uses both Base and Month might become ambiguous,
and have to be changed, for no good reason.

> Practically, you can just think of them as overloaded literals. It probably
> makes more sense that way. The definition as a function is primarily to make
> the language rules more consistent (and simpler); it's not some sort of
> important feature.

More consistent, perhaps.  Certainly not simpler.

- Bob

Re: Enumeration literals and their associated functions

[Larry Kilgallen]

In article <wcczmp36bid.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
> 
>> Right. The classic example is:
>> 
>>     type Base is (Bin, Oct, Dec, Hex);
>>     type Month is (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov,
>> Dec);
> 
> I thought the classic example was Rainbow_Color and Traffic_Light,
> both of which have a Red.  ;-)

No that would be Rainbow_Color and Political_Epithet to be full homonyms.

Re: Enumeration literals and their associated functions

[Jeffrey R. Carter]

Robert A Duff wrote:

> I thought the classic example was Rainbow_Color and Traffic_Light,
> both of which have a Red.  ;-)

Me, too. They both have Green, too, which is important for Ada.

-- 
Jeff Carter
"I was hobbling along, minding my own business, all of a
sudden, up he comes, cures me! One minute I'm a leper with
a trade, next minute my livelihood's gone! Not so much as a
'by your leave!' You're cured, mate. Bloody do-gooder!"
Monty Python's Life of Brian
76

Re: Enumeration literals and their associated functions

[adaworks]

"Jeffrey R. Carter" <spam@spam.com> wrote in message
news:fz_5f.3687$fc7.995@newsread3.news.pas.earthlink.net...
> Robert A Duff wrote:
>
> > I thought the classic example was Rainbow_Color and Traffic_Light,
> > both of which have a Red.  ;-)
>
> Me, too. They both have Green, too, which is important for Ada.
>
And we all know that, "It isn't easy being green."

Richard Riehle