Hello all, I'm back for real this time,
The proposal (link
https://github.com/ghc-proposals/ghc-proposals/pull/555 ) is quite reasonable. I think that, in general, higher order patterns are an uncontroversial extension to rewrite rules (it could be extended further but if I remember correctly, there are choices there).
I've got a question though: is the following rewrite rule something I can write in Haskell today?
```
{- RULES … forall f g. map (\x -> f (g x)) = map f . map g
```
In this rule `f (g x)` is not a pattern (because `g` is not rigid). And it is not clear to me how purely syntactic unification and pattern unification interact.
I think the automatic addition of lambdas is likely to be fairly innocuous (despite the fact that it may change `undefined` into, say, `\x y -> undefined y x`): it happens under lambdas already, so it's unlikely to effectively change the behaviour of program unbeknownst to the rule author. I'm sure someone will eventually manage to be bitten by it. But I think that it's an ok compromise.
/Arnaud
I am sorry for not getting back sooner Joachim,
I agree, rewrite rules are cool and this is clearly a useful generalisation.
I vote in favour.
A small suggestion when crafting instructions to us -- do not under any circumstances, ever, give us the option of doing nothing! You will be taken up on it (which is a sad reflection os us, not you). :-)
Chris
Dear GHC Steering Committee
Joachim wrote to us ten days ago recommending acceptance of #555. No one has responded.
Would you like to respond, please? (I think this is an easy one.)
Thanks
Simon
Dear Committee,
Jaro Reinders and Simon PJ propose to allow Higher Order Patterns in Rewrite
Rules.
The idea, by way of an example,
{-# RULES forall f. foo (\y. f y + f y) = bar f #-}
will now not only match "foo (\y. negate y + negate y)" (with f set to negate)
but also "foo (\y. y*y + y*y)" (with f set to (\x. x*x)).
Here "f y" is a higher-order pattern, which are restricted to a
_pattern_ variable followed by a list of _local_ variable, indicating
which variable the matched expression may depend on (previously, only
closed expressions could be matched).
An implementation is sitting ready at
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9343
The design was carefully crafted to be backward-compatible and not
introduce spurious etwa-expansion where there was non before.
It is not guarded by a LANGUAGE pragma (but RULES themselves are not).
Library authors who care about backward compat will have to deal with
CPP pragmas.
I’m a big fan of rewrite rules, and the proposal is straight forward
and provides a feature that I'd maybe optimistically already assumed to
be there already. Therefore, I’m recommending acceptance.
If you disagree please speak up within two weeks, or speed up the
process by indicating agreement earlier.
Cheers,
Joachim
--
Joachim Breitner
mail@joachim-breitner.de
http://www.joachim-breitner.de/
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.orghttps://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee