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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c8fd02a2b1be456a X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-02-23 15:32:09 PST Path: nntp.gmd.de!stern.fokus.gmd.de!gmdtub!cs.tu-berlin.de!fu-berlin.de!news.dfn.de!swiss.ans.net!europa.eng.gtefsd.com!news.mathworks.com!news.duke.edu!eff!blanket.mitre.org!linus.mitre.org!spectre!eachus From: eachus@spectre.mitre.org (Robert I. Eachus) Newsgroups: comp.lang.ada Subject: Re: Type extension with GNAT Message-ID: Date: 23 Feb 95 23:32:09 GMT References: <3ib6h2$19q4@source.asset.com> <3iguhr$ai4@gnat.cs.nyu.edu> Distribution: usa Organization: The Mitre Corp., Bedford, MA. NNTP-Posting-Host: spectre.mitre.org In-reply-to: dewar@cs.nyu.edu's message of 22 Feb 1995 22:14:03 -0500 Date: 1995-02-23T23:32:09+00:00 List-Id: In article <3iguhr$ai4@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes: > I disagree with Robert Eachus' complaint about overloading and > overriding. The critical point here is that constructors of this > type should not be made primitive. THAT's the solution, and that's > what we shold teach people to understand. If the fact that users need to put constructors in nested packages is the worst feature of Ada 95, then everyone involved did an incredibly good job. (And even if there are a few other worse blemishes discovered, Ada 95 turned out to be fantastically better than we could have hoped when the process started.) But given the amount of traffic generated on the net, and the number of times I have already had to explain this "feature" to naive users, I am going to grow very, very tired of explaining this over the next decade. Hmmm, maybe I had better explain where I am coming from. There was obviously a lot that could be improved in Ada 83, but there were some cases where judgement calls had to be made. In some cases the choices made were right for the time, but needed to be revisited in the revision. In many other cases history proved the decisions right. But there were two decisions which obviously hurt the acceptance of the language. I'm not sure, even in hindsight, whether the choice to leave the elementary math functions out of Ada 83 was right or wrong. (For Ada 9X, leaving them out was almost unthinkable--but that reflected the results of lots of work by many dedicated people. And the decision in 82 was that the work couldn't be done in time for that version of the standard, and putting in a poorly specified package would have been a mistake. Fair enough.) But I have ALWAYS felt guilty about the wording in the manual on expiration of delays. I feel that I correctly pointed out to the design team that the previous wording had unimplementable requirements, but I should have realized how the proposed correction would be read by non-language lawyers. (Robert Dewar should probably feel some guilt as well, for pointing out publicly--and correctly--that implementations without multple priority levels could be more useless than most people thought.) As the RM is written, if a compiler supports more than one priority level, it must do expiration of delays correctly. However, the wording seems to say that compilers can be lazy about restarting tasks after a delay, and this became a common misperception about Ada in embedded programming circles. Now I don't feel any guilt associated with the derivation of constructors in Ada 95. Even if in ten years we discover a better approach, that doesn't make the current design wrong. But I intend to work as hard as I can to make this a known design rule that gets into all the style guides and all the textbooks, so that we don't lose potential Ada users over this extremely minor seeming issue. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...