From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!gegeweb.org!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Your wish list for Ada 202X Date: Tue, 8 Apr 2014 18:44:12 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <7f1c01c5-3563-4b94-9831-152dbbf2ecdc@googlegroups.com> <2d62368c-9f64-49f3-98a8-5121d0c0fa23@googlegroups.com> <1396504291.12566.134.camel@pascal.home.net> <1396545517.12456.30.camel@pascal.home.net> <1893909476418340554.191505laguest-archeia.com@nntp.aioe.org> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1397000653 31959 69.95.181.76 (8 Apr 2014 23:44:13 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 8 Apr 2014 23:44:13 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:19197 Date: 2014-04-08T18:44:12-05:00 List-Id: "J Kimball" wrote in message news:lhvuom$g1$1@loke.gir.dk... > On 04/07/2014 07:47 PM, Randy Brukardt wrote: >> "Luke A. Guest" wrote in message >> news:1893909476418340554.191505laguest-archeia.com@nntp.aioe.org... >>> "Randy Brukardt" wrote: >>>> Very early in the design of Ada, there was a proposal to add a unary >>>> operator symbol specifically for the purpose converting between types. >>>> Ichbiah and his team rejected the proposal as "+" already exists and >>>> has >>>> no >>>> other useful purpose. They said that "+" should be used for this >>>> purpose. >>> >>> I don't get the idea of using plus as a conversion operator, I'd this so >>> e >>> mathematical notation I've not come across? >> >> The second part above is so garbled that I can't guess how to respond to >> it. >> The first part is easy, one camp says unary "+" doesn't have a (useful) >> mathematical meaning, so let's ignore that meaning and use the operator >> for >> conversions. The other camp says that unary "+" has a (useless) >> mathematical >> meaning that should be left alone. Because of the dynamics of the Ada >> standards process, neither camp ever gets to lead and the net effect is >> that >> we never get *any* conversion operator. Which we've needed from day 1, >> IMHO. > > Maybe they could agree on a new unused operator being added. Did you read my original message? That's been suggested for many years. There is a camp that thinks "+" is good enough for that, and thus blocks any attempts to add another such operator. (There's a lot of people in that camp.) The other group hates the idea of using "+" for that purpose, and blocks any use of that as a conversion in the language. (There's a lot of people in this group, too -- some are in both groups.) The ARG operates by consensus. We have no consensus on either point, thus nothing gets done at all. (Luckily, this dynamic doesn't happen very often.) > Of course mathematics > uses every known graphic in some area. We might be able to agree that an > addition should be in the ASCII code points for Unicode which leaves a > couple of things that > stand out that aren't already in use in Ada. "~" seems like a good > character with a derivative meaning "approximates" which often all a > conversion can do. If it was up to me, '@' or '#' or '$' or '~' would have been used for this long ago. > UBString := ~String; -- Would drive people from some linguisitic > backgrounds crazy, though. Probably any choice will annoy someone. I think that's the primary argument of the "+" backers -- no other solution is really obviously better, so lets not clutter the language further. It's hard to argue with that. Randy.