Re: [Haskell-cafe] Cons of -XUndecidableInstances

It seems that UndercidableInstances keep getting a bad rap. There are legitimate and decidable applications of UndercidableInstances. These applications have nothing to do with OOP, or HList for that matter. This topic is discussed at length in the article http://okmij.org/ftp/Haskell/types.html#undecidable-inst-defense Here are the conclusions: Thus there are patently decidable type programs that require UndecidableInstances. That extension should not be categorically stigmatized. In conclusion, UndecidableInstances is not a dangerous flag. It will never cause the type-checker to accept a program that `goes wrong.' The only bad consequence of using the flag is type checker's might be telling us that it cannot decide if our program is well-typed, given the context-stack--depth limit. We may ask the type-checker to try a bit harder (with a larger depth limit), or look through our program and find the problem. UndecidableInstances are quite like the primitive recursion criterion: all primitive recursion functions surely terminate; non-primitive recursion functions generally don't. Still there are many classes of non-primitive recursive functions that are total. To see their totality, one has to use more complex criteria.

I wrote:
You almost never want to use UndecidableInstances when writing practical programs in Haskell. When GHC tells you that you need them, it almost always means that your types are poorly designed, usually due to influence from previous experience with OOP.
wren ng thornton wrote:
That's a bit unfair. There are many kinds of type-level hackery which require UndecidableInstances but are (a) perfectly safe for practical use, and (b) have nothing to do with OOP. One particularly trivial example that comes to mind is: newtype Mu f = Mu (f (Mu f))
I agree. I've even used that one (well, something similar anyway). Oleg wrote:
It seems that UndercidableInstances keep getting a bad rap. There are legitimate and decidable applications of UndercidableInstances. These applications have nothing to do with OOP, or HList for that matter... That extension should not be categorically stigmatized.
I'm sorry if I came across as giving it a bad rap, or stigmatizing it. That was certainly not my intention. There are plenty of excellent techniques that use this and other GHC extensions; accomplished Haskellers should have them in their toolbox. But I stand by my statement, which is coming from my perspective as a professional Haskell software developer, not a PL researcher. Perhaps I should clarify it though. I am making two claims: 1. In everyday practical Haskell programming, it is very unusual that a technique requiring direct use of UndecidableInstances is the right tool for the job. Of course, that observation is colored by my own experience, but I believe that it is generally true. 2. If a person is surprised by the GHC error suggesting that UndecidableInstances is needed and is struggling with understanding it, then it is almost certain that person has inappropriately used OOP thinking in trying to design a Haskell program. Experienced Haskellers familiar with those techniques do not get the error. Or they get it and say, "Oops, forgot the UndecidableInstances." Whereas most programmers coming to Haskell have had OOP experience. The first thing that happens when they try to write a program in Haskell of any significant complexity is the "UndecidableInstances" error. It happened to me, too. Thanks, Yitz

Personally, I came much less against UndecidableInstances when I was trying
to do OOP in Haskell than when I was trying do Prolog-like things at the
type level.
Things like transitive relations: (If a type B contains an A, and if C
contains B, then C contains A, and so on).
I kind of abandonned quickly that way of reasoning ^^.
2011/6/7 Yitzchak Gale
I wrote:
You almost never want to use UndecidableInstances when writing practical programs in Haskell. When GHC tells you that you need them, it almost always means that your types are poorly designed, usually due to influence from previous experience with OOP.
wren ng thornton wrote:
That's a bit unfair. There are many kinds of type-level hackery which require UndecidableInstances but are (a) perfectly safe for practical use, and (b) have nothing to do with OOP. One particularly trivial example that comes to mind is: newtype Mu f = Mu (f (Mu f))
I agree. I've even used that one (well, something similar anyway).
Oleg wrote:
It seems that UndercidableInstances keep getting a bad rap. There are legitimate and decidable applications of UndercidableInstances. These applications have nothing to do with OOP, or HList for that matter... That extension should not be categorically stigmatized.
I'm sorry if I came across as giving it a bad rap, or stigmatizing it. That was certainly not my intention. There are plenty of excellent techniques that use this and other GHC extensions; accomplished Haskellers should have them in their toolbox.
But I stand by my statement, which is coming from my perspective as a professional Haskell software developer, not a PL researcher. Perhaps I should clarify it though.
I am making two claims:
1. In everyday practical Haskell programming, it is very unusual that a technique requiring direct use of UndecidableInstances is the right tool for the job. Of course, that observation is colored by my own experience, but I believe that it is generally true.
2. If a person is surprised by the GHC error suggesting that UndecidableInstances is needed and is struggling with understanding it, then it is almost certain that person has inappropriately used OOP thinking in trying to design a Haskell program.
Experienced Haskellers familiar with those techniques do not get the error. Or they get it and say, "Oops, forgot the UndecidableInstances."
Whereas most programmers coming to Haskell have had OOP experience. The first thing that happens when they try to write a program in Haskell of any significant complexity is the "UndecidableInstances" error. It happened to me, too.
Thanks, Yitz
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (3)
-
oleg@okmij.org
-
Yitzchak Gale
-
Yves Parès