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: fac41,af40e09e753872c X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,f292779560fb8442 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,30e368bdb3310fe5 X-Google-Attributes: gid1014db,public X-Google-Thread: f8c65,30e368bdb3310fe5 X-Google-Attributes: gidf8c65,public X-Google-Thread: 103376,30e368bdb3310fe5 X-Google-Attributes: gid103376,public X-Google-Thread: 1008e3,30e368bdb3310fe5 X-Google-Attributes: gid1008e3,public X-Google-Thread: 10db24,30e368bdb3310fe5 X-Google-Attributes: gid10db24,public From: ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) Subject: Re: Hungarian notation Date: 1996/05/28 Message-ID: <4oefrh$nan@goanna.cs.rmit.EDU.AU>#1/1 X-Deja-AN: 157120977 references: <4adem2$b5s@mercury.IntNet.net> <4n6off$6e2@mikasa.iol.it> <3198F30F.2A2@zurich.ibm.com> <4nsg3f$liu@solutions.solon.com> <31a3b322.442404233@sqarc> <4o19k3$o4b@goanna.cs.rmit.EDU.AU> organization: Comp Sci, RMIT, Melbourne, Australia newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2,comp.edu,comp.lang.eiffel nntp-posting-user: ok Date: 1996-05-28T00:00:00+00:00 List-Id: >Richard O'Keefe said >"Can anyone explain to me why Ada doesn't have Alphard-style selectors >(function().all isn't quite the same thing; selectors are usefully >restricted)." dewar@cs.nyu.edu (Robert Dewar) writes: >If one took all the features that might be added to Ada and applied the >following rule: >"Any feature shall be put in, unless there is a sound technical argument > that shows that the feature is undesirable" Yes, yes, of course. Understood. Misses the point, of course. What I am trying to ask is not "why haven't selectors been _added_", but "why were they left out of the original design"? Some of the major constructs in Ada are - variables => selectors (not provided) - expressions => functions - statements => procedures - blocks => packages One of the design goals of Ada was referential transparency, and selectors are one means to that end. The claim that you can replace an array by a function, often trotted out to explain why Ada arrays use () instead of Algol/Pascal/C [] (sometimes by me!) isn't really true, because you can assign to f(x) only when f is an array. Perhaps I phrase my question infelicitously, but I do feel that Deware has given it the worst possible interpretation. What I would like to know is - here is a syntactically simple concept - which is also simple to implement (I'm putting it in a compiler for another language, which will probably never see the light of day for other reasons entirely) - which had prior art - which would have made referential transparency something more than a slogan * so was the omission of this construct accidental or deliberate (in fact, I strongly suspect "accidental") and if deliberate, does anyone know what the arguments for and against were. With Ada 95, as with other revisions, "less is more" is a compelling practical argument. No matter how desirable a feature may be (and I could name several I would like) a feature whose inclusion postpones the delivery of the standard and the provision of higher ranked features should not be included. So what else is new? >So Richard, the burden is on you to argue that this feature is vital, not >on others to argue that it is not useful. There is no such burden on me, because I wasn't _demanding_ the feature, only asking why it was left out. I think my major question is whether it was accidental or deliberate. Please remember that I am a *friend* of Ada (I think anyone who has seriously tried to use C to develop reliable programs *has* to become a friend of Ada fairly rapidly) and I am unlikely to attack it, so if you think I am attacking Ada or the people who developed it, you know you are misunderstanding me. -- Fifty years of programming language research, and we end up with C++ ??? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.