Sorry to enter the discussion a little late ...
First, I'm not clear what Simon meant by "first class abstractions"
in this comment
Several proposals suggest first class abstractions rather that
first-class patterns. Here are the ones I know of ...
Second, I completely agree with Claus in his comment here that my
"First Class Patterns"
paper is definitely related to, and not orthogonal to view patterns:
The "big idea" of my paper was to stop the growing complexity of
the pattern-language
of Haskell. The idea was to use the abstraction capabilities of
the language along
with some simple syntactic sugar to give us 'pattern omnipotence'.
However, my approach could be seen as orthogonal in that I did not
propose
to change Haskell patterns. Instead, I suggested some additional
syntax that could
serve as a replacement for complicated uses of patterns.
Strangely, for other reasons, I'm planning, within a week or so, to
start implementing
the "pattern-binder" syntax I discussed in the paper (either in GHC
or as a pre-processor).
- Mark
Claus Reinke wrote:
3 what you call first class abstractions are not entirely
orthogonal to view patterns.
taking Tullsen's and my own proposal as examples:
- the way patterns and alternatives are handled needs to fit
together. that doesn't
seem to be a problem since your and our proposals agree on
using what I call
a monadic data parsing framework (using a MonadPlus such as
Maybe to handle
pattern match failure and alternatives)
- all three proposals have discussed how to handle patterns as
well. For Tullsen,
that is central to his proposal, for me, it was only one of the
more advanced
examples because I wanted to focus on match alternatives first.
Tullsen first builds his pattern combinators, then outlines a
point-free style that
avoids the need for pattern variables althogether but does not
seem to scale well,
then suggests syntactic sugar for translating patterns with
variables into applications
of his combinators. So that last part is closely related to, if
different from, your
proposal.
In my example, I build up patterns from de-constructors (which
use tests and
selectors), so that a cons pattern takes a head pattern and a
tail pattern as
parameters and applies them to the head and tail if it is
applied to a non-empty
list. To handle variables, I use an old trick from the early
functional logic
languages, namely that logic variables can be passed unbound,
then bound to
values later, just what we need for pattern variables. Since
Haskell doesn't
have logic variables, I have to simulate them, which is the
only awkward bit
of the example:
http://www.haskell.org/pipermail/haskell-prime/2006-November/
001915.html
as long as Haskell doesn't support logic variables, some syntactic
sugar for
variables in nested patterns, such as Tullsen's or your's, is
probably inevitable.
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
