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,a714625b3763f46e X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Modest proposal, 3 of 3 Date: 1996/11/25 Message-ID: X-Deja-AN: 198498434 references: <575aq0$t4j@netline-fddi.jpl.nasa.gov> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-11-25T00:00:00+00:00 List-Id: In article <575aq0$t4j@netline-fddi.jpl.nasa.gov>, Van Snyder wrote: >BACKGROUND >[... same stuff as in proposal 2 of 3] Did you really need to make us read all that twice? :-) >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, I think it's a good idea. The semantics of arrays and functions are different enough, that I think they deserve a different syntax. IMHO, uniform reference is a Good Thing only in cases where the semantics is closer. E.g. I think it's a Good Thing that variables and constants can be referenced using the same syntax (a simple name) in Ada, because the things you can do with contants are pretty much a subset of the things you can do with variables -- constants are just like variables, except they can't change. In the array-vs-function case, you can't say "arrays are just like functions except you can't do do-and-so". Nor can you say the reverse, "functions are just like...". Not to mention the fact that overload resolution of "F(X)" is a real pain for an Ada compiler. Consider for example: type T is array(Integer range <>) of Boolean; function F(X: Integer := 22) return T; if F(33) then -- means F(22)(33) >Minor incremental changes could bring Ada to the state of allowing one >to change the representation of objects without changing their >references. Minor? I think there are a *lot* of things that would have to change. Ada has lots of special-purpose syntaxes for things, which the programmer can't mimic. E.g., you can't define an abstract data type that is "just like" integers, except that it has an infinite range (up to available memory). You can define such a data type, but it won't have literals, range constraints, case statements, etc. It would be nice if you could define such a data type, but I don't think it would be "minor incremental changes". >PROPOSAL for next standardization of Ada > >Get rid of ".all". ... I think this case is like functions-vs-arrays -- the semantics of things vs. pointers-to-things is different enough, that I *like* having explicit syntax for dereferences. I just wish it weren't so ugly (I prefer Pascal's "^" to Ada's ".all"). In fact, Ada does allow you to leave out the ".all" in *most* cases ("X.all := Y.all" is much less common than "X.Field := Y.Field", which means "X.all.Field := Y.all.Field"). I don't think that's such a good thing. I think "X.all := Y.all" vs. "X := Y" is a perfectly reasonable way to distinguish pointer-vs-value assignment (except I'd prefer "X^ := Y^" for the former). It seems more elegant than having two different operators for ":=". Consider integer assignment. Is that value assignment? Well, usually, but if the integers are being used as array indices in the program, then they behave like pointers. You don't use a different ":=" operator to do "A := B" vs. "Table(A) := Table(B)". By the way, during the Ada 9X design, it was proposed to make ".all" optional in more cases. This was before I joined the 9X project, so I don't remember the details. I think there was some way to declare, for a given formal parameter, that ".all" was optional for corresponding actual parameters. Your proposal goes much further, if I understand -- you want to make ".all" illegal. >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. I doubt if you could write such a translator in less than about 100,000 lines of code. To do the above transformations, you have to know the type of every name and expression, which means you have to do overload resolution, which is a big chunk of code. OK, maybe 50,000 lines of code, if you're clever. Certainly not trivial. (Unless you happen to have an Ada front end lying around.) In addition, you would have to deal with cases like: type T is ...; type Ptr is access all T; procedure P(X: T); procedure P(X: Ptr); X: Ptr; ... P(X); The above is legal in Ada, but would become illegal (ambiguous) under your proposal. The above is probably fairly common in real code, too, for the same reason you mention (sort of) -- somebody wants to write "P(arg)" and not have to care whether arg is a T or a pointer-to-T. Don't say that the implicit ".all" is inserted only if needed, thus making the above legal and calling the second P. Besides being confusing and error-prone, such a rule would introduce Beaujolais effects. >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. I'm looking forward to it. This is a lot more fun than debating who has the best picture notation! - Bob