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