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.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.
On Jun 8, 2018, at 10:10 AM, Daniel Cartwright <chessai1996@gmail.com> 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 <chessai1996@gmail.com> 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
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 <matthewtpickering@gmail.com> wrote:
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 <chessai1996@gmail.com> 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 <libraries-bounces@haskell.org> On Behalf Of Matthew | Pickering | Sent: 08 June 2018 18:48 | To: Daniel Cartwright <chessai1996@gmail.com> | Cc: Haskell Libraries <libraries@haskell.org> | Subject: Re: Rename INLINABLE to SPECIALISABLE | | 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 <chessai1996@gmail.com> | 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 | > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Cs | > imonpj%40microsoft.com%7C4dcb66ed3d844dcf119208d5cd67fa2a%7C72f988bf86 | > f141af91ab2d7cd011db47%7C1%7C0%7C636640768833664956&sdata=oGZmlOi0PLsO | > ot%2FR5%2Fg3Vzl38sFyd6Dmzk6NPKB3DSo%3D&reserved=0 | > | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell | .org%2Fcgi- | bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Csimonpj%40microsoft.com% | 7C4dcb66ed3d844dcf119208d5cd67fa2a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C | 0%7C636640768833664956&sdata=oGZmlOi0PLsOot%2FR5%2Fg3Vzl38sFyd6Dmzk6NPKB3DSo | %3D&reserved=0
"SPJvL" == Simon Peyton Jones via Libraries <libraries@haskell.org> 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