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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
