[ghc-steering-committee] #555: Higher Order Patterns in Rewrite Rules, rec accept

Chris Dornan chris at chrisdornan.com
Thu Jan 19 14:51:31 UTC 2023


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

> On 2023-01-19, at 09:10, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> 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
> 
> On Tue, 10 Jan 2023 at 11:17, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> 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 <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 at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230119/37f72fcf/attachment.html>


More information about the ghc-steering-committee mailing list