optimization and rewrite rules questions

[Claus Reinke]

| II is where I'd like to be able to distinguish variables, constants,
| and complex expressions in the left-hand sides of RULES, and
| I and III are where I'd like control over the rewrite strategy, as
| in strategy combinators.

>I'm deep in icfp submissions, so no time to reply properly.

Okay, not urgent, just general concerns about GHC performance,
can wait a few days.

>You can distinguish between literals, variables etc, in GHC's 
>BuiltinRules.

Not really sufficient. If the loop body was about Maps instead
of Ints, different rules would apply. And the same limitations
apply for all uses of RULES, which were meant to provide
for user-extensible library-specific optimization by transformation.

>Another avenue is to elaborate the language of rules somehow 
>to let you say what you want. But I don't know a good *spec* 
>for such a feature, let alone an impl.
>Another possibility is to write a Core-to-Core optimiser aimed 
>at your target area.  Max B's plugins would let you dynamically 
>link that to a distributed GHC.  But it's not in the HEAD yet...

My guess would be to start from standard Strafunski/SYB-style
traversals over Core as the "semantic API", utilizing compiler plugins.

Then look for better syntax, closer to the existing RULES (for a
start, something like quasi-quoting, so that left- and right-hand
sides of rules can still be written in concrete syntax, even if they
are just Haskell function definitions).

Then move all RULES to the new framework (to reduce
duplication inside GHC, and to provide a single programmer 
API) and start adding further optimizations to libraries (I wonder:
surely others have encountered these limitations when adding
RULES for their libraries?).

But that is just a guess - as you imply, someone would have to
sit down, design, implement, and test. That is why I asked 
whether it would make a good GSoC topic for GHC HQ
(lots of potential, and building on one of last year's topics).

Claus