Views in Haskell
J. Garrett Morris
trevion at gmail.com
Sat Jan 27 00:04:54 EST 2007
On 1/24/07, John Meacham <john at repetae.net> wrote:
> I am having a hard time figuring out what views gain you, if anything.
> If you know from the start you want abstract deconstructors, then you
> can do that now and it has never been an issue, just mechanical and
> > date Term = Ap Term Term | Let Id Term Term
> > fromAp :: Term -> Maybe (Term,Term)
> > fromAp (Ap a b) = Just (a,b)
> > fromAp _ = Nothing
> > foo t | Just (a,b) <- fromAp t = ...
> now views give you some (perhaps) nicer syntax for matching these sort
> of functions, but they don't make declaring them any less mechanical and
> verbose, but more importantly, you still have to know a priori whether
> you will need abstract deconstructors or not.
I agree completely, although with the caveat that this applies more to
Peyton-Jones's view patterns than Wadler's original views, at least as
I understood them. I had thought the advantages to views (and the
reason I've always been hoping they would eventually be implemented)
1) Provide type-class like behavior for type constructors, and
2) Reuse Haskell's existing extremely nice syntax for construction and
nested pattern matching.
This proposal seems to do neither, and I think the troubles it gets
into as soon as you want to match multiple values (extension 1, the
Just2 type, etc) demonstrate a somewhat limited applicability. I
personally like pattern guards a great deal, as light-weight
extensions go, but I'm not sure what view patterns would add over and
It is myself I have never met, whose face is pasted on the underside of my mind.
More information about the Haskell-prime