Rename INLINABLE to SPECIALISABLE

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. 1. The function's (exact) definition is included in the interface file for the module. 2. 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.

“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

INLINABLE also ensures the definition ends up in the interface files
so that the function is able to be inlined across modules.
Matt
On Fri, Jun 8, 2018 at 7:10 PM, Daniel Cartwright
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

There is quite a lot of GHC tickets related to that
https://ghc.haskell.org/trac/ghc/search?q=SPECIALISABLE
https://ghc.haskell.org/trac/ghc/search?q=SPECIALIZABLE
sometimes even close to developing some consensus,
but always lacking a person that would create a formal GHC proposal,
iterating possible variants.
On Fri, Jun 8, 2018 at 7:47 PM, Matthew Pickering
INLINABLE also ensures the definition ends up in the interface files so that the function is able to be inlined across modules.
Matt
On Fri, Jun 8, 2018 at 7:10 PM, 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
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

For the record I don't have strong feelings here. Maybe SPECIALISABLE should simply be a synonym for INLINABLE, allowing the author to emphasise what's important to him or her.
S
| -----Original Message-----
| From: Libraries

"SPJvL" == Simon Peyton Jones via Libraries
writes:
SPJvL> For the record I don't have strong feelings here. Maybe SPECIALISABLE SPJvL> should simply be a synonym for INLINABLE, allowing the author to SPJvL> emphasise what's important to him or her. And SPECIALIZABLE a synonym for both? :) -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
participants (6)
-
Daniel Cartwright
-
Eric Mertens
-
John Wiegley
-
Matthew Pickering
-
Mikolaj Konarski
-
Simon Peyton Jones