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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,b47b15fda2aeb0b2
X-Google-Attributes: gid103376,public
From: ncohen@watson.ibm.com (Norman H. Cohen)
Subject: Re: Two ideas for the next Ada Standard
Date: 1996/09/10
Message-ID: <513vo7$g9b@watnews1.watson.ibm.com>#1/1
X-Deja-AN: 179719959
distribution: world
references: <50aao3$3r88@news-s01.ny.us.ibm.net>
organization: IBM T.J. Watson Research Center
reply-to: ncohen@watson.ibm.com
newsgroups: comp.lang.ada
Date: 1996-09-10T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <5137hi$9oq@goanna.cs.rmit.edu.au>, ok@goanna.cs.rmit.edu.au
(Richard A. O'Keefe) writes: 

|> So far the only way I've been able to figure out of exporting some
|> of the enumeration literals of an enumeration type is
|>
|>      package foo is
|>          type T is private;
|>          function X return T;
|>          function Z return T;
|>      private
|>          type T is (X, Y, Z, W);
|>      end foo;
|>
|> At least, I _thought_ it should work.  Enumeration literals are
|> parameterless functions returning values of the type, not so?
|> But gnat says that the declarations of X and Z in the private
|> part _conflict_ with the earlier declarations (instead of, as I
|> thought, matching them), and who am I to argue?
|>
|> My reaction to this was not to look through the standard for the fine
|> print explaining why I can't do it this way, but to stop trying.
|> Exporting half an enumeration type is probably too silly.

For the record, it's excluded by RM 6.1(20), which lists the allowable
completions for a subprogram declaration.  An enumeration-literal
specification is not among them.  (Also, RM 3.5.1(6) says that an
enumeration-literal specification DECLARES a parameterless function.
This makes it different from a function body, which serve as either a
declaration or a completion, depending on the context.  You cannot
declare the same function twice in the same package specification.)

However, a subprogram renaming declaration is allowed to serve as the
completion of a declaration, and can rename an enumeration literal, so
you can do the following: 

   package Foo is
       type T is private;
       function X return T;
       function Z return T;
   private
       type T is (X_Value, Y_Value, Z_Value, W_Value);
       function X return T renames X_Value;
       function Z return T renames Z_Value;
   end Foo;

(I gave the literals different names from the functions so that both
could be declared in the same package specification.)

I think that enumeration-literal specifications probably could have been
allowed as completions of function declarations without creating any
semantic difficulty.  I even think I recall someone mentioning the
possibility at the 9X review meeting where Tuck proposed allowing
renaming declarations as completions, but then again I may just be
imagining that (False Memory Syndrome ;-)).  In any event, if it was
thought of at the time, it wasn't considered important enough to add to
the burden of language implementors.

--
Norman H. Cohen    ncohen@watson.ibm.com