[Haskell] Views in Haskell
simonpj at microsoft.com
Wed Jan 24 15:27:46 EST 2007
| 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".
More information about the Haskell-prime