Rename INLINABLE to SPECIALISABLE

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Rename INLINABLE to SPECIALISABLE

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). 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 <[hidden email]> 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.
  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.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Rename INLINABLE to SPECIALISABLE

Matthew Pickering
In reply to this post by Daniel Cartwright
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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Rename INLINABLE to SPECIALISABLE

Mikolaj Konarski-2
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
<[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Rename INLINABLE to SPECIALISABLE

Haskell - Libraries mailing list
In reply to this post by Matthew Pickering
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 <[hidden email]> On Behalf Of Matthew
|  Pickering
|  Sent: 08 June 2018 18:48
|  To: Daniel Cartwright <[hidden email]>
|  Cc: Haskell Libraries <[hidden email]>
|  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 <[hidden email]>
|  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
|  > [hidden email]
|  > 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
|  [hidden email]
|  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
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Rename INLINABLE to SPECIALISABLE

John Wiegley-2
>>>>> "SPJvL" == Simon Peyton Jones via Libraries <[hidden email]> 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
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries