Eric Mertens emertens at
Fri Jun 8 17:17:25 UTC 2018

“Inlinable” definitions can be inlined using the “inline” function as explained in the documentation:

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 at> 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 at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list