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

[Henning Thielemann]

On Sat, 17 Nov 2007, Cale Gibbard wrote:

> On 17/11/2007, Ian Lynagh <igloo at earth.li> wrote:
> >
> > Hi all,
> >
> > This got a warm reception when I mentioned it in
> >     http://www.haskell.org/pipermail/haskell-cafe/2007-June/027557.html
> > so I'm formally proposing it now. It's trac #1902:
> >     http://hackage.haskell.org/trac/ghc/ticket/1902
> >
> > Note that this is a divergence from Haskell 98 (but the libraries
> > already have a handful of small divergences, and Haskell' is just around
> > the corner...).
> >
> > In my opinion, (^) has the wrong type. Just as we have, for example,
> >     (!!)         ::                 [a] -> Int -> a
> >     genericIndex :: (Integral b) => [a] -> b   -> a
> > we should also have
> >     (^)          :: (Num a)             => a -> Int -> a
> >     genericPower :: (Num a, Integral b) => a -> b   -> a
> > (or some other function name). The same goes for (^^) (genericPower').
> >
> > In my experience this would remove 99.9% of all defaulting (mostly where
> > you write things like x^12 and 8^12), which means it's easier to get
> > -Wall clean without having to put :: Int annotations everywhere.
> >
> > The impact to GHC's bootlibs and extralibs is minimal. In most cases we
> > have things like 2^15, where Int is clearly fine, although it happens to
> > be defaulted to Integer currently. In Data.Complex we have 2 cases of
> > e^(2::Int) which can now be beautified. There are several cases where
> > the type is inferred to be Int anyway.
> >
> > There are 3 files where we really do have an Integer, and it does
> > matter. They are all for parsing numbers of the form 18e43, in
> > base/Text/Read/Lex.hs, parsec/Text/ParserCombinators/Parsec/Token.hs and
> > haskell-src/Language/Haskell/Lexer.hs.
> >
> > Initial deadline: 1 Dec 2007.
> >
> >
> > Thanks
> > Ian
>
> This is a move in the opposite direction from what I'd really like to
> see. The Int type is usually a premature optimisation,

Accepted, but then I prefer fixed type 'Integer' as exponent and some
guarantee, that powers with small constant exponents are converted to
products by the optimizer.