CVS difference for 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