[Haskell] Views in Haskell

[Claus Reinke]

>I'm not quite sure whether it all means you think view patterns are good; or that 
>they would be good with a tweak; or that something else would be better.

probably because my opinion has been changing;-) at first, I wasn't convinced,
now I think it depends on the details. as Mark said, such syntactic extensions of
conventional patterns are not strictly necessary since we know how to avoid them
completely (using data parsing). so for a new functional language, I too would 
like to drop patterns as built-ins, providing their functionality via sugar and libraries.

but as far as Haskell is concerned, I am perhaps less radical in my approach 
than Mark is: Haskellers have invested an awful lot of work in those conventional 
patterns, in readibility, in optimisations, and in linking them with other extensions 
(eg., type system extensions). 

that is why I proposed the lambda-match construct to complement the library 
Control.Monad.Match, so that conventional patterns could be used within the 
data parsing framework. and that is why I think view patterns are useful: they 
allow us to embed data parsing into conventional patterns, reusing existing 
syntax for binding pattern variables while still allowing us to define our own 
pattern constructors.

so I'd like to have both lambda-match and view patterns, supported by 
Control.Monad.Match, and well integrated. but if suggestions to make Maybe 
explicit in view patterns, or to drop it alltogether, carry the day, I might lose 
interest. also, I'd like the syntax to stay close to conventional constructors, 
rather than close to pattern guards.

regarding first-class abstractions/terminology: for myself, I have settled on using
"first-class matches" (or "first-class match alternatives") for the likes of the
lambda-match construct (left-hand side pattern, right-hand side expression), 
and "first-class patterns" for proposals that actually allow to abstract over the 
left-hand sides of matches. both first-class matches and first-class patterns 
tend to use the common framework of MonadPlus instances for match failure 
and fall-through, as a generalisation of the good old monadic combinator 
parsers on strings. for this framework I use the term "monadic data parsing".

regarding syntax for view patterns: I like the prefix form, but agree that the use
of "->" is unfortunate. If it wasn't for pattern constants, I'd probably just use
application (lower case identifiers in function position in a pattern can only be
views, unless someone suggests other uses for that syntax; and the last 
parameter of a view has to be a pattern). The next best thing, to emphasize 
that we're essentially computing patterns, would be to borrow TH's notation 
for splicing, using

    $(view p1..pn) pattern

instead of

    view p1..pn -> pattern

Claus