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: 109fba,953e1a6689d791f6 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,953e1a6689d791f6 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,953e1a6689d791f6 X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Eiffel and Java Date: 1996/11/02 Message-ID: #1/1 X-Deja-AN: 193861955 sender: news@organon.com (news) references: organization: Organon Motives, Inc. newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c++ Date: 1996-11-02T00:00:00+00:00 List-Id: In article <6Jw2qT9k3RB@herold.franken.de> jhd@herold.franken.de (Joachim Durchholz) writes: > jsa@alexandria wrote 30.10.96: > > > 3) the function notation allows Ada to dispatch based on the _result_ of > > parameter which is a function call. Or has the function dispatch to > > the right thing based on the other parameters. Bob Duff gave a couple > > of nice examples of this: > > Actually, I see this as a *flaw* in Ada. > > Yes, it allows one to play some neat and useful tricks with dispatching. > > But it also allows totally ambiguous expressions. Example: > Let's have fictitious types INT and LONGINT, with the obvious operator > definitions > INT + INT -> INT (1) > INT + INT -> LONGINT (2) > INT + LONGINT -> LONGINT (3) > LONGINT + INT -> LONGINT (4) > LONGINT + LONGINT -> LONGINT (5) > However, this is ambiguous in an expression like > (INT + INT) + LONGINT No problem. Because this is an operation of specific types and so is statically checked and bound at compile time. And here, give that all the operations would be visible, the Ada compiler would catch this and flag it as an ambigous expression (note it is _statically_ flagged). Note that this has absolutely nothing to do with dispatching on a result and hence is basically irrelevant to the context. It is simply ordinary normal overloading resolution. > because there are two possible interpretations: > (INT +(1) INT) +(3) LONGINT > and > (INT +(2) INT) +(4) LONGINT Which will be called to your attention. > I'm not sure how Ada handles such cases. Solution (a) might be a compiler > error as soon as the compiler detects potentially ambiguous operator (or > function) declarations, solution (b) might be disambiguating rules. Modified Solution (a): Only if at the point of _USE_ the expression is not resolvable is there a problem and it will be flagged at compile time. The definitions may well be in totally separate name spaces, defined at different times, etc. and so should not be flagged as ambiguous (the signatures are all quite distinct). > Solution (a) would make it possible to break existing code by adding > innocently-looking functions. Only if you play fast and loose with polluting your name space. Which is why the use of "use" is so frowned upon in many circles. > Solution (b) is much, much worse. It is not only harder to read Solution (b) is not relevant, :-) > I'd like to hear wether this is a real problem in Ada or wether I'm seeing > ghosts here. You're seeing ghosts. The problem you mention with (a) _is_ possible if you write (what would universally be considered in Ada practice) horrible code. But even there, it would only happen if you were to 1) Go back and change existing code (it won't happen if you are _extending_ the code). AND 2) Willy nilly pollute the name space of the code. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com