Question

I’m having a terrible time trying to hook up functions at runtime (which I have to do) which might involve type class constraints in the inputs and outputs of the function.

In a language like Java, this would be trivial. f1 :: Int -> Num, f2 :: Num -> Num We can now call f2 . f1. If Num was a Java-style interface, that would work no problem. But type classes don’t behave like interfaces.

One thing a type class allows you to do is avoid converting between data types. We could just convert back and forth all over and get rid of type classes. But the concern is then we’re creating objects all over for no reason. Let’s try to avoid that.

I started out trying to create a tuple of (a, Api a) where Api is a record of functions that will operate on a. My guess is that’s probably very similar to how type classes work? But then you run into concrete type issue and I thought existentials. But then I realized that (a, Api a) should be able to hide the a completely since noone cares, and then the Api turns into a plain record of data types, not functions.

And so I’m left to wonder… is it laziness that solves this?

module Main where

--data Api a = Api { f1 :: a -> Int, f2 :: a -> String }
data Api = Api { f1 :: Int, f2 :: String }

data MyData = MyData Int String

myf1 (MyData x y) = x
myf2 (MyData x y) = y
myApi x = Api (myf1 x) (myf2 x)

from :: Int -> Api
from x = myApi $ MyData x "string"

to :: Api -> String
to api = f2 api

main = print $ to . from $ 5

So, is it smart enough (or could be) to realize that it doesn’t need to create an Api value at all since all we need is the call into myf2 on the MyData value?

So the “equivalent” of a Java interface is not a type class as someone once told me, but rather it’s a record or data type? And that laziness provides the “lightweightness” of the interface?

Answer 1

But then I realized that (a, Api a) should be able to hide the a completely since noone cares, and then the Api turns into a plain record of data types, not functions.

Exactly! Using an existential like that when a plain data-type would do is called the existential typeclass antipattern (see also the FAQ). It’s not directly related to laziness, however; you could just as easily represent every field as () -> Result in a strict language. Of course, it wouldn’t be nearly as nice to use.

The advantage of a type-class is in the implicit, type-directed resolution: you can just use operations directly, as if they were monomorphic on the specific types you’re using, and it works fine, without having to come up with a separate name for every type you want to implement an operation for. For an example of why type-classes are valuable, imagine if Num was implemented as a record; you’d have to pass around the implementation record for each type everywhere. Worse, there’s no place to put fromInteger :: (Num a) => Integer -> a, since it’s polymorphic in the result, and doesn’t take any value of type a at all!

Another example is something like Ord. You can’t represent Ord as a record, because any instance of Ord has to operate on the very values that are eliminated by this type-class-to-record transformation. Having Ord as a type-class also lets us write code that is generic on any type of value that can be ordered, which is very valuable indeed, and in this respect the use of type-classes certainly resembles OOP interfaces to some degree.

However, when there’s no real relevant values to speak of, or they all come from “outside” just to act as internal state (like an existential), a type-class just adds unnecessary boilerplate and is much less “first-class”. Functions and data-types are the real units of abstraction in Haskell; type-classes are just convenience.

So, is it smart enough (or could be) to realize that it doesn’t need to create an Api value at all since all we need is the call into myf2 on the MyData value?

GHC probably will create the intermediate data type, but you shouldn’t worry too much; an existential also carries around the type-class instance dictionary, which is just like your Api type. The advantage of this record interface isn’t really performance, but simplicity, clarity and composability (it’s easy to transform all the fields of a record to produce a “modified” implementation — but you can’t have a function that transforms a type-class instance).