TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
"Robert I. Eachus" <[log in to unmask]>
Thu, 27 May 1999 16:46:04 -0700
"Robert C. Leif, Ph.D." <[log in to unmask]>
"Robert C. Leif, Ph.D." <[log in to unmask]>
text/plain; charset="iso-8859-1"
text/plain (44 lines)
From: Bob Leif
To: Robert I. Eachus et al.

> -----Original Message-----
> From: Team Ada: Ada Advocacy Issues (83 & 95)
> [mailto:[log in to unmask]]On Behalf Of Robert I. Eachus
> Sent: Thursday, May 27, 1999 12:27 PM
> To: [log in to unmask]
> Subject: Re: Ada Question (correction)
Robert I. Eachus wrote
>     Two comments.  First, I believe the current status is that 8859/1 has
> been updated to include the Euro symbol, but the fixes to 10646 and ASCII
> are still in the approval pipeline.  I expect that patches and updates for
> character set software is already reflecting the change, because the old
> international currency symbol was never much used.
>     Second, it would have been fun if it had been available.  In
> fact maybe
> in the next Ada standard we can revisit this proposal with some other
> characters.  Using Unicode (or UTC) we could have loads of additional
> operator symbols.  Even staying within Latin-1 provides lots of
> interesting
> choices:
>      Left and Right Angle Quotations for labels.
>      Not sign as an alternative to "not".
>      Degree sign as a postfix operator.
>      Superscript two and three as (possibly static) aliases for
> "**2" and "**3".
>      Division and Multiplication signs as binary operators with
> the obvious
Big SNIP to end.
One other approach is to employ XML as an environment to read, edit, and
create Ada source text. This would permit the use of MathML and integrate
Ada with the web hypertext environment. I hope the result would be a true
fourth generation language. It would have the very great advantage of being
based on a third generation language that actually worked.

I should most strongly note that Robert I. Eachus' very interesting
suggestions and a move to XML should NOT interfere with each other. I hope
that they would be synergistic.