Version 1.3 of si99s/si99-0059-1.txt

Unformatted version of si99s/si99-0059-1.txt version 1.3
Other versions for file si99s/si99-0059-1.txt

!standard 16.4          10-01-02 SI99-0059-1/03
!standard 16.8
!class Binding Interpretation 09-12-30
!status work item 09-11-07
!status received 09-11-07
!priority Medium
!difficulty Medium
!qualifier Omission
!subject Handling enumerations with very many literals
!summary
** TBD **
!question
Ada 05 has Wide_Wide_Character. There is also the possibility of "type X is new Wide_Wide_Character;".
Technically there has always been the possibility of a user declaring an enumeration type with "a very great many" literals in it. With previous versions of the ASIS standard it was possible to dodge the problem and fall back on compiler implementation restrictions that would make it impossible for a user to, in any practical sense, declare an enumeration type with anything close to 2**32 literals in it. Now the language does this itself.
This leads to problems with using the ASIS specification when analyzing programs that actually use this language built-in type.
16.4 function Implicit_Inherited_Declarations - when presented with a type definition consisting of "new Wide_Wide_Character" this interface has the potential for raising Storage_Error, both inside itself, which can be caught and turned into Asis_Failed, and also while in the process of returning a computed value, which cannot be caught. This limitation is not mentioned in the standard.
16.8 function Enumeration_Literal_Declarations - has the same sort of problem. In addition, it is easy to imagine that a programmer would have the ability to define other enumerations where either (a) the list of An_Enumeration_Literal_Specifications could not be created internally to the ASIS implementation or (b) could not be returned once created. The probable cause of such problems will be either (a) not enough stack, (b) not enough free memory is available, or even (c) the machine supporting the ASIS program does not have sufficient address space to even conceivably support the creation of such a list.
The problem is fundamentally insurmountable. However it can be made somewhat less monumental and applications that wish to attempt analysis of such programs can be given a chance.
!recommendation
Add these cautions in 16.4 and 16.8:
May raise Asis_Failed with a Status of Storage_Error if the implementation is unable to create the result in the stack or memory space available and may raise Storage_Error if the result cannot be returned after being created. This is particularly likely if the Type_Definition involves Standard.Wide_Wide_Character but is possible with any very large enumeration type.
Add the following interfaces so that applications have the ability to (a) know how many enumeration literals there are even if it may be
unable to actually manipulate them all at one time,
(b) obtain any given literal specification regardless of how many
there may be, and
(c) tell when they can expect 16.4 and 16.8 to fail.
In package Asis.Definitions:
function Enumeration_Literal_Count
(Type_Definition: in Asis.Type_Definition) return Asis.Asis_Positive;
Returns the number of literals in An_Enumeration_Type_Definition. Raises Constraint_Error if the number is outside the range of ASIS_Positive.
Type_Definition expects an element that has the following Type_Kinds:
An_Enumeration_Type_Definition
Raises ASIS_Inappropriate_Element with a Status of Value_Error for any element that does not have one of these expected kinds.
Returns a list of elements that each have the following Declaration_Kinds:
An_Enumeration_Literal_Specification
function Enumeration_Literal_Specification
(Type_Definition : in Asis.Type_Definition; Position : in Asis.ASIS_Natural) return Asis.Declaration;
Returns the An_Enumeration_Literal_Specification for the literal indicated by Position of the enumeration type.
Type_Definition expects an element that has the following Type_Kinds:
An_Enumeration_Type_Definition
Raises ASIS_Inappropriate_Element with a Status of Value_Error for any element that does not have one of these expected kinds.
Returns an element that has the following Declaration_Kinds:
An_Enumeration_Literal_Specification
!wording
!discussion
[JPR] Removed type Asis_Unsigned; Wide_Wide_Character has 2**31 values, not 2**32, therefore using Asis_Integer should be OK.
[JPR] changed Enumeration_Literal_Specification to use plain Asis_Natural, rather than going through Strings.
[JPR] Changed name of Enumeration_Literal_Length to Enumeration_Literal_Count.
!appendix

Randy's thoughts on the version /01 proposal:

Surely, we don't want random musings like "Not a guarantee of course" in the
normative wording! Otherwise, the idea is sound. More importantly, should the
old function Enumeration_Literal_Declarations be made obsolescent? It seems
dangerous to use, and annoying if you only want one literal. A second question:
making the position a string adds extra steps into the common idiom of looping
over all of the positions. Since we already are defining a type to represent
position numbers (and that's what ASIS_Unsigned is here), we should use it in
the function. (We should also consider adding a Position_Number function that
returns the actual value.)

Alternatively, we should just make the user use the semantic interface to get
the literals if they need them for a type that is too long. Then we would only
need a single new function to get views of the literals based on position
numbers (there are already functions to get the bounds of a scalar subtype).

*****************************************************************

From: Jean-Pierre Rosen
Sent: Thursday, November 12, 2009  10:00 PM

Here is my homework to make a new AI from SI99-0057, the part that talks about
the problems with Wide_Wide_Character. [This is version /02 of the SI - ED]

I changed the suggested wording to use plain Asis_Integer, after I checked that
Wide_Wide_Character has 2**31 elements, not 2**32. There would be a problem for
Asis implementations that do not follow the implementation advice that
Asis_Integer is at least 32 bits - so unlikely in practice that I think we can
accept it. And it simplifies the interface a lot. But we can discuss it of
course.

****************************************************************

From: Tucker Taft
Sent: Thursday, November 12, 2009  10:07 PM

I would prefer "Enumeration_Literal_Count" to "Enumeration_Literal_Length".
"..._Length" sounds like the length of a particular enumeral (in characters,
presumably), rather than the number of enumerals.

****************************************************************

From: Jean-Pierre Rosen
Sent: Friday, November 13, 2009  12:51 AM

Absolutely agree. This is from the original, and apparently I forgot to make the
change as I intended... [Editor's note: I made the change as suggested.]

****************************************************************

From: Pascal Leroy
Sent: Sunday, November 15, 2009  9:37 AM

> I changed the suggested wording to use plain Asis_Integer, after I
> checked that Wide_Wide_Character has 2**31 elements, not 2**32. There
> would be a problem for Asis implementations that do not follow the
> implementation advice that Asis_Integer is at least 32 bits - so
> unlikely in practice that I think we can accept it. And it simplifies
> the interface a lot. But we can discuss it of course.

But you still have a problem, because as you point out it has 2**31 elements,
but the result subtype of function Enumeration_Literal_Length has a 'Last of
2**31-1.  Maybe the function should be Enumeration_Literal_Length_Minus_One, but
that stinks.

****************************************************************

From: Randy Brukardt
Sent: Wednesday, December 30, 2009  8:24 PM

> Here is my homework to make a new AI from SI99-0057, the part that
> talks about the problems with Wide_Wide_Character.

Umm, the two functions are missing the list of acceptable element Type_Kinds and
the boilerplate for raising exceptions. The wording needs to be consistent with
the rest of the ASIS standard! The second function needs a list of element kinds
that can be returned as well. (Sorry to be nitpicky, but that's my job.)

****************************************************************

From: Jean-Pierre Rosen
Sent: Saturday, January 2, 2010  1:47 AM

Better like this? [This is version /03 of the SI. - Editor.]

> Umm, the two functions are missing the list of acceptable element 
> Type_Kinds and the boilerplate for raising exceptions. The wording 
> needs to be consistent with the rest of the ASIS standard! The second 
> function needs a list of element kinds that can be returned as well. 
> (Sorry to be nitpicky, but that's my job.)
 
Sure. And happy new year!

****************************************************************

Questions? Ask the ACAA Technical Agent