List function pragma discipline
david.feuer at gmail.com
Sat Sep 12 01:43:18 UTC 2015
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 Sep 11, 2015 9:24 PM, "wren romano" <winterkoninkje at gmail.com> wrote:
> On Mon, Sep 7, 2015 at 5:08 AM, Joachim Breitner
> <mail at 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
> Live well,
> Libraries mailing list
> Libraries at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries