🚀 go-pugleaf

Dan.Pop@mail.cern.ch (Dan Pop) wrote:
>>"Yes, but the conversion does exist at the language definition level.
>>The language specifies that in these cases conversions have to be
>>performed and describes exactly how.

>>says Dan ...
>>what language? 
>
>Any language supporting binary arithmetic operators between operands of
>different types that I know of.
>

Aha, so this is what people want to use overloading for.  Now suppose
we invented a syntax that allowed programmer to describe such conversions
much the way lang. definition does:

   procedure sum( m : matrix ) : real
    begin .. end

   procedure sum( v : vector becomes vecToMat(v) )

   infix function '+' ( x,y:complex ) : complex
     begin .. end

   infix function '+' ( x:comlex; y:real becomes comp(y,0) ) : complex

This gets rid of need for full-blown operator overloading, and clarifies
that it really is the same task being performed, with a safe type
conversion that actually appears in the interface definition.

Now I think if you also have manifest arrays (or even lists) to cope
with the arb. length parameter problem, then 99% cases of desire
for overloading will disappear.  Whoops I forgot.  Lots
of people want to overload function names 'cos they can't be bothered
to invent clear description of task.  

Of course C++ programmers want to overload function names because
the language designer decided that all creation and destruction
functions in a class should have the same name.  What a stroke of
genius.