On Thu, Feb 26, 2009 at 7:25 PM, Thomas Davie wrote:

I'm not 100% certain here, so someone may correct me, but I think this is what's going on: [snip]

Yep, that's right. Is it just me or the monomorphism restriction suddenly became the hot topic here on beginners?

Another way to write it ofc would simply be uncurry (==).

Better yet, write a type signature. I highly recommend writing type signatures for *all* top-level definitions, including non-exported ones: - You avoid most cases where the monomorphism restriction would bother you. - You avoid type errors on other functions (sometimes you make a mistake but the code type checks with a wrong signature, and the type error shows up only when you use the function elsewhere). - It gives you some insights before implementing, and helps whoever reads your code. - It allows you to specialize the code when polymorphism is not needed. Probably there are other reasons as well, but these are the most prominent. -- Felipe.

Excellent list. It seems like every time I hear about a problem with the MMR, I go "wow, how come I never ran across that? oh yeah, because I write type signatures..." On Thu, Feb 26, 2009 at 5:51 PM, Felipe Lessa wrote:

On Thu, Feb 26, 2009 at 7:25 PM, Thomas Davie wrote:

...

I'm not 100% certain here, so someone may correct me, but I think this is what's going on: [snip]

Yep, that's right. Is it just me or the monomorphism restriction suddenly became the hot topic here on beginners?

...

Another way to write it ofc would simply be uncurry (==).

Better yet, write a type signature. I highly recommend writing type signatures for *all* top-level definitions, including non-exported ones:

- You avoid most cases where the monomorphism restriction would bother you.

- You avoid type errors on other functions (sometimes you make a mistake but the code type checks with a wrong signature, and the type error shows up only when you use the function elsewhere).

- It gives you some insights before implementing, and helps whoever reads your code.

- It allows you to specialize the code when polymorphism is not needed.

Probably there are other reasons as well, but these are the most prominent.

-- Felipe. _______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

The only disadvantage is that some things you might expect to be constants will actually get recomputed every time they are used. For example, suppose you define foo = very expensive computation involving a bunch of numbers You might think that foo will get computed just once, the first time it is needed. However, if foo ends up with a polymorphic type, like, say foo :: Num a => a then it is not actually a constant, but a function which takes a Num dictionary (i.e. a record of the Num methods) as an argument. So it will be recomputed every time it is used, since it might have different values for different types. Now, you might wonder why this is such a big deal. The answer is: it isn't. I have the MR automatically turned off in my .ghci file, and I've never missed it. Furthermore, the monomorphism restriction will be removed in the next version of the Haskell language standard. -Brent On Fri, Feb 27, 2009 at 08:41:36AM +0000, Matt R wrote:

On 26/02/2009, Andrew Wagner wrote:

...

Excellent list. It seems like every time I hear about a problem with the MMR, I go "wow, how come I never ran across that? oh yeah, because I write type signatures..."

Certainly. Still, it seems relatively easy to bump into it when tinkering on ghci.

Out of interest, what are the disadvantages to blanket turning off the restriction?

-- Matt _______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners