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,4961da398a273222 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-02-10 09:07:31 PST Path: nntp.gmd.de!newsserver.jvnc.net!nntpserver.pppl.gov!princeton!gw1.att.com!csn!ub!news.kei.com!news.mathworks.com!uunet!pipex!uknet!hrc63!gmrc.gecm.com!valiant!bill From: bill@valiant (R.A.L Williams) Newsgroups: comp.lang.ada Subject: Ada self-referential operators Date: 10 Feb 1995 17:07:31 GMT Organization: GEC-Marconi Research Centre Message-ID: <3hg6gj$mkt@miranda.gmrc.gecm.com> NNTP-Posting-Host: valiant.gmrc.gecm.com X-Newsreader: TIN [version 1.2 PL1] Date: 1995-02-10T17:07:31+00:00 List-Id: In article <3grqrf$jkd@gnat.cs.nyu.edu> Robert Dewar wrote: : A couple of things Bill, first you would like to see := be overloaded, but : this is notoriously difficult to define cleanly, and people's first naive : thoughts quickly founder on very tricky semantic rocks. C++ seems to manage. Does Eiffel? I can't offhand remember. OK, in Ada I can see that ":=" may have some implicit semantics not present with other operators. For example, I believe constraint checking is expected at this stage of the execution of a statement and not before. In C++ this would be approached by inheriting from some base operator. Optimisation is obviously another problem. Optimisation is just not possible if the compiler doesn't understand the semantics of the operators. After all, I could define something wierd like procedure ":="(lhs : out Integer; rhs : in Integer) is begin if rhs = 2 then lhs := 5; else lhs := 6; end if; end; Obviously, any compiler which tried to optimise a basic block containing that would be in for a nasty surprise! So, OK, we disable statement level optimisation where overloaded assignment is used. Caveat emptor (I don't know the latin for programmer) -- if you use this construct, don't expect optimisation. : As I assume you know, Ada 95 does allow for the effect of user defined : assignment, but not via providing a definition for the := "operator", : which of course is not an operator at all. My knowledge of Ada 95 is currently rudimentary, but improving. I did a lot of Ada 83 code some years ago. I wasn't aware of 'User Defined Assignment and Finalisation' (RM 7.6) until you pointed it out. I assume from the LRM that to make use of this facility I need to derive the types I want to perform 'adjustment' etc. on from 'Controlled'. Well, OK, with this model for assignment I can see that overlaoding ":=" is going to be inelegant. In fact, the equivalent that Ada 95 provides *is* inelegant (IMO :-) Effectively, Ada 95 imposes a 'tree' view of inheritance, and rules out the possibilty of a 'forest' if user defined init/final/adj is needed. This is because, as I understand it, all classes (sorry, object speak) must be inherited from Controlled or, presumably, Limited_Controlled. Probably not a problem, but the sort of minor irritation that we could do without. BTW, I don't understand your assertion that ':= [...] of course not an operator'. Perhaps not in Ada 95, with the semantics of package Ada.Finalization behind it, but the assignment operator is as good an operator as any other to my way of thinking. Can you explain your reasoning here? : Labor saving devices are indeed a good idea, PROVIDING that they save : labour in the right places. In particular, I regard labor saving devices : for code writers to be pretty unimportant. The only thing that is important : is the ease of code reading, and it is CERTAINLY not the case that anything : that makes code more compact makes it easier to read (if that were true, : then as Bob Eachus points out, everyone would program everything in APL!) Yes, but... (moderation in all things! Ada, sometimes makes us go to unnecessary lengths to do trivial operations; eg. bit shift in Ada 83 implemented with arrays of 1 bit variables! Let's face it, in a language promulgated specifically for *embedded* applications, this was nonsense!) : It is not that I think :+= is peculiar because it is not in the RM, rather : +:= is not in the RM because it is peculiar, i.e. it would be VERY difficult : to put it in without running into nasty semantic ramifications. I'm sorry, I still don't see that. The trouble is that we still disagree on the status of ":=" I think. If 'procedure ":=" (....)' were acceptable, and I still don't understand why not, then I can't see anything wrong with 'procedure ":+="(...)' (although I think that "+=" looks nicer). : I don't know how skilled you are as a language designer. Often it is : frustrating to plain users of the language that something that seems : like it should be simple to do is not there, when it seems so simple : to put it in. I have designed a language and led the team writing a compiler for a specialist event driven application. Not a great deal of experience, and not at all like Ada, but I have spent some time thinking about the implementation of such features in C++. I still don't see where the problem is. [delete] : Indeed it was very nearly the case that Ada 95 ended up with no user : defined assignment, since we couldn't find a way to do it. Then quite : late in the process someone suggested the current approach, and that : turned out to be tricky but practical, so it was put in. I would be interested in seeing a discussion about these design decisions. Some years ago I read the book "Engineering a Compiler" by some engineers at Digital. Fascinating stuff, but I haven't seen much similar discussion by language designers. I remain to be convinced, but I have an open mind (honest). Thanks for your comments. Bill Williams