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

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 On Thu, 19 Jan 2023 at 15:51, Chris Dornan wrote:

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 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 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

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.org https://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