Version 1.7 of ais/ai-00388.txt

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

!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
!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.

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

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.

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


Questions? Ask the ACAA Technical Agent