On Jan 25, 2007, at 6:40 AM, Claus Reinke wrote:
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).
I'm somewhat surprised to read this. Between view patterns, lambda-
match,
and Control.Monad.Match, I thought we were approaching a situation in
which we have all the essential aspects covered (perhaps apart from
the fact that your combinators come in both left-right and right-
left variants), with slightly more convenience and better
integration with existing pattern match facilities
Especially the pattern-binder syntax and translation strike me as more
complicated (so much so that I would rather use a simplified form
of the translation result than all that machinery) and no more
general than combining view patterns with pattern functions. But
perhaps that is a
question of personal style (and my own use of type-classes to lift
mplus to pattern-functions has also been classed as complicated by
others;-).
Is there anything specific you find missing, or a those other
reasons the
motivation with going for your own version?
Claus
Good question. It's not that I think there is some "essential aspect"
which isn't covered: View patterns will definitely add some useful
expressiveness,
and ditto for lambda-match and Control.Monad.Match (though I haven't
yet had time
to fully assimilate this stuff: I didn't start following this thread
till yesterday).
First Class Patterns are radical enough and are so far from meshing
with the
pattern language of Haskell that I don't really consider them a
"competing proposal".
My motivations for implementing "pattern-binder" syntax are as follows
1) I have a special need for some significant syntactic sugar for
which pattern binders
perfectly fit the bill. (For general programming I use my
pattern combinators and
the 'do' notation.)
2) There are other reasons why I want to use Haskell-98 and would
like to be able to use
other compilers. Thus, I'd want a pattern-binder preprocessor
(extending GHC is
not as important to me).
Here's my motivating example. Here's a fragment for an STG
interpreter in Haskell-98:
{{{
rule_CASE_ELIM (Case p alts, s, h, o) =
do
ConApp c as <- ptsTo p h
let matchAlt (Alt c' vs e) | c == c' = Just (vs,e)
matchAlt _ = Nothing
(vs,e) <- matchFirst matchAlt alts
return (e `sub` (vs,as), s, h, o)
}}}
I'd like it to have a textual form just a little more abstract, I can
do that with
pattern binders and some appropriate combinators:
{{{
rule_CASE_ELIM =
{ (Case p alts , s, h, o) }
&&& ptsTo p h === { ConApp c as }
&&& alts === matchFirst { Alt #c vs e }
.->
(e `sub` (vs,as), s, h, o)
}}}
I'll leave it as an exercise to figure out how the last is
parenthesized ;-).
- Mark
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
