[ghc-steering-committee] #493: SPECIALISE with expressions, rec: accept

[Adam Gundry]

Hi everyone,

I believe there is broad consensus to accept this proposal. One point of 
detail that has arisen on the proposal thread 
(https://github.com/ghc-proposals/ghc-proposals/pull/493#issuecomment-1831697143) 
is whether to deprecate and remove the awkward and undocumented 
multi-type form

     {-# SPECIALISE f :: Int -> Int
                      , Bool -> Bool
                      , Float -> Float #-}

since users can equally well write the clearer

     {-# SPECIALISE f :: Int -> Int #-}
     {-# SPECIALISE f :: Bool -> Bool #-}
     {-# SPECIALISE f :: Float -> Float #-}

The current text of the proposal retains the multi-type form, but 
discussion on the proposal thread suggests deprecating it instead, 
subject to the usual requirement that if/when this is implemented, GHC 
will issue a warning and continue to accept the old syntax for at least 
3 releases before completely removing it.

I suggest we accept the proposal on the basis that it will be amended to 
deprecate the multi-type form. If you disagree, please object in the 
next week or so.

Cheers,

Adam



On 19/12/2023 03:02, Eric Seidel wrote:
> Apologies, this sounds like an obvious win. +1
> 
> On Mon, Dec 18, 2023, at 04:36, Simon Peyton Jones wrote:
>> Eric, Joachim, Chris
>>
>> You have not yet responded (I think) to Adam's recommendation.    RSVP!
>>
>> https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing
>>
>> Simon
>>
>> On Wed, 29 Nov 2023 at 08:25, Adam Gundry <adam at well-typed.com> wrote:
>>> Dear all,
>>>
>>> Richard and Simon propose to generalise SPECIALISE pragmas to allow
>>> expressions, not just type signatures:
>>>
>>> https://github.com/ghc-proposals/ghc-proposals/pull/493
>>> https://github.com/goldfirere/ghc-proposals/blob/specialise/proposals/0000-specialise-expressions.rst
>>>
>>> This does not add anything fundamentally new, because such SPECIALISE
>>> pragmas can be translated using the existing RULES machinery, but it
>>> does make several idioms substantially more convenient:
>>>
>>>    * Using type applications in a SPECIALISE pragma to avoid repetition
>>>
>>>    * Manual call-pattern specialisation
>>>
>>>    * Loop unrolling
>>>
>>> Thus I propose we accept this proposal.
>>>
>>> Cheers,
>>>
>>> Adam


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England