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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,99ab4bb580fc34cd X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: Q: access to subprogram Date: 1996/07/09 Message-ID: #1/1 X-Deja-AN: 167581825 references: <4rb9dp$qe6@news1.delphi.com> <4rr5tu$sap@watnews1.watson.ibm.com> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-07-09T00:00:00+00:00 List-Id: Jon says "While the lack of direct support for recursive types across package boundaries and lack of assertions are more important (IMO) goofs, and while the evinced reasons for the latter one are mind numbingly incomprehensible, this latest example would appear to take the crown for the most stupefying goof." Well it is always easy for users to decide that they want everything and don't want to worry about the required resources, but a language design can't be quite that cavalier in balancing requirements. The fact of the matter is that providing for displays to work reasonably easy *has* had value in getting at least some Ada 95 compilers to market more easily than might have otherwise been the case. I think everyone agrees that it is valuable to have several compilers competing, and the balance in features vs implementability was always a tricky one. Note that we did lose one compiler (the DEC Ada compiler), and a large part of the reason for DEC's decision to get out of the Ada compiler business was that they estimated it was too expensive to modify their technology for Ada 95. We have also lost at least one front end (the old Alsys technology, and before that the Systeam technology), and more may dissappear before we are through. At least the Alsys code generators proved largely adaptable to Ada 95. Of course we have gained at least two new front ends (GNAT and Intermetrics, so the front end situation looks healthy, although it is interesting that both of these front ends were "from scratch". One of the key requirements in the design was that Ada 95 not be such a big change that it would be impractical to adapt existing Ada 83 front ends. At some points in the design, some people expressed the opinion that this was impractical, and that we should assume that "from scratch" development was the only practical path, but WG9 insisted on a viewpoint that we should not restrict things in this way. It appears that we at least partially succeeded, since at least two Ada 95 front ends *are* adaptations of Ada 83 frontends. There is certainly no doubt that Ada 95 is close to the limits of acceptable front end complexity. Of course when you look at individual features, it is hard to label any one feature as a back-breaking straw, but that's what that little fable is all about after all :-)