BTW, if any HN readers have good practical examples of GADT I'd love to hear them. The article does a fine job of explaining the advantages GADT give but real world examples would greatly complement that.
Also, has anyone ever used gadts to implement type safe syntax trees like that? Last time I implemented a little programming language I used regular ADTs and had a separate type-checking pass to verify that everything is all right. I don't know how hard it would be to write a gadt version of my ast and if it would be worth the trouble.
1) Type Question models questions that the game might ask of players. Its constructors are tagged with the type of the answer to that question:
data Question a where
AskKeepHand :: Question Bool
AskTarget :: [EntityRef] -> Question EntityRef
...
This allows me to write cards that ask questions and later on plug in various interpreters of these questions (command line interface, JSON webserver, AI, test framework).
2) The ZoneRef datatype enumerates the various zones in a game of Magic (battlefield, hand, etc) but I've chosen to tag each ZoneRef constructor with a type that indicates what the type of a card is when you look up a reference to a card ("object" in Magic jargon):
type ObjectRef ty = (ZoneRef ty, Id)
lookupObject :: ObjectRef ty -> Magic (ObjectOfType ty)
Most functions that take object references as an argument like to constrain the type of the object referenced, and using a GADT allows them to do so. For example, dealing damage to an object (creature or planeswalker):
data SimpleOneShotEffect = DamageObject Object (ObjectRef TyPermanent) Int ...
3) Type TargetList models zero or more targets a spell on the stack can target. Even though in essence it is just a list of targets, it is a GADT so that it can have a "return type" which is re-evaluated when one of more of the targets change (for example, by a card like Redirect or Reverberate).
What an interesting example. Not what I was expecting!
Can you think of an example of a bug that you avoided due to the extra type safety of gadts? Magic has some pretty complex rules so I imagine that writing exaustive test must be hard and that the extra static guarantees might be able to find something a dynamic checker wouldn't. (Its ok if you need some ingame jargon to explain that, I know the basic rules).
It's a combination of avoiding potential bugs and just modelling things differently altogether:
If I had to leave out the answer type of questions, I'd have to come up with an entirely different way of modelling answers. For example, I might have had to write a datatype like:
data Answer = AnswerBool Bool | AnswerInt Int | ...
and then processing the answer (through pattern matching) would have to discard any answer it didn't like, which is awkward. Or I would have had to use a type class to keep everything type-safe which would have resulted in more complicated type signatures throughout the code.
For the TargetList, the current setup allows me to write functions that consume a target list of exactly the right size, for example:
\(target1, target2) -> ...
rather than a normal list:
\[target1, target2] -> ...
which in this case results in a pattern match exception if you pass it a list of any length other than 2.
I use them all the time for little EDSLs in Haskell. They also go really nicely when implementing AFRP libraries. You can also do a lot with them and type families for making typed APIs. Oliver Charles has some work doing this over websockets for instance: https://skillsmatter.com/skillscasts/5356-oliver-charles
I thought Ollie had a blog post about this stuff somewhere, but I can't find it now. He does other things which involve fairly advanced GADT work, though
Also, has anyone ever used gadts to implement type safe syntax trees like that? Last time I implemented a little programming language I used regular ADTs and had a separate type-checking pass to verify that everything is all right. I don't know how hard it would be to write a gadt version of my ast and if it would be worth the trouble.