One way to use INLINABLE is in conjunction with the special function inline (Special built-in functions). The call inline f tries very hard to inline f. To make sure that f can be inlined, it is a good idea to mark the definition of f as INLINABLE, so that GHC guarantees to expose an unfolding regardless of how big it is. Moreover, by annotating f as INLINABLE, you ensure that f‘s original RHS is inlined, rather than whatever random optimised version of f GHC’s optimiser has produced.

Calling the name misleading might be a stretch. I’d be against this if it was up to the libraries list to change it, but I don’t think it’s in scope here.

On Jun 8, 2018, at 10:10 AM, Daniel Cartwright <chessai1996@gmail.com> wrote:
The "INLINABLE" pragma's name is misleading, it is more like "SPECIALISABLE". Consider the documentation for INLINABLE:
Top-level definitions can be marked INLINABLE.
myComplicatedFunction :: (Show a, Num a) => ...
myComplicatedFunction = ...

{-# INLINABLE myComplicatedFunction #-}
This causes exactly two things to happens.
The function's (exact) definition is included in the interface file for the module.
The function will be specialised at use sites -- even across modules.
Note that GHC is no more keen to inline an INLINABLE function than any other.
I propose that we deprecate "INLINABLE" over a number of years at the same time as introducing "SPECIALISABLE". This wouldn't cause breakages for a long time.
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries