[ghc-steering-committee] Please review #303: Constraint based arrow notation, Shepherd: Alejandro

[Spiwack, Arnaud]

It seems to me that the proposal is well-motivated and well-written. It
proposes to dust up a dark corner of GHC. I don't have technical insight
into this, but it does look like something worth accepting, and not really
costly.

Do I understand correctly that the choice between wired-in and non-wired-in
type families is mostly an implementation detail? If so, this is a
conversation which would best take place in the corresponding MR, rather
than in the proposal.

On Mon, Jun 1, 2020 at 9:44 PM Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> Dear Committee,
> Apart from Richard's concerns about wired-in families, there seems that
> there is no further discussion regarding this topics.
> If nobody raises any further concern, I'll write back to the author of the
> proposal asking them to remove or rework that part.
>
> Regards,
> Alejandro
>
> El lun., 25 may. 2020 a las 13:14, Richard Eisenberg (<rae at richarde.dev>)
> escribió:
>
>> I'm in support of the proposal as written, perhaps with the exception of
>> the special error-handling for ArrowStackTup (which I think is unnecessary).
>>
>> On May 24, 2020, at 8:19 PM, Alejandro Serrano Mena <trupill at gmail.com>
>> wrote:
>> - Should the proposal be under a different extension or under `Arrows`?
>>
>>
>> No. As the proposal authors argue, the backward-compatibility problem is
>> essentially non-existent, because the feature is so inconvenient to use
>> today that no one does.
>>
>> - Should a flattened or nested tuple representation be used? This
>> comments [
>> https://github.com/ghc-proposals/ghc-proposals/pull/303#issuecomment-633199848]
>> may give you some additional information.
>>
>>
>> I prefer the flat tuples. If need be, this can revisited in the future,
>> but the flat tuples seem better today.
>>
>> - Should the type families described there be wired-in?
>>
>>
>> I don't see a need for this. The type families will necessarily be part
>> of the specification of these features, and so their appearance in error
>> messages are not an example of abstraction leakage. Maybe we want to
>> carefully normaliseType here or there to avoid them unnecessarily, but I
>> see no need to wire-in.
>>
>> Richard
>>
>>
>> Looking forward to hearing from everyone. This is a complex proposal,
>> with possible future ramifications. If there's no discussion in one week,
>> I'll write again to the list.
>> Regards,
>> Alejandro
>>
>> El mar., 19 may. 2020 a las 9:02, Joachim Breitner (<
>> mail at joachim-breitner.de>) escribió:
>>
>>> If there is active discussion, we usually put it back to the previous
>>> state, and wait for discussion to come to conclusions.
>>>
>>> 19.05.2020 08:36:42 Alejandro Serrano Mena <trupill at gmail.com>:
>>>
>>> Dear Committee,
>>> When I took care of this proposal, the GitHub thread was quite dormant.
>>> However, it seems that right now there's quite some activity, and even
>>> proposals to completely redesign arrows. What is the right approach: let
>>> the discussion cool off, and then ask all of you to review the text (which
>>> I don't think is going to change substantially in any case) or move the
>>> proposal back to the previous state?
>>>
>>> Alejandro
>>>
>>> El vie., 15 may. 2020 a las 11:03, Richard Eisenberg (<rae at richarde.dev>)
>>> escribió:
>>>
>>>> I have some concerns -- mostly: is the improvement worth the
>>>> implementation complexity? I've posted on GitHub.
>>>>
>>>> Richard
>>>>
>>>> On May 15, 2020, at 8:01 AM, Alejandro Serrano Mena <trupill at gmail.com>
>>>> wrote:
>>>>
>>>> Dear Committee,
>>>> This proposal looks good to me. The author has done a lot of work to
>>>> formalize the new rules, and has done a check that no packages using arrow
>>>> syntax would be broken by this modification. Thus, I recommend we accept
>>>> this proposal.
>>>>
>>>> Apart from the general discussion, I think it might be worth focusing
>>>> on a specific part of the design: the use of a couple of type families to
>>>> express "arrow stacks". I am not aware of other GHC extensions depending on
>>>> particular type families.
>>>> - As the author discusses, these type families ought to be wired-in, so
>>>> they can benefit from improvement during type checking. Is this a good
>>>> choice? It looks to be, but other may have a different opinion.
>>>> - Would this type family pose a problem for optimization /
>>>> specialization / ...?
>>>>
>>>> Kind regards,
>>>> Alejandro
>>>>
>>>> El lun., 4 may. 2020 a las 23:08, Joachim Breitner (<
>>>> mail at joachim-breitner.de>) escribió:
>>>>
>>>>> Dear Committee
>>>>>
>>>>> I took the liberty to re-asssign #303 to Alejandro; the authors
>>>>> rightfully asked for progress in the discussion thread.
>>>>>
>>>>> Cheers,
>>>>> Joachim
>>>>>
>>>>> Am Freitag, den 03.01.2020, 15:20 +0100 schrieb Joachim Breitner:
>>>>> > Dear Committee,
>>>>> >
>>>>> > this is your secretary speaking:
>>>>> >
>>>>> > Constraint based arrow notation
>>>>> > has been proposed by Aleix King
>>>>> > https://github.com/ghc-proposals/ghc-proposals/pull/303
>>>>> >
>>>>> https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-notation/proposals/0000-constraint-based-arrow-notation.md
>>>>> >
>>>>> > I propose Chris Done as the shepherd.
>>>>> >
>>>>> > Please guide us to a conclusion as outlined in
>>>>> > https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>>> >
>>>>> > Thanks,
>>>>> > Joachim
>>>>> --
>>>>> Joachim Breitner
>>>>>   mail at joachim-breitner.de
>>>>>   http://www.joachim-breitner.de/
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ghc-steering-committee mailing list
>>>>> ghc-steering-committee at haskell.org
>>>>>
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>>>
>>>>
>> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200603/96a4bc43/attachment-0001.html>