generic functions

[Francois-Rene Rideau]

   Generic functions are just *more expressive* than single-dispatch functions.
You need exponentially more single-dispatch code to express a generic function
than the generic fucntion has arguments, while the converse is trivial.
   Single-dispatch is some example of "false gain" in language design: you
believe you have something simpler, but actually, it makes everything much
more complex, and you end up with people "going around" your code rather than
using it. For instance, if you have a generic function of type A->B->C,
it is only a very narrow and low-level view to consider it as some A-member,
some B-member or some C-constructor.
   Why choose any particular view ? Especially when no single argument is
priviledged. Let's just make it a generic function ! As for "generic method",
that's just the same as a generic function, except that the semantics is
heavier because some argument was arbitrarily priviledged (see below).
   As for implementation, hash tables for multiple arguments are as good as
hash table for single argument when a function only uses single-argument
dispatch, and do allow multiple argument dispatch. Anyway, partial evaluation
allows early dispatch, so such thing does not have a lot of efficiency impact,
whereas expressivity and simplicity of semantics gains a lot in generic
functions.

   I think that the "single dispatch" paradigm is a particular case of
getting mixed up between object and meta-object (aka taking the word for the
meaning). Yes, objects and meta-objects are different concepts, and
a function does not lie in the object, but the meta-object.
   I disagree when you (Rainer) say:
"generic functions are the opposite of location specific [modular]."
Of course you can have modules, but you don't get mixed up between the
module meta-object, and objects constructible thanks to the module !
The object is in the module, not the module in the object. It is not
the generic function that is a poison for modularity, but the lack of
recursive scoping for functions in lame languages like C++.
   Of course, in first-order languages, such confusion is needed to achieve
any usable object packaging, but in better languages, this should be banned.
The meta-object (aka context) should be well distinguished from objects.
A context -- sorry, Rainer, I can't grab the nuances of german -- is an
meta-object that expresses the meaning of an object, that binds constructors
from which objects are made into another, more directly observable space.
There are many kinds of contexts, depending on the meta-contexts involved,
etc. So the execution context is a context for low-level objects, whereas
the lexical scope is a context for lexical analysis, etc.

   I must say I agree with most of what Patrick said lately on the list.
I'll just add, as for execution policy, that programmable execution policies
is one of the goals of the Migration subproject...

   Now, as for message passing, I also think this faddy paradigm is too much
used where it shouldn't, and being imposed as an unadapted way to see how
things happen in a low-level way: sure, message passing is a great model for
objects whose state evolve asynchronuously while exchanging data. But trying
to model everything using it is dull, especially since lambda-calculus and
suches allow much neater specification for simple and/or stateless
computations.
   So as for associating a "selector" to a "value", this can be called
a function as well as an object.

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"

exit 1000




------>8------>8------>8------>8------>8------>8------>8------>8------>8------
------>8------>8------>8------>8------>8------>8------>8------>8------>8------
------>8------>8------>8------>8------>8------>8------>8------>8------>8------
elm -s '
'  <<'END'