Re: Odd subtyping error.

[Adam Beneschan <adam@irvine.com>]

On Friday, October 5, 2012 3:19:57 PM UTC-7, Shark8 wrote:
> On Friday, October 5, 2012 4:11:06 PM UTC-6, Adam Beneschan wrote:
> 
> > 
> 
> > Ah, "the rest of the story"!  The size clause isn't the problem.  The problem is that referring to Item_2 and Item_4 in the declaration of Derived_Type freezes Base_Type, and you can't add any more representation information after that.  That makes "For Base_Type Use ..." illegal.  If the error messages in your original case pointed you to the wrong line numbers, that's something you can complain to the GNAT folks about.  But the error is legitimate, at least in your reduced source.
> 
> 
> 
> Hm, why does it force freezing?

If you're looking for the rule that says this, it's 13.14(8).  If you're looking for the reason:

When you declare the enumeration type, the values of the type are provisionally given the representations 0, 1, 2, ...  i.e. in your example Item_1=0, Item_2=1, etc.  Those will be the defaults if there is no other representation clause.  When you *use* one of the enumeration literals, though, then depending on what you use it for, the compiler could have to generate code to use the correct representation, e.g. it may have to generate code to put Item_2 into a variable(or a word in a data section in the executable), pass it to a function, or do something else with it.  Therefore, at that point, the representation has to have been determined, so that the compiler knows what value to store or load or whatever.  It could turn out (as in your small example) that the compiler doesn't actually have to do anything with the value.  But the language has to have rules to make sure things work right when the value *is* needed, and writing relatively simple rules that may make things a little more restrictive than necessary is preferred over writing overly complex rules to try to get every case perfect, or leaving the rules so vague that the program isn't portable.

You might be thinking, "well, why doesn't the compiler just look ahead in the source and find the representation clause?"  All I can say is, this isn't in line with Ada's design philosophy, which is to design the language so that it can be compiled with one scan through the code.  I'm not exactly sure why this philosophy was adopted.  Efficiency was probably one reason.  But another advantage, I think, is that it eliminates the possibility of mutual dependencies that could come up if you were allowed to write code that the compiler couldn't handle without looking ahead. 
 
> Is there a way to force defferment, or flag that there will be a representation-clause, maybe with an aspect clause " with Representation, Size => Enum'Size"

No, I don't think so.

I think you'll have to move the representation clause out of the private part.  This shouldn't have any impact, except on readability (which I acknowledge is important); but as far as I know, there is no case where the legality or semantics of a program *using* your package is affected by whether an enumeration representation clause is in the visible or private part.

                                -- Adam