[Haskell-cafe] Inlinable (>>>)

[Joachim Breitner]

Hi,

Am Samstag, den 04.03.2017, 22:28 +0530 schrieb Saurabh Nanda:
> I had a similar WTF moment when I noticed that Lucid's HtmlT over IO
> was 2x slower than HtmlT over Reader/Identity. Discussions over this
> mailing list pointed to the lack of INLINE pragmas on various
> functions, like >>=
> 
> It was finally resolved via a liberal sprinkling of INLINE -- https:/
> /github.com/chrisdone/lucid/pull/67/files 
> 
> Why can't GHC automatically consider *every* function as INLINABLE?
> Let the GHC heuristics decide what is worthy of being inlined. What's
> the downside?

the original post was about INLINEABLE not INLINE – let’s keep these
two apart.

INLINEABLE says: „Dear compiler, keep the definition of this function
in the interface so that you can, maybe, inline (or specialize) it
later.“

INLINE implies INLINEABLE, but also says: „…, and really do inline it“.

BTW, there is a flag -fexpose-all-unfoldings that effectively add
INLINEABLE to all functions.

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170304/f4b72ac9/attachment.sig>