> Can rule writers assume that some simple inlining will be
> done on LHSs? For instance, could I rewrite map/map as
> follows and expect to get as much coverage?
>
> {-# RULES
> "map/map" forall f,g. map f . map g = map (f.g)
> #-}
>
> What kind of matching do you support? Higher-order (i.e.
> modulo alpha, beta, & eta) is one very useful category,
> though only semi-decidable. Second-order is decidable and
> very useful for program transformation (See Huet & Lang,
> Proving and applying Program Transformations Expressed with
> Second Order Patterns, Acta Informatica, Vol. 11, pp. 31-55, 1978.)
Good questions. At present things are *very* simple; the idea is to see how
well it
works and soup it up where necessary. At the moment there is *no* inlining
on the
LHS, and I'm leery about allowing it. Imagine inlining "build"!!! That
would ruin the
rule.
First order matching only. When I see you (I hope Thurs and/or Fri 6/7 May
when I'll be in Redmond)
I'd like to discuss the matcher, which I'm not very proud of. Higher order
matching is
going to be a lot more expensive too.
No side conditions either. The name of the game is trying to come up with
improvments
that have high benefit for their cost. I don't know what those will be!
But the first thing to
do is to try the simplest thing and see where it fails.
> But there are so many of these rules! It might help to
> redefine map, zipWith, zipWith3, etc, in terms of repeat and "zipApp":
That's just what the fold/build story tries to do. Maybe a similar thing
would work.
Simon
