Re: Eiffel and Java + Ada dispatching

[donh@syd.csa.com.au (Don Harrison)]

Robert I. Eachus writes:

:   Okay... (This code is for demonstration purposes only...these
:features are useful, but not often used with predefined types or small
:generics.)
:
:   generic
:     with function "+"(L, R: Integer) return Integer is <>;
:   procedure Test(X,Y: in Integer);
:   
:   
:   with Text_IO;
:   procedure Test(X,Y: in Integer) is 
:   begin
:     Text_IO.Put_Line(" The sum of" & Integer'IMAGE(X) & " and" &
:               Integer'IMAGE(Y) & " is" & Integer'IMAGE(X+Y) & ".");
:   end Test;
:
:   with Test;
:   procedure Main is
:     procedure Test1 is new Test;
:
:     function "+"(L,R: Integer) return Integer
:     is begin return L*R; end "+";
:
:     procedure Test2 is new Test;
:   
:  begin 
:    Test1(5, 10);
:    Test2(5, 10);
:  end Main;
:
:spectre% main
: The sum of 5 and 10 is 15.
: The sum of 5 and 10 is 50.

Thanks for the example.

:     Notice that a much more normal situation would have the two
:instantiations in non-overlapping scopes, and the operator definitions
:coming from a package which defined some generic formal type.
:
:     What this is showing is not that it is possible to maliciously
:mess with definition of "+", 

Okay, we'll try to ignore that. :)

but that the fact that parameter matching
:for generic formal subprogram parameters uses overloading rules is
:significant.  It is a very useful feature to be able to instantiate a
:generic in a scope and inherit the local statically enclosing
:definitions of certain operations.  It is even more useful that the
:operations are selected based on the name of the function AND the
:parameter and return value profile.  You not only get the local
:operator, you get the right version to match the other generic
:formals.

Okay but the problem I have with this is that picking up the local stuff 
implicitly as parameters to the instantiation is potentially confusing
(as your example demonstrates). What would be clearer and less confusing, 
IMO, would be to declare the parametric information in a type together with 
the operation so that when you instantiate (explicitly) with that type 
(or a descendant type), you get the right operation with it. This way, it's 
very plain what the actual instantiation parameters are.

Not sure how you would write this in Ada. Maybe (excuse the syntax errors)

   type Some_Type is tagged ...
   function Some_Op (...) return Some_Type;

   generic
     type T is private;
   procedure Generic_Op (...);

   ...

   procedure Actual_Op is new Generic_Op (Some_Type);

The implicit resolution stuff is not a good idea, IMHO.

:     (Note that to get the local definitions of predefined operators
:for types, generic formal and otherwise, you need to explicitly
:declare those operators as generic formal subprograms.  But the at the
:point of the instantiation, defaults allow the user to ignore these
:"extra" formal parameters.)

Understand.

:     Now what does all this have to do with the no overloading model?
:There are programs which take advantage of these rules that can be
:rewritten--but not trivially--to work in the absence of overloading.
:And the non-overloading version will be exponentially larger than the
:version which uses overloading and generics.

If the non-overloading versions are exponentially larger, maybe the originals 
were a bit dodgy anyway. :)

:     The case of generics with formal tagged type parameters is even
:more complex.  (The ARG is trying to decide just how much more
:complex. ;-)

Sounds like a headache. :)

IMHO, overloading should have no semantic impact. It should merely be 
'syntactic sugar' as Jean-Marc suggested.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au