RE: [commit: ghc] master: Add a comment to the mapFB rules (665cefe)
| +-- The "mapFB" rule optimises compositions of map and | +-- the "mapFB/id" rule get rids of 'map id' calls. | +-- (Any similarity to the Functor laws for [] is expected.) Yes, obviously. But did you have a use-case, or did you just to this on principle? If you don't have this rule what goes wrong. You must have had a proximate reason for adding it. Oh. And I've just realised that mapFB c id will turn into \x y. c x y as soon as you inline mapFB. So why do you need a RULE to do that? Why not leave it for the inliner? Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git@git.haskell.org | Sent: 09 March 2017 15:14 | To: ghc-commits@haskell.org | Subject: [commit: ghc] master: Add a comment to the mapFB rules | (665cefe) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha | skell.org%2Ftrac%2Fghc%2Fchangeset%2F665cefe80d112ed2e4fb9617d277a1466 | e83f9bd%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C8854d69a18b4459 | e528808d466feef08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362466 | 92510080066&sdata=IR%2BftPvaSs2xZa74FEWe67ynoP6bgLKOExK7jtPe4Yg%3D&res | erved=0 | | >--------------------------------------------------------------- | | commit 665cefe80d112ed2e4fb9617d277a1466e83f9bd | Author: Joachim Breitner <mail@joachim-breitner.de> | Date: Thu Mar 9 16:13:08 2017 +0100 | | Add a comment to the mapFB rules | | to amend 2fa44217c1d9722227297eefb0d6c6aed7e128ca. | | | >--------------------------------------------------------------- | | 665cefe80d112ed2e4fb9617d277a1466e83f9bd | libraries/base/GHC/Base.hs | 6 ++++-- | 1 file changed, 4 insertions(+), 2 deletions(-) | | diff --git a/libraries/base/GHC/Base.hs b/libraries/base/GHC/Base.hs | index 6f9d454..a678c22 100644 | --- a/libraries/base/GHC/Base.hs | +++ b/libraries/base/GHC/Base.hs | @@ -964,10 +964,12 @@ mapFB c f = \x ys -> c (f x) ys | -- (along with build's unfolding) else we'd get an infinite loop | -- in the rules. Hence the activation control below. | -- | --- The "mapFB" rule optimises compositions of map. | --- | -- This same pattern is followed by many other functions: | -- e.g. append, filter, iterate, repeat, etc. | +-- | +-- The "mapFB" rule optimises compositions of map and | +-- the "mapFB/id" rule get rids of 'map id' calls. | +-- (Any similarity to the Functor laws for [] is expected.) | | {-# RULES | "map" [~1] forall f xs. map f xs = build (\c n | -> foldr (mapFB c f) n xs) | | _______________________________________________ | ghc-commits mailing list | ghc-commits@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C8854d69a18b4459e52880 | 8d466feef08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362466925100 | 80066&sdata=cU6XkSWb5Lg1oaEnVPwB2%2BesI9jtneA2051MhD4SnnM%3D&reserved= | 0
Hi, Am Donnerstag, den 09.03.2017, 15:21 +0000 schrieb Simon Peyton Jones via ghc-devs:
+-- The "mapFB" rule optimises compositions of map and +-- the "mapFB/id" rule get rids of 'map id' calls. +-- (Any similarity to the Functor laws for [] is expected.)
Yes, obviously. But did you have a use-case, or did you just to this on principle? If you don't have this rule what goes wrong. You must have had a proximate reason for adding it.
Just on principle. I saw "map id" in some code dump and thought that this should not be there.
Oh. And I've just realised that mapFB c id will turn into \x y. c x y as soon as you inline mapFB. So why do you need a RULE to do that? Why not leave it for the inliner?
Because we have to keep mapFB around to rewrite it back with this rule "mapList" [1] forall f. foldr (mapFB (:) f) [] = map f This is explained in Note [Inline FB functions] in GHC.List, which is referenced from the {-# INLINE [0] mapFB #-} pragma. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
participants (2)
-
Joachim Breitner -
Simon Peyton Jones