The dreaded M-R

[Cale Gibbard]

On 29/01/06, Lennart Augustsson <lennart at augustsson.net> wrote:
> Hmmm, maybe a warning is the best solution in general.
> Even without trying any link time resolution.
>
> Given how hard Cale had to work to reproduce it, I think
> it's a rare problem.  Maybe someone who knows the innards
> of ghc could make a quick hack that turns on the M-R and
> warns when there's actually sharing being lost.
>

Yeah, this is a good idea, I wonder how often this actually comes up.
I'd had trouble reproducing it since I accidentally gave 'b' a type
signature which wasn't sufficiently polymorphic to make the problem
occur.

Inside a module, optimisation to determine if sharing was needed is
surely possible. Having the compiler produce specialised code to
handle cases which recover sharing from inside a single module seems
practical enough to do.

Across module boundaries, if whole-program optimisation can't be
applied to restore sharing somehow, you'd need extra runtime support -
and you're right, that does seem like it may be a little heavy. How I
see it, it would basically amount to a polymorphic value becoming a
lookup in a memo map from instances at which it's been computed to
(weak pointers to?) final values, together with a fall-through to the
code which uses the dictionary to compute the value, and then inserts
a new entry into the map before returning normally.

Whether all that's really worth it, we should probably look into. How
many ordinary programs do we have sitting around that run into this
sharing problem?

Anyway, I see mandating the MR as somewhat ugly, while including it as
a possible compiler optimisation seems okay. Since a smart enough
compiler/runtime could make sure that the problems the MR solves are
nonexistent anyway, do we really want to include it in the standard?

 - Cale