| However, I would guess that changing the type signature of | the current showInt function is unacceptable for Haskell'98. | Maybe we should consider adding the more general version | under a new name like showIntBase, together with | show{Dec,Oct,Hex}? This would break no existing code, and | clear up the slight anomaly in the current capability of the | Haskell'98 library. Hmm. This is another unforced change, but admittedly to the libraries, which have received much less attention and in some cases (like this) look more accidental than deliberate. So I've been using a lower "bar" for modifications to the Libraries than to the Report. As you say, we can't change the type of showInt. I suppose we could add: showIntAtBase :: Integral a => a -- base -> (a -> Char) -- digit to char -> a -- number to show. -> ShowS showOct, showHex :: Integral a => a -> ShowS Q1: But would we really want showDec too? Identical to existing showInt? I am disinclined to use K-F's extra generality for H98, nice though it is. Too different from readInt. Also, GHC's NumExts has doubleToFloat :: Double -> Float floatToDouble :: Float -> Double Q2: If we are going to run round adding functions to Numeric, should we add those too? It's hard to know where to stop... but if that conversion is what you want to do, H98 doesn't give a good way to do it. Simon
As you say, we can't change the type of showInt. I suppose we could add:
showIntAtBase :: Integral a=20 =3D> a -- base -> (a -> Char) -- digit to char -> a -- number to show. -> ShowS
showOct, showHex :: Integral a =3D> a -> ShowS
Q1: But would we really want showDec too? Identical to existing showInt?
I only suggested it for consistency of naming. However, since showInt is not the dual of readInt, we can't have consistency anyway. Regards, Malcolm
Also, GHC's NumExts has
doubleToFloat :: Double -> Float floatToDouble :: Float -> Double
Q2: If we are going to run round adding functions to Numeric, should we add those too? It's hard to know where to stop... but if that conversion is what you want to do, H98 doesn't give a good way to do it.
Haskell already has fromRealFrac which does the same job (ignoring NaNs, -0, etc.). AFAIK, the only reason you'd use these shortcuts is if you're using a compiler that can't optimize fromRealFrac (i.e., you're not using HBC or GHC) or exploring the limits of Haskell's support for IEEE arithmetic. My feeling is that this is something of an unforced change. Adding functions can break code (though the fix is easy) so, whilst I agree that the bar is lower for libraries and for adding functions, I think we should still exercise some restraint. This is especially true since it's not clear that this is the right thing to do (since we have fromRealFrac already) and it is hard to remove features once you've added them. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
participants (3)
-
Alastair David Reid -
Malcolm Wallace -
Simon Peyton-Jones