!standard A.5(3) 05-10-10 AI95-00388/03 !class amendment 04-11-10 !status Amendment 200Y 04-12-01 !status WG9 Approved 06-06-09 !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: : constant := Pi; Where is the character at position 16#03C0#. <> !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; : 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) @drepl @xcode<@b Ada.Numerics @b @b Pure(Numerics); Argument_Error : @b; Pi : @b := 3.14159_26535_89793_23846_26433_83279_50288_41971_69399_37511; e : @b := 2.71828_18284_59045_23536_02874_71352_66249_77572_47093_69996; @b Ada.Numerics;> @dby @xcode<@b Ada.Numerics @b @b Pure(Numerics); Argument_Error : @b; Pi : @b := 3.14159_26535_89793_23846_26433_83279_50288_41971_69399_37511; @Pi : @b := Pi; e : @b := 2.71828_18284_59045_23536_02874_71352_66249_77572_47093_69996; @b 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. ************************************************************* From: Bob Duff Sent: Saturday, January 29, 2005 4:21 PM [Editor's note: The thread that this is commenting on is filed in AI-395.] > I would not be the least bit surprised if IBM has current or pending > patents or other IP claims on Unicode, and if so, the licensing rights > should be clearly stated before we go adding Unicode tables and algorithms > to our compilers, and especially before we go adding a gratuitous > Unicode character to the spec of a predefined Ada package, ... Sorry to make light of this, but I just can't resist: What we're talking about here is the patenting of pi, given the particular Ada package Dan is referring to! ;-) **************************************************************** From: Robert Dewar Sent: Saturday, January 29, 2005 10:31 PM > What we're talking about here is the patenting of pi, > given the particular Ada package Dan is referring to! That's not *quite* fair. Dan is worrying that the use of the code 16#03C0# for pi might be patented. However, that's almost equally ludicrous :-) There are good arguments against the use of pi. Dan made them earlier. Now he is (probably fatally) diluting his case by making arguments that are (at least in my opinion) irrelevant. **************************************************************** From: Dan Eilers Sent: Saturday, January 29, 2005 9:34 PM ... > That's not *quite* fair. Dan is worrying that the use of > the code 16#03C0# for pi might be patented. Well that's not quite fair either. The stated purpose of requiring Greek pi in a predefined package is to ensure full support for Unicode across the full spectrum of tools that process Ada source code, whether they be tools supplied by Ada compiler vendors, or third-party tools, or a user's home-grown tools, including CM systems, mail systems, etc., that aren't intended specifically for use with Ada source code. There may well be patents of the form "use of Unicode in programming environment tools" that are more serious in the context of AI-388 than AI-285. **************************************************************** From: Randy Brukardt Sent: Saturday, January 29, 2005 10:01 PM Now you're overstating the case. There is nothing of the sort in AI-388, and I know that there was no discussion of the above when the AI was proposed. *I* pointed out that requiring full support for Unicode is the logical consequence of the AI; I still don't think that a lot of people really believe that is a consequence -- but they're fooling themselves. Be that as it may, the ARG certainly never voted on anything like "ensuring full support for Unicode" and I have no idea on how such a statement would be received by the ARG. **************************************************************** From: Dan Eilers Sent: Saturday, January 29, 2005 11:02 PM I am referring to the Atlanta ARG minutes, where this AI was first proposed, which say: > Pascal says that AI-285 will be required anyway. But that only > requires the compiler to recognize the characters, not all of the > tools. Moreover, that can (and probably will) be accomplished > with a practically useless hack until/unless there is sufficient > customer demand for the expensive changes needed. But a toolset > that can't edit/display the standard libraries is junk. What does this mean if it doesn't mean ensuring that not only the compiler but all of the tools will recognize full Unicode? p.s. Is the "practically useless hack" referring to implementations that encode Unicode characters in ASCII using notations like ACATS/GNAT uses? **************************************************************** From: Randy Brukardt Sent: Sunday, January 30, 2005 12:10 AM > What does this mean if it doesn't mean ensuring that not only the compiler > but all of the tools will recognize full Unicode? That was an opinion expressed by one person (the recorder of the minutes). It certainly wasn't universally shared, and I don't think we discussed it for long. Certainly we never tried to reach a consensus on this point (indeed, if the minutes don't indicate that a consensus was reached on some point, it's best to assume that it was not reached. I generally record interesting points made by people, and I certainly make no special effort to figure if everyone agrees with a point that I've recorded -- if we did that, we'd never get anything done). > p.s. > Is the "practically useless hack" referring to implementations that > encode Unicode characters in ASCII using notations like ACATS/GNAT uses? I think I was thinking of even worse (no tools support of any kind), but I'm not certain. In any case, it was my position in the debate, not some general consensus. **************************************************************** From: Dan Eilers Sent: Sunday, January 30, 2005 1:39 AM > That was an opinion expressed by one person (the recorder of the minutes). > It certainly wasn't universally shared, and I don't think we discussed it > for long. Certainly we never tried to reach a consensus on this point OK, I think I understand. After the sentence starting "Pascal says" there is a missing "Randy says". But this makes even less sense. If the only reason for proposing this AI was a better looking Pi symbol, and not ensuring support of Unicode (at least to level 1) throughout the programming environment, then I don't see how it could come even remotely close to meeting the criteria in effect at the time for new AI's, which Pascal gave as: "Remember that the deadline for submitting new proposals was December 31st, 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." There is obviously no pressing issue in the RM or in other AIs for a better looking Pi symbol. I suppose it could be argued that SC22's resolution 02-24 for "appropriate support of Unicode" constitutes as a pressing need for certain Unicode characters _other_ than Pi. For example, Unicode recommends that paired quotation marks use U+201C and U+201D instead of the ASCII double-quote mark that Ada currently uses. I am not suggesting following this recommendation, but if there is a pressing need to follow Unicode recommendations as closely as possible, then Pi is the wrong symbol to start with. **************************************************************** From: Robert Dewar Sent: Sunday, January 30, 2005 3:05 AM > What does this mean if it doesn't mean ensuring that not only the compiler > but all of the tools will recognize full Unicode? Incredible leap of shaky logic :-) I cerytainly think your toolset must be able to edit/display the standard libraries. But that's easily achieved. Assuming you use brackets notation, here is the code from the GNAT spec of Ada.Numerics (on which ACT asserts no IPR's :-). What you see here was generated by the following tools that for sure are not "recognizing full Unicode" DOS type command DOS cut Thunderbird paste command 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 (for Ada 2005 AI-388). 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. e : constant := 2.71828_18284_59045_23536_02874_71352_66249_77572_47093_69996; end Ada.Numerics; P.S. while I am reminded of this, one of our numerics experts says that the number of digits of pi here is just sufficient for some interesting use in conjunction with an algorithm not known at the time the RM was written :-) **************************************************************** From: Robert Dewar Sent: Sunday, January 30, 2005 3:22 AM > p.s. > Is the "practically useless hack" referring to implementations that > encode Unicode characters in ASCII using notations like ACATS/GNAT uses? Just for the record, yes, of course GNAT supports the ASCII brackets notation, but it also supports many other real life useable encodings including: Simple Hex encoding with ESC (ASCII notation preceding brackets use) Upper half encoding (used in China) Shift-JIS encoding (used in Japan, probably the only one used for real now) EUC encoding (also used in Japan) UTF-8 encoding (the only real encoding supporting full 32-bits) Brackets encoding (extended to support full 32-bits) For Ada.Numerics, we use the bracket notation precisely because we don't want problems when people process this source with various tools. Yes, this means that people with fancy editors (but not fancy enough to understand Ada brackets notation) will not see an elegant pi on their screens. Too bad. And in any case unavoidable. Suppose we used UTF-8 for the pi in Ada.Numerics. Well then our Japanese users not only will not see the pi in their Shift-JIS environments but they will see some gobbledygook sequence of junk characters much worse than the brackets notation. **************************************************************** From: Robert Dewar Sent: Sunday, January 30, 2005 2:55 AM > Now you're overstating the case. There is nothing of the sort in AI-388, and > I know that there was no discussion of the above when the AI was proposed. > *I* pointed out that requiring full support for Unicode is the logical > consequence of the AI; I still don't think that a lot of people really > believe that is a consequence -- but they're fooling themselves. What are the various cases here 1. A compiler intends to support real practical use of AI-285 including its use in all its tools etc. In this case AI-388 falls out and there is no concern. 2. A compiler intends to miminally support AI-285, e.g. for the purposes of validation and passing ACATS tests, and perhaps some limited use, but does not want to bother to do anything with subsidiary tools. Well here the RM has nothing whatever to say about tools. But in any case the burden placed by pi is just part of the (hugely more complex) AI-285. 3. A compiler intends to support the AI-388, but not AI-285, and to support if fully including all tools. This seems a bizarre business decision, and is the only case in which the above statement is even vaguely reasonable. Even there, the burden is far less than full support of AI-285. 4. A compiler intends to support the AI-388 for the purposes of validation, but does not care about tools etc. In this case you don't need full unicode support, just allow ["03C0"] as a special case identifier. 5. A compiler intends to support neither AI-285 nor the AI-388. This seems a perfectly reasonable decision to me. These days when validation is not important to many/most/all customers, there may well be no point in wasting time on this stuff. Certainly I don't see any poin in decisions 3 or 4 above. If you intend to snub AI-285, it is consistent to snub the AI-388. Of course there will be competitive pressure (for sure GNAT intends to support the entire standard as it always has), but I doubt this competitive pressure is that significant (it didn't make anyone else implement the distribution annex :-) GNAT is taking roughly approach 2. For example, for full support of approach 1, we would have to fully support unicode in our GPS editing environment. That's a huge job, and one I have not even listed as a desirable enhancement. If a customer comes along with dollars (or more likely yen or some other currency) on the table, anything can be considered :-) > > Be that as it may, the ARG certainly never voted on anything like "ensuring > full support for Unicode" and I have no idea on how such a statement would > be received by the ARG. Hmmm, if any such vote was taken, it is for sure the vote on AI-285, and not the vote on AI-388 tha would qualify. **************************************************************** From: Pascal Leroy Sent: Sunday, January 30, 2005 5:49 AM Thank you, Robert, for a very clear and cogent analysis of the implications of AI 388. Before writing this AI I made roughly the analysis above (I must confess that I didn't consider option 3, which I find really weird). My conclusion was the following: - Option 1: clearly AI 388 comes for free, and users get the benefit of a more readable identifier. - Option 2 makes perfect sense: users can write code using some off-the-shelf Unicode editor, and to submit their code to the compiler, provided that the compiler can read some sort of standard interchange format (eg UTF-8); if users want more support in the auxiliary tools, they'll ask for it, but at least this provides a workable solution; at any rate, AI 388 doesn't impose any significant extra cost. - Option 4 makes it possible to pass validation at a very small extra implementation cost; AI 388 is not useful to users in this case, but they can still use Pi anyway, so there is no loss of functionality. - Option 5: evidently AI 388 is not problematic. It is clear that option 2 is a substantial implementation effort. It is also clear that option 1 is a much bigger effort, since virtually all parts of the IDE are affected. IBM Rational intends to support option 2, with UTF-8 as an interchange format. Then we'll see if there is user demand for better support. In fact at the meeting my view was that it would be natural for those compilers which want to validate to choose option 2, so AI 388 is not a big deal. That's what I meant by: "Pascal says that AI-285 will be required anyway. But that only requires the compiler to recognize the characters, not all of the tools." In the light of your analysis, this discussion sounds like a tempest in a teapot, since it's only if you choose option 3 that AI 388 is costly. But if you don't like AI 388, why would you choose option 3 in the first place? It's hard to imagine users clamoring for Greek pi... **************************************************************** From: Dan Eilers Sent: Monday, January 31, 2005 3:46 AM > It's hard to imagine users clamoring for Greek pi... Please explain the apparent inconsistency between this statement and your earlier statement: "Remember that the deadline for submitting new proposals was December 31st, 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. ****************************************************************