I think this is an admirable goal, but I do have a few concerns.
1. The inliner is a finicky beast. A guideline that makes sense for one function may make less sense for another depending on how the inliner tends to look at them prior to fusion.
2. There may (I'm not sure) be some combinations that are common enough in real code that it's worth thinking about them specially.
3. unfoldr is a bit of an oddball, because there are good reasons to want to inline it every time regardless of fusion.
On Mon, Sep 7, 2015 at 5:08 AM, Joachim Breitner
<mail@joachim-breitner.de> wrote:
> Given such a guideline, I would then know what to do with such a
> ticket, instead of stabbing in the dark. It might mean that we would
> have to tell a user who observes suboptimal performance in one case
> that this is unavoidable (we cannot optimize for everyone) and possibly
> explain how to work around the issue. Or we might find that the
> discipline could be improved, but then the improvement should be
> applied to all functions.
I'm all for this. I've messed around with a lot of list-fusion rewrite
rules, and though I have a good handle on them now, it took a good
deal of trial and error to learn the art of it. In addition to
offering a route to learning, another key aspect of these guidelines
should be to keep track of which practices are still relevant. Over
the years there've been a number of changes in the details of how
rules interact with other optimizations, so it'd be good to air out
what practices are still relevant (and why) vs which ones arose from
legacy issues (and maybe note why they used to but no longer are a
concern)
--
Live well,
~wren
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries