[Haskell] Views in Haskell

[Claus Reinke]

>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.

interesting point. the left-hand sides are non-linear, in that variables may appear 
several times, but the context distinguishes between pattern-variables and expression
variables in view patterns, and the parts concerned with matching are linear, so
every pattern-variable will still only have a single point of definition.

perhaps that is sufficient to avoid confusion. 

but the idea that bindings have a left to right bias is new to Haskell patterns,
and switching formal and actual parameters can now be statically different,
not just dynamically different. Unless the plan is to treat the following two 
as equivalent?

    let { f1 p (p -> ()) = () } in f1 return ()
    let { f2 (p -> ()) p = () } in f2 () return

>I've added a section called "Nesting". 

it certainly makes the point. the part I didn't get at once was that I can build
up abstract patterns from view patterns as I would build up abstract data from
abstract constructors, and still be able to bind sub-structures to variables.

>| 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.

true first-class patterns, in whatever form, include the functionality provided
by view patterns as a subset. only the syntax differs, and the means of variable 
binding. since we are aiming for a smooth integration with the rest of current
Haskell, these differences are important, but they don't make the approaches 
orthogonal.

Tullsen has the pattern binder construct (Section 4.1), which includes the ability 
to apply any pattern function (functions of type a->Maybe b) anywhere inside a 
pattern using the % construct. The result is matched against a pattern, which can
be a variable. which covers the two aspects of view patterns.

and as I've shown for the lambda-match library, one can compose pattern 
functions in the same way as one builds up a pattern from constructors, ie
every part of the pattern is a pattern function. since I don't have syntactic
sugar for variable binding, that second aspect of view patterns is a little more
awkward. but it can be done in at least two ways, using the logic variable
emulation I showed, or something similar to the result of Tullsen's translation 
of pattern binders. again covering both aspects of view patterns, without 
additional extensions.

>| 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

I wasn't very clear, as I was still trying to get a handle on what view patterns
can do. Sorry about that. Perhaps my second mail has already clarified my 
misconception, but let me try again:

concrete data structures are built from concrete data constructors.
concrete patterns are built from concrete data constructors (which thereby
double as data de-constructors).

abstract data structures are built from abstract data constructors, hiding the
concrete representation.
abstract patterns are built from abstract data-deconstructors (in our current
context, that means pattern functions of type a -> Maybe b, for some a,b).

my concern was whether it makes sense to use view patterns as abstract
de-constructors inside otherwise concrete patterns, or whether one should
encourage a wholesale switch to abstract patterns. as long as I can do the
latter, I don't mind if the former is also possible.

>I think I must be missing what you mean by a "compositional abstract pattern".

most of the examples suggested that view patterns are used one a case by
case basis, to select components from an adt part of a parameter.

the alternative I'm aiming for, as exhibited in the consP example, would be
to build patterns systematically from view patterns used as abstract 
de-constructors, composed in the same way as one would compose the
abstract constructors to build the abstract data structure. in other words,
you define your pattern constructors once, with the adt, and export them;
and anytime you want to match somethind of that abstract type, you simply
compose your pattern from those abstract pattern constructors.

is that clearer?

Claus