Rename INLINABLE to SPECIALISABLE

[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.

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.

[Eric Mertens]

“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.html#special-ids>). 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.

Post by Daniel Cartwright
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[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

Post by Daniel Cartwright
The "INLINABLE" pragma's name is misleading, it is more like
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[Mikolaj Konarski]

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

Post by 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

Post by Daniel Cartwright
The "INLINABLE" pragma's name is misleading, it is more like
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[John Wiegley]

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? :)