As I mentioned in a previous post, I’ve been reworking some of my sound change applier to try to unify the 3 different ASTs which evolved as I developed the current code base. And in the process, I’ve been experiencing a measure of what I’m going to call “type anxiety”: the worry that a particular decision about how to structure your program’s types is going to come back and bite you on the behind later.
Of course, this problem isn’t unique to Haskell. Certainly, any statically typed language has the potential to inflict pain if the coder tries to change the structure or interface of a fundamental type/class half-way through, so it’s always recommended to carefully think about the layout of your data early. And even dynamic languages still have interface and layout decisions, it’s just that they don’t have a compiler that will try to check compliance before the program runs, so if anything the consequences of change can be even worse without static types.
I guess the reason I’m worrying about it so much with Haskell is that I’m still not fully familiar with all the nooks and crannies of the language. In this particular case, I’m experimenting for the first time with some of the newer type wizardry, primarily in the form of GADTs, to try to guarantee that my ASTs always obey certain invariants. The problem, of course, is that there are many invariants that can be stated but it doesn’t seem possible to enforce all of them at the same time. Additionally, the enforcement of constraints by the type system can involve a lot of additional manual book keeping to satisfy the type-checker if you’re not careful.
So my anxiety has primarily been around what the most important invariant(s) to preserve are, how to structure the AST into type(s) and type constructors to get the type system to help me, and how much of this to do vs just relying on myself, testing and run-time checking. I think that I’ve now found a happy compromise, but if now I’m sure I’ll post here again to describe the source of my woe.
Posted by chrisdb on 2011-02-19
Tags: haskell
Comments