[Haskell-cafe] What I wish someone had told me...

[Claus Reinke]

> I'm not advocating existential types in this case.  I rarely use them myself.
> I was just pointing out that the mechanism for doing the OO thing
> exists in Haskell too, albeit looking a little different.
>
> I don't think there's anything weird about existential types, except
> an unfamiliar name.

Perhaps, it helps to make Lennart's point about composable building
blocks made more explicit (simplifying slightly):

- a function 'f :: a -> IO a' has to accept any type 'a', so it can't know
    anything about those 'a's

- a function 'f :: Interface a => a -> IO a' only has to accept types 'a'
    that *at least* implement 'Interface', so there's a *lower bound* on the
    information required about those 'a's, and 'f' can't use any more than
    that (but since 'a' is exposed to 'f's calling context, it might be fixed there)

- a constructor of type '(forall a . Interface a => a) -> SomeType' can only
    be applied to objects of type 'a' that *at least* implement 'Interface',
    but if 'SomeType' doesn't mention 'a', the result *at most* implements
    'Interface' and 'a' itself gets hidden, so there's an *upper bound* on
    the information being provided

The reference that comes to mind

    On understanding types, data abstraction, and polymorphism.
    Luca Cardelli and Peter Wegner.
    ©1985  Computing Surveys, 17(4):471-522, 1985.
    http://lucacardelli.name/Bibliography.htm

predates Haskell, so any 'splodin' heads can't be blamed on Haskell!-)

I wouldn't expose beginning programmers to this level of detail about
types, but if you're going to talk about interfaces and types at all, and
about type classes in particular, to programmers who are beginning
their switch to Haskell, it can't hurt them much to read it. It might
even help, and if not, it is at least a concrete basis for more Haskell
specific explanations when they start running into those questions.

Claus

> On Wed, Oct 15, 2008 at 1:15 AM, John Lato <jwlato at gmail.com> wrote:
>> Are you advocating introducing existential types to beginning
>> Haskellers?  I think something with the scary name "existential
>> quantification" would greatly increase the head'splodin' on the
>> learnin' slope.  Certainly there's a place for them, but I wouldn't
>> want to see new Haskell programmers habitually approach problems with
>> a "first create a type class, then make an existential wrapper"
>> mentality.  Which is exactly what I fear is the current situation.
>>
>> Although my list example is far to shallow to make this point, it
>> seems to me that it's fairly likely that somebody faced with this
>> problem has had something go severely wrong at some earlier time.
>>
>> Existentials are certainly useful, but isn't it also possible that,
>> for many cases, an alternative design exists which fits a functional
>> idiom better and doesn't face this issue at all?
>>
>> John
>>
>> On Tue, Oct 14, 2008 at 5:03 PM, Lennart Augustsson
>> <lennart at augustsson.net> wrote:
>>> You can do equivalent of
>>> // List and MyList are different classes
>>> if (something) { return new List(); }
>>> else { return new MyList(); }
>>> in Haskell as well.  But to do that you have to introduce an
>>> existential wrapper in the return type.
>>> In OO languages the existential wrapper is built in to OO constructs,
>>> but in Haskell you have smaller building blocks that you have to
>>> assemble to make the thing you want.
>>>
>>> So to extend your example, you can do
>>> data IList = forall a . (Foldable a, Indexable a) => IList a
>>> getListOfData :: IO IList
>>> and now you can return different kinds of types from getListOfData
>>> depending on circumstances.
>>>
>>>  -- Lennart
>>>
>>> On Tue, Oct 14, 2008 at 1:11 PM, John Lato <jwlato at gmail.com> wrote:
>>>> I was just thinking about what I wish someone had told me when I
>>>> started working with Haskell (not that long ago).  It would have saved
>>>> me a great deal of trouble.
>>>>
>>>> The Difference Between Interfaces and Type Classes.
>>>>
>>>> Many "Introduction to Haskell for the OOper" style tutorials claim
>>>> that type classes are like Interfaces (for languages with that
>>>> feature).  I now think that, although this is technically true, it's
>>>> fundamentally misleading.  Here's a simple example demonstrating my
>>>> line of thought:
>>>>
>>>> In C# (and presumably Java), this sort of function is common:
>>>> public IList GetListOfData()
>>>>
>>>> In Haskell, a similar function may be
>>>> GetListOfData :: (Foldable a, Indexable a) => IO a
>>>>
>>>> In C#, it doesn't matter what the actual type returned by
>>>> GetListOfData is, as long is it supports the IList interface.  It's
>>>> not uncommon for GetListOfData to make a choice between several
>>>> different implementations, depending on the nature of the data to be
>>>> returned.  The following code is perfectly reasonable in C# :
>>>>
>>>> // List and MyList are different classes
>>>> if (something) { return new List(); }
>>>> else { return new MyList(); }
>>>>
>>>> The equivalent won't compile in Haskell, because the actual return
>>>> type does matter, and *is determined by the calling code*.  Our
>>>> fictional GetListOfData can't return a List or a Mylist depending on
>>>> some conditional, in fact it can't explicitly return either one at
>>>> all, because the actual type of the result, as determined by the
>>>> caller, could be either one, or something else entirely (ignoring the
>>>> IO bit for the time being).
>>>>
>>>> So I've come to the conclusion that stating type classes are like
>>>> interfaces is misleading to newcomers to Haskell, because it leads
>>>> people to think they should use type classes for the same sorts of
>>>> problems OO-languages solve with interfaces.  In turn this means new
>>>> programmers are encouraged to use OO-style architecture in programs,
>>>> reassured that they're in a "functional" idiom because they're using
>>>> the "functionally-approved" feature of type classes.  I think that if
>>>> I had understood this earlier, I would have embraced functional idioms
>>>> more quickly.
>>>>
>>>> Incidentally, I'm still horrible at designing functional APIs and
>>>> modules, but at least now I know it, and I'm no longer trying to force
>>>> OO interfaces into Haskell.  So I've made progress.
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>>
>>>
>>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe