<div dir="ltr"><div>Simon amended the proposal to say just that more or less at the same time as your email.</div><div><br></div><div>At any rate, I think we should accept the proposal regardless of deprecation. Both choices are equally reasonable in my opinion.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 11 Jan 2024 at 10:55, Adam Gundry <<a href="mailto:adam@well-typed.com">adam@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi everyone,<br>
<br>
I believe there is broad consensus to accept this proposal. One point of <br>
detail that has arisen on the proposal thread <br>
(<a href="https://github.com/ghc-proposals/ghc-proposals/pull/493#issuecomment-1831697143" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/493#issuecomment-1831697143</a>) <br>
is whether to deprecate and remove the awkward and undocumented <br>
multi-type form<br>
<br>
     {-# SPECIALISE f :: Int -> Int<br>
                      , Bool -> Bool<br>
                      , Float -> Float #-}<br>
<br>
since users can equally well write the clearer<br>
<br>
     {-# SPECIALISE f :: Int -> Int #-}<br>
     {-# SPECIALISE f :: Bool -> Bool #-}<br>
     {-# SPECIALISE f :: Float -> Float #-}<br>
<br>
The current text of the proposal retains the multi-type form, but <br>
discussion on the proposal thread suggests deprecating it instead, <br>
subject to the usual requirement that if/when this is implemented, GHC <br>
will issue a warning and continue to accept the old syntax for at least <br>
3 releases before completely removing it.<br>
<br>
I suggest we accept the proposal on the basis that it will be amended to <br>
deprecate the multi-type form. If you disagree, please object in the <br>
next week or so.<br>
<br>
Cheers,<br>
<br>
Adam<br>
<br>
<br>
<br>
On 19/12/2023 03:02, Eric Seidel wrote:<br>
> Apologies, this sounds like an obvious win. +1<br>
> <br>
> On Mon, Dec 18, 2023, at 04:36, Simon Peyton Jones wrote:<br>
>> Eric, Joachim, Chris<br>
>><br>
>> You have not yet responded (I think) to Adam's recommendation.    RSVP!<br>
>><br>
>> <a href="https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing</a><br>
>><br>
>> Simon<br>
>><br>
>> On Wed, 29 Nov 2023 at 08:25, Adam Gundry <<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a>> wrote:<br>
>>> Dear all,<br>
>>><br>
>>> Richard and Simon propose to generalise SPECIALISE pragmas to allow<br>
>>> expressions, not just type signatures:<br>
>>><br>
>>> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/493" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/493</a><br>
>>> <a href="https://github.com/goldfirere/ghc-proposals/blob/specialise/proposals/0000-specialise-expressions.rst" rel="noreferrer" target="_blank">https://github.com/goldfirere/ghc-proposals/blob/specialise/proposals/0000-specialise-expressions.rst</a><br>
>>><br>
>>> This does not add anything fundamentally new, because such SPECIALISE<br>
>>> pragmas can be translated using the existing RULES machinery, but it<br>
>>> does make several idioms substantially more convenient:<br>
>>><br>
>>>    * Using type applications in a SPECIALISE pragma to avoid repetition<br>
>>><br>
>>>    * Manual call-pattern specialisation<br>
>>><br>
>>>    * Loop unrolling<br>
>>><br>
>>> Thus I propose we accept this proposal.<br>
>>><br>
>>> Cheers,<br>
>>><br>
>>> Adam<br>
<br>
<br>
-- <br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
<br>
Registered in England & Wales, OC335890<br>
27 Old Gloucester Street, London WC1N 3AX, England<br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div>