On Fri, Jun 12, 2009 at 03:00:12PM +0100, Paul Keir wrote:
> Thanks Ryan, I'm slowly becoming aware of the effects of Monomorphism. I'll
> look
> again at Neil Mitchell's blog post.
>
> I guess it's the same thing when I try:
>
> > let a = 1
> > a + 1.0
>
> I'm taking the "mono" as a clue that
On Fri, 2009-06-12 at 15:00 +0100, Paul Keir wrote:
> Thanks Ryan, I'm slowly becoming aware of the effects of Monomorphism.
> I'll look
> again at Neil Mitchell's blog post.
>
> I guess it's the same thing when I try:
>
> > let a = 1
> > a + 1.0
>
> I'm taking the "mono" as a clue that the type
Thanks Ryan, I'm slowly becoming aware of the effects of Monomorphism. I'll look
again at Neil Mitchell's blog post.
I guess it's the same thing when I try:
> let a = 1
> a + 1.0
I'm taking the "mono" as a clue that the type inferencing will complete after
each ghci carriage return; once only. I
:set -XNoMonomorphismRestriction
or eta-expand:
let op x y = x+y
The problem is that "op" looks like a value to the user, but it's a
function (based on the dictionary passed in), which means that any
evaluation it does isn't shared between instances.
Consider:
f1 = let v = fib 1 in \x -> x
Hi,
I'm finding that some data types which use Applicative to
instantiate the Num class, give responses I wasn't expecting
at the ghci prompt. A simple example is list:
import Control.Applicative
instance (Num a) => Num [a] where
as + bs = (+) <$> as <*> bs
(*) = undefined;abs = undefined
