Version 1.2 of ai12s/ai12-0403-1.txt

!topic Wrong profile in 4.2.1 Examples
!reference Ada 202x RM4.2.1(18/5,19/5)
!from Max Reznik 20-09-14
!keywords User-Defined String Literal Wide_Wide_String
!discussion

In ARM 202x Draft 26 "4.2.1 User-Defined Literals" there is an example:

    function To_Roman_Number (S : String) return Roman_Number

But its profile is incorrect, because, according to the rules above,
the parameter should have Wide_Wide_String type.

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

!topic Wrong profile in 4.2.1 Examples
!reference Ada 202x RM4.2.1(18/5,19/5)
!from Max Reznik 20-09-14
!keywords User-Defined String Literal Wide_Wide_String !discussion

In ARM 202x Draft 26 "4.2.1 User-Defined Literals" there is an example:

    function To_Roman_Number (S : String) return Roman_Number

But its profile is incorrect, because, according to the rules above, the 
parameter should have Wide_Wide_String type.

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

From: Christoph Grein
Sent: Wednesday, September 23, 2020 7:35 AM

There is more wrong:

In (19/5) Reduce("+", 0), zero does not belong to the subtype Roman_Number, 
so it's illegal.

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

From: Christoph Grein
Sent: Wednesday, September 23, 2020 7:59 AM

Oh, and also negative numbers are not in range, so also this  is illegal:

(if I < R'Last and then R(I) < R(I + 1) then -1 else 1) * R(I)]

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

From: Christoph Grein
Sent: Saturday, October  3, 2020  5:24 AM

Hm, I withdraw my claims about the initial value 0 and factor -1 being 
illegal. value_type and accum_type are Roman_Number'Base, a subtype of the
type of Roman_Number.

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

From: Tucker Taft
Sent: Monday, October 5, 2020  9:21 AM

In 4.3.5(93/5), the example should be fixed as follows:

--  Is equivalent to:
V := Empty_Vector (<estimate of size of M>); for Elem of M loop
   [Add_Positional]{Append_One} (V, Elem); end loop;

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

From: Claire Dross
Sent: Friday, September 18, 2020  9:54 AM

[Part of Claire's RM review - Editor.]

Annex H
2/5 No_Controlled_Parts
                The type of this aspect is Boolean. If True, requires that the
                 type and any descendants do not have any controlled parts.

>> I am not a native speaker, but the sentence seems awkward to me. Maybe 
>> someone could double check?

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

From: Tucker Taft
Sent: Friday, September 18, 2020  10:39 AM

Agreed.  The word "do" could be dropped -- "If True, requires that the type 
and any descendants not have any controlled parts."

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

From: John Barnes
Sent: Friday, September 18, 2020  5:03 PM

This is awkward. I would retain the do. The English language is, I believe , 
somewhat flawed in this area. 

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

From: Richard Wai
Sent: Friday, September 18, 2020  5:14 PM

I agree! I felt removing the 'do' sounded somewhat archaic. I wasn't going to 
chime in, but your distinguished opinion lends credibility!

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

From: Bob Duff
Sent: Friday, September 18, 2020  6:09 PM

> This is awkward. I would retain the do. The English language is, I 
> believe , somewhat flawed in this area.

Which English language?  ;-)

To me, it reads OK with or without the "do".  I think slightly better with.

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

From: John Barnes
Sent: Saturday, September 19, 2020  3:58 AM

Oh dear, Bob said

-----Original Message-----

"John Barnes" wrote:

> This is awkward. I would retain the do. The English language is, I 
> believe , somewhat flawed in this area.

Which English language?  ;-)

To me, it reads OK with or without the "do".  I think slightly better with.

=======

And Richard agreed as well.

======

To me it reads better with do.

I had a problem sleeping last night thinking about do and not.

In some situations we can just insert not to produce negation but in some 
cases we need an auxiliary verb such as do

if  the verbal form is normal present indicative then we need do.

Thus

I kill the dragon.

I do not kill the dragon.

We cannot say (in Modern English)

I kill not the dragon. or I not kill the dragon

We have to have do as an auxiliary verb.

However, if we use a continuous form

I am killing the dragon

then we can say 

I am not killing the dragon.

I have consulted all the  books I have which is many.  None address this
topic.

Bobby  (my wife) used to work in the linguistics department of Reading 
University. She could try contacting some venerable academics such as 
David Crystal.

Her first reaction to this problem was that

"small children and non-native English speakers often omit do"

One can waste a lot of one's life fretting over this sort of thing.

In the case in hand it is made more complex by being an auxiliary clause 
anyway. Maybe it should be in the subjunctive. One could try translating 
it into Latin and then analysing the situation.

I wonder what a German speaker would say.  Erhard??

Do have a nice day.

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


From: Tucker Taft
Sent: Saturday, September 19, 2020  7:55 AM

Decency requires that Americans not use "do" in such contexts... ;-)

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

From: Jeff Cousins
Sent: Saturday, September 19, 2020  5:07 AM

> To me, it reads OK with or without the "do".  I think slightly better with. 

Ditto

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

From: Erhard Ploedereder
Sent: Saturday, September 19, 2020  8:59 PM

> I wonder what a German speaker would say.  Erhard??

I don't think we have a comparable situation in German wrt an auxillary word 
in these contexts.

As to my foreign D-English, I normally use the do and omit it only in rare 
cases, especially when the remainder is short or if it happens to save a 
crucial line in print ;-).
And I use it for emphasis of course, as you do.

The "do" also avoids the burning question whether:
   "Requires that the type have"
  or
   "Requires that the type has".
I do not like the former, probably because, for this situation, we do have 
an analogy in German:
"Erfordert dass der Typ X habe" (a subjunctive, since it might not) vs.
"Erfordert dass der Typ X hat" (present, more assertive)

The first form is theoretically more correct, but any text that contains it, 
is likely older than me. Nobody is using a subjunctive in this context any 
more.

Incidently, for the example that started this:
1. Hate sentences that are not.
2. Do not like to be thrown verbal bones to catch.
3. (Know that this is often done in the RM in
     similar contexts.)

As in "Requires that a sentence has a subject."

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

From: John Barnes
Sent: Monday, September 21, 2020  5:06 AM

The subjunctive is fading in Br Engilsh too. One use is in a phrase such as 

"If I were you I would have a large gin." rather than "If I was you...

On the other hand it is very rare in the present tense.  Thus

"If I be good" sounds archaic, I  am sure I would say "If I am good..."

I think we can agree that languages both human and computer are tricky topics!

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

From: Randy Brukardt
Sent: Wednesday, September 23, 2020  12:09 AM

> Annex H
> 2/5 No_Controlled_Parts
>                 The type of this aspect is Boolean. If True, requires that
>                 the type and any descendants do not have any controlled 
>                 parts.
> 
> >> I am not a native speaker, but the sentence seems awkward to me. 
> >> Maybe someone could double check?

Followed by a lot of non-advice which boils down to no credible direction for 
the editor at all. Thanks a lot guys!

Anyway, this is like a restriction that applies to a single set of 
descendants, and as such is going to be awkward since it is combining a 
negative with "True".

Probably the best thing to do with this one is to rearrange and make it clear 
this is a Legality Rule:

   No_Controlled_Parts
            The type of this aspect is Boolean. If True, the
            type and any descendants shall not have any controlled parts.

And I got rid of the "do", making the whole discussion moot. I hope. ;-)

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

From: Claire Dross
Sent: Friday, September 18, 2020  9:54 AM

[From her RM review.]

Annex H-7-1

17/5 Within an operation to which a Dispatching aspect applies, any dispatching 
call that does not match any dispatching_operation_specifier of the dispatching 
operation set is checked using the Nonblocking and Global'Class aspect(s) 
applicable to the called dispatching operation; if there is a match, there is 
no checking against the Nonblocking or global aspects applicable at the point 
of call.

>> Is it clear that parameters are still considered to be read/written? should 
we add a comment?

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

From: Tucker Taft
Sent: Friday, September 18, 2020  10:39 AM

> Annex H-7-1
> 
> 17/5 Within an operation to which a Dispatching aspect applies, any 
> dispatching call that does not match any 
> dispatching_operation_specifier of the dispatching operation set is 
> checked using the Nonblocking and Global'Class aspect(s) applicable to 
> the called dispatching operation; if there is a match, there is no 
> checking against the Nonblocking or global aspects applicable at the 
> point of call.
> 
>>> Is it clear that parameters are still considered to be read/written? 
>>> should we add a comment?

Perhaps an AARM note with an example where the actual parameter is a global, 
indicating it should be treated as a read and/or write of that global.  
Normative wording could perhaps be clarified by saying "checking {of these 
aspects} against the ...".  Hence:

"Within an operation to which a Dispatching aspect applies, any dispatching 
call that does not match any dispatching_operation_specifier of the 
dispatching operation set is checked using the Nonblocking and Global'Class 
aspect(s) applicable to the called dispatching operation; if there is a match,
there is no checking of these aspects against the Nonblocking or global 
aspects applicable at the point of call."

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

Editor's note: A summary of private mail between me and Tucker Taft.

Randy:

Humm. I think this makes it worse, because it's not at all clear what "these 
aspects" refer to. The noun here is "a Dispatching aspect"; I know you're not
talking about that.

I suspect some the confusion here is that the two parts here seem to be 
talking about slightly different parts of the process; the first talks 
about "checking" using the N and G aspects of the called operation, but 
doesn't say anything about what that entails, whereas the second talks 
about "not checking" (unidentified aspects) against some specific aspects 
at the point of the call.

It would be better if the two halves were truly equivalent, talking about 
exactly the same thing. I realize that's not easy to do. The overly long 
version would be something like:

"Within an operation to which a Dispatching aspect applies, any dispatching 
call that does not match any dispatching_operation_specifier of the dispatching
operation set is checked {against the Nonblocking or global aspects applicable 
at the point of call} using the Nonblocking and Global'Class aspect(s) 
applicable to the called dispatching operation; if there is a match, there 
is no checking {of the Nonblocking and Global'Class aspect(s) applicable to 
the called dispatching operation} against the Nonblocking or global aspects 
applicable at the point of call."

It might be best to mention that we're talking about the "usual" check in the 
first case (which of course makes it longer still):

"Within an operation to which a Dispatching aspect applies, any dispatching 
call that does not match any dispatching_operation_specifier of the 
dispatching operation set is checked {in the normal way against the 
Nonblocking or global aspects applicable at the point of call} using the 
Nonblocking and Global'Class aspect(s) applicable to the called dispatching
operation; if there is a match, there is no checking {of the Nonblocking and
Global'Class aspect(s) applicable to the called dispatching operation} against 
the Nonblocking or global aspects applicable at the point of call."

I suspect this can be refactored to simplify and clarify it. Perhaps:

"Within an operation to which a Dispatching aspect applies, the manner in 
which the Nonblocking and Global'Class aspect(s) of a dispatching call are 
checked against the Nonblocking or global aspects applicable at the point of 
call depends upon the Dispatching aspect(s) that apply. In particular, for any 
dispatching call that does not match any dispatching_operation_specifier of 
the dispatching operation set the aspects are checked in the normal way; if 
there is a match, there is no checking of those aspects."

Maybe "in the normal way" would be better phrased as "as usual"? Or more 
pedantically "as described elsewhere in this Standard"?

Maybe there even a better way to organize this wording?

Tucker:

> Humm. I think this makes it worse, because it's not at all clear what 
> "these aspects" refer to. The noun here is "a Dispatching aspect"; I 
> know you're not talking about that.

To me it seems pretty clear what "these aspects" refers to, since it is plural 
while "dispatching aspect" is singular.  But perhaps we can avoid any hint of 
ambiguity.

...
> Maybe there even a better way to organize this wording?

I don't think "normally" or "usually" work very well here, so I think we 
should be a bit more pedantic.

In fact, I would suggest we merge this legality-rule paragraph's content 
(and the one following) into the Static Semantics section, as they seem 
closely related to a Static Semantics paragraph (14/5), and there is no 
"shall" or "shall not" in these paragraphs anyway.

Hence, I would suggest the following:

Modify H.7.1(14/5):

The dispatching operation set is identified by a set of 
dispatching_operation_specifiers. It indicates that the Nonblocking and 
global effects of dispatching calls that match one of the specifiers need 
not be accounted for by the Nonblocking or global aspect, but are instead 
to be accounted for by the invoker of the operation. A dispatching call 
matches a dispatching_operation_specifier if the name or prefix of the call 
statically denotes the same operation(s) as that of the 
dispatching_operation_specifier, and at least one of the objects controlling 
the call is denoted by, or designated by, a name that statically names the 
same object as that denoted by the object_name of the 
dispatching_operation_specifier. {

}In the absence of any dispatching_operation_specifiers{, or if none of them 
match a dispatching call C within an operation P}, Nonblocking and global 
aspects checks are performed at the point of [a dispatching]{the} call {C} 
within [the operation]{P} using the Nonblocking and Global'Class aspects that
apply to the [named] dispatching operation {named in call C}. {If there is a 
match, any global access or potential blocking within the subprogram body 
invoked by the call C is ignored at the point of call within P. Instead, 
when the operation P itself is invoked, Nonblocking and global aspect checks 
are performed presuming each named dispatching operation is called at least 
once (with the named object controlling the call), but similarly ignoring 
those dispatching calls that would match a dispatching_operation_specifier 
applicable at the point of invocation of P.}

-------

Then we can delete H.7.1(17/5 and 18/5).

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