| At the risk of being a spoil-sport, I have a somewhat negative take on | view patterns. Not because I think they're particularly bad, but | because I don't think they're significantly useful enough to warrant | adding to the language, at least if we also have pattern guards. Syntactic sugar is always like this. It's always a judgement call: is the extra expressiveness worth the extra cost? One could ask that about list comprehensions, or pattern guards, or as-patterns, or records. Yet syntactic sugar can sometimes have quite a powerful effect -- think of do-notation for example. The other question is about cost. Syntactic sugar that can be readily explained, is easy to implement, and involves only localized changes (to the spec and to the compiler) are cheap. The views that Dan and I propose are specifically crafted to be minimally invasive and cheap in this sense. I swing to and fro on this one. On one day I think that view patterns are OK but just not quite worth it. On the next I think that perhaps they'll lower the barrier to allowing us to combine *abstraction* and *pattern matching*. The answer probably differs from one person to another. At the moment we're faced with this tension; pattern guards (also arguably superfluous) make it a bit easier but not easy enough. Views have been the subject of rather inconclusive debate for a long time, certainly since the inception of Haskell. I'm thinking of pattern views as a way to break the logjam by implementing something that is a reasonable stab, and seeing whether it "sticks". I thought of pattern guards in the same way, and they certainly seem to have stuck. But we can only find out by trying it out. That said, I'm keen to do it as well as possible -- so the more comments the better. Simon