CVS difference for ais/ai-00388.txt

Differences between 1.6 and version 1.7
Log of other versions for file ais/ai-00388.txt

--- ais/ai-00388.txt	2005/02/10 05:46:40	1.6
+++ ais/ai-00388.txt	2005/10/31 05:18:39	1.7
@@ -1,4 +1,4 @@
-!standard A.5(3)                                    04-12-30  AI95-00388/02
+!standard A.5(3)                                    05-10-10  AI95-00388/03
 !class amendment 04-11-10
 !status Amendment 200Y 04-12-01
 !status ARG Approved 8-1-1  04-11-19
@@ -71,7 +71,7 @@
 
 @drepl
 @xcode<@b<package> Ada.Numerics @b<is>
-   @b<pragma> Pure (Numerics);
+   @b<pragma> Pure(Numerics);
    Argument_Error : @b<exception>;
    Pi : @b<constant> :=
           3.14159_26535_89793_23846_26433_83279_50288_41971_69399_37511;
@@ -80,11 +80,11 @@
 @b<end> Ada.Numerics;>
 @dby
 @xcode<@b<package> Ada.Numerics @b<is>
-   @b<pragma> Pure (Numerics);
+   @b<pragma> Pure(Numerics);
    Argument_Error : @b<exception>;
    Pi : @b<constant> :=
           3.14159_26535_89793_23846_26433_83279_50288_41971_69399_37511;
-   @Pi : constant := Pi;
+   @Pi : @b<constant> := Pi;
    e  : @b<constant> :=
           2.71828_18284_59045_23536_02874_71352_66249_77572_47093_69996;
 @b<end> Ada.Numerics;>
@@ -641,6 +641,130 @@
   2003 (yes, that's 2003) and that the scope of the Amendment was frozen in
   June 2004.  So for a new AI to stand a chance, it must address a pressing
   issue in the existing RM or in other AIs."
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, April 5, 2005  8:04 AM
+
+I really think AI-388 is a huge mistake (pi in standard library).
+
+Not only does this cause trouble with all kinds of existing tools,
+
+but it also encourages people to write applications programs which
+will have similar trouble.
+
+I think we will simply unimplement this in GNAT whatever the standard
+says, it's just too silly and too annoying, and it is pointless to
+deal with all the problems it causes.
+
+If anyone really wants to use pi in their programs, they can easily
+make a package that defines it (in fact they can probably use all
+kinds of other wondrous upper plane unicode math symbols if they
+are in the mood!)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, April 5, 2005  5:59 PM
+
+That certainly was my initial reaction. And I also have to agree with Dan
+that there are a lot of other Unicode characters that we should be
+supporting if we are going to do that seriously. Why just this one?
+
+I've had trouble even getting Unicode characters to display properly;
+apparently, Windows support for Unicode in most fonts is weak.
+
+I am on record as having voted against this, but was unable to convince
+anyone else to take my side. Perhaps if you had been at the Atlanta meeting
+this would have been different. Anyway, you'll have to convince others that
+this is a bad idea before we can reconsider it; since I voted against it in
+the first place, I can't even call for reconsideration.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, April 5, 2005  6:23 PM
+
+Well my argument is there, it's not very important to me, we have decided not
+to implement this in any case, whatever the standard in its wisdom decides.
+If we ever have to validate (which is unlikely these days), we can cough up
+a validation only version of the package :-)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, April 5, 2005  7:09 PM
+
+Can you elaborate on the specific kinds of problems you have
+faced?  If we are supposed to support use of Unicode
+characters in identifiers, it would be helpful to know
+what sorts of problems are lurking out there.  Do you
+think these problems are short-lived, or systemic
+and not going to be solved for years?
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Tuesday, April 5, 2005  7:41 PM
+
+In this case I am not the Robert being addressed, but I think I can
+answer it.  We are used to 256-character fonts where every character
+point except the 32 or 64  non-graphic positions, has a graphic.
+However many Unicode fonts only support one of Chinese, Japanese, or
+Korean, and have lots of character points with no glyphs.  Expecting the
+Unicode Pi to be there is a lot less likely than when choosing the ISO
+8859/7 Latin Greek character set.
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Tuesday, April 5, 2005  7:50 PM
+
+I realized that adding a pointer to a  place that reflects the state of
+the practice would be a good idea.  Try:
+http://www.alanwood.net/unicode/fonts_windows.html
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, April 6, 2005  6:45 PM
+
+Actually it is really not that. Most programs and consequently
+many Ada utilities just do not handle wide character, so that means
+that suddently the library causes problems with tools. If there was
+some important substantive use of wide wide character that would be
+one thing, but the isolated use of pi is gratuitous for this purpose.
+I would guess that most applications environments will forbid the use
+of wide characters other than in comments and perhaps in string
+constants (certainly that's the way our Japanese customers have always
+worked). This means that typically they want to suppress the use of
+wide characters in identifiers, but now that means you can't have
+a WITH of Ada.Numerics, which is a huge pain.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, April 6, 2005  7:00 PM
+
+> ...  Do you
+> think these problems are short-lived, or systemic
+> and not going to be solved for years?
+
+Systemic. I would expect most Ada software to forbid wide characters
+in identifiers indefinitely (I would certainly recommend that to any
+one who asked). I am talking about long lived serious software (not
+student/hobbyist stuff). That means that Ada.Numerics cannot be used.
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Thursday, April 7, 2005  12:19 AM
+
+For the record, we also consider AI-388 to be a huge mistake,
+and do not intend to implement it whatever the standard says.
+This is not a position we take lightly, much preferring a
+deliberative process to voting with one's feet.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent