| 1 I am a bit concerned about the use of non-linear patterns in your examples. | There are good arguments for non-linear patterns, and Haskellers have made good | arguments against non-linear patterns. But you seem to suggest allowing non-linear | patterns in some cases (related to view patterns), but not in others (general patterns). | That is likely to be confusing.
I don't think view patterns are non-linear at all! They are just as linear as Haskell's existing patterns. Definitely no implicit use of equality, for example. | 2 view patterns nicely separate expressions in patterns from pattern variables. But I | didn't realize at first that view patterns can be used nested inside other patterns. | | Yet this variable binding during nested matching is the essential contribution, and | the only reason why the extra syntactic sugar is justified. Perhaps this point could | be repeated and emphasized in "The proposal more formally", for people like me?-) I've added a section called "Nesting". You can readily edit it (since I moved the page) to amplify if you think it would help. | 3 what you call first class abstractions are not entirely orthogonal to view patterns. | taking Tullsen's and my own proposal as examples: I'm afraid I don't follow this. I think they are entirely orthogonal. | 4 whether to use view patterns inside ordinary patterns, or whether to build up | patterns from abstract de-constructors (just as expressions are built from | abstract constructors) may seem only a question of style. but if your aim is | to encourage people to transition from exporting concrete data types to | exporting abstract types only, the latter approach seems more consistent | to me. Again, I didn't follow | 5 possible extension 1 smells of superfluous complexity. There is almost no gain | compared to using tuples, but there's a lot to pay in added types and rules. You may well be right. | 6 possible extension 2 seems a non-starter if we want compositional abstract | patterns, and I certainly do want them. Imagine the example in (4) with | explicit Maybe. | | Being able to have compositional abstract patterns would be the make-or-break | criterion for me. Without them, new syntactic sugar wouldn't be justified, with | them, their precise form is a matter of convenience. I think I must be missing what you mean by a "compositional abstract pattern". Simon _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
