>  >
>  > I fear that your share proposal will not interact well with separate compiling of
>  > modules:
>  > how can the list of all share definition be completely know to the compiler ?

It is not the case if you consider that two modules sharing the same
symbol 
should declare it with the same type and then you merge the list of
possible values. Some value may be hiden by other, but this is already
the case for usual module field.

> Well, I can't remember offhand how SMJ/NJ handles overloading, but it
> seems to work reasonably well.  On the other hand, I am nowadays a
> convert to ocaml's hard line on overloading---it's an absolute curse
> of many, many C++ programs by coders whose enthusiasm outruns their
> judgement.

I agree with you that one should not abuse overloading. The problem of
C++
is that you can even overload operator such as = ! I would live happy if
there was a finite, fixed and short lists of overloadable operator (In
fact  arithmetic operators are the most needed).

The pb is that if you use twice the same functors declaring + (which is 
unavoidable if you do formal calculus). You can never have access to
both symbols with their short names. So sharing/overloading
is really needed as soon as you use and reuse functors in complex ways.

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI