Re: Enumeration literals and their associated functions

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"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