CVS difference for ais/ai-00388.txt

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

--- ais/ai-00388.txt	2005/01/28 02:10:50	1.5
+++ ais/ai-00388.txt	2005/02/10 05:46:40	1.6
@@ -303,3 +303,344 @@
 
 *************************************************************
 
+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."
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent