List function pragma discipline

Joachim Breitner mail at
Mon Sep 7 09:08:15 UTC 2015

Dear list,

I was working on (performance regressions
involving minimum), and I found it quite unsatisfactory to twiddle with
individual functions, based on individual test cases, this way. Of
course I can improve things for a combination of functions and
testcase, but if so, shouldn’t I be improving others as well? What
about other test cases – will they regress? How should I balance the
goals of speed, code size and simplicity?

This feels more like a random walk rather than hill-climbing, let alone
a disciplined approach to the problem.

Can we have a disciplined approach? I.e. a set of guidelines that work
well in general, can be documented and communicated to the user, and
that we can follow in such cases?

Here is a rough draft, more to show what I am aiming for, rather than a
finished work:

 * Functions that can take part in list fusion have RULES to rewrite
   them in terms of foldr/build, but also RULES to write them back.
   Phase control ensures that this is done by phase 0, and the 
   following applies to phase 0.
 * Recursive non-polymorphic non-higher-order functions are not
   marked as INLINE (and thus not inlineable, beside possibly the
   wrapper of a worker-wrapper split).
 * Recursive polymorphic non-higher-order functions are marked as
   INLINEABLE, and SPECIALIZE pragmas are given for common cases.
   (Example: minimum, maximum).
 * Recursive higher-order functions are implemented with a local 
   recursive function, to allow for inlining (foldl, foldr, 
   maximumBy), at least if there is a chance of further optimizations
   due to strictness analysis.

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.


Joachim “nomeata” Breitner
  mail at joachim-breitner.de
  Jabber: nomeata at  • GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the Libraries mailing list