[Haskell] Views in Haskell

[Simon Peyton-Jones]

| 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