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-1831697...) 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-b18MDkpTfH3SMHhFu5...

Simon

On Wed, 29 Nov 2023 at 08:25, Adam Gundry 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-s...

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

In the absence of further discussion, I've declared this proposal to be accepted. Thanks Richard and Simon! Adam On 11/01/2024 13:06, Arnaud Spiwack wrote:

Simon amended the proposal to say just that more or less at the same time as your email.

At any rate, I think we should accept the proposal regardless of deprecation. Both choices are equally reasonable in my opinion.

On Thu, 11 Jan 2024 at 10:55, Adam Gundry mailto:adam@well-typed.com> wrote:

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-1831697... https://github.com/ghc-proposals/ghc-proposals/pull/493#issuecomment-1831697...) 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-b18MDkpTfH3SMHhFu5... https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5... >> >> Simon >> >> On Wed, 29 Nov 2023 at 08:25, Adam Gundry mailto:adam@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/ghc-proposals/ghc-proposals/pull/493 >>> https://github.com/goldfirere/ghc-proposals/blob/specialise/proposals/0000-s... https://github.com/goldfirere/ghc-proposals/blob/specialise/proposals/0000-s... >>> >>> 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