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

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.)

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

From: Tucker Taft
Sent: Thursday, September 26, 2019  3:57 PM

It seems like Steve ran out of time before his vacation, or simply missed one 
of your emails, Randy.  I agree that your "meta rule" is a good start, and it 
would be nice to discuss it explicitly in the ARG meeting, hopefully with 
some examples (since in the abstract it can be pretty hard to decide!).

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