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 <[EMAIL PROTECTED]> 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 > <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe