[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