Monomorphism restriction - is this still needed for efficiency?
Hi - I'm wondering if the monomorphism restriction is now just an anachronism from Haskell 98 or if it is still needed for efficiency ie should I just now use -fno-monomorphism-restriction when compiling all my code to consign it to the dustbin of history? :-) A related question is, if it can still improve efficiency when applied to local bindings, whether it would be worthwhile to have an additional option to switch monomorphism off for top level bindings but still keep it for local bindings, since I can't think of any situation where I don't want a top level binding to be fully polymorphic. Does anyone know of any situation where a top level binding should not be fully polymorphic? Thanks, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com
Brian Hulley wrote:
I'm wondering if the monomorphism restriction is now just an anachronism from Haskell 98 or if it is still needed for efficiency ie should I just now use -fno-monomorphism-restriction when compiling all my code to consign it to the dustbin of history? :-)
A related question is, if it can still improve efficiency when applied to local bindings, whether it would be worthwhile to have an additional option to switch monomorphism off for top level bindings but still keep it for local bindings, since I can't think of any situation where I don't want a top level binding to be fully polymorphic.
Does anyone know of any situation where a top level binding should not be fully polymorphic?
The discussion on the monomorphism restriction on the haskell-prime list recently should help you: http://www.haskell.org//pipermail/haskell-prime/2006-February/000252.html I measured what happened to the nofib suite with -fno-monomorphism-restriction. The answer was, on the whole, "not much". But there were a couple of programs that got worse. It's a matter of personal taste whether you should use -fno-monomorphism-restriction, I wouldn't like to emphatically declare one way or the other which is best. Cheers, Simon
Simon Marlow wrote:
Brian Hulley wrote:
I'm wondering if the monomorphism restriction is now just an anachronism from Haskell 98 or if it is still needed for efficiency ie should I just now use -fno-monomorphism-restriction when compiling all my code to consign it to the dustbin of history? :-)
A related question is, if it can still improve efficiency when applied to local bindings, whether it would be worthwhile to have an additional option to switch monomorphism off for top level bindings but still keep it for local bindings, since I can't think of any situation where I don't want a top level binding to be fully polymorphic. Does anyone know of any situation where a top level binding should not be fully polymorphic?
The discussion on the monomorphism restriction on the haskell-prime list recently should help you:
http://www.haskell.org//pipermail/haskell-prime/2006-February/000252.html
I measured what happened to the nofib suite with -fno-monomorphism-restriction. The answer was, on the whole, "not much". But there were a couple of programs that got worse.
It's a matter of personal taste whether you should use -fno-monomorphism-restriction, I wouldn't like to emphatically declare one way or the other which is best.
Hi Simon - Thanks for the link to H' MR discussion and measurements for nofib. I don't find the MR to be a big problem - it's just that I occasionally run into it so I don't really mind writing explicit type signatures if this makes sure my code runs as fast as possible. Best regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com
participants (2)
-
Brian Hulley -
Simon Marlow