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!news.stack.nl!reality.xs3.de!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: Fri, 4 Apr 2014 15:43:17 -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> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1396644198 880 69.95.181.76 (4 Apr 2014 20:43:18 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 4 Apr 2014 20:43:18 +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:19131 Date: 2014-04-04T15:43:17-05:00 List-Id: "J Kimball" wrote in message news:lhn2ht$v5e$1@loke.gir.dk... > On 04/04/2014 03:20 AM, Stefan.Lucks@uni-weimar.de wrote: >> On Thu, 3 Apr 2014, Jeffrey Carter wrote: >> >>> On 04/03/2014 02:17 PM, Randy Brukardt wrote: >>>> >>>> I : Unbounded_Integer := +1E1000; >>>> >>>> works today. >>> >>> I would like to see the definition of "+". >> >> Second! >> >> My understanding is that 1E1000 is of the pseudo-type Universal Integer, >> (or maybe Universal Float). But the "+" function cannot have an >> in-parameter of that type, so that *should* not work. >> >> Randy, please enlighten us! > > On the other hand, using "+" operators in these ways obscures it's real > meaning to people and > often the compiler. In using a system that combines renames of > language-defined and > Templates Parser-defined conversion functions things can get rather hairy. > Object names > usually indicate what's being described, but rarely what type it is. A > rich use of the type system > makes using "+" boorish. I find this attitude infurating. (And it's wrong, too; literals provide no useful type information and adding "+" to the front does not change that situation. Taken literally and to the extreme, your thinking implies that all overloading of operators is a bad thing because it obscures the types involved. But let's stick with the infurating part). Let me give you a bit of history: 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. The idea to add a unary operator symbol resurfaces periodically, but it always gets shot down because "+" works for that purpose. OTOH, attempts to actually *use* "+" in that way in the language-defined libraries also have always gotten shot down because there is a group which cannot stomach using it for non-numeric purposes. For instance, we had proposed to add: function "+" (A : String) return Unbounded_String renames To_Unbounded_String; to the Unbounded_String package because the conversion here is way too wordy. (Most of my packages that use unbounded string start with this declaration. The real problem is getting too many such declarations colliding.) The net effect is that Ada has neither an explicit conversion operator nor the balls to use "+" as intended. Which makes using language-defined packages a wordy mess to the point that I try pretty hard to avoid them. That's not how that's supposed to work! Attitudes such as yours prevent using the language as it was (and is) intended. And similar attitudes (on the other side of the debate) prevent changing it to make that less controversial. It leaves most people thinking the language has no way to do things when in fact the solutions have been there ever since the beginning of Ada. As for the difficulty of figuring out errors in complex expressions -- remember two things: (1) quality of error handling is not something that the standard can changes; and (2) qualified expressions and prefix notation are your friend. Compilation is quick enough these days that there is no real problem sticking in some qualifications and/or prefix calls to narrow down problems in complicated expressions. (And why are you writing complicated expressions in the first place? Use some expression functions to break those up.) Randy.