On 1/24/07, John Meacham <[EMAIL PROTECTED]> 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
verbose:
> 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)
were:
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
above them.
/g
--
It is myself I have never met, whose face is pasted on the underside of my mind.
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
