Re: Eiffel and Java

[jsa@alexandria (Jon S Anthony)]

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