With the functional dependency, you can't work with the view datatypes at all. Once you write type Typ data TypView = Unit | Arrow Typ Typ instance View Typ TypView where view = ... you're no longer allowed to take apart a TypView at all! E.g. you can't write outUnit :: TypView -> Bool outUnit Unit = True outUnit _ = False because the implicit application of the view function will mean that outUnit must consume a Typ. Personally, I'd rather have special syntax in the pattern (-> pat) than have these global effects on what you can do with certain types. -Dan On Jul27, Stefan O'Rear wrote:
On Fri, Jul 27, 2007 at 05:22:37AM -0400, Dan Licata wrote:
On Jul26, Stefan O'Rear wrote:
So, this syntax affects a lot of code, existing or otherwise, that doesn't use view patterns, which is something we're trying to avoid.
Eh? I *think* the typing rules are the same for the no-view case. If the auto-deriving hack isn't implemented, you only need a deriving(View), otherwise there should be no change at all...
Assuming you don't have the functional dependency: "affects" in the sense that any code you write has a generalized type, so you have to explain view patterns to beginners right out of the gate, etc. If you write
length [] = [] length (h : t) = 1 + length t
we don't want to have to explain to beginners why it has type
length :: forall a,b,c. View a [b] -> a -> Num c
Right, which is why I think the functional dependency is good. If we have it, and the auto-deriving hack, what breaks?
length [] = [] length (h : t) = 1 + length t
length :: forall a b c. (View a [b], Num c) => a -> c
==> (one of the FD rules)
length :: forall a b c. (View [a] [b], Num c) => [a] -> c
==> (plain context reduction, the first constraint is tautological)
length :: forall a c. Num c => [a] -> c
Stefan
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe