[jhc] explanation of FrontEnd.KindInfer.constrain

[John Meacham]

On Wed, Mar 19, 2008 at 07:37:55PM -0400, Samuel Bronson wrote:
> > and Future Proofing is always a good answer, assuming one can back it
> > up, full kind polymorphism is an eventual goal and the kind inference
> > algorithm and terminology used was written with that in mind. oddly
> > enough it leads to a much cleaner implementation than the THIH
> > implementation as a side effect...
> 
> It's only a good answer if the code actually works... dead code
> doesn't get much testing, generally...

Hrm? I am not sure what you mean. I knew I needed a constrained
polymorphic inference algorithm so thats what I wrote. The difference
between kind schemes and kinds may not have been obvious because ghc
uses a similar (but distinct algorithmically) subtyping algorithm. 


you might as well complain about someone writing

fst3 (x,_,_) = x

without explicitly saying

fst3 :: (Int,Char,Foo) -> Int

because that happens to be the way it is used.

one of the most beautiful things about haskell is that the general
solution is almost always _easier_ than just solving a specific problem.
you gotta work harder to constraint 'fst3', and having to throw away my
kindchecker just because I introduced kind schemes would have been a
whole lot more work (especially since I knew I was going to introduce
them). jhc couldn't exist if I didn't think about the future of every
bit of code I write. Luckily, haskell is such a great language, it's
hard to write code that isn't future safe, but I'm not gonna go out of
my way to work myself into a corner.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈