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

[Lennart Augustsson]

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.

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
>>>
>>
>