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,a714625b3763f46e,start X-Google-Attributes: gid103376,public From: vsnyder@math.jpl.nasa.gov (Van Snyder) Subject: Modest proposal, 3 of 3 Date: 1996/11/22 Message-ID: <575aq0$t4j@netline-fddi.jpl.nasa.gov>#1/1 X-Deja-AN: 198151802 organization: Jet Propulsion Laboratory content-type: text/plain; charset=US-ASCII mime-version: 1.0 newsgroups: comp.lang.ada Date: 1996-11-22T00:00:00+00:00 List-Id: BACKGROUND One of the reasons for code-bloat is the way we teach our children to structure programs. What Parnas had in mind when he recommended "information hiding" and "encapsulation" in Comm. ACM (Dec 72) in "On the criteria for dividing programs into modules" was that one could thereby (almost) change the representations of objects in a program by changing their declarations, but not their references -- no matter what representation one chooses, the references always look the same: a procedure. Almost. In the procedures that support an "abstract data type" one must still cope with changes in representation. That's not terrible. The amount of work necessary to change a representation is reduced from something proportional to the size of a program to something on the order of the complexity of the data type. The unfortunate side effect is that it leads to innumerable tiny procedures. On the positive side, the design methodology is applicable to any language. Geschke and Mitchell had a better idea in IEEE TSE SE-1, 2 (June 75) in "On the problem of uniform references to data structures": Design languages so that differences in representation are not reflected in references. So the [] vs () for arrays vs functions in C would be considered to be a bad idea. (Actually, Ross described the germs of the idea in Software Engineering 1 (1969) in "Uniform referents: An essential property for a software enginering language.") Minor incremental changes could bring Ada to the state of allowing one to change the representation of objects without changing their references. PROPOSAL for next standardization of Ada Get rid of ".all". When an access type appears, dereference it automatically. This requires some way to copy "pointers." PL/1 and Fortran 90 had the right idea: Use a different syntax for "pointer assignment." This is OK, because there are only two things you can do with pointers (in a sane language): dereference them and copy them. Both Fortran 90 and PL/1 use "a => b" to mean "change a so it points where b points" and "a = b" to mean copy the data where b points into the place where a points." The latter in Ada requires "a.all := b.all". If one has a datum, say "A: T", and one later decides it's necessary to allocate it from the free store, the type of A changes from T to "access T". That's not too bad. But all the references change from "A" to "A.ALL". That's bad. With the change I propose, one needn't touch the references -- just change the declaration, and add "A => new T;". In this case, "A" refers to the "pointer", not the data where the "pointer" points. References in any other context, except where "A" is bound as an actual argument to a formal argument of "access T" type, derefences "A". If "A" is bound as an actual argument of type "T" instead of "access T", "A" is effectively dereferenced, but the compiler may independently choose to pass "A" by value or by reference, just as it could for a non-access type. Removing ".all" breaks source code compatibility with older versions of the language, but it's not a disaster. One could write a not-very- difficult source-to-source translator that would replace "a := b" by "a => b", whenever "a" and "b" are access types, and then "a.all" by "a". Ideally, this would be an Ada program, distributed in source form, without fee. Maybe even the standard committee could require it accompany all compilers. There's more that could be done to make programs more mutable, less fragile, and more efficient, all at once. See "Not so modest proposal, 1 of 1" to be posted soon. -- What fraction of Americans believe | Van Snyder Wrestling is real and NASA is fake? | vsnyder@math.jpl.nasa.gov