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

Adam Gundry adam at well-typed.com
Mon Jan 22 21:02:20 UTC 2024


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 <adam at well-typed.com 
> <mailto:adam at 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-1831697143 <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 <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
>     <mailto: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/ghc-proposals/ghc-proposals/pull/493>
>      >>>
>     https://github.com/goldfirere/ghc-proposals/blob/specialise/proposals/0000-specialise-expressions.rst <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



More information about the ghc-steering-committee mailing list