Discussion:
Rename INLINABLE to SPECIALISABLE
(too old to reply)
Daniel Cartwright
2018-06-08 17:10:08 UTC
Permalink
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
2018-06-08 17:17:25 UTC
Permalink
“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
2018-06-08 17:47:44 UTC
Permalink
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
2018-06-08 20:08:30 UTC
Permalink
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
2018-06-11 18:45:26 UTC
Permalink
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
Loading...