Version 1.1 of ai12s/ai12-0342-1.txt

Unformatted version of ai12s/ai12-0342-1.txt version 1.1
Other versions for file ai12s/ai12-0342-1.txt

!standard 4.2.1(0)          19-09-24 AI12-0342-1/01
!standard 6.3.1(22)
!reference AI12-0249-1
!reference AI12-0295-1
!reference AI12-0325-1
!class Amendment 19-04-01
!status Amendment 1-2012 19-04-01
!status ARG Approved 10-0-0 19-04-09
!status work item 19-09-10
!status received 19-08-15
!priority Low
!difficulty Easy
!subject Various issues with user-defined literals (part 2)
!summary
The aspects related to user-defined literals are inheritable. In order to make inheritance work in the tagged case, we follow the example of the Constant_Indexing and Variable_Indexing aspects: the literal-related aspects specify the name of a subprogram, as opposed to specifying a subprogram.
A user-defined literal was previously defined to be have the same dynamic semantics as a function call. That equivalence is extended to also apply in a number of cases involving static semantics (e.g., interactions with abstract types and abstract subprograms).
!problem
There are a number of issues with definition of user-defined literals (even after AI12-0325, which is the "part 1" implicitly referred to in the !subject text).
!proposal
(See summary.)
!wording
Replace all of 4.2.1 with the following:
4.2.1 User-Defined Literals
Using one or more of the aspects defined below, a type may be specified to allow the use of one or more kinds of literals as values of the type.
Static Semantics
The following nonoverridable, type-related operational aspects may be specified for any type T:
Integer_Literal
This aspect is specified by a direct_name that denotes a primitive function of T with one parameter of type String and a result type of T.
Aspect Description for Integer_Literal:
Specifies the name of a function to be used to implement user-defined integer literals.
Real_Literal
This aspect is specified by a direct_name that denotes a primitive function of T with one parameter of type String and a result type of T.
Aspect Description for Real_Literal:
Specifies the name of a function to be used to implement user-defined real literals.
String_Literal
This aspect is specified by a direct_name that denotes a primitive function of T with one parameter of type Wide_Wide_String and a result type of T.
[TBD: the corresponding uses of function_name instead of direct_name in 4.1.6 probably should be changed to match the above; we don't want to allow
package Foo is ... type T is ... with Constant_Indexing => Foo.Bar; function Bar ... ; ... end Foo;
, right?]
Aspect Description for String_Literal:
Defines a function to implement user-defined string literals.
The preceding three rules about what the direct_name in an aspect specification shall denote are name resolution rules. [AARM note: Thus, the following example is legal:
package P is type T is record X, Y : Integer; end record with Integer_Literal => Int_Lit; function Int_Lit (X, Y : T) return Duration; -- wrong profile function Int_Lit (Lit_Image : String) return T; -- right profile end;
]
When a numeric literal is interpreted as value of a non-numeric type T or a string_literal is interpreted a value of a type T that is not a string type (see 4.2), it is equivalent to a call to the primitive operation of type T denoted by the corresponding aspect of T: the Integer_Literal aspect for an integer literal, the Real_Literal aspect for a real literal, and the String_Literal aspect for a string_literal. Such a literal is said to be a "user-defined literal".
[TBD: We could define the term "user-defined literal" in 4.2 instead.]
[AARM note: Many properties are determined by this equivalence. For example, the result of evaluating such a literal is an object because the return object of a function is an object. The nominal type, nominal subtype, and accessibility level are defined as for the equivalent function call. Such a literal is considered to be statically tagged, dynamically tagged, or tag indeterminate depending on the status of the equivalent function call. The freezing associated with evaluation of a user-defined literal is the freezing associated with the equivalent function call. This list of properties is not intended to be exhaustive.]
These aspects are inherited by specific descendants of T. [AARM note: These aspects are never specified for or inherited by a class-wide type.]
Legality Rules
The Integer_Literal or Real_Literal aspect shall not be specified for a type T if the full view of T is a numeric type. The String_Literal aspect shall not be specified for a type T if the full view of T is a string type.
A user-defined literal is illegal if the equivalent function call is illegal.
[AARM note: For example, this implies that if the equivalent function call is a call to an abstract subprogram then the equivalent function call shall be a dispatching call.]
A user-defined integer literal of a type T is illegal if the type T does not have exactly one visible primitive function having the name specified in T's (explicit or inherited) Integer_Literal aspect specification, a result type of T, one parameter of type String, and no other parameters. [AARM note: If exactly one such primitive function exists then that is the function that is called when the literal is evaluated.]
A user-defined real literal of a type T is illegal if the type T does not have exactly one visible primitive function having the name specified in T's (explicit or inherited) Real_Literal aspect specification, a result type of T, one parameter of type String, and no other parameters. [AARM note: If exactly one such primitive function exists then that is the function that is called when the literal is evaluated.]
A user-defined string literal of a type T is illegal if the type T does not have exactly one visible primitive function having the name specified in T's (explicit or inherited) String_Literal aspect specification, a result type of T, one parameter of type Wide_Wide_String, and no other parameters. [AARM note: If exactly one such primitive function exists then that is the function that is called when the literal is evaluated.]
[AARM note: This implies that the following examples are illegal:
package Too_Few is type T1 is null record with Integer_Literal => I_L; type T2 is new T1; function I_L (S : String) return T1 is (null record); X : T2 := 123; -- too few candidates end Too_Few;
procedure Too_Many is generic type Element is private; package G is type T is (Aa, Bb, Cc) with Integer_Literal => I_L; function I_L (X : String) return T1; function I_L (X : Element) return T1; end G; package body G is ... end; package I is new G (Element => String); X : I.T := 123; -- too many candidates begin null; end;
]
In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit.
Dynamic Semantics
For the evaluation of a user-defined literal, the result is the result of the equivalent function call described above. The actual parameter that is passed in is as follows:
- For a numeric literal, the String with lower bound one whose value
corresponds to the textual representation of the literal;
- For a string_literal, the Wide_Wide_String with lower bound one
that corresponds to the literal.
[AARM note: Within an expanded instance of a generic unit, the usual rules about resolution of primitives of formal derived types apply.
That means that in this example,
procedure Proc is package Pkg is type T1 is (T1_Op, T2_Op) with Integer_Literal => I_L; function I_L (S : String) return T1 is (T1_Op);
type T2 is new T1; function I_L (S : String) return T2 is (T2_Op); end Pkg;
generic type Formal_Derived is new T1; package G is end;
package body G is X : Formal_Derived := 123; end G;
package I is new G (T2); begin null; end;
the variable I.X is initialized with the value T1_Op, not T2_Op.]
---
Replace 6.3.1(22-22.a)
- each primary that is a literal in one has the same value as the
corresponding literal in the other.
Ramification: The literals may be written differently.
with
- each primary that is a literal in one is a user-defined literal
if and only if the corresponding literal in the other is also a user-defined literal. Furthermore, if neither are user-defined literals then they shall have the same values [redundant , but they may have differing textual representations]; if both are user-defined literals then they shall have the same textual representation.
!discussion
This AI is about two topics:
1) Inheritance of Integer_Literal, Real_Literal, and String_Literal
aspects.
2) Treating a user-defined literal like a function call for purposes
static semantics, not just dynamic semantics. This is intended to clarify, for example, the rules about how user-defined literals interact with abstract types and abstract subprograms.
A minor hole in the 6.3.1 conformance rules is also addressed.
1) Inheritance
As the RM stands today, the Integer_Literal, Real_Literal, and String_Literal aspects are not inherited. This was clearly unintended and needs to be fixed.
Background: The Integer_Literal, Real_Literal, and String_Literal aspects are defined to be operational aspects.
13.1 says ... whether operational aspects are inherited by a derived type depends on each specific aspect; unless specified, an operational aspect is not inherited.
There is currently no mention of inheritance or of derived types in 4.2.1 (the section on User-Defined Literals), so the aspects are not inherited.
Simply saying "ok, so those aspects are inherited" isn't enough. In a tagged case like
type T1 is tagged record ... end record with Integer_Literal => Nested_Pkg.Nonprimitive_Function; package Nested_Pkg is function Nonprimitive_Function (Lit_Image : String) return T1; end Nested_Pkg; type T2 is new T1 with record ... <more components> ... end record;
the "default" inheritance rule described in 13.1(15.2/2) doesn't work.
To address this issue, we follow the model of the Constant_Indexing and Variable_Indexing aspects; the value of these aspects is not a subprogram but rather the name of a subprogram. [Although unlike those two aspects, the specified name denotes exactly one primitive subprogram of the type.] This means that, even though the three aspects are nonoverridable, users can get the effect of overriding by overriding the primitive operation named by the aspect value.
In this example,
package Pkg is type T1 is record X, Y : Integer; end record with Integer_Literal => I_L; function I_L (S : String) return T1 is ((0, 0)); type T2 is new T1; function I_L (S : String) return T2 is ((1, 1)); X : T2 := 123; -- end;
the initial value of Pkg.X is (1,1), not (0,0).
2) Extending "function call" equivalence rule into static semantics.
Currently, the equivalence between a user-defined literal and a call to the specified function is defined only as a dynamic semantics rule. This results in a lot of definitional holes that are addressed by extending the application of this equivalence into static semantics.
For example, assume we have a tagged type Big_Num whose Integer_Literal aspect specifies a primitive operation of the type, and which also has a primitive two-parameter addition operator with the usual profile. Suppose further that we have this procedure:
procedure Increment (X : in out Big_Num'Class) is begin X := X + 1; end;
We want this example to be legal, but that requires a rule that somehow causes the literal to be treated as a tag-indeterminant call. The second topic of this AI is issues of this kind.
I have discussed earlier versions of this proposal with Randy and Tuck.
They feel (I hope I am stating their position correctly) that following the "Constant_Indexing model", where the value of the aspect is not a subprogram but rather the name of a subprogram, may be unnecessarily complex in the case where the aspect refers to a single subprogram rather than to (potentially) a set of subprograms (as is the case with the Constant_Indexing aspect). They would prefer something more similar to the way that inheritance of streaming attributes is handled. This would presumably involve mandatory overriding in the case of a type extension.
Tuck makes the good point that we need to agree on a meta-rule to decide when to use which model so that we don't end up making this decision arbitrarily on an aspect-by-aspect basis as new aspects arise.
We should discuss this issue, but today's proposal follows the Constant_Indexing model. I am not sure that this is the best approach, but it does solve the inheritance problems associated with type extensions.
Randy questions whether these new aspects need to be overridable. I think we at least want the property (which is a consequence of being overridable) that all views of a single type agree with respect to the new aspects.
!ASIS
No change here; the aspects already exist.
!ACATS test
ACATS B- and C-Tests will be needed to test that inheritance happens and that the various Legality Rules are enforced.
!appendix

From: Steve Baird
Sent: Thursday, August 15, 2019  7:49 PM

I have some questions question about user-defined literals.

#1)

The Integer_Literal, Real_Literal, and String_Literal aspects are
defined to be operational aspects.

13.1 says
   ... whether operational aspects are inherited by a derived type
   depends on each specific aspect; unless specified, an operational
   aspect is not inherited.

I saw no mention of inheritance or derived types in 4.2.1 (the section
on User-Defined Literals).

So these are not inherited? Is this what was intended?

There is no discussion of this question in the AI, so I'm wondering
whether this was an oversight.

Do we really want to reject

     package Big_Nums is
        type Big_Integer is private with Integer_Literal => ... ;
        ...
     end Big_Nums;

     with Big_Nums;
     package Client is
        type My_Int is new Big_Nums.Big_Integer;
        procedure Foo (X : My_Int := 1); -- legal literal ?
     end Client;
?

You can't even work around the problem because these are
nonoverridable aspects. Having nonoverridable non-inherited
aspects seems like a really bad idea - you can't inherit them
and you can't explicitly (re)specify them (unless you can
figure out how to write a confirming specification for a
non-inherited aspect),

One could imagine a rule that the specified subprogram for one of these
aspects has to be a primitive operation of the type; this would allow
the definition of an inherited aspect for a derived type to be the
corresponding primitive operation of the derived type. At least in the
case of a tagged type (and presumably for other types, just for
consistency) this notion of "corresponding" would then have to take
overriding into account.

Perhaps we want something along these lines.

#2)

Related to the question of derivation, do we really want to allow
these three aspects to be specified for an abstract type?

    type T1 is abstract tagged null record with Integer_Literal => ... ;

And do we want to allow an abstract function to be specified as
the value of one of these aspects?

    type T2 is private with Integer_Literal => Abstract_Func;
    function Abstract_Func (Lit_Image : String) return T2 is abstract;

At first glance, it might seem that other rules prevent these constructs
from causing any real problems. Specifically:
    If the result type of a function is abstract, then the function shall
    be abstract.
and
    A call on an abstract subprogram shall be a dispatching call;

But recall that the equivalence between a literal and a function
call is only dynamic semantics; it has nothing to do with any legality
rules. So the aforementioned rule about "a call on an abstract
subprogram" has no bearing on the legality of a use of a numeric
literal.

In any case, it seems like useless implementation complexity to allow
these useless constructs. As far as I can see, allowing these constructs
isn't doing the user any favors either.

#3)

Presumably the specified subprogram for one of these aspect
specifications can be the dereference of an access-to-subprogram
value?

Can it be a prefixed view of a subprogram?

I see no rule disallowing these cases, but I thought I'd
check to be sure.

Of course the restrictions discussed above in item #1 would
disallow them.

#4)

Is one of these user-defined literals an object or just a value?

More specifically, is the following example legal or not?

     type T1 is ... with Integer_Literal => ...;
     ...
     X : T1 renames T1'(123); -- legal?

I'd say it is not because, statically, 123 is not a function call
and literals are not on 3.3's "All of the following are objects"
list.

As mentioned earlier, the equivalence between literals and function
calls is strictly dynamic semantics.

On the other hand, something like

    type T2 is record
         Aliased_Component : aliased Some_Type;
         ...
      end record
      with Integer_Literal => ... ;
    ...
    procedure Foo (Ref : access Some_Type);
    ...
   begin
    Foo (T2'(123).Aliased_Component'Access); -- legal?
   end;

seems less clear. Is this legal?

I think we want these guys to be treated like function result objects
in the aforementioned 3.3 list. And besides, composite "values" seem odd
- for example, what does it mean to have an actual parameter in
a call which is a value, but not an object, of a by-reference type?

Interestingly, the 3.3 list does include "the result of evaluating
an aggregate" while 4.2 says "The evaluation of a string_literal ...
yields an array value ...". This seems like an area where the
equivalence between string_literals and array aggregates breaks
down even before we start talking about user-defined literals.

AI12-0270, which is about cleaning up these object/value issues,
is on hold. But just because we don't want to tackle the existing
problem doesn't mean we shouldn't avoid making the situation worse
with the addition of new features.

#5)

If one of these literals is not an object, then it doesn't have
a nominal subtype (recall that 3.3 says "At the place where a view of an 
object is defined, a nominal subtype is associated with the view").

I don't see that this causes any of the problems that
AI05-0006 was worried about because you cannot case on
a literal (because the expression of a case statement is
a complete context). And besides, a literal is not
a name (if that matters - AI05-0006 talks about ensuring
that every *name* has a well-defined nominal subtype).

On the other hand, "nominal type" is defined in terms of
"nominal subtype". However, having an undefined "nominal type"
doesn't seem to introduce any definitional problems.

So I don't think there are any problems here, but I thought I'd
raise the question.

===

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

From: Tucker Taft
Sent: Thursday, August 15, 2019  9:22 PM

...
> So these are not inherited? Is this what was intended?

Certainly not, in my view.
 
> There is no discussion of this question in the AI, so I'm wondering 
> whether this was an oversight.

Oversight for sure.

...
>    end Client;
> ?

Clearly these should be inherited.
 
> You can't even work around the problem because these are 
> nonoverridable aspects. Having nonoverridable non-inherited aspects 
> seems like a really bad idea - you can't inherit them and you can't 
> explicitly (re)specify them (unless you can figure out how to write a 
> confirming specification for a non-inherited aspect),

Yes, clearly an oversight.

...
> In any case, it seems like useless implementation complexity to allow 
> these useless constructs. As far as I can see, allowing these 
> constructs isn't doing the user any favors either.

But suppose you have an abstract type derived from a non-abstract type that 
has literals?  It seems we might want that to be legal. 

I would say you can't have a literal of an abstract type, but I see no 
particular harm in allowing an abstract type to have an aspect specifying 
it has user-defined literals.  Non-abstract types derived from the abstract 
type is where the literals could actually be used.

...
> Presumably the specified subprogram for one of these aspect 
> specifications can be the dereference of an access-to-subprogram 
> value?
> 
> Can it be a prefixed view of a subprogram?
> 
> I see no rule disallowing these cases, but I thought I'd check to be 
> sure.

Seems unimportant; if they create any problem I would make them illegal.

...
> I'd say it is not because, statically, 123 is not a function call and 
> literals are not on 3.3's "All of the following are objects"
> list.

Agreed. 

...
> seems less clear. Is this legal?

This looks really weird.  I don't particularly care whether or not it is 
legal.  Whatever is simpler.  I wouldn't go out of our way to make it legal, 
nor make it illegal.  Whatever falls out from the rules.

...
> AI12-0270, which is about cleaning up these object/value issues, is on 
> hold. But just because we don't want to tackle the existing problem 
> doesn't mean we shouldn't avoid making the situation worse with the 
> addition of new features.

Agreed.  Again, I don't think it matters much from the point of view of 
usability, so the simpler rule is probably the better rule.

...
> On the other hand, "nominal type" is defined in terms of "nominal 
> subtype". However, having an undefined "nominal type"
> doesn't seem to introduce any definitional problems.
> 
> So I don't think there are any problems here, but I thought I'd raise 
> the question.

There seems no harm in defining the nominal subtype/type of a user-defined 
literal, even if we don't have to for other reasons.

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

From: Steve Baird
Sent: Friday, August 16, 2019  3:07 AM

> If one of these literals is not an object, then it doesn't have
> a nominal subtype (recall that 3.3 says "At the place where a view of an 
> object is defined, a nominal subtype is associated with the view").
> 
> I don't see that this causes any of the problems that
> AI05-0006 was worried about because you cannot case on
> a literal (because the expression of a case statement is
> a complete context).

There is slightly more to this than I thought at first.

I implied that we can't case on a user-defined literal.

I think I was right about casing on an integer literal, as in

    case 123 is
      ...
    end case;

because that will always be ambiguous, but this might not be
true for other forms of literals.

The name resolution rules for case statements include
    The selecting_expression is expected to be of any discrete type.
so we can case on a literal other than an integer literal and it
is possible that resolution will be successful.

So I think it is possible to have case statements of the form

     case 123.45 is
        ...
     end case;

or

    case "dog" is
      ...
    end case;

where the type of the user-defined literal is an enumeration type
(enumeration types are discrete but not numeric).

But since a literal is not a name, the case statement rules
don't care about its nominal subtype so it is ok that
nominal subtype is undefined in these cases.

We don't want this example to be legal

     procedure Foo1
        type Enum1 is (Aa, Bb, Cc, Dd, Ee);
        type Enum2 is new Enum1 range Bb .. Dd with Real_Literal => R_L;
        function R_L (Lit : String) return Enum2'Base is (Ee);
     begin
        case 1.0 is
            when Enum2 =>
               null;
        end case;
     end;

but I think that falls out from the current rules.

====

> Clearly these should be inherited.

I agree, but it needs to be stated explicitly how this works
in the tagged case (for the same reason that we have the 3.9.3
rules about the "if a type other than a nonabstract null extension 
inherits a function with a controlling result" case).

We don't want to allow something like

     package Pkg is
        type T1 is tagged null record
          with Integer_Literal => Nested.Not_A_Primitive;

        package Nested is
          function Not_A_Primitive (Lit : String) return T1 is
            (null record);
        end Nested;

        type T2 is new T1 with record Field : Float; end record;

        X2 : T2 := 123;
     end Pkg;

and even if we delete the inner package so that
the function becomes a primitive, we still need some rules to
define how the inheritance works.

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

From: Randy Brukardt
Sent: Friday, August 16, 2019  5:51 PM

> and even if we delete the inner package so that the function becomes a 
> primitive, we still need some rules to define how the inheritance 
> works.

Actually, we need rules to state how it works in any case, 'cause untagged 
routines don't magically work without rules, either. (Recall the rules about
type converting the arguments given in 3.4.) I would suggest just requiring 
the routine to be primitive for any type, as that way the routine will always
be inherited and thus we wouldn't need to define any rules for what that 
means. It's easy enough to define a primitive expression function in the 
unusual case where someone needs to declare a non-primitive function as the 
user-defined literal routine, so the added expressivity by allowing any 
routine in the untagged case doesn't seem worth the complication.

I presume that you are providing a fix-up AI with rules for all of these 
issues, right, complete with questions/discussion??? :-)

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

From: Steve Baird
Sent: Friday, August 16, 2019  6:20 PM

> I presume that you are providing a fix-up AI with rules for all of 
> these issues, right, complete with questions/discussion???

Sure, I'll take that action item.

Like you, I'm leaning toward the general idea that the specified function
has to be a primitive operation of the type (I like your approach of requiring 
this even in the untagged case). In the untagged case presumably you get 
reemergence - overriding an inherited subprogram doesn't change the behavior 
of evaluating a literal.

In the tagged case, I see the dynamic semantics of evaluating a literal whose 
type has an inherited user-defined-literal aspect as being equivalent to those
of a dispatching call to the function named in the original aspect 
specification (having the descendant type's tag as the controlling tag value) 
followed by a conversion to the descendant type. So in that case, overriding 
an inherited subprogram can change the behavior of evaluating a literal.

I haven't thought about untagged views of tagged types and descendants 
thereof, but I don't think there are big problems there.

Obviously wording is needed for all of this (that was your point).

Presumably the 13.1.1 rule that
   If a type inherits a nonoverridable aspect from multiple ancestors,
   the value of the aspect inherited from any given ancestor shall be
   confirming of the values inherited from all other ancestors.

means that the following example is legal

     package Pkg is
       type Ifc1 is Interface with Integer_Literal => I_L;
       function I_L (Lit : String) return Ifc1 is abstract;

       type Ifc2 is Interface with Integer_Literal => I_L;
       function I_L (Lit : String) return Ifc2 is abstract;

       type Concrete is new Ifc1 and Ifc2 with null record
         with Integer_Literal => I_L;
       function I_L (Lit : String) return Concrete;
     end Pkg;

and, furthermore, the aspect specification for type Concrete is redundant 
and could be omitted without any effect.

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

From: Steve Baird
Sent: Tuesday, September 10, 2019  7:31 PM

The attached is a new AI, aimed at addressing some of the problems with 
user-defined literals that were identified in my ARG mail message of 
Aug 15 2019 and in subsequent discussions.

[This is version /01 of the AI, with some missing parts added. - Editor.]

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

From: Randy Brukardt
Sent: Tuesday, September 24, 2019  10:33 PM

This AI is not ready for prime-time, sadly. You didn't change it at all (at
least I can't see any significant changes) from the version we discussed
privately and was considered the wrong solution.

(1) Editorial: A !proposal section should immediately follow the !problem
section. (I stuck in "See summary."). The !discussion goes after the
wording. I realize you put this where you did because the entire AI is not
really finished given that you ignored the advice Tucker and I gave you
privately -- but this is useless for the ARG -- finish it first.

(2) Abandoning 100% of the existing wording means a complete restart on the
wording. Most likely, all of the wording changes in 4.2 and elsewhere will
also have to be reworded (which you neither did nor made any discussion
about having checked). All of the existing wording was written in terms of a
type having a specified aspect, and that isn't appropriate when an aspect is
inherited.

(3) Constant_Indexing is only defined for tagged types, and thus the
inheritance rules are built around that. Integer_Literal et. al. have to
work for untagged types, and inheritance of those is squirrely at best.

(4) Similarly, "Nonoverridable" is only well-defined for tagged types.

(5) The "stream-attribute" model seems a better fit for these aspects.
There's no reason to make this overly complicated -- indeed, if it gets much
more complicated, I suspect most of the ARG would simply vote to remove it
(only a handful of people really supported it in the first place -- it has
to be simple). I could even make an argument that the original
no-inheritance model is best for untagged types.

A few specific comments.

>... the "default" inheritance rule described in 13.1(15.2/2) doesn't work.

Right, but you seem to be drawing the wrong conclusion from that. One
*always* has to specify how inheritance works for type extensions as no
default rule could possibly make sense. What happens to the extension
components always has to be defined.

>They feel (I hope I am stating their position correctly) that following
>the "Constant_Indexing model", where the value of the aspect is not a
>subprogram but rather the name of a subprogram, may be unnecessarily
complex
>in the case where the aspect refers to a single subprogram rather than
>to (potentially) a set of subprograms (as is the case with the
>Constant_Indexing aspect). They would prefer something more similar
>to the way that inheritance of streaming attributes is handled. This would
>presumably involve mandatory overriding in the case of a type extension.

At a minimum, we need to try writing up the AI that way to see if it does
simplify the presentation. I personally think the stream attribute model
makes far more sense for these aspects, but in the absence of trying it, we
cannot really know.

>Tuck makes the good point that we need to agree on a meta-rule to decide
>when to use which model so that we don't end up making this decision
>arbitrarily on an aspect-by-aspect basis as new aspects arise.

I proposed a meta-rule in the private e-mail as a starting point for
discussion:

(1) If any type is allowed, and the profile is fully specified with only a
single match allowed, then use the streaming model.
(2) If only tagged types are involved, and if the profile is only partially
specified, and especially if a family is desired, then use "nonoverriding"
and names.
(3) If only tagged types are involved, and the profile is fully specified,
use whichever model makes the most sense. ("Nonoverriding" might work better
for interfaces, not sure.)
(4) In any other case (mainly any type with a partially specified family
profile), please don't do that. ;-)

Note that the only other sensible meta-rule is "Never use the stream
attribute model", but that will require extending the
"Constant_Indexing/nonoverridable" model to support untagged types. (Which I
suspect will be a morass, given that inheritance/overriding of untagged
types has almost no rules, especially about parameter modes and defaults.)

To hack an example from your private mail to show one part of the problem:

      type T1 is (T1_Op, T2_Op) with Integer_Literal => I_L;

      function I_L (S : String) return T1 is (T1_Op); -- primitive

      type T2 is new T1;  

      overriding
      function I_L (S : out String) return T2 is (T2_Op);

The overriding function is a legal overriding for an untagged type. But it
is not a legal Integer_Literal aspect. The Constant_Indexing/nonoverridable
model doesn't worry about such cases 'cause they can't happen for tagged
types. Adding a pile of such rules sounds messy and expensive for
implementations.

>Randy questions whether these new aspects need to be overridable. I think
>we at least want the property (which is a consequence of being overridable)
>that all views of a single type agree with respect to the new aspects.

This is a basic property of aspects (that they are never view-specific); the
question is how that is enforced, not whether it is true or not. As
previously noted, "nonoverridable" prevents certain specifications of
aspects; I don't see any reason to do that here (certainly not for untagged
types). The stream attribute model uses re-specification to handle
redefinition, otherwise the original routine is inherited unmodified.

Note that the stream attribute model essentially makes the stream aspects
primitive operations of the type (and there is no relationship to any
inherited subprograms); that seems to make more sense in this case.

...
>[TBD: the corresponding uses of function_name instead of direct_name
>in 4.1.6 probably should be changed to match the above; we don't want to
allow
>   package Foo is
>      ...
>      type T is ... with Constant_Indexing => Foo.Bar;
>      function Bar ... ;
>      ...
>   end Foo;
>, right?]

Why? What's the harm? The requirement for a "primitive function" eliminates
any dynamic names (dereferences are never primitives), so we're only talking
about expanded names. Yes, it's a bit redundant, but I don't see any problem
with it.

...
>A user-defined literal is illegal if the equivalent function call is
illegal.
>
>[AARM note: For example, this implies that if the equivalent function call
>is a call to an abstract subprogram then the equivalent function call
>shall be a dispatching call.]

I note that this particular example is not possible in the stream-attribute
model; specified subprograms cannot be abstract. Not sure if that is
significant.

>A user-defined integer literal of a type T is illegal if the type T
>does not have exactly one visible primitive function having the name
>specified in T's (explicit or inherited) Integer_Literal aspect
specification,
>a result type of T, one parameter of type String, and no other parameters.
>[AARM note: If exactly one such primitive function exists then that is the
>function that is called when the literal is evaluated.]

This is horrible. This is always known when type is defined (since we're
only talking about primitive operations) [at least at the end of the unit in
which it is defined], it needs to be enforced there. That should be the case
even if we end up using the Constant_Indexing model (which clearly is not a
good match given the need for this bizarre rule). Also note that you seem to
be using this to fix up the deficiencies of "nonoverridable" for untagged
types, but that is a terrible approach since the next guy to use
"constant_indexing" on all types is highly unlikely to remember this nuance.

----

Replace 6.3.1(22-22.a):

>   - each primary that is a literal in one is a user-defined literal
>     if and only if the corresponding literal in the other is also a
>     user-defined literal. Furthermore, if neither are user-defined
literals
>     then they shall have the same values [redundant , but they may have
>     differing textual representations]; if both are user-defined literals
then
>     they shall have the same textual representation.

While I agree with this semantics, the term "textual representation" is
undefined in the RM (the only place it appears is twice in the current 4.2.1
-- and that isn't acceptable either). Either we have to define what this
means somewhere in Clause 2 (OK, Chapter 2 to pretty much anyone not using
current ISO terminology), or come up with an alternative. 

In particular, "representation" has a formal meaning in Ada (see 13.1), and
this use is very different. 2.2 using the term "text of a program", but
lexical elements are made up of a "sequence of characters". (Thus the two
possible wordings given above.) I note that equivalence of identifiers are
described in terms of a "sequence of characters", so probably that would be
the best.

So either say "the sequence of characters of the literal lexical elements is
the same", or define "textual representation of a lexical element" in 2.2 to
mean "the sequence of characters of the lexical element". (Since the latter
doesn't seem to shorten anything much, I'd just use the longer phrase.)

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

Questions? Ask the ACAA Technical Agent