Version 1.10 of ai12s/ai12-0317-1.txt

Unformatted version of ai12s/ai12-0317-1.txt version 1.10
Other versions for file ai12s/ai12-0317-1.txt

!standard 3.10.2(16.1/5)          19-03-09 AI12-0317-1/08
!standard 4.3.2(5.1/5)
!standard 4.3.2(5.2/5)
!standard 4.3.2(5.3/5)
!standard 4.3.2(5.4/5)
!standard 4.3.2(5.5/5)
!standard 4.4(9)
!standard 4.5.9(6/5)
!standard 6.2(10/5)
!standard 7.5(2.1/5)
!class Amendment 19-02-22
!status Amendment 1-2012 19-02-26
!status work item 19-03-07
!status ARG Approved 10-0-0 19-02-26
!status work item 19-02-22
!status received 19-02-21
!priority Low
!difficulty Easy
!subject Simplifying the rules for newly constructed objects
!summary
Introduce two new terms to avoid duplicate wording in a number of places.
AI12-0236 exacerbates the problem of having to enumerate all cases where a construct like parenthesized expression or conditional expression passes through some property or some requirement to its operand(s).
In addition, in two places we have nearly identical lists of kinds of expressions that represent newly constructed objects of a limited type. It would be nice to avoid this redundancy.
!proposal
We introduce the term "operative constituents" to represent the subexpressions that represent the "fundamental" computations of a given expression (or name), and we introduce the term "newly constructed" to represent expressions that create a new object.
!wording
[Editor's note: 3.9.2(3) has too many special cases to be shifted over to using the "operative constituents" terminology.]
Modify RM 3.10.2(16.1/5):
In the above rules, the {operative constituents of a name or expression (see 4.4) are considered to be used in a given context if the enclosing name or expression is used in that context.} [operand of a view conversion, parenthesized expression or qualified_expression is considered to be used in a context if the view conversion, parenthesized expression or qualified_expression itself is used in that context. Similarly, a dependent_expression of a conditional_expression is considered to be used in a context if the conditional_expression itself is used in that context, and a body_expression of a declare_expression is considered to be used in a context if the declare_expression itself is used in that context.]
Modify RM 4.3.2(5.1/5-5.5/5):
If the type of the ancestor_part is limited and at least one component is needed in the record_component_association_list, then the ancestor_part shall not [be: ] {have an operative constituent expression (see 4.4) that is} a call to a function with an unconstrained result subtype{.}[; nor ...
Add after RM 4.4(9):
A primary that is an expression surrounded by ( and ) is known as a parenthesized expression.
[This has been missing from the Standard for 40 years, seems like time to fix it - Editor.]
Every name or expression comprises one or more /operative constituent/ names or expressions, only one of which is evaluated as part of evaluating the name or expression (the /evaluated operative constituent/). The operative constituents are determined as follows, according to the form of the expression or name:
* if the expression is a conditional_expression, the operative constituents of its dependent_expressions;
* if the expression (or name) is a parenthesized expression, a qualified_expression, or a view conversion, the operative constituent(s) of its operand;
* if the expression is a declare_expression, the operative constituent(s) of its body_expression;
* otherwise, the expression (or name) itself.
In certain contexts, we specify that an operative constituent shall (or shall not) be /newly constructed/. This means the operative constituent shall (or shall not) be an aggregate or a function_call; in either case, a raise_expression is permitted.
AARM To Be Honest: If an if_expression does not have an else clause, "True" is an operative constituent of the expression and it can be the evaluated opeerative constituent.
Modify RM 4.5.9(6/5):
A declare_item that is an object_renaming_declaration (see 8.5.1) shall not rename an object of a limited type {if any operative constituent of the object_name is a value conversion or is newly constructed (see 4.4).} [that is a function_call, aggregate, a parenthesized expression, qualified_expression, or type_conversion with an operand of one of these, a conditional_expression that has at least one dependent_expression that is one of these, or a declare_expression whose body_expression is one of these.]
Modify RM 6.2(10/5):
A parameter of a by-reference type is passed by reference, as is an explicitly aliased parameter of any type. Each value of a by-reference type has an associated object. [For a parenthesized expression, qualified_expression, or view conversion, this object is the one associated with the operand.] For a value conversion, the associated object is the anonymous result object if such an object is created (see 4.6); otherwise it is the associated object of the operand. {In other cases, the object associated with the evaluated operative constituent of the name or expression (see 4.4) determines its associated object.} [For a conditional_expression, this object is the one associated with the evaluated dependent_expression. For a declare_expression, this object is the one associated with the body_expression.]
Modify RM 7.5(2.1/5):
In the following contexts, an expression of a limited type is [not] permitted {only if each of its operative constituents is newly constructed (see 4.4):} [unless it is an aggregate, a function_call, a raise_expression, a parenthesized expression or qualified_expression whose operand is permitted by this rule, a conditional_expression all of whose dependent_expressions are permitted by this rule, or a declare_expression whose body_expression is permitted by this rule:] ...
!discussion
Introducing new terms means choosing among all the possible English words that communicate the appropriate notion, and that don't already have uses that conflict. We originally chose "constituent" after considering various other terms like "component" or "part" or "element" all of which have existing uses in Ada, as well as other terms which don't quite capture the intent. Unfortunately, we failed to notice that the term is already defined in 1.1.4. Luckily, what we want is a subset of constituents, so we settled on "operative constituent", which seems to imply the "meat of the expression" without implying that the "salad" is useless. We chose "newly constructed" because it seems to capture the idea, without using the term "create" which already has a very technical meaning in Ada.
We tried to replace the wording in 3.9.2 about statically and dynamically tagged, and tag-indeterminate to use the "operative constituents" terminology, but it just began to get out of hand.
!corrigendum 3.10.2(16.1/3)
Replace the paragraph:
In the above rules, the operand of a view conversion, parenthesized expression or qualified_expression is considered to be used in a context if the view conversion, parenthesized expression or qualified_expression itself is used in that context. Similarly, a dependent_expression of a conditional_expression is considered to be used in a context if the conditional_expression itself is used in that context.
by:
In the above rules, the operative constituents of a name or expression (see 4.4) are considered to be used in a given context if the enclosing name or expression is used in that context.
!corrigendum 4.3.2(5.1/3)
Replace the paragraph:
If the type of the ancestor_part is limited and at least one component is needed in the record_component_association_list, then the ancestor_part shall not be:
by:
If the type of the ancestor_part is limited and at least one component is needed in the record_component_association_list, then the ancestor_part shall not have an operative constituent expression (see 4.4) that is a call to a function with an unconstrained result subtype.
!corrigendum 4.3.2(5.2/3)
Delete the paragraph:
!corrigendum 4.3.2(5.3/3)
Delete the paragraph:
!corrigendum 4.3.2(5.4/3)
Delete the paragraph:
!corrigendum 4.4(9)
Insert after the paragraph:
Each expression has a type; it specifies the computation or retrieval of a value of that type.
the new paragraphs:
A primary that is an expression surrounded by ( and ) is known as a parenthesized expression.
Every name or expression comprises one or more operative constituent names or expressions, only one of which is evaluated as part of evaluating the name or expression (the evaluated operative constituent). The operative constituents are determined as follows, according to the form of the expression (or name):
In certain contexts, we specify that an operative constituent shall (or shall not) be newly constructed. This means the operative constituent shall (or shall not) be an aggregate or a function_call; in either case, a raise_expression is permitted.
!corrigendum 4.5.9(0)
Insert new clause:
Just some text to cause a conflict; the real text is found in the conflict file.
!corrigendum 6.2(10/4)
Replace the paragraph:
A parameter of a by-reference type is passed by reference, as is an explicitly aliased parameter of any type. Each value of a by-reference type has an associated object. For a parenthesized expression, qualified_expression, or view conversion, this object is the one associated with the operand. For a value conversion, the associated object is the anonymous result object if such an object is created (see 4.6); otherwise it is the associated object of the operand. For a conditional_expression, this object is the one associated with the evaluated dependent_expression.
by:
A parameter of a by-reference type is passed by reference, as is an explicitly aliased parameter of any type. Each value of a by-reference type has an associated object. For a value conversion, the associated object is the anonymous result object if such an object is created (see 4.6); otherwise it is the associated object of the operand. In other cases, the object associated with the evaluated operative constituent of the name or expression (see 4.4) determines its associated object.
!corrigendum 7.5(2.1/5)
Replace the paragraph:
In the following contexts, an expression of a limited type is not permitted unless it is an aggregate, a function_call, a raise_expression, a parenthesized expression or qualified_expression whose operand is permitted by this rule, a conditional_expression all of whose dependent_expressions are permitted by this rule, or a declare_expression whose body_expression is permitted by this rule:
by:
In the following contexts, an expression of a limited type is permitted only if each of its operative constituents is newly constructed (see 4.4):
!ASIS
No ASIS effect.
!ACATS test
ACATS tests might be needed for the minor changes in these rules: view conversions are allowed as newly constructed objects, and the 4.3.2 rule makes newly legal view conversions illegal in some cases.
Otherwise, no separate ACATS tests should be needed, as the actual rules aren't changing.
!appendix

From: Tucker Taft
Sent: Monday, February 11, 2019  2:31 AM

There were several times we had debates about the best term to use for a 
particular concept.  I remember talking about the term for those limited 
objects that can or cannot be renamed in a declare-expression, returned from 
a function, built in place, etc.  Another term was Steve's "screened" or 
"supplementary" or "extended" or "superfluous" or ...

Randy or anyone else, do you have notes on any other term(s) we wanted to give 
a (better) name to?

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

From: Tucker Taft
Sent: Thursday, February 21, 2019  7:39 AM

Below is a proposed addition to AI12-0236 (well, I suppose it really needs 
to be a "fix-up AI") which eliminates a redundant list of the kinds of 
expressions of a limited type that are allowed or disallowed based on 
whether they are newly constructed.

[This is version /01 of the AI - Editor.]

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

From: Steve Baird
Sent: Thursday, February 21, 2019  11:33 AM

Do we need a new term (perhaps "potentially newly constructed") for this use 
in 4.5.9(6/5) where the treatment of conditional expressions needs to be 
different than in 7.5(2.1/5) (i.e., "at least one" vs. "all")?

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

From: Steve Baird
Sent: Thursday, February 21, 2019  12:05 PM

I think this change would result in incorrectly allowing some 
previously-disallowed type conversions, as in

       X : My_Immutably_Limited_Type renames
            My_Immutably_Limited_Type (Some_Function_Call);

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

From: Randy Bukardt
Sent: Thursday, February 21, 2019  3:13 PM

Correct. When requiring "newly constructed" items, we don't allow any type 
conversions, since they are either better written as a qualified expression,
or a real pain to support in build-in-place. When not allowing this, we 
clearly don't want to allow type conversions of "newly constructed" items.

Steve's other concern also matters. There really are three kinds of
expressions: "newly constructed", "existing", and some sort of mix (where it 
is not known until runtime which it is). The mix case can't be allowed when 
either "existing" or "newly constructed" is required. So this isn't quite a 
binary choice that can be just negated by "not".

I could see explicitly adding the two missing cases to the 4.5.9 wording (not 
showing changes 'cause it is a mess):

   A declare_item that is an object_renaming_declaration (see 8.5.1)
   shall not rename a newly constructed object of a limited type
   {(see 7.5), nor a type_conversion of such an object, nor a 
   conditional_expression that has at least one 
   dependent_expression that is such an object.

although this isn't quite right because it doesn't support the recursion 
properly.

I'm starting to think that the (almost) duplication isn't that bad.

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

From: Tucker Taft
Sent: Thursday, February 21, 2019  3:44 PM

I was thinking that conditional expressions of a limited type had to be all 
or none, no matter where they appeared.  But I guess that isn't true.  If 
it appears as an initialization expression or return expression, they all 
need to be newly constructed. But if it appears as a parameter, it can be 
some newly constructed, and some not.  

So yes, we need to deal with the case where some of the dependent_expressions 
of a conditional expression are newly constructed.  I don't love the 
"potentially newly constructed," since this seems to be mixing up static and 
dynamic semantics.  Perhaps we can define something like a "constituent" of 
a name, and require that no constituent of the object_name is allowed to be 
newly constructed if it is of a limited type.  We can't just use a term like 
"subexpression" because we don't care anything about the parameters of a 
function call, nor about the subexpressions of the condition of an 
if_expression, etc.  

I'll send another attempt shortly, and try to address both issues Steve 
identified.

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

From: Tucker Taft
Sent: Thursday, February 21, 2019   4:09 PM

Can you remind me why we disallow renaming type conversions?  They seem quite 
useful, especially if they are changing the type from specific to class-wide, 
or vice-versa.  If we know the operand is not newly constructed, why is there 
any problem?

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

From: Tucker Taft
Sent: Thursday, February 21, 2019   4:11 PM

Never mind.  We are only disallowing renaming of type conversions if their 
operand is newly constructed, and I agree we should continue to do so.

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

From: Tucker Taft
Sent: Thursday, February 21, 2019  4:22 PM

So here is another attempt.  I have made a somewhat subtle change.  I have 
distinguished view conversions and other conversions.  View conversions are
really the only "interesting" conversions from a renaming point of view, and
we want to allow those, so long as the operand is renamable.  Similarly, 
there seems no problem allowing a function to return a view conversion of a 
newly-constructed object, and this is important because a qualified expression
cannot be used to change from specific to class-wide, or vice-versa (and all 
aggregates are of a specific type).

In any case, here is the attempt:

Define /constituents/ somewhere (referred to as RM X.X below):
 
  The /constituent(s)/ of an expression (or a name) are defined as
  follows, depending on the kind of the expression or name:

    * if the expression (or name) is a parenthesized expression, a
      qualified_expression, or a view conversion, the constituents of its
      operand;

    * if the expression is a conditional_expression, the constituents of
      its dependent_expressions;

    * if the expression is a declare_expression, the constituents of its
      body_expression;

    * otherwise, the expression (or name) itself.
   
Modify RM 4.5.9(6/5):

  A declare_item that is an object_renaming_declaration (see 8.5.1)
  shall not rename an object of a limited type {if any constituent (see
  RM X.X) of the object_name is newly constructed (see 7.5)}[that is a
  function_call, aggregate, a parenthesized expression,
  qualified_expression, or type_conversion with an operand of one of
  these, a conditional_expression that has at least one
  dependent_expression that is one of these, or a declare_expression
  whose body_expression is one of these].

Modify RM 7.5(2.1/5):

  In the following contexts, an expression of a limited type is not
  permitted unless [it is] {each of its constituents (see RM X.X) is
  /newly constructed/, that is,} an aggregate, a function_call, {or} a
  raise_expression[, a parenthesized expression or qualified_expression
  whose operand is permitted by this rule, or a conditional_expression
  all of whose dependent_expressions are permitted by this rule, or a
  declare_expression whose body_expression is permitted by this rule]:
  ...

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

From: Randy Brukardt
Sent: Thursday, February 21, 2019  4:47 PM

> Can you remind me why we disallow renaming type conversions? 

I think you're confused. Type conversions of any sort are not allowed in newly 
constructed objects. The renames case needs to disallow type conversions of 
newly constructed objects, because we don't want to allow sort of newly 
constructed object, even ones that wouldn't be legal in a context where a 
newly constructed object is required.
 
No one has asked to this point that renaming of type conversions of existing 
objects be banned. (The existing wording certainly does not do that.)
 
Now that you mention it, however, I could see a case for doing so when there 
is a representation change -- such an object is more like a newly constructed 
object than it is like an existing one -- as the conversion is creating a new 
object. This is the reason that newly constructed objects don't allow type 
conversions (it would be a mess to implement build-in-place), and if we're 
trying to avoid renaming non-existing limited objects, a type conversion can 
fall into that category.
 
The rules governing this are relatively new and found in 4.6(58.1-58.6). 
Essentially, a type conversion can be allowed if the type is a target type is 
a by-reference type and there is a type that is an ancestor of both the target 
type and the operand type (and, of course, the operation is not newly 
constructed). In other cases, new objects are possible. I don't suppose there 
is any real need to disallow elementary type conversions, either (this whole 
rule is aimed at composite types because of tasks and finalization). Since 
most limited types are by-reference and would qualify, most reasonable 
conversions could be allowed.
 
The interesting question is whether many of the problematic conversions are 
legal anyway. The only ones I'd expect to be legal and troublesome are those 
between unrelated arrays of some limited type. Perhaps just requiring a 
common ancestor would be enough??

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

From: Randy Brukardt
Sent: Thursday, February 21, 2019  5:35 PM

>So here is another attempt.

This is mostly good. Three comments.

1) "RM X.X" isn't going to fly in an AI. You need to pick a place. I'd suggest 
   4.4 (which is the clause where expression is defined).
2) The change to allow view conversions is of course allowing more 
   build-in-place expressions. This isn't necessarily bad, but of course there 
   is an implementation cost associated. Hopefully not too much, don't want 
   Bob to frazzle too much ;-).
3) The wording as you have it disallows renaming an expression that contains a 
   raise_expression, even if it otherwise would be OK. It's hard to get too 
   worked up about this, but that was allowed by the original wording.

That is, I'm thinking of something like:
    Fooey renames Some_Limited_Type'(if X then Y else raise TBD_Error); 
where Y is an existing limited object.

This happens since "raise_expression" is declared to be "newly constructed".
(When in actual fact, it is more "whatever you want it to be").


1B) It strikes me (especially if it is defined in 4.4) that the term 
"constituent" might be useful to reduce the clutter in a bunch of other 
existing rules. Because there are a lot of places where we allow parens and 
qualification (and probably many of them meant to allow the other things as 
well).

If we have a nice term like this, it would be a pity not to use it more often 
than in just two rules.

AI12-0236-1 has some candidate places. For instance, the set of rules
4.3.2(5.1/3-5.5/5) [ugh, there's a paragraph numbering error there] could be 
replaced by:

If the type of the ancestor_part is limited and at least one component is 
needed in the record_component_association_list, then the ancestor_part shall 
not have a consistuent that is a call to a function with an unconstrained 
result subtype.

That's not 100% the same (because it is now including view conversions), but 
it certainly seems like an improvement. (And I have to wonder if there is a 
bug in this rule associated with view conversions to unconstrained subtypes, 
it would seem to need to apply to those.)

Perhaps the AI author could check other rules (6.2(10)?, 3.10.2(16.1/3)?, 
3.9.2(3)?, perhaps others) to see if such a change would be sensible.

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

From: Steve Baird
Sent: Friday, February 22, 2019  1:48 PM

> 3) The wording as you have it disallows renaming an expression that 
> contains a raise_expression, even if it otherwise would be OK.

Tuck - the way you factored out constituents seems elegant to me, but perhaps 
"newly constructed" should not include raise expressions; then the 7.5 rule 
would have to be something like "is not permitted unless each of its 
constituents is newly constructed or is a raise expression".

This definition for "newly constructed" also seems more intuitive - does it 
really make sense to say that a raise expression is newly constructed? It 
might make sense to say that it does not reference a preexisting object, but 
that's not the terminology we are using here.

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

From: Tucker Taft
Sent: Friday, February 22, 2019  2:14 PM

Below is an attempt to address Randy's comments in this AI12-0236 "fix-up" AI.

[This is version /02 of the AI - Editor.]

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

From: Tucker Taft
Sent: Friday, February 22, 2019  2:18 PM

>> 3) The wording as you have it disallows renaming an expression that 
>> contains a raise_expression, even if it otherwise would be OK.
> 
> Tuck - the way you factored out constituents seems elegant to me, but 
> perhaps "newly constructed" should not include raise expressions; then 
> the 7.5 rule would have to be something like "is not permitted unless each
> of its constituents is newly constructed or is a raise expression".
> 
> This definition for "newly constructed" also seems more intuitive - 
> does it really make sense to say that a raise expression is newly 
> constructed? It might make sense to say that it does not reference a 
> preexisting object, but that's not the terminology we are using here.

Sorry, I didn't see this e-mail before I sent my update.

As far as renaming "raise expressions" of a limited type, it is hard to get 
too excited about them.  Clearly a raise expression is at least conceptually 
creating a new object, rather than copying an existing object.  Do you think 
it is important to allow a renaming of them in a declare expression?

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

From: Tucker Taft
Sent: Friday, February 22, 2019  2:29 PM

...
> !problem
> 
> AI12-0236 exacerbates the problem of having to enumerate all cases 
> where a construct like parenthesized expression or conditional 
> expression passes through some property or some requirement to its 
> operand(s).  In two places, we have nearly identical lists of kinds of 
> expressions that represent newly constructed objects of a limited type.

These are two separate problems, so probably should have been two separate paragraphs.

...
> Modify RM 3.9.2(16.1/5):

Oops, I meant RM 3.10.2(16.1/5).  Heart of darkness strikes again!
> 
>  In the above rules, the {constituents of a name or expression (see
>  4.4) are considered to be used in a context if the enclosing name or  
> expression is used in a given context.} ...

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

From: Steve Baird
Sent: Friday, February 22, 2019  2:43 PM

> Clearly a raise expression is at least conceptually creating a new object, 
rather than copying an existing object.

I disagree.

It is certainly clear that it is not copying/referencing an existing object, 
but that (to me) does not mean that it is creating a new object. It is an 
oversimplification to assume that those are the only two options.

When we are saying that creation of a new object is required, then we want to 
include raise expressions in with one category.

When we are saying that creation of a new object is forbidden, then we want to 
include raise expressions in with the other category.

If folks agree that getting this exactly right isn't worth the trouble, then I 
can live with that.

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

From: Tucker Taft
Sent: Friday, February 22, 2019  2:56 PM

> It is certainly clear that it is not copying/referencing an existing 
> object, but that (to me) does not mean that it is creating a new 
> object. It is an oversimplification to assume that those are the only two
> options.
> 
> When we are saying that creation of a new object is required, then we 
> want to include raise expressions in with one category.
> 
> When we are saying that creation of a new object is forbidden, then we 
> want to include raise expressions in with the other category.

I suppose, though I think it is simpler to only have two categories, where we 
think of a raise expression as a call on a function that always raises an 
exception, and whose result type morphs into whatever type is expected.

> If folks agree that getting this exactly right isn't worth the 
> trouble, then I can live with that.

I would be in that camp, since having to always worry about a third category
just to accommodate the presence of raise-expressions seems like unnecessary 
complexity.

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

From: Randy Brukardt
Sent: Friday, February 22, 2019  3:09 PM

> Below is an attempt to address Randy's comments in this
> AI12-0236 "fix-up" AI.

Looks good, except:

...
> Modify RM 6.2(10/5):
> 
>   A parameter of a by-reference type is passed by reference, as is an
>   explicitly aliased parameter of any type. Each value of a by-reference
>   type has an associated object. {The evaluated constituent of a name or
>   expression (see 4.4) determines the associated object.}  [If For a
>   parenthesized expression, qualified_expression, or view conversion,
>   this object is the one associated with the operand. For a value
>   conversion, the associated object is the anonymous result object if
>   such an object is created (see 4.6); otherwise it is the associated
>   object of the operand. For a conditional_expression, this object is
>   the one associated with the evaluated dependent_expression. For a
>   declare_expression, this object is the one associated with the
>   body_expression.]

You lost the value conversion case from this wording. (Consistuents don't 
include value conversions.)

> Modify RM 7.5(2.1/5):
> 
>   In the following contexts, an expression of a limited type is not
>   permitted unless [it is] {each of its constituents (see 4.4) is
>   /newly constructed/, that is,} an aggregate, a function_call, {or} a
>   raise_expression[, a parenthesized expression or qualified_expression
>   whose operand is permitted by this rule, a conditional_expression
>   all of whose dependent_expressions are permitted by this rule, or a
>   declare_expression whose body_expression is permitted by this rule]:
>   ...

I tend to agree with Steve that raise_expression ought to be handled specially 
here. When I thought of the problem yesterday, it didn't bother me much, but 
when I wrote an example using a TBD exception, it started to look possible:

   (declare
        Foo renames Lim_Type'(if B then Obj else raise TBD_Error);
     begin
        ...

I write a lot of code with -- *** TBD comments, and it seems that using a 
TBD exception instead would be safer. But that doesn't work if there are 
contexts that don't allow raise_expressions just because we were lazy.

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

From: Tucker Taft
Sent: Friday, February 22, 2019  3:26 PM

...
> You lost the value conversion case from this wording. (Consistuents 
> don't include value conversions.)

Oops, right you are.  I noticed the special case when I started, but forgot 
it by the time I finished... ;-)

...
> I write a lot of code with -- *** TBD comments, and it seems that 
> using a TBD exception instead would be safer. But that doesn't work if 
> there are contexts that don't allow raise_expressions just because we were
> lazy.

Hmmm...  I am not sure it is laziness.  I see it as trying to avoid creating a 
lot of special cases for raise-expressions, and instead adopting a uniform 
model, namely they are equivalent to a call on a function that raises an 
exception.  Such things are usable almost everywhere.  Do we really need to 
create this third case just for renaming of limited objects in declare 
expressions?  That really seems like some sort of priority inversion. ;-)

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

From: Tucker Taft
Sent: Friday, February 22, 2019  3:39 PM

Below is a version incorporating a few more fixes.

[This is version /03 of the AI - Editor.]

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

From: Randy Brukardt
Sent: Friday, February 22, 2019  4:10 PM

...
> > I write a lot of code with -- *** TBD comments, and it seems that 
> > using a TBD exception instead would be safer. But that doesn't work 
> > if there are contexts that don't allow raise_expressions just 
> > because we were lazy.
> 
> Hmmm...  I am not sure it is laziness.  I see it as trying to avoid 
> creating a lot of special cases for raise-expressions, and instead 
> adopting a uniform model, namely they are equivalent to a call on a 
> function that raises an exception.
> Such things are usable almost everywhere.  Do we really need to create 
> this third case just for renaming of limited objects in declare 
> expressions?  That really seems like some sort of priority inversion. 
> ;-)

Some wise person (might have been you) once noted that if there has to be a 
complexity in either the user model or in the RM wording, we should put the 
complexity in the RM everytime. We shouldn't be afraid of extra RM wording 
if it will make the user experience better. Because we want the user model 
to be as seamless as possible. (This is also related to your "bump under the 
carpet" analogy.)

If the example I showed is plausible (and I think it is), someone will 
eventually trip over it. Is simplifying the RM wording worth leaving a "bump" 
in the user model??

   (declare
        Foo renames Lim_Type'(if B then Obj else raise TBD_Error);
     begin
        ...

I doubt whomever trips over this is going to be interested in your argument 
that raise TBD_Error is equivalent to a function that raises TBD_Error. :-) 
We clearly want as little illegal here as possible (subject to the goal of 
preventing temporary objects containing tasks being declared here).

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

From: Tucker Taft
Sent: Friday, February 22, 2019  4:24 PM

> ...
> We clearly want as little illegal here as possible (subject to the 
> goal of preventing temporary objects containing tasks being declared here).

OK, enough said.  Hence, here is yet another version.

[This is version /04 of the AI - Editor.]

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

From: Tucker Taft
Sent: Saturday, February 23, 2019  10:22 AM

After more thought, I decided putting the definition of "newly constructed" in
section 7.5 was not great, especially as I found new places where it might be 
used which had nothing to do with limited types.  Also, my handling of 
raise-expressions was not ideal, in that they had to be handled as special 
cases when we started talking about newly-constructed objects.  I felt a more 
general permission would be useful.  So, here is one more version (yeah, I 
know, Randy already uploaded all the AIs).

So this is an update to what is now identified as AI12-0317-1...

[This is version /05 of the AI - Editor.]

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

From: Randy Brukardt
Sent: Saturday, February 23, 2019  8:20 PM

> After more thought, I decided putting the definition of 
> "newly constructed" in section 7.5 was not great, especially 
> as I found new places where it might be used which had 
> nothing to do with limited types.

The AI doesn't use it in any such places, or even tell us in the !discussion 
where they might be.

> Also, my handling of 
> raise-expressions was not ideal, in that they had to be 
> handled as special cases when we started talking about 
> newly-constructed objects.  I felt a more general permission 
> would be useful.  So, here is one more version (yeah, I know, 
> Randy already uploaded all the AIs).

Sigh. I suppose it doesn't pay to insist on discussing the previous version, 
and if I don't post it half of the group won't find it, so I've posted an 
update.
 
> So this is an update to what is now identified as AI12-0317-1...

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

From: Tucker Taft
Sent: Monday, February 25, 2019  9:05 PM

...
> The AI doesn't use it in any such places, or even tell us in the 
> !discussion where they might be.

The latest version of the "ownership" AI is the place I had in mind.

...
> Sigh. I suppose it doesn't pay to insist on discussing the previous 
> version, and if I don't post it half of the group won't find it, so 
> I've posted an update.

Thanks.

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

From: Randy Brukardt
Sent: Thursday, February 28, 2019  11:53 PM

Does anyone object to adding the following to AI12-0317-1 just before the 
definition of "constituent":

A primary that is an expression surrounded by ( and ) is known as a 
*parenthesized expression*.

We use the term "parenthesized expression" a lot in the Standard (the search 
engine turns up more than 15 uses), but the syntax "(expression)" does not 
have an associated nonterminal (it is just one of the forms of primary), and 
there is no definition of "parenthesized expression" in the Standard. (At 
least there is not one in the index.)

It might be "obvious", but so are "part" and "descendant". :-)

I would like to add this to AI12-0317-1 as an "Editorial change", but since it 
alters the definition in some sense I won't if someone objects. (Then I'll 
probably stick it into some other AI.) We're adding a bunch of other 
definitions to the exact right place, and even use the term in the following 
definitions. So this seems to be a great time to fix an oversight of the last
40 years.

Speak now or lose your chance. :-)

P.S. I have no interest in determining Resolution Rules for a parenthesized 
expression, though. I've tried those in the past, and everything I could come 
up with seemed worse than ignoring it. (It would need rules similar to those 
for conditional expressions, which are anything but simple - see 4.5.9(8/3).)
This is covered in AI12-0066-1, the "we aren't going to fix it AI". We're 
also missing Dynamic Semantic rules, but that could just be "Evaluation of a 
parenthesized expression evaluates the contained expression." or something 
like that.

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

From: John Barnes
Sent: Friday, March 1, 2019  5:26 AM

Just do it.

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

From: Tucker Taft
Sent: Friday, March 1, 2019  6:36 AM

Fine by me,

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

From: Tucker Taft
Sent: Wednesday, March 6, 2019  6:32 PM

I just bumped into a place in the manual where we already use the term
"constituent" as a technical term with a meaning other than that 
proposed recently.  In fact, "constituent" is defined to be essentially 
any part of a syntactic construct, in RM 1.1.4(17).  

I looked around for other similar terms which are not already used 
technically in the RM, and came up with "fragment."  Another possibility 
would be to qualify "constituent" with some additional term, such as "basic 
constituent."

Any opinions about "fragment" vs. "basic constituent" vs. some third term?

I think I am somewhat favoring "basic constituent" given that they are in 
fact "constituents" as defined in 1.1.4(17), since they correspond to a part 
of a larger syntactic construct.  "Fragment" doesn't have any particular 
intuition to it, whereas "basic constituent" has a bit of an intuitive 
connection to the proposed purpose.  These are the constituents of a name or 
expression that represent the "basic," fundamental computations, and are 
composed via conditional expressions to form the overall name/expression.

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

From: Steve Baird
Sent: Wednesday, March 6, 2019  6:44 PM

> Any opinions about "fragment" vs. "basic constituent" vs. some third term?

I prefer "basic constituent" to "fragment".

Incidentally, another place where this term can be used (you are probably 
already aware of this) is in the definition of applicable index constraint
in 4.3.3; something like

    The applicable index constraint of a basic constituent of an
    expression is the applicable index constraint of the expression.

would be better than the current list of rules.

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

From: Randy Brukardt
Sent: Wednesday, March 6, 2019  7:00 PM

> I prefer "basic constituent" to "fragment".

I agree. Especially since I've already put all of the "constituent" wording 
into the RM (we approved that AI last time).

> Incidentally, another place where this term can be used (you are 
> probably already aware of this) is in the definition of applicable 
> index constraint in 4.3.3; something like
> 
>     The applicable index constraint of a basic constituent of an
>     expression is the applicable index constraint of the expression.
> 
> would be better than the current list of rules.

Yes, this seems like a good idea as well.

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

From: Tucker Taft
Sent: Wednesday, March 6, 2019  7:08 PM

> Incidentally, another place where this term can be used (you are 
> probably already aware of this) is in the definition of applicable 
> index constraint in 4.3.3; something like
> 
>   The applicable index constraint of a basic constituent of an
>   expression is the applicable index constraint of the expression.
> 
> would be better than the current list of rules.

No, I hadn't noticed that.  Actually, I don't think it is quite as useful 
there as you imply.  Most of the rules are specifying how the applicable index 
constraint is determined.  There are only three constructs, parenthesized 
expressions, conditional expressions, and declare expressions, that merely
"pass through" the applicable index constraints.  For those we could perhaps 
say:

  * For a parenthesized expression, conditional_expression, or declare_expression,
   the applicable index constraint for each basic constituent is that, if any, 
   defined for the expression.

But I don't think that actually works, because "basic constituent" will "skip 
over" qualified expressions, when in fact, the subtype specified in the 
qualification matters.

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

From: Steve Baird
Sent: Wednesday, March 6, 2019  7:12 PM

Good point.

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

From: Randy Brukardt
Sent: Wednesday, March 6, 2019  7:14 PM

> I think I am somewhat favoring "basic constituent" given that they are 
> in fact "constituents" as defined in 1.1.4(17), since they correspond 
> to a part of a larger syntactic construct.

However, "construct" is defined as:

A construct is a piece of text (explicit or implicit) that is an instance 
of a syntactic category defined under "Syntax". 

I think it's arguable whether or not a parenthesized expression is a construct 
by this definition. There's definitely not any syntactic category defined for 
it (it's part of something more general). I doubt we've ever cared before (or 
will again), but that argues (weakly) for a different term.

As a matter of English, I certainly prefer "basic constituent" to "fragment"; 
the latter has the wrong connotation. I do wonder if "basic" is the right 
adjective, though. It's more the "important constituent" or "interesting 
constituent" (being the one on which the rules are enforced, properties 
determined, and so on).

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

From: Tucker Taft
Sent: Wednesday, March 6, 2019  8:36 PM

> However, "construct" is defined as:
> 
> A construct is a piece of text (explicit or implicit) that is an 
> instance of a syntactic category defined under "Syntax".
> 
> I think it's arguable whether or not a parenthesized expression is a 
> construct by this definition. There's definitely not any syntactic 
> category defined for it (it's part of something more general). I doubt 
> we've ever cared before (or will again), but that argues (weakly) for a 
> different term.

By any reasonable definition, a parenthesized expression is a syntactic 
construct.  It is just an odd quirk of the Ada grammar that it doesn't have 
its own rule.  I don't think that quirk argues for or against anything, 
personally.
 
> As a matter of English, I certainly prefer "basic constituent" to 
> "fragment"; the latter has the wrong connotation. I do wonder if 
> "basic" is the right adjective, though. It's more the "important 
> constituent" or "interesting constituent" (being the one on which the 
> rules are enforced, properties determined, and so on).

I thought briefly about other terms, but "basic" seemed the simplest and 
clearest.  I suppose one of us might come up with a better term over the 
next few days, but failing that, I am at least in these ARG discussions 
going to start using the term "basic constituent," and hopefully it will 
be clear what I mean! ;-)

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

From: Randy Brukardt
Sent: Thursday, March 7, 2019  2:18 PM

> I thought briefly about other terms, but "basic" seemed the simplest 
> and clearest.  I suppose one of us might come up with a better term 
> over the next few days, but failing that, I am at least in these ARG 
> discussions going to start using the term "basic constituent," and 
> hopefully it will be clear what I mean! ;-)

I suppose given this severe bug (redefining an existing term is pretty bad),
AI12-0317-1 should be reopened and put back on the agenda.

But the more I think about it, the less I like "basic constituent". This 
typically is the largest and most complex part of an expression, and I don't 
see anything "basic" about it. In

     (Foo(A, B, C) + Bar(D, E, F))

the "basic constituent" is:

     Foo(A, B, C) + Bar(D, E, F)

The idea really is that some constituents are insignificant for many (not 
quite all) rules. Perhaps they are "transparent constituents" or 
"insignificant constituents". In which case the others are "non-transparent 
constituents" or "significant constituents".

The thesaurus for "significant" gives the following possible terms (not all 
serious suggestions):

   "important constituents"
   "momentous constituents"
   "earthshaking constituents"
   "evidential constituents"
   "fundamental constituents"
   "profound constituents"
   "large constituents"
   "monumental constituents"
   "noteworthy constituents"
   "remarkable constituents"
   "operative constituents"
   "key constituents"
   "portentous constituents"
   "prodigious constituents"
   "meaningful constituents"

Of these, I'd lean toward "key" or "meaningful". "fundamental" isn't bad 
either, but a bit long (as is "significant").

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

From: Tucker Taft
Sent: Thursday, March 7, 2019  2:27 PM

I actually like "operative constituents" because it distinguishes itself from
all the "fruit salad" around conditional expressions, declare expressions, 
qualified expressions, which don't really produce a final value that is used.
The "operative constituents" are the "meat" of the expression.

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

From: Edmond Schonberg
Sent: Thursday, March 7, 2019  2:35 PM

> Of these, I'd lean toward "key" or "meaningful". "fundamental" isn't 
> bad either, but a bit long (as is "significant”).

We are trying to capture the notion of a piece of text to which some rules 
apply. What about "relevant constituent" ?

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

From: Steve Baird
Sent: Thursday, March 7, 2019  2:45 PM

> Of these, I'd lean toward "key" or "meaningful".

I prefer "operative" precisely because it is more vague.

As you noted, we are looking through some constructs and not looking through 
others; I don't think you will find a nice one-word term that captures the idea, 
so better to go with a term that doesn't intuitively suggest something that 
isn't right.

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

From: Tucker Taft
Sent: Thursday, March 7, 2019  4:00 PM

> We are trying to capture the notion of a piece of text to which some rules 
> apply. What about "relevant constituent" ?

Pretty much everything is "relevant" to something.  We are trying to define a 
term before we have explained what rules might use the term.  Of the ones 
mentioned, "operative constituents" seems to imply that the constituents are 
somehow special, but as Steve says, the term doesn't come with a lot of 
"baggage" that might interfere with our defining exactly what we want it to 
mean. 

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

From: Randy Brukardt
Sent: Thursday, March 7, 2019  4:11 PM

"Operative constituents" is OK with me; I'll update the (previously approved
but fatally flawed) AI that way for discussion on Monday. At least until I 
get 3 messages telling me to do something else. ;-)

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

From: Bob Duff
Sent: Thursday, March 7, 2019  5:01 PM

> I actually like "operative constituents" because it distinguishes 
> itself from all the "fruit salad" around conditional expressions, 
> declare expressions, qualified expressions, which don't really produce 
> a final value that is used.  The "operative constituents" are the 
> "meat" of the expression.

"operative constituents" is OK with me.

I was about to suggest something like "meat of...", but never mind.

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

From: Randy Brukardt
Sent: Thursday, March 7, 2019  6:02 PM

"ham" vs. "spam"?? :-)

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

Questions? Ask the ACAA Technical Agent