:set +t :set +t GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
Prelude> :?
...
Options for ':set' and ':unset':
+t print type after evaluation
Of course it isn't necessary at all. $ ghci
GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> 5
5
Prelude> :t it
it :: Integer
Try it at home. GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :t 5
5 :: (Num t) => t
This is the sort "practicality" issue. Care to enlighten on the rules about when `(Num t) => t` resolves to `Integer`?In the type query `:t 5`, ghci doesn't have to decide or resolve anything, it gives all the possibilities, `5: Num a => a`. But if it is to evaluate the expression it needs you or it to make decisions. You can see this pretty clearly in the following:
Prelude> :t 5
5 :: (Num t) => t
Prelude> 5
5
Prelude> :t it
it :: Integer
Prelude> 5 :: Float
5.0
Prelude> :m + Data.Ratio
Prelude Data.Ratio> 5 :: Rational
5 % 1
Prelude Data.Ratio> :t it
it :: Rational
In the first case, it decided, in the other two, I decided what type I meant.I'm not sure I grasp everything about this, but in your example, `p [1,2,3,4,5]` ghci couldn't make its natural assumption - i.e. the one you in fact think should be it's natural assumption -- since no Monoid (in your sense) instance had been declared for its preferred case, Integer, so it backed off and demanded clarification.
You had unconsciously over-ruled the defaults you wanted. As has been pointed out, if you had realized that Integer is the name for Haskell's integer type, and Int a dirty approximation like Float, and had used it, everything would have gone as you claim to have wanted. In fact you get everything you want if you just add these lines to your module:
instance Monoid Integer
where
addId = 0
add = (+)
keeping all of the other Int stuff intact. Then in ghci can use its defaults -- the defaults you want -- and you get: Ok, modules loaded: Main.
*Main> p [1,2,3,4,5]
(5x^4 + 4x^3 + 3x^2 + 2x + 1)
*Main> :t it
it :: UnivariatePolynomial Integer
Though of course the unevaluated expression is given a more general type: *Main> :t p [1,2,3,4,5]
p [1,2,3,4,5] :: (Num t, Monoid t) =>
UnivariatePolynomial t
-- and rightly, since this very module permits an Int interpretation of the expression. In a case that goes against its defaults, I have to tell it that that's how I want the complex functional expression to be understood, before I ask for evaluation: *Main> p [1,2,3,4,5] :: UnivariatePolynomial Int
(5x^4 + 4x^3 + 3x^2 + 2x + 1)
*Main> :t it
it :: UnivariatePolynomial Int
It is the same if you add another Monoid instance for the non-default reading of "1", e.g. instance Monoid Float
where
addId = 0
add = (+)
This can exist side by side with the others. Then you get: *Main> p [1,2,3,4,5] :: UnivariatePolynomial Float
(5.0x^4 + 4.0x^3 + 3.0x^2 + 2.0x + 1.0)
*Main> :t it
it :: UnivariatePolynomial Float
Note that even with three Monoid instances in play in the module, we still get what you wanted: *Main> p [1,2,3,4,5]
(5x^4 + 4x^3 + 3x^2 + 2x + 1)
*Main> :t it
it :: UnivariatePolynomial Integerhttp://www.haskell.org/onlinereport/decls.html#sect4.3.4
In my opinion, though it wasn't me you asked, it's an ugly workaround for Haskell's lack of proper coercion rules.
ghci -XOverloadedStrings
Prelude> :m +Data.Text
Prelude Data.Text> "cargo cult"
"cargo cult"
Prelude Data.Text> :t it
it :: String
Prelude Data.Text> "cargo cult" :: Text
"cargo cult"
Prelude Data.Text> :t it
it :: Text
It defaults to String. What's wrong with this exactly? A general coercion, understood as something different from a function (pack, unpack), would have to coerce between two types of wildly different structures. One is a list type [Char] that you can map over and into from any kind of list you like - and the user is forever employing this fact - the other is totally different.It is different from other systems, but doesn't that just mean you have to learn something different, which is of course annoying until it becomes second nature. There doesn't seem to be any legitimate technical objection here, or am I wrong?
I wonder who is that we you refer to. Is applicative a Bourbaki-style pseudonym for a group of aspiring Haskell hackers?
I never said it is bad, it looks like a useful and convenient mechanism. My complaint is about its non-genericity. Indeed, it is limited to numeric literals only; even to reuse it for string literals, you need a compiler extension.
A general coercion, understood as something different from a function (pack, unpack), would have to coerce between two types of wildly different structures.
By general coercion, I mean implicit conversion not limited to numeric literals (or string literals, with an extension) only.
Numeric and string literals are all that were ever under discussion. `OverloadedStrings` is a language extension, not a compiler extension; it is a candidate for inclusion in later specifications, not in the new Haskell 2010. The Ghc supports it with a language pragma. That it, and the associated IsString class, didn't exist in Haskell 98, the previous specification, is obviously due to the fact that there was not widespread use of types like ByteString and Text for handling text; if there had been it would have been, surely; the idea is pretty straightforward.