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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,baa6871d466e5af9 X-Google-Attributes: gid103376,public From: Mats Weber Subject: Re: Redefinition of "=", elaboration and learning Ada Date: 1997/04/30 Message-ID: <33674E45.276E@elca-matrix.ch>#1/1 X-Deja-AN: 238434732 References: <528878564wnr@diphi.demon.co.uk> <336089AF.6046@elca-matrix.ch> <3365E879.567F@elca-matrix.ch> Organization: ELCA Matrix SA Reply-To: Mats.Weber@elca-matrix.ch Newsgroups: comp.lang.ada Date: 1997-04-30T00:00:00+00:00 List-Id: Robert A Duff wrote: > > In article <3365E879.567F@elca-matrix.ch>, > Mats Weber wrote: > >Another reason why I think we should have... no reemergence of > >predefined operations ... > > >Having predefined "=" reemerge in strange places when it's been > >redefined is also counterintuitive ... > > You talk about "=" specifically, but above you say "operators", > presumably meaning all of them. You still haven't given a complete > definition of when *all* operators should and should not "reemerge". Yes, I want the same treatment for all operators. I was just using equality as an example because it is so important. A fairly complete statement of what I would like (or would have liked) is in my thesis at I had overlooked the case statments at the time, but the general idea is still valid. > >And then try explaining to a novice programmer, without making him > >believe that the language definition is flawed, that if he makes his > >type tagged then everything will work fine :-) > > OK, but try to explain to the novice why Text_IO.Integer_IO doesn't > work, because "mod" is redefined. I find that more natural (just my opinion): if you change the arithmetic of a type, packages that use the arithmetic are naturally affected. And Text_IO.Integer_IO could very well internally convert to another type in order to get the normal arithmetic operations, if that is really required. Anyway, there are other similar situations in Ada 83: type Tiny is range 1 .. 3; generic type T is range <>; pakcage P is ... if P uses the literal 10 in its body, it will fail when instantiated with T => Tiny (and Ada 83 had no 'Base attribute to solve this). > >What the user sees when he discovers packages and private types is that > >he can define abstractions that he can use without knowing how they are > >implemented. What he sees when he discovers a library of generic > >components is that he can instantiate them and then use them. In both > >cases, he hits what is IMO a severe pitfall: reemergence breaks his > >abstraction, and he (potentially) gets Program_Error when he > >instantiates his generic. > > But having the user-defined operator used in a generic has a similar > problem. How can I write Text_IO.Integer_IO (or a similar generic)? > How do I write the code that converts an integer to a string, if I can't > get my hands on the predefined ops? You can always get your hands on the predefined ops by declaring a new type with the same (or maximal) range and type conversions. Text_IO.Integer_IO had to do this anyway because of subtype problems (excluding 0 for instance) and the lack of a usable 'base attribute in Ada 83. So it is even likely that the existing Ada 83 implementations of Text_IO.Integer_IO would work even if reemergence of predefined operations was totally removed. > I agree with you about elaboration -- the current rules are a mess. > And I mostly agree with you about "=". But I don't see how you can > sensibly extend it to other ops. Perhaps one wants to have *both* What do you mean by "other ops" ? Things like case, or things like "+", "*". For "+", "*", I would definitely take the same approach as for "=". > available -- Eiffel is sort of like that. You define something like > Basic_Compare and Compare, and then never override Basic_Compare (freeze > it). So then a client can choose one or the other. By default, they do > the same thing, but subclasses can override Compare. You can also get the predefined operations in Ada, see above.