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