On 24-Feb-1999, Thomas Hallgren <[EMAIL PROTECTED]> wrote:
> I agree with Johns objection to the compiler warning solution, so here is
> another suggestion:
>
> The monomorphism restriction makes sure that certain values are computed
> at most once by restricting them to be used at only one type. Couldn't
> the same be achieved by
>
> * getting rid the monomorphism restriction, i.e., let all definitions
> to be overloaded by default,
> * add the language implementation requirement that overloaded values
> should be computed at most once for each instance they are used at.
Yes, it could.
> One question then is how feasible this is to implement.
It's quite feasible to implement. But not in the manner that you
were thinking of.
> But isn't this what you get in implementations that resolve overloading
> at compile time rather than by passing dictionaries at run time? Hasn't
> this been tried already (In GHC? In Hugs?) and found to be feasible?
> (The reason it might not be feasible is that you can get a code
> explosion, possibly an infinite one.)
Resolving overloading at compile time is feasible in most cases, but not
in all cases. There are some cases where you do indeed get an infinite
code explosion if you try to resolve all the overloading at compile time.
Another problem with trying to resolve all the overloading at compile
time is that this doesn't work well in combination with separate compilation.
You need seperate compilation for things like shared libraries, DLLs,
components (COM/CORBA/etc.), and so on. If you have separate compilation,
then resolving the overloading can't be done until link time, and with
dynamic linking that means run time. It can be done before main, so that
it is only done once, but that requires dynamic code generation, which
is quite non-trivial to implement efficiently.
However, it *is* possible to implement this suggestion without resolving
the overloading statically, by using memoing. This kind of implementation
would be perfectly compatible with seperate compilation. On the other hand,
memoing is itself a form of hidden overhead, albeit only O(log(size(t)))
(using tries for the memo tables), where `size(t)' is the size of the type.
For most programs, the size of types is bounded, so this will usually
be constant time.
Using memoing seemed like a pretty bizarre idea when I first thought of it,
hence the smileys in my previous post. But this idea is growing on me.
Implementations could resolve things statically where possible and
using memoing only in cases that can't easily be resolved statically.
--
Fergus Henderson <[EMAIL PROTECTED]> | "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh> | but source code lives forever"
PGP: finger [EMAIL PROTECTED] | -- leaked Microsoft memo.
