<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Dear GHC Steering Committee</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Joachim wrote to us ten days ago recommending acceptance of #555.  No one has responded.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Would you like to respond, please?  (I think this is an easy one.)<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Thanks</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 10 Jan 2023 at 11:17, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Committee,<br>
<br>
Jaro Reinders and Simon PJ propose to allow  Higher Order Patterns in Rewrite<br>
Rules.<br>
<br>
The idea, by way of an example,<br>
<br>
   {-# RULES forall f.  foo  (\y. f y + f y) = bar f #-}<br>
<br>
will now not only match "foo (\y. negate y + negate y)" (with f set to negate)<br>
but also "foo (\y. y*y + y*y)" (with f set to (\x. x*x)).<br>
<br>
Here "f y" is a higher-order pattern, which are restricted to a<br>
_pattern_ variable followed by a list of _local_ variable, indicating<br>
which variable the matched expression may depend on (previously, only<br>
closed expressions could be matched).<br>
<br>
An implementation is sitting ready at<br>
<a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9343" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9343</a><br>
<br>
The design was carefully crafted to be backward-compatible and not<br>
introduce spurious etwa-expansion where there was non before.<br>
<br>
It is not guarded by a LANGUAGE pragma (but RULES themselves are not).<br>
Library authors who care about backward compat will have to deal with<br>
CPP pragmas.<br>
<br>
<br>
I’m a big fan of rewrite rules, and the proposal is straight forward<br>
and provides a feature that I'd maybe optimistically already assumed to<br>
be there already. Therefore, I’m recommending acceptance.<br>
<br>
If you disagree please speak up within two weeks, or speed up the<br>
process by indicating agreement earlier.<br>
<br>
Cheers,<br>
Joachim<br>
<br>
-- <br>
Joachim Breitner<br>
  <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
  <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>