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

Fri Jun 5 17:01:00 UTC 2020

I've updated the GH thread of this proposal to "revisions needed".

Regards,
Alejandro

El mié., 3 jun. 2020 a las 12:04, Richard Eisenberg (<rae at richarde.dev>)
escribió:

>
>
> On Jun 3, 2020, at 10:25 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
> 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.
>
>
> I would say that there are real costs to this proposal, as can be seen by
> the new complexity introduced by the MR. But, as has been well argued, the
> complexity is worth the cost -- arrows are essentially only
> half-implemented without this.
>
>
> 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.
>
>
> I'm quite happy to delay this detail to the implementation. I don't think
> it's a critical piece, in either direction. And it's just about error
> messages, which are generally not part of proposals proper.
>
> Thanks,
> Richard
>
>
> 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/20200605/8a7454e3/attachment.html>