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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
