Re: PROPOSAL: Restrict the type of (^), (^^), and add genericPower, genericPower'

On Sat, Nov 17, 2007 at 02:46:56PM -0800, David Benbennick wrote:

I thought of two more reasons I'm against this proposal:

2) It isn't backwards compatible. It will cause some existing Haskell code to not compile.

That is true, and is why I checked all the bootlibs and corelibs in my original message. I don't believe many programs/libraries will be affected, but I'm willing to be proven wrong! (The fix is trivial anyway, of course. The only annoying bit is checking that you weren't relying on any cases being defaulted to Integer, but you should be able to check for that easily by compiling with -fwarn-type-defaults).

3) It makes things more difficult in GHCI. Under this proposal, you'd have the following:

Prelude> let x = 2 Prelude> 6 ^ x <interactive>: Couldn't match expected type `Int' against inferred type `Integer'

This is true, just as you currently get: Prelude> let x = 2 Prelude> take x [1..] <interactive>:1:5: Couldn't match expected type `Int' against inferred type `Integer' and likewise for (!!) etc. I hadn't really noticed that the default defaulting conflicts with the use of Int in the standard functions in this way. I guess in ghci is the only time it comes up, though.

On 11/17/07, Henning Thielemann wrote:

...

Let me guess - you don't use -Wall. :-) Warnings are not the problem, warnings point to a problem. The problem here is, that the compiler has to guess a type, because it cannot be infered from other operands.

I don't see how that's a problem. Have you ever had a case where defaulting to Integer produced the wrong behavior?

Unintentional defaulting can mean significant performance loss. If you leave intentional defaulting in the code then you will get warnings when you compile with -Wall, and if you always get warnings when you compile then you just ignore all warnings. This means that warnings don't help you to find bugs in your code. Thanks Ian