The dreaded M-R

Yes, you can do something to regain sharing. That's what I meant
by having some clever runtime machinery. But it's rather complex
for what the problem at hand is.
-- Lennart
Cale Gibbard wrote:
> Aha, okay. Yeah, I can reproduce that now, and it makes good sense
> what's going on. It is in fact quite sensible that x be evaluated
> twice with that sort of polymorphism.
>> Hmm... however, could we not assign to each instance a unique
> identifier which could be compared? Say a cryptographic hash of the
> source code for the instance? (Which of course would never be exposed
> to the user.) That should be enough to tell them apart. The
> translation would then partition the work according to the incoming
> instances, and share all computation possible.
>> - Cale
>> On 28/01/06, Lennart Augustsson <lennart at augustsson.net> wrote:
>>>Oh, I guess I did one more change. I put b in a separate module.
>>>>Your type signature isn't the most general, the most general is
>>b :: (Num a, Num b) => (a, b)
>>And that is the source of the problem. You need to pass two
>>dictionaries. To keep sharing you'd need some very clever
>>runtime machinery to find that the dictionaries are the same.
>>>> -- Lennart
>>>>Cale Gibbard wrote:
>>>>>On 28/01/06, Lennart Augustsson <lennart at augustsson.net> wrote:
>>>>>>>>>>Remove the type signature for b and you will see the
>>>>loss of sharing.
>>>>>>>>>Nope, still not seeing it with either profiling or Debug.Trace. Also
>>>-- the type signature I gave was polymorphic, so what's the deal? If
>>>adding a polymorphic type signature fixes the problem, and a
>>>polymorphic type signature can be inferred, why not simply treat the
>>>source as if one had been written there?
>>>>>>>>>>>>>It mostly hurts people like John Hughes that don't
>>>>have the energy to put in type signatures. ;)
>>>>>>>>>Well, sure. I don't think that we should see exponential blowup in
>>>complexity of some programs by leaving out type signatures (though if
>>>it was only in sufficiently rare cases, I could put up with it).
>>>>>>>>>>>>>On the subject of type signatures, I don't want to
>>>>make them mandatory, but I think they should be strongly
>>>>encouraged. I don't buy the argument that they make
>>>>refactoring programs that much harder. It's still
>>>>very easy to do, the type checker will tell you exactly
>>>>where. :)
>>>>>>>>>Me too. It's nice to be able to write quick programs where you leave
>>>out the type signatures, but including them is always good for real
>>>code. I also think that type signatures (and the type system in
>>>general), makes it much easier to refactor code and work on code with
>>>which you're unfamiliar.
>>>>>> - Cale
>>>>>>>>