Re: Multiple dispatch

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Wed, 15 Jun 2011 12:30:43 +0200, Natasha Kerensikova  
<lithiumcat@gmail.com> a écrit:
> This makes the dispatch table completely isotropic and allows to
> implement any element of the matrix in any compilation unit (as long as
> it is linked (statically or dynamically) to the final binary). I found
> this feature very nice when the "glue" between the row type and the
> column type does not obviously belong to either type
This is a common source of design ambiguity, and that's one of the reason  
why I've posted this topic. It's a long time (multiple years) I have this  
question in mind. Each time, I encounter difficulties to do a choice.

A common and simple example, while not related to dispatching, is stream  
operations : although its clear a input/ouput method must have two  
arguments, one for the stream and one for the data, how do you decide the  
operation belongs to the package defining the type or to the package  
defining the stream. This one is not the worst, as you would say : if the  
type is primitive enough, it will belongs to the stream package, and if  
the type is complex, it will belong to the package defining the complex  
type. Reasonable enough ?

Not the worst, but expose an example of this common question : does this  
method should belong to this or that type/package ?

Finally the question about multiple dispatch ends to be similar.

> I know other high-level languages do have introspection mechanisms, but
> I haven't seen anything like that in Ada. Have I missed them?
I guess this would disallow many kind of binary code optimization. If one  
need introspection, the he/she have to explicitly implement it.  
Introspection comes as more natural to interpreted language than to  
compiled language. Or else, may be you are thinking about compilers aware  
of introspection as they actually are of dispatching ? This would require  
to mark some type as requiring introspection, like you mark some type as  
tagged and defined dispatching operation on that type.

But I also feel to guess introspection is more suited to interpreted  
language for another reason than the one that is comes more natural with  
the implementation of interpreted language : self modifying program. Why  
would you need introspection if that is not to apply some alteration to  
what your are inspecting ? If this is not to alter the program itself  
(which is clearly a thing for interpreted language only), then that would  
probably be for debugging purpose then; and debugging can be done without  
introspection (while this can be done with introspection, as I my-self did  
when one day I modified an Eiffel compiler that way… the compiler was  
generating code which allowed introspection when the compile-for-debug  
flag was On).

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
“c++; /* this makes c bigger but returns the old value */” [Anonymous]