[Haskell-cafe] Typeclasses question in "Real World Haskell" book

[Daniel Fischer]

On Monday 26 July 2010 21:03:10, Angel de Vicente wrote:
> Hi,
>
> thanks for the answer. This is my first attempt at Typeclasses, and I
> think there is something "deep" that I don't understand...
>
> On 26/07/10 15:03, Daniel Fischer wrote:
> >> class JSON a where
> >>       toJValue :: a ->  JValue
> >>       fromJValue :: JValue ->  Either JSONError a
> >>
> >> instance JSON JValue where
> >>       toJValue = id
> >>       fromJValue = Right
> >>
> >> instance JSON Bool where
> >>       toJValue = JBool
> >>       fromJValue (JBool b) = Right b
> >>       fromJValue _ = Left "not a JSON boolean"
> >>
> >>
> >> I don't understand how the JSON typeclass is defined, in particular
> >> the fromJValue definition.
> >
> > Given a JValue and a type
> > (like Bool, JValue, String, Maybe [(Integer, ())]), fromJValue returns
> > either
>
> a JValue and a type???
>

Apparently not the best way to express it.

The function fromJValue has the type

fromJValue :: JSON a => JValue -> Either JSONError a

Read that as "for any type a being an instance of the JSON class, 
fromJValue can convert¹ a JValue to the type Either JSONError a".

For different types a, fromJValue does different things if applied to the 
same JValue, more precisely, different fromJValue functions are called.
Which version of fromJValue is called depends on the type the type variable 
a is instantiated to at the call site. (So, in some sense, fromJValue also 
takes a type as an argument.)

Perhaps looking at things in a more homely setting helps.
Consider the Enum class and the function

toEnum :: Enum a => Int -> a

What happens if you enter `toEnum 5' at the prompt?
In hugs:

Hugs> toEnum 5
ERROR - Unresolved overloading
*** Type       : Enum a => a
*** Expression : toEnum 5

you get an error, hugs complains that it doesn't know which type to choose 
for the result. And how could it, there are many types to choose from. If 
you tell hugs which type to choose, be it by an explicit type signature or 
by some calling context, it works:

Hugs> toEnum 5 :: Char
'\ENQ'
Hugs> [toEnum 42, 'k']
"*k"
Hugs> :set +t
Hugs> [toEnum 12, 42]
[12,42] :: [Integer]      -- Why Integer? ²
Hugs> [toEnum 12, 42] :: [Rational]
[12 % 1,42 % 1] :: [Rational]

¹ Actually, it doesn't 'convert' the value, rather it constructs a new 
value based on the provided one, but saying 'convert' is less cumbersome.

² [toEnum 12, 42] can have type [a] for every type a that belongs to the 
two classes Enum and Num, illustrated by the example with an explicit 
signature. hugs must choose one or it would have to throw an unresolved 
overloading error as above.
The Haskell report (in section 4.3.4) specifies that under certain 
circumstances ambiguous types [like (Enum a, Num a) => a] are defaulted.
The defaulting rules say that in this case, the ambiguous type is defaulted 
to Integer - and that's why I've used hugs here, and not ghci, because ghci 
uses extended defaulting rules and does something different:

Prelude> toEnum 5
*** Exception: Prelude.Enum.().toEnum: bad argument
Prelude> toEnum 0
()

as you can see, ghci chooses the unit type () as the default here [the 
other expressions work as in hugs] and doesn't complain about an ambiguous 
type variable as in the fromJValue example.

> >> For instance, when defining the instance for Bool types, then I
> >> understand that both functions (toJValue and fromJValue) will be
> >> called upon when we supply a Bool type, but then the (JBool b) type
> >> in function fromJValue doesn't match....
> >
> > fromJValue always takes a JValue as argument. That JValue can be a
> > wrapped String, a wrapped Bool, a wrapped number (Double), ...
>
> so, fromJValue takes a JValue and a type, or only a JValue?

On the source code level, it takes only a JValue, but it needs some context 
to resolve which instance to choose. There, functions can only take values 
as arguments, not types.
On a lower implementation level, it is possible that overloaded functions 
[type class methods] take explicit type arguments, but let the compiler 
writers worry about such details :)

> I was assuming the second,

On the implementation level, in GHC, it takes a dictionary and a JValue as 
arguments, but again, that's a low-level detail you shouldn't care about.
On the Haskell code level, your assumption is correct.

> but then my misunderstanding kicks in, I guess.
> I'll try to explain myself. When defining
>
> class JSON a [...], then I thought that for an instance I would have to
> identify the type of that instance and that all functions would work on
> that type. Thus, when defining
>
> instan JSON Bool [...] I was expecting that all the function definitions
> would have as argument a Bool.

No, Bool may also appear in the result type of the functions and not in the 
argument type(s). Return ing to the Enum class, that contains

toEnum :: Enum a => Int -> a
fromEnum :: Enum a => a -> Int

in the former, the instance type is the result type of the function, in the 
latter it's the argument type.
In the JSON class, we have

toJValue :: JSON a => a -> JValue

where it's the argument type, and

fromJValue :: JSON a => JValue -> Either JSONError a

where it's a parameter of the result type.

> toJValue is no problem there, but I don't
> see the fromJValue definition, since this matches against either (JBool
> b) or _ , but not a Bool...
>
> Another misunderstading on my side: if I call fromJValue (JBool True),
> which instance ofr fromJValue should be used: instance JSON JValue or
> instance JSON Bool.

That depends on the context in which (fromJValue (JBool True)) is called.
If the context determines that the type of that expression is 
(Either JSONError Bool), the (instance JSON Bool) is used; if it determines 
the type is (Either JSONError JValue), the (instance JSON JValue) is used.
If it doesn't determine the type of the expression, as in

print (fromJValue (JBool True))

, it's a compile-time error (ambiguous type variable/unresoled 
overloading), since no defaulting takes place for the JSON class.

> If we only look at the signature of the fromJValue
> functions, then both could match?
>

Yes, both match (and potentially many others), so instance selection must 
be driven by other factors. If the expression is e.g. a subexpression of

list = [fromJValue (JBool True), Right JNull]

the context determines the instance. 
Since both expressions belong to the same list, they must have the same 
type t.
fromJValues type says t = Either JSONError a for some a (we don't know yet 
which, and it can be any type belonging to the JSON class).
The type of (Right JNull) is Either b JValue, where b can be any type 
whatsoever, thus we find t = Either b JValue.
Putting both together, we find t = Either JSONError JValue, whence
list = [Right (JBool True), Right JNull].

If the context in which the expression occurs doesn't determine its type 
(and the defaulting rules don't fix it), you must help the compiler by an 
explicit type annotation.

> >> *Main>  fromJValue False
> >>
> >> <interactive>:1:11:
> >>       Couldn't match expected type `JValue' against inferred type
> >> `Bool' In the first argument of `fromJValue', namely `False'
> >>       In the expression: fromJValue False
> >>       In the definition of `it': it = fromJValue False
> >
> > That one should be pretty clear, fromJValue expects a JValue as
> > argument and gets a Bool, it's like calling
>
> Yes, but I guess you see why I try this given my misunderstanding above?
>
> >> *Main>  fromJValue (JBool False)
> >>
> >> <interactive>:1:0:
> >>       Ambiguous type variable `a' in the constraint:
> >>         `JSON a' arising from a use of `fromJValue' at
> >> <interactive>:1:0-23 Probable fix: add a type signature that fixes
> >> these type variable(s) *Main>
> >
> > That's less easy.
> > The compiler/interpreter doesn't know which result type to use.
> >
> > fromJValue :: JSON a =>  JValue ->  Either JSONError a
> >
> > with which type should a be instantiated, should it use
> > - JValue, in which case the result would be
> > Right (JBool False)
> >
> > - Bool, in which case the result would be
> > Right False
> >
> > - String, in which case the result woulde be something like
> >      No instance for (JValue [Char])
> >        arising from a use of `fromJValue' at ...
> >
> > (unless you have such an instance in scope, then it would be something
> > like Left "not a JSON string")
> >
> > - Int, in which case you'd get analogous behaviour
> > - ...
> >
> >> Any pointers?
> >
> > In an actual programme, there is usually enough context to fix the
> > type variable a, then the compiler/interpreter knows what to do.
> > At the prompt or when there isn't enough context otherwise, you need
> > to explicitly tell the compiler/interpreter which type to use,
> >
> > *Main>  fromJValue (JBool False) :: Either JSONError Bool
> > Right False
> > *Main>  fromJValue (JBool False) :: Either JSONError JValue
> > Right (JBool False)
>
> Ah... OK, I think with these two examples the whole thing starts to make
> sense.
>
> When defining
>
> instance JSON Bool
>
> then this doesn't mean that the functions need to work just on Bool's,
> but rather that wherever there is an "a" in the typeclass definition,
> then this should be instantiated to a Bool, correct?
>

Yes.

>
>
> And now that we are at it... In the next page, 152 there is the
> following instance definition, but no explanation is (I think) given of
> what it means:
>
> instance (JSON a) => JSON [a] where
>
> until then all instance definitions where of the type
>
> instance JSON Int where ...
>
> How should I read that definition?

As a first approximation, read it as

"for all types a which are instances of JSON, the type [a] is also an 
instance of JSON, with the following methods ..."

However, instance resolution in GHC is done without taking the context 
(JSON a) into account, so for GHC it reads more like

"I will view all list types as instances of the JSON class, but if you try 
to use the class instance for a list type where the element type is not an 
instance of JSON, the programme will not compile. Nor will it compile if 
you try to define another instance of JSON for any list type [e.g. String] 
- at least, if you don't turn on some language extension(s)."

That is the cause of many puzzlements and problems.

>
> Thanks for you help,
> Ángel de Vicente