There's been lots of interesting feedback about the views proposal -- thank you. Many of the suggestions amount to plausible design alternatives. If I do all the editing, I'll just become a bottleneck, and I'm more than usually snowed-under at the moment. So I've moved the Wiki page to the GHC wiki, which is world-editable. It's here http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns The wiki isn't a good place for to-and-fro debate, but it is a good way to capture design alternatives. If those with alternatives to propose would like to add them (in an even handed way needless to say) to the wiki page, that'd be good. Feel free to re-structure the text if that'd make it clearer. The big question is, as several people have observed, whether the (modest) gain is worth the (also modest) pain. If the proposal has merit, it is its extreme simplicity. There's no comparison with things like class aliases, which are a Much Bigger Deal on both those metrics. Simon
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. the issue that needs to be solved is letting you extend pattern matching "after the fact", if you know you want abstract deconstructors from the beginning, then views don't make much difference, if you don't and want to seamlessly extend an existing type, then you are out of luck, views or not. John -- John Meacham - ⑆repetae.net⑆john⑈
On 1/24/07, John Meacham
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.
participants (3)
-
J. Garrett Morris -
John Meacham -
Simon Peyton-Jones