This is an interesting proposal. The merits of the proposal are one thing, but it also feels like someone is proposing to renovate an abandoned corner of GHC. I'll try to weigh these orthogonal benefits as best I can. I'll take a deeper look after work. Cheers, Chris On Fri, Jan 3, 2020 at 11:30 AM Joachim Breitner wrote:

Of course I mean Chris Allen. Sorry for the confusion.

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-not...

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@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Chris Allen Currently working on http://haskellbook.com

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 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 (mailto:mail@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/ghc-proposals/ghc-proposals/pull/303 https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-not... https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-not...

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 https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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 :

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@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@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@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-not...

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@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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 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-6331998... https://github.com/ghc-proposals/ghc-proposals/pull/303#issuecomment-6331998...] 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 (mailto:mail@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 mailto:trupill@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 (mailto:rae@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 mailto:trupill@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 (mailto:mail@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/ghc-proposals/ghc-proposals/pull/303 https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-not... https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-not...

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 https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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 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 () 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 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-6331998...] 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@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 :

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 () 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 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@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-not...

...

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@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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 () escribió:

On Jun 3, 2020, at 10:25 AM, Spiwack, Arnaud 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 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 () 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 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-6331998...] 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@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 :

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 () 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 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@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-not... > > 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@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee