The dreaded M-R

[Lennart Augustsson]

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
>>>
>>
>>
>