From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,d0452dbe16ac0df4
X-Google-Attributes: gid103376,public
From: "Nick Roberts" <Nick.Roberts@dial.pipex.com>
Subject: Re: ObjectAda vs Gnat -- bugs
Date: 1997/05/18
Message-ID: <01bc63a9$6e4575c0$LocalHost@xhv46.dial.pipex.com>#1/1
X-Deja-AN: 242998820
References: <EA93C3.CF4@thomsoft.com> <EAAIBG.A7s@world.std.com>
 <dewar.863824104@merv>
Organization: UUNet PIPEX server (post doesn't reflect views of UUNet PIPEX)
Newsgroups: comp.lang.ada
Date: 1997-05-18T00:00:00+00:00
List-Id: <comp.lang.ada>




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.