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,953e1a6689d791f6
X-Google-Attributes: gidfac41,public
X-Google-Thread: 109fba,953e1a6689d791f6
X-Google-Attributes: gid109fba,public
X-Google-Thread: 103376,953e1a6689d791f6
X-Google-Attributes: gid103376,public
From: jhd@herold.franken.de (Joachim Durchholz)
Subject: Re: Eiffel and Java
Date: 1996/10/31
Message-ID: <6Jw2qT9k3RB@herold.franken.de>#1/1
X-Deja-AN: 193701071
references: <mheaney-ya023180002810962151220001@news.ni.net>
newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c++
Date: 1996-10-31T00:00:00+00:00
List-Id: <comp.lang.ada>


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
because there are two possible interpretations:
  (INT +(1) INT) +(3) LONGINT
and
  (INT +(2) INT) +(4) LONGINT

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.

Solution (a) would make it possible to break existing code by adding  
innocently-looking functions.

Solution (b) is much, much worse. It is not only harder to read  
potentially ambiguous code because you need to know more rules to  
interpret it (and disambiguating rules tend to contain arbitraryness which  
makes remembering the correct rules even harder).
It also introduces subtle changes in semantics - when a new function like  
(3) is introduced, routine calls all over the rest of the system might  
dispatch to the new function, and without an obvious hint to the  
programmer. (You can't even use a string-search tool to find all affected  
calls, because the "+" function is heavily overloaded.)

I'd like to hear wether this is a real problem in Ada or wether I'm seeing  
ghosts here.

Regards,
-Joachim

--
Looking for a new job. Resume available on request. WWW version of resume
available under http://www.franken.de/users/herold/jhd/resume/index.html