
“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 https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts...). 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
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