On Feb 15, 2014, at 2:38 PM, Alexander Batischev wrote:

Hi,

Alejandro Gomez already posted an answer that should be enough for you to figure out the solution by yourself, but I decided to post mine anyway, in case you have trouble understanding how to proceed.

Yes, thank you. I really appreciate both of you taking the time to respond to my question, but that’s exactly the problem I was having. I had broken down and inspected the type signature of the subsections of my “lower” function. Each subsection on its own seemed fine, but what was confusing me was the type signature for the whole thing. And I wasn’t sure how to fix it. I really appreciate you walking me through the process. Beforehand, I kind of guessed that I probably needed to use fromIntegral somewhere, but I wasn’t sure where, and even if I got lucky and guessed, I don’t think I would have understood why.

After the composition you have a function with the following type:

λ: :t (ceiling . sqrt) (ceiling . sqrt) :: (Floating b, Integral c, RealFrac b) => b -> c

It accepts Float or Double (which both belong to Floating and RealFrac typeclasses) and returns Int or Integer.

But you want to feed it an Int! Unlike many other languages, Haskell never casts (converts) types unless you order to do so.

Again, thank you for this very helpful explanation of the problem, and I understand that Haskell doesn’t cast types automatically. In fact I was relying on that as I built up my function. What I guess really confused me was that this worked: Prelude> filter (\y -> mod 36 y == 0) [2..(ceiling . sqrt) 36] [2,3,4,6] while this didn’t. Prelude> let lower x = filter (\y -> mod x y == 0) [2..(ceiling . sqrt) x] Prelude> lower 36 Since the former worked, I really expected the latter to work as well.

:t 36 36 :: Num a => a

I am still slightly confused about the type that I passed into the function. If the type of 36 is Numeric, that doesn’t seem to necessarily tell me that it is an Int. Float and Double are listed under Numeric in the chart (https://www.haskell.org/onlinereport/classes.gif). This seems like a really stupid question, but how do I know that I can’t pass a Numeric into a function like sqrt that is expecting a Float? ghci> :t sqrt sqrt :: Floating a => a -> a And again, why does it work in the former case when it’s not a function, but not in the latter as a function? If there is no casting going on, it seems like it should fail every single time. Why does it work at all?

As you can see, you've got a function that accepts any instance of Integral typeclass, i.e. Int and Integer types. Precisely what was required.

Hope that makes sense.

Yes, thank you. I do think I have a better understanding now. Best regards, James

Hi, On Sat, Feb 15, 2014 at 03:52:25PM -0600, James Toll wrote:

What I guess really confused me was that this worked:

Prelude> filter (\y -> mod 36 y == 0) [2..(ceiling . sqrt) 36] [2,3,4,6]

while this didn’t.

Prelude> let lower x = filter (\y -> mod x y == 0) [2..(ceiling . sqrt) x] Prelude> lower 36

Since the former worked, I really expected the latter to work as well.

Because in the first case, you have 36 in two places, and they have different types. In the second case, though, both numbers are replaced by `x`, that has one type. Something should have just clicked in your brain, and every piece fell in place, but if not, read on. In my previous email, I showed you what constraints a composition of ceiling and sqrt places on `x`: λ: :t (ceiling . sqrt) (ceiling . sqrt) :: (Floating b, Integral c, RealFrac b) => b -> c From here, you can see that `x` is only constrained by typeclasses Floating and RealFrac. But `lower` has one more constraint, Integral: λ: :t lower lower :: (Floating b, Integral b, RealFrac b) => b -> [b] Why is that? Because you do `mod`: λ: :t mod mod :: Integral a => a -> a -> a When you filter the list, `x` gets constrained by the Integral typeclass, which leads to the situation you observe - too many constraints, typechecker can't pick a type to satisfy them all. And what do we do? We help the compiler using `fromIntegral`, thus removing the Floating and RealFrac constraints from `x` (they're now placed on a result of `fromIntegral`).

...

:t 36 36 :: Num a => a

I am still slightly confused about the type that I passed into the function. If the type of 36 is Numeric, that doesn’t seem to necessarily tell me that it is an Int. Float and Double are listed under Numeric in the chart (https://www.haskell.org/onlinereport/classes.gif).

It's incorrect to say that "the type of 36 is Numeric", but I guess it's just bad wording - you get the idea right, 36 isn't necessary Int. There's a thing called "type defaulting". It's a set of rules that GHC follows in order to pick a type for a thing whose type is not specified, like 36. (Note that GHCi has slightly different, more relaxed rules.) So when you run `filter`, GHCi has to pick some type for the results, and it settles for Integer. But type defaulting doesn't kick in until the very last moment. Up until binding the result, it stays as polimorphic as possible: λ: :t 36 36 :: Num a => a The moment you bind the result, though, it gets concrete type: λ: let x = 36 λ: :t x x :: Integer

This seems like a really stupid question, but how do I know that I can’t pass a Numeric into a function like sqrt that is expecting a Float?

ghci> :t sqrt sqrt :: Floating a => a -> a

I don't know how well you understand typeclasses, so pardon me if I explain something you already know. The thing is, each typeclass adds some new restrictions (functions to implement) that narrow the choice of possible instances of that typeclass. Almost every type instantiates Eq, but only four standard ones instantiate Num. Furthermore, only two standard types instantiate Floating. That's why you can't pass every Num instance into sqrt - not every one of them implements all the necessary methods. Is that clear enough? -- Regards, Alexander Batischev PGP key 356961A20C8BFD03 Fingerprint: CE6C 4307 9348 58E3 FD94 A00F 3569 61A2 0C8B FD03

On Sat, Feb 15, 2014 at 06:00:14PM -0500, Brent Yorgey wrote:

It has nothing to do with binding, actually. The above is just due to the monomorphism restriction. If you turn it off (highly recommended!):

I stand corrected. Been thinking about it, actually, but somehow managed to miss it when tried things out in GHCi. Thanks! -- Regards, Alexander Batischev

On Sat, Feb 15, 2014 at 05:11:39PM -0600, James Toll wrote:

On Feb 15, 2014, at 4:53 PM, Alexander Batischev wrote:

...

Something should have just clicked in your brain, and every piece fell in place, but if not, read on.

Yes, the light bulb has gone on. Thanks to you and Brent. I really appreciate both of your explanations to my follow-up question. It’s almost a bit difficult to keep up with responding while reading your excellent and very helpful responses. I do think I now understand what was going on in this particular instance and why I was tricking myself. It always seems so simple in hindsight. I’m sure this won’t be the last time I get tripped up on this though. But I’m hopeful I can better reason it out going forward.

Thanks again for all the extremely helpful responses.

Glad to be of help! For what it's worth, the whole numeric-types-and-type-classes thing is definitely one of the trickiest corners of Haskell, at least when starting out. I remember spending a good deal of time struggling through it at first too. -Brent