
On 2/17/12 2:51 PM, Roman Cheplyaka wrote:
Out of these FunctionalDependencies seems to be the most exotic (even in GHC-oriented development there has been some shift towards type families, it seems).
Is it used only for mtl stuff (and thus can be replaced by 'transformers' + some lifts), or is it necessary for your own API?
It is indeed used for the unification-fd API, mainly to assist type inference and to avoid the need to have type annotations everywhere (due to the use of MPTCs). The use of fundeps was largely because that's what I'd used when first writing it up a number of years ago, before understanding and implementation of type families had solidified and long before type families had gained much traction. However, the type family variant should be straightforward. In particular the classes using MPTCs are: class (Unifiable t, Variable v, Applicative m, Monad m) => BindingMonad v t m | m -> v t where... class (BindingMonad v t m) => RankedBindingMonad v t m | m -> v t where... AFAICT, those could be easily converted to the following without any loss in expressivity: class ( Unifiable (BMTerm t) , Variable (BMVar m) , Applicative m -- should be implied by (Monad m), but alas! , Monad m ) => BindingMonad m where type BMVar m :: * type BMTerm m :: * -> * ... class (BindingMonad m) => RankedBindingMonad m where... The type signatures may get a bit uglier (as they tend to, due to type equality constraints and the calls to associated types being longer than type variable names), but given that they're not especially pretty to begin with, that's not really a concern. If the above does indeed work, then one nice thing is that it also gets rid of the need for MPTCs (except for the use of mtl's MonadError and MonadState), which brings it one step closer to being usable on JHC. I'm not sure what UHC's status is on implementing MPTCs, fundeps, and type families. The hesitation about releasing unification-tf with the above change implemented is just that I wanted to play around with the ranked unification stuff a bit more, to see if I could get it to a place I liked before forking the package. Also the lack of round tuits. -- Live well, ~wren