Odd subtyping error.

Odd subtyping error.

[Shark8]

I'm making a new OpenGL binding taking advantage of Ada 2012 and have come across several interesting errors, including a compiler-bug... but this one is by far the oddest:

    Type Pixel_Storage is (
	UNPACK_SWAP_BYTES,	UNPACK_LSB_FIRST,	UNPACK_ROW_LENGTH,		
	UNPACK_SKIP_ROWS,	UNPACK_SKIP_PIXELS,	UNPACK_ALIGNMENT,
	PACK_SWAP_BYTES,	PACK_LSB_FIRST,		PACK_ROW_LENGTH,
	PACK_SKIP_ROWS,		PACK_SKIP_PIXELS,	PACK_ALIGNMENT,
	PACK_SKIP_IMAGES,	PACK_IMAGE_HEIGHT,	UNPACK_SKIP_IMAGES,
	UNPACK_IMAGE_HEIGHT
			  ) with Size => Enum'Size;

    SubType Pixel_Packing is Pixel_Storage Range PACK_SWAP_BYTES..PACK_IMAGE_HEIGHT;

Unless I'm just completely misunderstanding the above should be perfectly fine, yet it generates a few errors:
	warning: no more representation items for type "Pixel_Storage" defined at line 625
	representation item appears too late [private section representation-clause]

Re: Odd subtyping error.

[Niklas Holsti]

On 12-10-05 19:05 , Shark8 wrote:
> I'm making a new OpenGL binding taking advantage of Ada 2012 and have come across several interesting errors, including a compiler-bug... but this one is by far the oddest:
> 
>     Type Pixel_Storage is (
> 	UNPACK_SWAP_BYTES,	UNPACK_LSB_FIRST,	UNPACK_ROW_LENGTH,		
> 	UNPACK_SKIP_ROWS,	UNPACK_SKIP_PIXELS,	UNPACK_ALIGNMENT,
> 	PACK_SWAP_BYTES,	PACK_LSB_FIRST,		PACK_ROW_LENGTH,
> 	PACK_SKIP_ROWS,		PACK_SKIP_PIXELS,	PACK_ALIGNMENT,
> 	PACK_SKIP_IMAGES,	PACK_IMAGE_HEIGHT,	UNPACK_SKIP_IMAGES,
> 	UNPACK_IMAGE_HEIGHT
> 			  ) with Size => Enum'Size;
> 
>     SubType Pixel_Packing is Pixel_Storage Range PACK_SWAP_BYTES..PACK_IMAGE_HEIGHT;
> 
> Unless I'm just completely misunderstanding the above should be perfectly fine, yet it generates a few errors:
> 	warning: no more representation items for type "Pixel_Storage" defined at line 625
> 	representation item appears too late [private section representation-clause]
> 

It would be easier to answer you if you showed a complete, minimal
example (i.e. an .ads file) where you have removed the irrelevant parts.

The second error/warning line suggests to me that you have declared
Pixel_Storage first as a "private" type, and that the full type
declaration, including the "with Size" clause, appears only in the
"private" part of the package declaration. Is that the case?

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

Re: Odd subtyping error.

[Adam Beneschan]

On Friday, October 5, 2012 11:12:18 AM UTC-7, Niklas Holsti wrote:
> On 12-10-05 19:05 , Shark8 wrote:
> 
> > I'm making a new OpenGL binding taking advantage of Ada 2012 and have come across several interesting errors, including a compiler-bug... but this one is by far the oddest:
> 
> >     Type Pixel_Storage is (
> > 	UNPACK_SWAP_BYTES,	UNPACK_LSB_FIRST,	UNPACK_ROW_LENGTH,		
> > 	UNPACK_SKIP_ROWS,	UNPACK_SKIP_PIXELS,	UNPACK_ALIGNMENT,
> > 	PACK_SWAP_BYTES,	PACK_LSB_FIRST,		PACK_ROW_LENGTH,
> > 	PACK_SKIP_ROWS,		PACK_SKIP_PIXELS,	PACK_ALIGNMENT,
> > 	PACK_SKIP_IMAGES,	PACK_IMAGE_HEIGHT,	UNPACK_SKIP_IMAGES,
> > 	UNPACK_IMAGE_HEIGHT
> > 			  ) with Size => Enum'Size;
> > 
> 
> >     SubType Pixel_Packing is Pixel_Storage Range PACK_SWAP_BYTES..PACK_IMAGE_HEIGHT;
> 
> > Unless I'm just completely misunderstanding the above should be perfectly fine, yet it generates a few errors:
> 
> > 	warning: no more representation items for type "Pixel_Storage" defined at line 625
> > 	representation item appears too late [private section representation-clause]
> 
> It would be easier to answer you if you showed a complete, minimal
> example (i.e. an .ads file) where you have removed the irrelevant parts.
> 
> The second error/warning line suggests to me that you have declared
> Pixel_Storage first as a "private" type, and that the full type
> declaration, including the "with Size" clause, appears only in the
> "private" part of the package declaration. Is that the case?

I agree that a more complete example would be helpful.  However, I can't imagine how the fact that it's declared as private could make a difference.  A private type's full declaration must occur before the type is frozen, so if something occurred earlier that would freeze the type, he would have gotten error messages at that point.  The error message he's getting seems to imply that the compiler already thinks the type is frozen by the time it sees the aspect clause, which is impossible; or, if it's displaying the error when it sees the subtype declaration, then it's just plain lost its head.

                            -- Adam

Re: Odd subtyping error.

[Shark8]

On Friday, October 5, 2012 12:12:18 PM UTC-6, Niklas Holsti wrote:
> 
> The second error/warning line suggests to me that you have declared
> Pixel_Storage first as a "private" type, and that the full type
> declaration, including the "with Size" clause, appears only in the
> "private" part of the package declaration. Is that the case?

No; the representation {For Pixel_Storage Use ( ... )} is in the private portion.

The "with Size" aspect is to force the elements/values to use a certain size so that they will be compatible via conversion with the OpenGL functions taking GLEnum parameters -- I chose this typing method to eliminate the possibility of calling incorrect parameters, though perhaps it would have been better to use subtypes with Static_Predicate disallowing invalid values.

Re: Odd subtyping error.

[Shark8]

    Package Subtype_Error is
	Type Base_Type is (
		   Item_1, Item_2, Item_3, Item_4, Item_5
		   ) with Size => Integer'Size;

	SubType Derived_Type is Base_Type Range Item_2..Item_4;
    Private
	For Base_Type Use
	  (
		Item_1	=> 18,
		Item_2	=> 21,
		Item_3	=> 22,
		Item_4	=> 25,
		Item_5	=> 28
   	  );
    End Subtype_Error;

Re: Odd subtyping error.

[Adam Beneschan]

On Friday, October 5, 2012 2:00:53 PM UTC-7, Shark8 wrote:
> Package Subtype_Error is
> 
> 	Type Base_Type is (
> 		   Item_1, Item_2, Item_3, Item_4, Item_5
> 		   ) with Size => Integer'Size;
> 
> 	SubType Derived_Type is Base_Type Range Item_2..Item_4;
>     Private
> 	For Base_Type Use
> 	  (
> 		Item_1	=> 18,
> 		Item_2	=> 21,
> 		Item_3	=> 22,
> 		Item_4	=> 25,
> 		Item_5	=> 28
>    	  );
>     End Subtype_Error;

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.

                              -- Adam

Re: Odd subtyping error.

[Shark8]

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?
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"

Re: Odd subtyping error.

[Adam Beneschan]

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

Re: Odd subtyping error.

[Shark8]

On Friday, October 5, 2012 9:08:07 PM UTC-6, Adam Beneschan wrote:
> 
> 
> 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.

Hm, I see; this might make it a bit unacceptable readability-wise -- there's already a LOT of stuff in the non-private portion ~ though as a mitigating factor, you wouldn't necessarily have to even look in that file to with/use it.

Thank you for the references too, btw.

Re: Odd subtyping error.

[sbelmont700]

On Friday, October 5, 2012 6:19:57 PM UTC-4, Shark8 wrote:
> 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"

Perhaps move the subtypes to a child package?  It would not exactly be the most streamlined, but would allow you to have the public/private/public-again setup

-sb

Re: Odd subtyping error.

[Shark8]

On Saturday, October 6, 2012 3:21:57 PM UTC-6, (unknown) wrote:
> 
> Perhaps move the subtypes to a child package?  It would not exactly be the most streamlined, but would allow you to have the public/private/public-again setup

That's what I ended up doing. Thank you for the suggestion.