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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!uunet!husc6!think!ames!pasteur!ucbvax!compass.UUCP!worley From: worley@compass.UUCP (Dale Worley) Newsgroups: comp.lang.ada Subject: Stanley Allen's comments on the Ada language revision Message-ID: <8811181613.AA13866@galaxy.compass.com> Date: 18 Nov 88 16:13:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet List-Id: I consider most of these very well founded. However, the first thing that needs to be decided upon is the domain for which Ada-9x is being targeted. The Steelman requirements presuppose that Ada is intended for embedded software. Thus, for example, input-output was not considered an important feature. However, it seems that Ada is mostly used as a general purpose programming language, and this means that the detailed requirements in Steelman are probably not ideal for Ada-9x. The degree of upward-compatibility from Ada to Ada-9x should be determined early on. I suspect that genuine upward-compatibility (being able to recompile ANY Ada program to run under Ada-9x without change) would make it hard to straighten out some of the stranger aspects of overloading. The only general suggestion that I can make is that the definition of Ada-9x should probably be more formalized than the current RM. (You may complain that formal language definitions are unreadable, but this can be solved by publishing an official gloss written in a style similar to the current RM.) The advantage of a formally defined language is that it leads to fewer "gotchas". For instance, Algol 68 is defined extremely formally, and as far as I know, there has never been a question as to the exact meaning of any Algol 68 program. (Although digging that meaning out of the formal definition can be hard.) Conversely, there have been "megabytes of commentaries" spelling out tricky special cases on which the Ada RM is unclear. Even worse, with a non-formal definition, it is more likely that some tricky special case simply can't be solved cleanly within the framework of the rest of the language. The beneficial influence of formal definitions can be seen by comparing the syntax of Fortran with the syntax of a more modern language. Fortran's syntax was designed informally, because formal grammars hadn't been accepted as only way to define syntax. Thus, Fortran's syntax is very irregular, bedeviling both programmers and compiler writers. Conversely, a new syntactic construction can be added to Ada relatively easily, because the formal grammar method makes it clear how such a new feature must fit in with the existing features. It is also clear that more work needs to be done on portability questions. I've noticed in Info-Ada that people have projects with three different versions of the Ada code, for three different compilers! (We've done such things, also.) Most of these incompatibilites probably arise when interfacing to external code, which is going to be hard anyway, but Ada-9x should try to force compilers to be as compatible as possible in this area also. Dale -- Dale Worley, Compass, Inc. compass!worley@think.com