Version 1.5 of ais/ai-00388.txt

Unformatted version of ais/ai-00388.txt version 1.5
Other versions for file ais/ai-00388.txt

!standard A.5(3)          04-12-30 AI95-00388/02
!class amendment 04-11-10
!status Amendment 200Y 04-12-01
!status ARG Approved 8-1-1 04-11-19
!status work item 04-11-10
!status received 04-11-10
!priority Medium
!difficulty Easy
!subject Add Greek pi to Ada.Numerics
!summary
(See proposal.)
!problem
AI95-00285 introduces support for the entire ISO/IEC 10646:2003 character repertoire in source files. In particular, many characters from non-Latin alphabets are now allowed in identifiers.
The identifiers appearing in language-defined units are typically written in English, and therefore use the ASCII subset. In general this is appropriate, and there is no reason to take advantage of the support added by AI95-00285.
One exception to this is the named number Ada.Numerics.Pi. It is universally written using the Greek letter pi in printed text. Having to use the ASCII identifier Pi in numerical algorithms written in Ada degrades the readability of the program text. Being able to use the Greek letter would make it clearer to the reader that a piece of code is using the mathematical number pi, not some random identifier that happens to read PI.
Adding Greek pi to Ada.Numerics is a compatible change because there is currently no code that uses that character as an identifier.
!proposal
Add the following declaration to Ada.Numerics:
<GREEK SMALL LETTER PI> : constant := Pi;
Where <GREEK SMALL LETTER PI> is the character at position 16#03C0#.
<<Author's note: to properly represent Greek pi in the AI I would have to make this file UTF-8, which would probably confuse both the tools and the readers. However, there are already occurrences of this character in the RM, so it shouldn't be a problem to make it look nice and fancy in the final text.>>
!wording
Replace A.5(3) by:
package Ada.Numerics is pragma Pure (Numerics); Argument_Error : exception; Pi : constant := 3.14159_26535_89793_23846_26433_83279_50288_41971_69399_37511; <GREEK SMALL LETTER PI> : constant := Pi; e : constant := 2.71828_18284_59045_23536_02874_71352_66249_77572_47093_69996; end Ada.Numerics;
!discussion
(See proposal.)
!example
No example is needed.
!corrigendum A.5(3)
Replace the paragraph:
package Ada.Numerics is pragma Pure (Numerics); Argument_Error : exception; Pi : constant := 3.14159_26535_89793_23846_26433_83279_50288_41971_69399_37511; e : constant := 2.71828_18284_59045_23536_02874_71352_66249_77572_47093_69996; end Ada.Numerics;
by:
package Ada.Numerics is pragma Pure (Numerics); Argument_Error : exception; Pi : constant := 3.14159_26535_89793_23846_26433_83279_50288_41971_69399_37511; π : constant := Pi; e : constant := 2.71828_18284_59045_23536_02874_71352_66249_77572_47093_69996; end Ada.Numerics;
!ACATS test
An ACATS test needs to be constructed to check the existence of this declaration.
!appendix

From: Dan Eilers
Sent: Monday, January 24, 2005  5:49 PM

  What's the story with AI-388, which claims that Ada code would
print better if numerics.pi used the UTF-8 symbol.   But there
are a lot of Ada symbols that would print better if Ada used the
UTF-symbol, such as *, /, <=, >=, /=, etc.  Using UTF-8 only for
PI makes it stick out like a sore thumb.

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

From: Randy Brukardt
Sent: Monday, January 24, 2005  6:20 PM

I don't know, I was strongly against it (for this and other reasons) and in
fact voted against it at the ARG level (see the Atlanta minutes). I
apparently wasn't very convincing...(the vote was 8-1-1). But it's not
important enough to get all worked up about.

We had talked about allowing overloading for various Unicode symbols early
on in the process, but essentially decided that there was nothing near a
consensus on what to allow. (See AI-322, sorry I forget which meeting we
discussed that AI.)

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

From: Robert Dewar
Sent: Monday, January 24, 2005  9:56 PM

Yes, indeed, this is an indulgeance we could do without. But
I guess someone felt strongly about it, and apparently the general
reaction was that it was not horrible enough to make a fuss about.

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

From: Robert Dewar
Sent: Monday, January 24, 2005  9:58 PM

> I don't know, I was strongly against it (for this and other reasons) and in
> fact voted against it at the ARG level (see the Atlanta minutes). I
> apparently wasn't very convincing...(the vote was 8-1-1). But it's not
> important enough to get all worked up about.

Very peculiar (the vote ...)

However, it really is not hard to handle, the Ada.Numerics package in GNAT now
looks like

package Ada.Numerics is
pragma Pure (Numerics);

    Argument_Error : exception;

    Pi : constant :=
           3.14159_26535_89793_23846_26433_83279_50288_41971_69399_37511;

    ["03C0"] : constant := Pi;
    --  This is the greek letter Pi. Note that it is conforming to have this
    --  present even in Ada 95 mode, because there is no way for a normal mode
    --  Ada 95 program to reference this identifier in any case.

    e : constant :=
          2.71828_18284_59045_23536_02874_71352_66249_77572_47093_69996;

end Ada.Numerics;

:-)

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

From: Dan Eilers
Sent: Tuesday, January 25, 2005  6:29 PM

I do think this is horrible enough to make a fuss about.
It seems to be a complete breakdown of the AI process.
There is no documented user demand for this silly feature,
and the AI contains absolutely no record of any discussion.

It's particularly galling to see AI's with no user demand
making the cut at this late stage, when many AI's and AC's
that do have documented user demand and discussion (e.g., AI 390)
didn't.

I expect many Ada projects will enforce pragma restrictions(no_wide_characters),
(in order to be able to discuss program fragments in email and
process with ASCII-based tools).  It will be a considerable burden
for these projects to have to maintain a copy of the Ada.Numerics
hierarchy that eliminates the Greek Pi.

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

From: Randy Brukardt
Sent: Tuesday, January 25, 2005  6:50 PM

> I do think this is horrible enough to make a fuss about.
> It seems to be a complete breakdown of the AI process.
> There is no documented user demand for this silly feature,
> and the AI contains absolutely no record of any discussion.

Why would the AI contain a discussion? Lots of AIs have no e-mail
discussion. It was discussed for quite a while in Atlanta; it certainly
wasn't "snuck in".

> It's particularly galling to see AI's with no user demand
> making the cut at this late stage, when many AI's and AC's
> that do have documented user demand and discussion (e.g., AI 390)
> didn't.

The AIs in that category (I'd include AI-359 and AI-315 there, too) didn't
make the cut because their solutions were too complex for the gain. In the
case of AI-390, for instance, the proposal was so narrow and obscure that it
seems unlikely that users would know to use it even when the problem was
encountered. (I know I would be unlikely to remember this weird feature in
the very rare case that it was needed.) The problem is worth solving, but we
didn't have a solution that we were comfortable with, and we have to stop
adding things at some point, or we'd never finish.

I don't like this AI anymore than you do, but the AI went through the
process; because it was easy, there wasn't a need for lots of drafts and
discussion -- it came down to a simple yes or no vote. And the vote showed
the needed consensus, even if it came out wrong. The result seems a lot
clearer than the presidential election, for instance.

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

From: Dan Eilers
Sent: Wednesday, January 26, 2005  3:28 AM

> Why would the AI contain a discussion? Lots of AIs have no e-mail
> discussion. It was discussed for quite a while in Atlanta; it certainly
> wasn't "snuck in".

The AI would contain a discussion because the originator would
send email saying something like I know that WG9 has already
approved the scope of the language, but I've come across an
issue that I think is really important to squeeze in because ...
And someone else will respond either by seconding it, or
by saying they think the language is insufficiently broke,
or by pointing out problems with the proposal, such as the
glaring inconsistency this proposal creates between the one
mathematical symbol represented in unicode, and no others.

> I don't like this AI anymore than you do, but the AI went through the
> process; because it was easy, there wasn't a need for lots of drafts and
> discussion -- it came down to a simple yes or no vote.

I'm not sure what you mean by "easy".  Yes, its a one-line
source change, but that doesn't mean the ramifications to
the consistency of the language or to users that don't want
wide_characters shoved in their faces, don't merit more
consideration than the short time available at a single ARG meeting.

> In the case of AI-390, for instance, the proposal was so narrow and
> obscure that it seems unlikely that users would know to use it even
> when the problem was encountered. (I know I would be unlikely to
> remember this weird feature in the very rare case that it was needed.)
> The problem is worth solving, but we didn't have a solution that we
> were comfortable with, and we have to stop adding things at some point,
> or we'd never finish.

I agree that the proposed syntax was somewhat obscure.  I think this
was done to avoid adding a new keyword, such as the less obscure:
  procedure foo is inherited;

Given the urgency of this problem for our customers, we will probably
resort to implementing a solution using a pragma such as:
  pragma inherited(foo);

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

From: Pascal Leroy
Sent: Wednesday, January 26, 2005  5:14 AM

> I do think this is horrible enough to make a fuss about.
> It seems to be a complete breakdown of the AI process.
> There is no documented user demand for this silly feature,
> and the AI contains absolutely no record of any discussion.

That you don't like the conclusion of the AI is certainly legitimate, and
it happens to all of us from time to time.

That you claim that this is "a complete breakdown of the process" is an
entirely different statement, which questions my integrity and that of the
ARG in general.

I don't think that you have any factual evidence that the ARG procedures
were not dutifully followed in this instance.  True, there was no email
exchange, but I don't see anything in the procedures that requires an
email exchange.  The procedures require that each AI be discussed at a
meeting, and this is what happened in Atlanta, and the minutes summarize
the discussion. True, the discussion was rather short, but this is
probably because people were able to make up their mind relatively
quickly.  I certainly didn't put a lid on the discussion or try to shorten
it in any way.

Of course the procedures allow any ARG member to ask for a letter ballot
on any AI that has not been sent to WG9 yet, so you might try to convince
some member to do that.  If that happens I will conduct the letter ballot
as required by the procedures, and I will put the AI on the agenda of the
Boston meeting if the ballot fails.

If you still think that the process has not been obeyed, I guess you'll
have to lodge a complaint with WG9 through the US TAG.  But this mailing
list is not the appropriate medium for doing this.

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


Questions? Ask the ACAA Technical Agent