4
Defeating Return Type Polymorphism
(philipphagenlocher.de)
**The Haskell programming language community.** Daily news and info about all things Haskell related: practical stuff, theory, types, libraries, jobs, patches, releases, events and conferences and more... ### Links - Get Started with Haskell
Yes, the parsing function could return anything, but that's not the exclusive source of values of the GADT.
So, yes, when consuming the output of the parsing function, you have to deal with all the variations. But, when you have types that reflect some information is known about the type index, you only have to deal with the matching constructors.
This is particularly important given the copy-paste transport of code from one context to another. You might have some code that works for a
MyGADT MyType
and doesn't handle all the constructors. But, when you transport that code elsewhere and ask it to handle aMyGADT a
, the type system will correctly warn you that you haven't handled all the cases. This is an improvement over writing something likecase x of { Right y -> stuff y; Left{} -> error "Can't happen; won't happen"; }
, since I'm sure works fine in the right context, but doesn't have a type that reflects what the programmer knows aboutx
so if it is transported to a context where that information/assumption is no longer true, that's only discovered at runtime. (This isn't the best example, but it's what I have for you.)Well, I guess that I can see the value.. Leaving copy-pasting problem aside, you might, for instance, want to have a type for a message with moderately complex envelope and a wide variety of possible payload types. It would be useful to have functions that act on the envelope, and treat payload as something opaque.
Thanks for the conversation!