Talk:Haskell/GADT

About Example: Trouble with GADTs
We can define SafeList in the following manner, without such troubles:

data Empty data NonEmpty

data SafeList :: * -> * -> * where Nil :: SafeList x Empty Cons :: x -> SafeList x y -> SafeList x z

safeHead :: SafeList x NonEmpty -> x safeHead (Cons x _) = x

-- bad typed as before --bad = safeHead Nil

-- OK silly 0 = Nil silly 1 = Cons 1 Nil


 * Nice. Thanks. Can you please update the page with some discussion? -- Kowey 15:07, 2 July 2007 (UTC)


 * That doesn't buy you much, though: safeHead (silly 1) still fails.

About Example: Existential Types
The bits about TE2/TG2 talk about "heterogenous lists", but that's inaccurate. Each TE2/TG2 instance contains a homogeneous list of b's (the existentially-quantified type). Of course, each instance may use a different b. (Paul Steckler)

Poorly written, but gets the point across
I think somebody made this point about this (stub) article on #haskell. Criticism gratefully received! Any takers? For what it's worth, I always found the examples used explaining GADT to be a little hard to understand (it took quite a while for them to really sink in). Some nice new examples would be useful. Also Ganesh's talk in LondonHUG seems to do a pretty good job explaining GADTs. Worth borrowing some ideas from him -- Kowey (talk) 09:13, 25 February 2008 (UTC)


 * I had some time and digged up examples:
 * Ganesh's talk in LondonHUG GADTs for patches.
 * SPJ - type inference for GADTs (rewritten version of the wobbly paper). Features the standard expression evaluator example.
 * LtU - Prototyping new monads Term implementation for the state monad.
 * Hinze - Fun with Phantom Types Strongly typed . (It's possible to do that without GADTs, though). Generic programming (= representing types as values).
 * This wikibook: safe lists.
 * Fixed size vectors/matrices. Other invariants like AVL or red-black trees.
 * So, most examples emphasize safety, but I think the one that does not is the most compelling one. Its basic message is: with GADTs, pretty much every abstract data type has a term-implementation, that can be used to cook up its implementation. That's enough to warrant GADTs in the language and makes a good starting point for the wikibook. Unfortunately, it's the state monad, which may create unwanted associations in the reader's mind... I wonder whether there is a different example without troubling ballast.
 * Btw, I think the word "safety" should be replaced by "more precise types" or "more fine-grained types" or something; just a feeling.
 * -- apfe&lambda;mus 17:25, 25 February 2008 (UTC)
 * More example goodness:
 * LtU - How are GADTs useful in practical programming?. Meta-resource.
 * Augustsson,Petersson - Silly Type Families Parser combinators as GADTs, they're not monadic. The intention is to automatically left-factor easy grammars, you need an (G)ADT for that. But I think that these combinators can be recast as applicative functors, eliminating the need for  which forces the extension to GADTs. Not sure whether left-factoring is still feasible then, though. If it ever was...
 * Yampa GADTs enable optimizations by cutting down dynamic checks, or so I hear.
 * Contracts for functional programming. An embedded DSL for dynamically checking constraints ("contracts"), i.e. more invariants but dynamically checked. GADTs make the implementation easy / make it possible at all.
 * -- apfe&lambda;mus 21:14, 6 March 2008 (UTC)

Comments
I watched the first few minutes of the video mentioned on apfeλmus's blog. I generally like the text medium much better than video. Video works better if it shows a person giving a lecture, there are animated demonstrations, that sort of thing. The video did have a few examples that appeared in handwriting that were helpful, but I think they could be integrated into the text. About the content itself, what's here is reasonably good, but it could use expansion. I found the assertion "GADT's are mostly useful for EDSL's" to be surprising, though EDSL's are a good example. Darcs uses GADT's in an interesting way, to track complicated invariants of patches. GADT's are considered by some to be a gateway drug to dependent types, so I'd be interested to see how they can be used for nontrivial code verification. I'd also like to see an example of using an existential wrapper to introduce GADT-typed values from external data. I've fooled around with code like that, but have never understood the idea well enough to do anything interesting with it. 75.57.243.88 (talk) 21:48, 2 June 2010 (UTC)


 * Thanks for your comment! :-)
 * I take it that you didn't like the video format because of the pace? The great advantage of text is indeed that the reader can choose the pace and can also glance at the overall structure.
 * Since the video is only an introduction, I didn't include material on dependent types. That would be a second video / text. ;-)
 * -- apfe&lambda;mus 19:38, 3 June 2010 (UTC)


 * Yes, I guess it's mostly that the video and text have about the same content, but with text it's much easier to adjust reading speed depending on difficulty of the passage, go over a section again, that sort of thing. The video is like having the text read out loud, which is not that useful.  Maybe it departs more from the text further in--I might watch the rest of it sometime just to see if it makes a difference.  Video is useful for informal presentations where you're speaking somewhat off the cuff, and that's less work than preparing a complete text.  But if you're writing the text anyway, the video doesn't gain much.  Video can also be useful at the other extreme, where you have elaborate productions of moving images, but that's even more work.  If you're serious about adding some dependent type material, that would be great, I'm looking forward to seeing it.  75.57.243.88 (talk) 09:49, 6 June 2010 (UTC)


 * The text here is pretty much a transcription of what I said off the cuff in the video. Well, or what I was still saying in the sixth take. :-) Pleasantly, this meant that the text didn't take much work to prepare.
 * Curiously, some things don't work so well in text, like discussing code "incrementally", i.e. writing it, underlining parts that they don't type check, rewriting the type signature, that sort of thing. That's what's happening in the subsection "Extending the language", but it just doesn't have the same look and feel as in the video.
 * Anyway, I'm preparing another video experiment, stay tuned. ;-)
 * -- apfe&lambda;mus 08:26, 7 June 2010 (UTC)

Relationship to other features
The article notes briefly that GADTs subsume existential types, but it also subsumes (at least partly) functional dependencies, doesn't it? This is nice information to have for e.g. me, who are familiar with the old ways, and want to learn how GADTs fit in. Ketil (talk) 14:07, 5 July 2010 (UTC)


 * GADTs don't subsume functional dependencies.
 * -- apfe&lambda;mus 07:15, 6 July 2010 (UTC)

A simple alternative to GADT is ignored
The following simple solution without GADT seems to be silently ignored: define

and use smart constructors. Am i missing something? --Alexey Muranov (discuss • contribs) 21:04, 14 April 2018 (UTC)


 * While that would work, not having to rely on smart constructors is part of the point. The general idea is that, instead of carefully weaving a set of combinators that preserve the invariants and pruning your interface so that nothing else is exported, you can encode the invariants in the type, making them impossible to break from the start. (By the way, as the constructors in the GADT type here won't break the invariants, they can be safely exported and used for pattern matching.) --Duplode (discuss • contribs) 04:51, 19 April 2018 (UTC)


 * In my opinion, this solution (and an explanation why GADT are supposed to be better) should better be included. --Alexey Muranov (discuss • contribs) 12:48, 19 April 2018 (UTC)


 * Indeed, it would be good to make such motivations more explicit. The whole chapter, in fact, could do with some reworking. --Duplode (discuss • contribs) 01:37, 20 April 2018 (UTC)