Dear all, Johannes Waldmann wrote:

So, what about making type signatures mandatory, as the rest of the civilized world does happily for decades ...

Given that explicit type signatures increasingly are required for dealing with other aspects (polymorphic recursion, rank 2-or-higher polymorphism, GADTs ...) that would seem reasonable. Personally, though, I have to admit that I've never had all that much problems with the M-R restriction in the first place. Probably because I do write top-level type signatures as soon as I get into serious programming. That said, I do find it convenient that type signatures can be omitted. And I wonder if this is a sufficiently significant problem to warrant breaking backwards compatibility in this respect. All the best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

On Thu, 26 Jan 2006, Johannes Waldmann wrote:

If this seems impossible, then the function itself probably *is* complex, and its type would give valuable information, and I don't see what a programmer (or a reader) benefits from a language that allows to omit this information.

For one, because that makes it possible to load it into an interpreter and be told the type. -- flippa@flippac.org A problem that's all in your head is still a problem. Brain damage is but one form of mind damage.

On 1/28/06, Cale Gibbard wrote:

Do you have an example of such a program handy?

b = (x, x) where { x :: Num a => a; x = fromInteger 1 } fromInteger is called twice. -- Taral "Computer science is no more about computers than astronomy is about telescopes." -- Edsger Dijkstra

Remove the type signature for b and you will see the loss of sharing. It mostly hurts people like John Hughes that don't have the energy to put in type signatures. ;) 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. :) -- Lennart Cale Gibbard wrote:

On 28/01/06, Taral wrote:

...

On 1/28/06, Cale Gibbard wrote:

...

Do you have an example of such a program handy?

b = (x, x) where { x :: Num a => a; x = fromInteger 1 }

fromInteger is called twice.

--- mr.hs --- {-# OPTIONS_GHC -fno-monomorphism-restriction #-}

import Debug.Trace

b :: Num a => (a,a) b = (x,x) where x :: Num a => a x = (trace "x" . fromInteger) 1

main = print b ------------ cale@zaphod[~]$ ghci -fno-monomorphism-restriction mr.hs Loading package base-1.0 ... linking ... done. Compiling Main ( mr.hs, interpreted ) Ok, modules loaded: Main. *Main> :t b b :: (Num a) => (a, a) *Main> b (x 1,1) ------------ cale@zaphod[~]$ ghc -fno-monomorphism-restriction -o mr mr.hs && ./mr x (1,1) -----------

If x isn't being shared, then Debug.Trace at least seems incapable of resolving that fact.

Let's try profiling:

--- mr.hs, revised ----- {-# OPTIONS_GHC -fno-monomorphism-restriction #-}

b :: Num a => (a,a) b = (x,x) where x :: Num a => a x = {-# SCC "x" #-} fromInteger 1

main = print b -------------- cale@zaphod[~]$ ghc -fno-monomorphism-restriction -prof -auto-all -o mr mr.hs && ./mr +RTS -p (1,1) cale@zaphod[~]$ cat mr.prof Sat Jan 28 18:21 2006 Time and Allocation Profiling Report (Final)

mr +RTS -p -RTS

total time = 0.00 secs (0 ticks @ 20 ms) total alloc = 17,972 bytes (excludes profiling overheads)

COST CENTRE MODULE %time %alloc

CAF GHC.Handle 0.0 48.2 CAF System.IO 0.0 1.4 CAF Main 0.0 50.3

individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc

MAIN MAIN 1 0 0.0 0.0 0.0 100.0 CAF Main 150 6 0.0 50.3 0.0 50.5 b Main 157 1 0.0 0.1 0.0 0.2 x Main 158 1 0.0 0.1 0.0 0.1 main Main 156 1 0.0 0.0 0.0 0.0 CAF System.IO 105 1 0.0 1.4 0.0 1.4 CAF GHC.Handle 103 3 0.0 48.2 0.0 48.2

-------

One entry to x. So where is this lack of sharing I keep hearing about? Even if I repeat these tests with -fno-cse, the results are the same.

- Cale _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime

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

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

Jacques Carette wrote:

Personally I think that this ought to be resolved by static means -- and yes, by the linker, as it can't be done properly earlier.

But there are cases that cannot be resolved statically. On the other hand, they are probably rare enough to ignore. -- Lennart

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. Philippa Cowderoy wrote:

On Sun, 29 Jan 2006, Lennart Augustsson wrote:

...

Jacques Carette wrote:

...

Personally I think that this ought to be resolved by static means -- and yes, by the linker, as it can't be done properly earlier.

But there are cases that cannot be resolved statically. On the other hand, they are probably rare enough to ignore.

Or to flag up a compiler and/or linker warning for those who request them?

Lennart Augustsson wrote:

Jacques Carette wrote:

...

Personally I think that this ought to be resolved by static means -- and yes, by the linker, as it can't be done properly earlier.

But there are cases that cannot be resolved statically. On the other hand, they are probably rare enough to ignore. There will always be some things that are impossible to do statically - but we should still strive to do as many as possible, even if we are forced to be incomplete about it. As long as the cases that can't be done are relatively easy to define and occur rarely, that seems like a good compromise to me.

Jacques