From bravit111 at gmail.com Tue Mar 1 07:41:53 2022 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Tue, 1 Mar 2022 10:41:53 +0300 Subject: [ghc-steering-committee] #475: New tuple and list syntax, rec: accept In-Reply-To: <010f017f427a6eae-ee69e2bd-5771-4bab-9b4b-1e94691ee67e-000000@us-east-2.amazonses.com> References: <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com> <010f017eff25a113-34a9d84d-399d-4252-a938-cbea1283cc96-000000@us-east-2.amazonses.com> <010f017f41a0b450-f6350d30-4226-4ca9-a9c4-8f969ea020a3-000000@us-east-2.amazonses.com> <010f017f427a6eae-ee69e2bd-5771-4bab-9b4b-1e94691ee67e-000000@us-east-2.amazonses.com> Message-ID: Hi Vlad, I am in favor of dropping TupleN and I'm next to support Tuple [A, B, C] option. And of course, I support the proposal as a whole. Vitaly вт, 1 мар. 2022 г. в 01:36, Richard Eisenberg : > Thanks, Vlad! > > I just want to explicitly declare that I am agnostic to the different > design choices Vlad mentions below. Whatever we as a committee settle on is > fine with me. > > Richard > > > On Feb 28, 2022, at 2:31 PM, Vladislav Zavialov (int-index) < > vlad.z.4096 at gmail.com> wrote: > > > > Thanks for the ping. > > > > Firstly > > ===== > > > > To answer Arnaud’s question whether the visual noise is worse than the > quote – we have earlier agreed on the syntactic unification principle, so > the quote has to go (unless we want to start writing it at term level). > > > > Secondly > > ======= > > > > Everyone who has expressed their opinion so far (Simon Peyton-Jones, Tom > Harding, Arnaud Spiwack, Richard Eisenberg, and I) is either in favor or > does not object to dropping TupleN. I suggest to incorporate this change to > the proposal now. > > > > There’s also a new alternative described in the proposal. Here are our > options: > > 1. TupleN A B C > > 2. Tuple [A, B, C] > > 3. Tuple (A, B, C) — NEW > > > > Why would one write Tuple (A, B, C) rather than Tuple [A, B, C]? This > allows us to introduce Tuple# as well: Tuple# [Int#, Double#] does not > kind-check, but Tuple# (Int#, Double#) does. However, I find that Tuple (A, > B, C) is weirdly circular, using the tuple constructor to describe the > tuple type. If, say, Tuple was a data family instead of a type family, this > could not possibly work. This leaves me with an uneasy feeling: while I > understand how and why it’s an appealing option, it exploits the fact that > Tuple is defined on top of the actual tuple types such as Tuple2, Tuple3, > Tuple4, etc, whereas I’d like to abstract over this implementation detail. > > > > Frankly, it’s hard to choose between (2) and (3). Do we have to choose? > Well, this is all about pretty-printing. If we’re fine with printing Tuple3 > Int Bool String as is, then we can let libraries define their own type > families. But if we want to print it as e.g. Tuple [Int, Bool, String], > then the Tuple type family must be hard-coded in the pretty-printer, and > therefore provided in `base`. > > > > I suggest we stick with Tuple [A, B, C]. > > > > Thirdly > > ===== > > > > Since the discussion has started, the proposal evolved a bit and now > disallows tuple/list promotion ticks under -XNoListTuplePuns, which I > believe is the right call and very much in spirit of the change. > > > > Finally > > ===== > > > > We still have not heard from Vitaly Bragilevsky, Eric Seidel, Simon > Marlow, and Joachim Breitner. > > > > Let’s wait another week, and then I will assume silence to mean “no > objection” and accept the proposal. > > > > - Vlad > > > >> On 28 Feb 2022, at 21:38, Richard Eisenberg wrote: > >> > >> Bump. Could our dear shepherd Vlad guide us toward a conclusion? > >> > >> Thanks! > >> Richard > > > > _______________________________________________ > 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: From mail at joachim-breitner.de Tue Mar 1 08:17:05 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 01 Mar 2022 09:17:05 +0100 Subject: [ghc-steering-committee] Welcome Baldur and Chris, welcome again Eric, and Farewell Vitaly Message-ID: Dear Committee and wider community, thanks to everyone who has put forward their nominations this round, and we are happy to welcome Chris Dornan, Baldur Blöndal and Eric Seidel as new or, in the case of Eric, re-joining members of the GHC Steering Committee! Chris and Baldur, if you haven’t already, please subscribe to our mailing list at https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee and familiarize yourself with our processes at https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst and https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst You’ll find a list of proposals under discussion at https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+committee+review%22 and your opinion is welcome on all of them. The committee wants to thank Vitaly Bragilevsky for his full term of service on the committe. Your contributions were valued, and I certainly would be happy to see your nomination again at some point in the future. The next regular call for nominations (early resignations notwithstanding) will likely be in January 2023. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simon.peytonjones at gmail.com Tue Mar 1 08:49:40 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 1 Mar 2022 08:49:40 +0000 Subject: [ghc-steering-committee] #475: New tuple and list syntax, rec: accept In-Reply-To: References: <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com> <010f017eff25a113-34a9d84d-399d-4252-a938-cbea1283cc96-000000@us-east-2.amazonses.com> <010f017f41a0b450-f6350d30-4226-4ca9-a9c4-8f969ea020a3-000000@us-east-2.amazonses.com> Message-ID: > However, I find that Tuple (A, B, C) is weirdly circular, using the tuple constructor to describe the tuple type Is it really so weird? We still have (A,B,C) for the *data constructor*, right? So the prefix "Tuple" in the front is a bit like the tick-mark, saying "not the data constructor but the type constructor". If anything it's stranger to use Tuple to move from list syntax to tuple syntax. One might ask (of both): can you write "forall a. Tuple a -> blah", and then instantiate at `[A,B,C]` or `(A,B,C)` resp? Sorry if the proposal already says this -- but if it doesn't say so explicitly it should, with examples. On Mon, 28 Feb 2022 at 19:31, Vladislav Zavialov (int-index) < vlad.z.4096 at gmail.com> wrote: > Thanks for the ping. > > Firstly > ===== > > To answer Arnaud’s question whether the visual noise is worse than the > quote – we have earlier agreed on the syntactic unification principle, so > the quote has to go (unless we want to start writing it at term level). > > Secondly > ======= > > Everyone who has expressed their opinion so far (Simon Peyton-Jones, Tom > Harding, Arnaud Spiwack, Richard Eisenberg, and I) is either in favor or > does not object to dropping TupleN. I suggest to incorporate this change to > the proposal now. > > There’s also a new alternative described in the proposal. Here are our > options: > 1. TupleN A B C > 2. Tuple [A, B, C] > 3. Tuple (A, B, C) — NEW > > Why would one write Tuple (A, B, C) rather than Tuple [A, B, C]? This > allows us to introduce Tuple# as well: Tuple# [Int#, Double#] does not > kind-check, but Tuple# (Int#, Double#) does. However, I find that Tuple (A, > B, C) is weirdly circular, using the tuple constructor to describe the > tuple type. If, say, Tuple was a data family instead of a type family, this > could not possibly work. This leaves me with an uneasy feeling: while I > understand how and why it’s an appealing option, it exploits the fact that > Tuple is defined on top of the actual tuple types such as Tuple2, Tuple3, > Tuple4, etc, whereas I’d like to abstract over this implementation detail. > > Frankly, it’s hard to choose between (2) and (3). Do we have to choose? > Well, this is all about pretty-printing. If we’re fine with printing Tuple3 > Int Bool String as is, then we can let libraries define their own type > families. But if we want to print it as e.g. Tuple [Int, Bool, String], > then the Tuple type family must be hard-coded in the pretty-printer, and > therefore provided in `base`. > > I suggest we stick with Tuple [A, B, C]. > > Thirdly > ===== > > Since the discussion has started, the proposal evolved a bit and now > disallows tuple/list promotion ticks under -XNoListTuplePuns, which I > believe is the right call and very much in spirit of the change. > > Finally > ===== > > We still have not heard from Vitaly Bragilevsky, Eric Seidel, Simon > Marlow, and Joachim Breitner. > > Let’s wait another week, and then I will assume silence to mean “no > objection” and accept the proposal. > > - Vlad > > > On 28 Feb 2022, at 21:38, Richard Eisenberg wrote: > > > > Bump. Could our dear shepherd Vlad guide us toward a conclusion? > > > > Thanks! > > Richard > > _______________________________________________ > 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: From simon.peytonjones at gmail.com Tue Mar 1 08:50:28 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 1 Mar 2022 08:50:28 +0000 Subject: [ghc-steering-committee] Welcome Baldur and Chris, welcome again Eric, and Farewell Vitaly In-Reply-To: References: Message-ID: Welcome Chris, Balur, and Eric! Thank you for being willing to join us. Simon On Tue, 1 Mar 2022 at 08:17, Joachim Breitner wrote: > Dear Committee and wider community, > > thanks to everyone who has put forward their nominations this round, > and we are happy to welcome > > Chris Dornan, Baldur Blöndal and Eric Seidel > > as new or, in the case of Eric, re-joining members of the GHC Steering > Committee! > > Chris and Baldur, if you haven’t already, please subscribe to our > mailing list at > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > and familiarize yourself with our processes at > https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst > and > https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst > > You’ll find a list of proposals under discussion at > > https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+committee+review%22 > and your opinion is welcome on all of them. > > The committee wants to thank Vitaly Bragilevsky for his full term of > service on the committe. Your contributions were valued, and I > certainly would be happy to see your nomination again at some point in > the future. > > The next regular call for nominations (early resignations > notwithstanding) will likely be in January 2023. > > Cheers, > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Tue Mar 1 08:51:11 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 1 Mar 2022 08:51:11 +0000 Subject: [ghc-steering-committee] Welcome Baldur and Chris, welcome again Eric, and Farewell Vitaly In-Reply-To: References: Message-ID: Vitaly, thank you so much for your work on the steering group. We will miss you! Simon On Tue, 1 Mar 2022 at 08:17, Joachim Breitner wrote: > Dear Committee and wider community, > > thanks to everyone who has put forward their nominations this round, > and we are happy to welcome > > Chris Dornan, Baldur Blöndal and Eric Seidel > > as new or, in the case of Eric, re-joining members of the GHC Steering > Committee! > > Chris and Baldur, if you haven’t already, please subscribe to our > mailing list at > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > and familiarize yourself with our processes at > https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst > and > https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst > > You’ll find a list of proposals under discussion at > > https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+committee+review%22 > and your opinion is welcome on all of them. > > The committee wants to thank Vitaly Bragilevsky for his full term of > service on the committe. Your contributions were valued, and I > certainly would be happy to see your nomination again at some point in > the future. > > The next regular call for nominations (early resignations > notwithstanding) will likely be in January 2023. > > Cheers, > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at chrisdornan.com Tue Mar 1 09:23:49 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Tue, 1 Mar 2022 09:23:49 +0000 Subject: [ghc-steering-committee] Welcome Baldur and Chris, welcome again Eric, and Farewell Vitaly In-Reply-To: References: Message-ID: A pleasure to be with you! > On 2022-03-01, at 08:50, Simon Peyton Jones wrote: > > Welcome Chris, Balur, and Eric! Thank you for being willing to join us. > > Simon > > On Tue, 1 Mar 2022 at 08:17, Joachim Breitner > wrote: > Dear Committee and wider community, > > thanks to everyone who has put forward their nominations this round, > and we are happy to welcome > > Chris Dornan, Baldur Blöndal and Eric Seidel > > as new or, in the case of Eric, re-joining members of the GHC Steering > Committee! > > Chris and Baldur, if you haven’t already, please subscribe to our > mailing list at > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > and familiarize yourself with our processes at > https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst > and > https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst > > You’ll find a list of proposals under discussion at > https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+committee+review%22 > and your opinion is welcome on all of them. > > The committee wants to thank Vitaly Bragilevsky for his full term of > service on the committe. Your contributions were valued, and I > certainly would be happy to see your nomination again at some point in > the future. > > The next regular call for nominations (early resignations > notwithstanding) will likely be in January 2023. > > Cheers, > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Mar 1 14:42:01 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 01 Mar 2022 15:42:01 +0100 Subject: [ghc-steering-committee] #477: Unicode ellipsis, recommendation: accept In-Reply-To: References: <18DD3012-398A-4FA9-8881-D1C04B9BE2DE@gmail.com> <9a059656-128d-4282-a156-161d0eb4c00d@www.fastmail.com> Message-ID: Hi, it’s a worthwhile observation that we (somewhat oddly) use a two-dot ellipsis in ASCII-Haskell, and Artem took this up on Github to ponder if we should allow ASCII ... as well, but I am not convinced. I wrote on the Github thread: > Hmm, I am not sure I agree that it's confusing. At least to me, from > the start when I saw Haskell, the ascii .. meant what's \ldots in > LaTeX, and what I tend to write as three close-to-each other dots on > paper and is semantically an ellipsis, which in Unicode has a > codepoint with that names that in most fonts looks like what you > expect it to… > > So the .. is an ASCII cludge like all others (probably because ... is > unnecessarily wide). > > The analogue is \ for λ - just because the left leg is missing we > wouldn't use a unrelated look-alike like \ for the unicode variant, > nor ask to be able to write ,\ in ASCII for a better approximation of > the real letter. > > TL;DR: no need to change ASCII-Haskell, and let's use the > semantically correct ellipsis symbol in Unicode-Haskell. Vlad, how firm is your -1? If you feel strongly enough about it (which is of course absolutely fine), I’d maybe just put this up for a vote? It’s a mostly aesthetical, superficial change where voting may be more efficient than long discussions. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From vlad.z.4096 at gmail.com Tue Mar 1 15:09:21 2022 From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index)) Date: Tue, 1 Mar 2022 18:09:21 +0300 Subject: [ghc-steering-committee] #477: Unicode ellipsis, recommendation: accept In-Reply-To: References: <18DD3012-398A-4FA9-8881-D1C04B9BE2DE@gmail.com> <9a059656-128d-4282-a156-161d0eb4c00d@www.fastmail.com> Message-ID: <6049C938-00B1-4576-8C32-553B5E214FA1@gmail.com> My -1 is firm. After some digging, I found out that the two dots are the intended notation, not just a shorthand for three dots. If you look at "Ronald L. Graham, Donald E. Knuth, and Oren Patashnik. Concrete Mathematics. Addison–Wesley, second edition, 1994”, you will find the following passage: For our next problem let's consider a handy new notation, suggested by C. A. R. Hoare and Lyle Ramshaw, for intervals of the real line: [α .. β] denotes the set of real numbers x such that α ≤ x ≤ β. This set is called a closed interval because it contains both endpoints α and β. The interval containing neither endpoint, denoted by (α .. β), consists of all x such that α < x < β; this is called an open interval. The book is typeset beautifully, and I believe they could’ve used three dots if they wanted, but they used two. Since then, the Hoare-Ramshaw interval notation has been incorporated into various programming languages, including Pascal and Haskell. I have no idea why the proposal uses three dots, actually. - Vlad > On 1 Mar 2022, at 17:42, Joachim Breitner wrote: > > Hi, > > it’s a worthwhile observation that we (somewhat oddly) use a two-dot > ellipsis in ASCII-Haskell, and Artem took this up on Github to ponder > if we should allow ASCII ... as well, but I am not convinced. I wrote > on the Github thread: > >> Hmm, I am not sure I agree that it's confusing. At least to me, from >> the start when I saw Haskell, the ascii .. meant what's \ldots in >> LaTeX, and what I tend to write as three close-to-each other dots on >> paper and is semantically an ellipsis, which in Unicode has a >> codepoint with that names that in most fonts looks like what you >> expect it to… >> >> So the .. is an ASCII cludge like all others (probably because ... is >> unnecessarily wide). >> >> The analogue is \ for λ - just because the left leg is missing we >> wouldn't use a unrelated look-alike like \ for the unicode variant, >> nor ask to be able to write ,\ in ASCII for a better approximation of >> the real letter. >> >> TL;DR: no need to change ASCII-Haskell, and let's use the >> semantically correct ellipsis symbol in Unicode-Haskell. > > Vlad, how firm is your -1? If you feel strongly enough about it (which > is of course absolutely fine), I’d maybe just put this up for a vote? > It’s a mostly aesthetical, superficial change where voting may be more > efficient than long discussions. > > Cheers, > 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 From mail at joachim-breitner.de Tue Mar 1 15:10:35 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 01 Mar 2022 16:10:35 +0100 Subject: [ghc-steering-committee] #475: New tuple and list syntax, rec: accept In-Reply-To: References: <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com> <010f017eff25a113-34a9d84d-399d-4252-a938-cbea1283cc96-000000@us-east-2.amazonses.com> <010f017f41a0b450-f6350d30-4226-4ca9-a9c4-8f969ea020a3-000000@us-east-2.amazonses.com> Message-ID: Hi, Am Montag, dem 28.02.2022 um 22:31 +0300 schrieb Vladislav Zavialov (int-index): > There’s also a new alternative described in the proposal. Here are our options: > 1. TupleN A B C > 2. Tuple [A, B, C] > 3. Tuple (A, B, C) — NEW I am not convinced it’s a good idea to introduce many ways of naming the same thing, and given that the above three are already in addition to the primitive (Tuple2 Bool Int), (which I’ll call (0) below), we need a good justification to have more than one. Between (2) and (3), I’d prefer (3): The strange loop of tuples referring to tuples isn’t too unhaskellish, and if it works better for unboxed tuples, then yay! Between (3) and (1) I am unsure. Presumably, if we didn’t have (3) we’d use the less idiosyncratic name `Tuple` for (1)?  Are there other, not purely cosmetic, differences between (1) and (3)? Maybe related to partial application? It’s a bit sad we can't just have (1) without even needing (0), so that there really is only _one_ name that’s reasonably ergonomic. How far out would that be? Worth making Haskell good enough to support a nice design here? :-) Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Tue Mar 1 15:21:33 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 01 Mar 2022 16:21:33 +0100 Subject: [ghc-steering-committee] #477: Unicode ellipsis, recommendation: reject? In-Reply-To: <6049C938-00B1-4576-8C32-553B5E214FA1@gmail.com> References: <18DD3012-398A-4FA9-8881-D1C04B9BE2DE@gmail.com> <9a059656-128d-4282-a156-161d0eb4c00d@www.fastmail.com> <6049C938-00B1-4576-8C32-553B5E214FA1@gmail.com> Message-ID: <7efb45300605be4fff3c291de29a5c12cb25f14d.camel@joachim-breitner.de> Hi, TIL! That’s indeed interesting research, and refutes my assumption that .. was an ASCII-approximation of an ellipsis (aka \ldots in latex). I thought for a moment that surely my typographic intuition is better than Knuth’s, but … no, I didn’t. I’ll bring this before the author and will see if he wants to pursue the proposal anyways, retract it, or (maybe) suggest to use ‥ (U+2025 TWO DOT LEADER) instead. Although I would probably not suppor the latter, given that I find essentially no prior art of using that. Thanks for changing my mind, Joachim Am Dienstag, dem 01.03.2022 um 18:09 +0300 schrieb Vladislav Zavialov (int-index): > My -1 is firm. After some digging, I found out that the two dots are the intended notation, not just a shorthand for three dots. If you look at "Ronald L. Graham, Donald E. Knuth, and Oren Patashnik. Concrete Mathematics. Addison–Wesley, second edition, 1994”, you will find the following passage: > > For our next problem let's consider a handy new notation, suggested by C. A. R. Hoare and Lyle Ramshaw, for intervals of the real line: [α .. β] denotes the set of real numbers x such that α ≤ x ≤ β. This set is called a closed interval because it contains both endpoints α and β. The interval containing neither endpoint, denoted by (α .. β), consists of all x such that α < x < β; this is called an open interval. > > The book is typeset beautifully, and I believe they could’ve used three dots if they wanted, but they used two. Since then, the Hoare-Ramshaw interval notation has been incorporated into various programming languages, including Pascal and Haskell. > > I have no idea why the proposal uses three dots, actually. > > - Vlad > > > On 1 Mar 2022, at 17:42, Joachim Breitner wrote: > > > > Hi, > > > > it’s a worthwhile observation that we (somewhat oddly) use a two-dot > > ellipsis in ASCII-Haskell, and Artem took this up on Github to ponder > > if we should allow ASCII ... as well, but I am not convinced. I wrote > > on the Github thread: > > > > > Hmm, I am not sure I agree that it's confusing. At least to me, from > > > the start when I saw Haskell, the ascii .. meant what's \ldots in > > > LaTeX, and what I tend to write as three close-to-each other dots on > > > paper and is semantically an ellipsis, which in Unicode has a > > > codepoint with that names that in most fonts looks like what you > > > expect it to… > > > > > > So the .. is an ASCII cludge like all others (probably because ... is > > > unnecessarily wide). > > > > > > The analogue is \ for λ - just because the left leg is missing we > > > wouldn't use a unrelated look-alike like \ for the unicode variant, > > > nor ask to be able to write ,\ in ASCII for a better approximation of > > > the real letter. > > > > > > TL;DR: no need to change ASCII-Haskell, and let's use the > > > semantically correct ellipsis symbol in Unicode-Haskell. > > > > Vlad, how firm is your -1? If you feel strongly enough about it (which > > is of course absolutely fine), I’d maybe just put this up for a vote? > > It’s a mostly aesthetical, superficial change where voting may be more > > efficient than long discussions. > > > > Cheers, > > 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 -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From lists at richarde.dev Tue Mar 1 19:26:18 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Tue, 1 Mar 2022 19:26:18 +0000 Subject: [ghc-steering-committee] Welcome Baldur and Chris, welcome again Eric, and Farewell Vitaly In-Reply-To: References: Message-ID: <010f017f46f298cb-a5b6edcf-4958-4c47-b30f-8b2338d0ab6e-000000@us-east-2.amazonses.com> Welcome to all! Baldur and Chris, please do subscribe to this list at https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee, or I can arrange a subscription for you, if you send me your preferred email address. Also, please do check out https://github.com/ghc-proposals/ghc-proposals/blob/master/GRC.rst, our Guidelines For Respectful Communication, which intends to cover committee members in their participation across the Haskell sphere. And, finally, thanks Vitaly, for working with us. :) I will not unsubscribe you from the list (anyone can subscribe, actually), but you may wish to do so. Richard > On Mar 1, 2022, at 3:17 AM, Joachim Breitner wrote: > > Dear Committee and wider community, > > thanks to everyone who has put forward their nominations this round, > and we are happy to welcome > > Chris Dornan, Baldur Blöndal and Eric Seidel > > as new or, in the case of Eric, re-joining members of the GHC Steering > Committee! > > Chris and Baldur, if you haven’t already, please subscribe to our > mailing list at > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > and familiarize yourself with our processes at > https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst > and > https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst > > You’ll find a list of proposals under discussion at > https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+committee+review%22 > and your opinion is welcome on all of them. > > The committee wants to thank Vitaly Bragilevsky for his full term of > service on the committe. Your contributions were valued, and I > certainly would be happy to see your nomination again at some point in > the future. > > The next regular call for nominations (early resignations > notwithstanding) will likely be in January 2023. > > Cheers, > 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 From lists at richarde.dev Tue Mar 1 19:45:36 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Tue, 1 Mar 2022 19:45:36 +0000 Subject: [ghc-steering-committee] #475: New tuple and list syntax, rec: accept In-Reply-To: References: <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com> <010f017eff25a113-34a9d84d-399d-4252-a938-cbea1283cc96-000000@us-east-2.amazonses.com> <010f017f41a0b450-f6350d30-4226-4ca9-a9c4-8f969ea020a3-000000@us-east-2.amazonses.com> Message-ID: <010f017f470443e4-8d07440c-9668-49ba-b63c-e9e0018755cc-000000@us-east-2.amazonses.com> Between (2) and (3), I'm leaning toward (3). I'm not bothered by the loopiness, and it has the nice properties written in the proposal. I have also come to lean against (1) at all. Maybe if there's a clamor for it, we can add it later, but I see it as unnecessary. Even if we could make it the primitive definition for tuples (and I bet we could, via data instances), its kind is quite complex and could be a real stumbling block for newcomers and experienced Haskellers alike. For something as fundamental as tuples, I would want to keep the basic definition quite simple. Richard > On Mar 1, 2022, at 10:10 AM, Joachim Breitner wrote: > > Hi, > > Am Montag, dem 28.02.2022 um 22:31 +0300 schrieb Vladislav Zavialov > (int-index): >> There’s also a new alternative described in the proposal. Here are our options: >> 1. TupleN A B C >> 2. Tuple [A, B, C] >> 3. Tuple (A, B, C) — NEW > > I am not convinced it’s a good idea to introduce many ways of naming > the same thing, and given that the above three are already in addition > to the primitive (Tuple2 Bool Int), (which I’ll call (0) below), we > need a good justification to have more than one. > > Between (2) and (3), I’d prefer (3): The strange loop of tuples > referring to tuples isn’t too unhaskellish, and if it works better for > unboxed tuples, then yay! > > Between (3) and (1) I am unsure. Presumably, if we didn’t have (3) we’d > use the less idiosyncratic name `Tuple` for (1)? > > Are there other, not purely cosmetic, differences between (1) and (3)? > Maybe related to partial application? > > > > It’s a bit sad we can't just have (1) without even needing (0), so that > there really is only _one_ name that’s reasonably ergonomic. How far > out would that be? Worth making Haskell good enough to support a nice > design here? :-) > > Cheers, > 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 From bravit111 at gmail.com Wed Mar 2 09:10:59 2022 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Wed, 2 Mar 2022 12:10:59 +0300 Subject: [ghc-steering-committee] Welcome Baldur and Chris, welcome again Eric, and Farewell Vitaly In-Reply-To: <010f017f46f298cb-a5b6edcf-4958-4c47-b30f-8b2338d0ab6e-000000@us-east-2.amazonses.com> References: <010f017f46f298cb-a5b6edcf-4958-4c47-b30f-8b2338d0ab6e-000000@us-east-2.amazonses.com> Message-ID: Hi, thank you all! It was a pleasure for me to work with you! Vitaly вт, 1 мар. 2022 г. в 22:26, Richard Eisenberg : > Welcome to all! > > Baldur and Chris, please do subscribe to this list at > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee, > or I can arrange a subscription for you, if you send me your preferred > email address. > > Also, please do check out > https://github.com/ghc-proposals/ghc-proposals/blob/master/GRC.rst, our > Guidelines For Respectful Communication, which intends to cover committee > members in their participation across the Haskell sphere. > > And, finally, thanks Vitaly, for working with us. :) I will not > unsubscribe you from the list (anyone can subscribe, actually), but you may > wish to do so. > > Richard > > > On Mar 1, 2022, at 3:17 AM, Joachim Breitner > wrote: > > > > Dear Committee and wider community, > > > > thanks to everyone who has put forward their nominations this round, > > and we are happy to welcome > > > > Chris Dornan, Baldur Blöndal and Eric Seidel > > > > as new or, in the case of Eric, re-joining members of the GHC Steering > > Committee! > > > > Chris and Baldur, if you haven’t already, please subscribe to our > > mailing list at > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > and familiarize yourself with our processes at > > https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst > > and > > https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst > > > > You’ll find a list of proposals under discussion at > > > https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+committee+review%22 > > and your opinion is welcome on all of them. > > > > The committee wants to thank Vitaly Bragilevsky for his full term of > > service on the committe. Your contributions were valued, and I > > certainly would be happy to see your nomination again at some point in > > the future. > > > > The next regular call for nominations (early resignations > > notwithstanding) will likely be in January 2023. > > > > Cheers, > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Mon Mar 7 10:49:09 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Mon, 7 Mar 2022 11:49:09 +0100 Subject: [ghc-steering-committee] #475: New tuple and list syntax, rec: accept In-Reply-To: <010f017f470443e4-8d07440c-9668-49ba-b63c-e9e0018755cc-000000@us-east-2.amazonses.com> References: <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com> <010f017eff25a113-34a9d84d-399d-4252-a938-cbea1283cc96-000000@us-east-2.amazonses.com> <010f017f41a0b450-f6350d30-4226-4ca9-a9c4-8f969ea020a3-000000@us-east-2.amazonses.com> <010f017f470443e4-8d07440c-9668-49ba-b63c-e9e0018755cc-000000@us-east-2.amazonses.com> Message-ID: I'm indifferent between (2) and (3). I'm still somewhat unconvinced, though. I understand that this is working towards the Syntax Unification principle. But I don't think that the result pays for itself quite yet. On Tue, Mar 1, 2022 at 8:45 PM Richard Eisenberg wrote: > Between (2) and (3), I'm leaning toward (3). I'm not bothered by the > loopiness, and it has the nice properties written in the proposal. > > I have also come to lean against (1) at all. Maybe if there's a clamor for > it, we can add it later, but I see it as unnecessary. Even if we could make > it the primitive definition for tuples (and I bet we could, via data > instances), its kind is quite complex and could be a real stumbling block > for newcomers and experienced Haskellers alike. For something as > fundamental as tuples, I would want to keep the basic definition quite > simple. > > Richard > > > On Mar 1, 2022, at 10:10 AM, Joachim Breitner > wrote: > > > > Hi, > > > > Am Montag, dem 28.02.2022 um 22:31 +0300 schrieb Vladislav Zavialov > > (int-index): > >> There’s also a new alternative described in the proposal. Here are our > options: > >> 1. TupleN A B C > >> 2. Tuple [A, B, C] > >> 3. Tuple (A, B, C) — NEW > > > > I am not convinced it’s a good idea to introduce many ways of naming > > the same thing, and given that the above three are already in addition > > to the primitive (Tuple2 Bool Int), (which I’ll call (0) below), we > > need a good justification to have more than one. > > > > Between (2) and (3), I’d prefer (3): The strange loop of tuples > > referring to tuples isn’t too unhaskellish, and if it works better for > > unboxed tuples, then yay! > > > > Between (3) and (1) I am unsure. Presumably, if we didn’t have (3) we’d > > use the less idiosyncratic name `Tuple` for (1)? > > > > Are there other, not purely cosmetic, differences between (1) and (3)? > > Maybe related to partial application? > > > > > > > > It’s a bit sad we can't just have (1) without even needing (0), so that > > there really is only _one_ name that’s reasonably ergonomic. How far > > out would that be? Worth making Haskell good enough to support a nice > > design here? :-) > > > > Cheers, > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldurpet at gmail.com Fri Mar 11 01:14:00 2022 From: baldurpet at gmail.com (=?UTF-8?Q?Baldur_Bl=C3=B6ndal?=) Date: Fri, 11 Mar 2022 01:14:00 +0000 Subject: [ghc-steering-committee] Welcome Baldur and Chris, welcome again Eric, and Farewell Vitaly In-Reply-To: References: Message-ID: Hello everyone. Excited to be on board :) 2022-03-01 8:17 GMT, Joachim Breitner : > Dear Committee and wider community, > > thanks to everyone who has put forward their nominations this round, > and we are happy to welcome > > Chris Dornan, Baldur Blöndal and Eric Seidel > > as new or, in the case of Eric, re-joining members of the GHC Steering > Committee! > > Chris and Baldur, if you haven’t already, please subscribe to our > mailing list at > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > and familiarize yourself with our processes at > https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst > and > https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst > > You’ll find a list of proposals under discussion at > https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+committee+review%22 > and your opinion is welcome on all of them. > > The committee wants to thank Vitaly Bragilevsky for his full term of > service on the committe. Your contributions were valued, and I > certainly would be happy to see your nomination again at some point in > the future. > > The next regular call for nominations (early resignations > notwithstanding) will likely be in January 2023. > > Cheers, > Joachim > > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > From mail at joachim-breitner.de Tue Mar 15 15:35:20 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 15 Mar 2022 16:35:20 +0100 Subject: [ghc-steering-committee] #477: Unicode ellipsis, recommendation: accept, please vote In-Reply-To: References: Message-ID: <174d7ad4b756ca192fec2f00775f7f8744bf81de.camel@joachim-breitner.de> Dear Commitee! https://github.com/ghc-proposals/ghc-proposals/pull/477 https://github.com/kindaro/ghc-proposals/blob/unicode-ellipsis/proposals/477-unicode-ellipsis.md It turns out this simple change isn’t so simple after all. Maybe just Wadler’s law again… Anyways, it seems all arguments have been brought before, and it’s up to us to make a decision. A concise summary could be: Ignat suggests that under -XUnicodeSyntax, the `…` symbol can be used instead of `..` (e.g. import Prelude (Maybe(…)), [1…10]). This is roughly a very reasonable thing to do under -XUnicodeSyntax, at least for the former use, where `..` clearly is an ellipsised omission. The wrinkle is the range syntax: Vlad researched that there the two-dot syntax has historic precendent going back to Knuth and is used in other languages, and that it is _not_ just a bad ASCII approximation of a three dot … ellipsis, but really it’s own symbol, and pushed back because of that. He does not contest the use of … in export/import statements, though. A possible rebuttal is that despite the existence of a two-dot-range notation in some contexts, it is not _that_ universal, and it is still a form of omission for which an ellipsis (…) is a semantically suitable symbol. Pragmatically, I’d argue it would be a bad idea to allow … instead of .. only in import/export lists, but not range syntax. So my recommendation is as before (but maybe a bit more weakly): Don’t let perfect get in the way of good and accept the proposal, despite the history aspects of the [1..10] syntax, to improve -XUnicodeSyntax for the Unicode fans out there, and keeping the mapping between Unicode syntax and ASCII syntax in Haskell one-to-one. Vlad said on Github he is still opposed, but more weakly. The existence of this surprisingly long discussion may be an indication that this feature is not worth it. To avoid an out-of-proportion discussion (for a change of that relative now implication), I suggest to simply vote. I have seen +1 from Arnaud, Richard, and SPJ, and a -1 from Vlad. Let me know if any of you changed their mind, and the others: let me know which way you are leaning. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From marlowsd at gmail.com Tue Mar 15 15:55:34 2022 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 15 Mar 2022 15:55:34 +0000 Subject: [ghc-steering-committee] #477: Unicode ellipsis, recommendation: accept, please vote In-Reply-To: <174d7ad4b756ca192fec2f00775f7f8744bf81de.camel@joachim-breitner.de> References: <174d7ad4b756ca192fec2f00775f7f8744bf81de.camel@joachim-breitner.de> Message-ID: I find it hard to care a great deal about this, but I appreciate all the effort you and others have gone to to try to find the right solution. +0.5 Cheers Simon On Tue, 15 Mar 2022 at 15:35, Joachim Breitner wrote: > Dear Commitee! > > https://github.com/ghc-proposals/ghc-proposals/pull/477 > > https://github.com/kindaro/ghc-proposals/blob/unicode-ellipsis/proposals/477-unicode-ellipsis.md > > It turns out this simple change isn’t so simple after all. Maybe just > Wadler’s law again… Anyways, it seems all arguments have been brought > before, and it’s up to us to make a decision. A concise summary could > be: > > Ignat suggests that under -XUnicodeSyntax, the `…` symbol can be used > instead of `..` (e.g. import Prelude (Maybe(…)), [1…10]). This is > roughly a very reasonable thing to do under -XUnicodeSyntax, at least > for the former use, where `..` clearly is an ellipsised omission. > > The wrinkle is the range syntax: Vlad researched that there the two-dot > syntax has historic precendent going back to Knuth and is used in other > languages, and that it is _not_ just a bad ASCII approximation of a > three dot … ellipsis, but really it’s own symbol, and pushed back > because of that. He does not contest the use of … in export/import > statements, though. > > A possible rebuttal is that despite the existence of a two-dot-range > notation in some contexts, it is not _that_ universal, and it is still > a form of omission for which an ellipsis (…) is a semantically suitable > symbol. > > Pragmatically, I’d argue it would be a bad idea to allow … instead of > .. only in import/export lists, but not range syntax. > > So my recommendation is as before (but maybe a bit more weakly): Don’t > let perfect get in the way of good and accept the proposal, despite the > history aspects of the [1..10] syntax, to improve -XUnicodeSyntax for > the Unicode fans out there, and keeping the mapping between Unicode > syntax and ASCII syntax in Haskell one-to-one. > > Vlad said on Github he is still opposed, but more weakly. The existence > of this surprisingly long discussion may be an indication that this > feature is not worth it. > > To avoid an out-of-proportion discussion (for a change of that relative > now implication), I suggest to simply vote. > > I have seen +1 from Arnaud, Richard, and SPJ, and a -1 from Vlad. Let > me know if any of you changed their mind, and the others: let me know > which way you are leaning. > > Cheers, > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Tue Mar 15 17:40:42 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 15 Mar 2022 17:40:42 +0000 Subject: [ghc-steering-committee] #477: Unicode ellipsis, recommendation: accept, please vote In-Reply-To: <174d7ad4b756ca192fec2f00775f7f8744bf81de.camel@joachim-breitner.de> References: <174d7ad4b756ca192fec2f00775f7f8744bf81de.camel@joachim-breitner.de> Message-ID: I really don't have a well-informed opinion here. I'm happy to accept provided it doesn't add an unreasonable complexity burden to the implementation (which I doubt it will). Simon On Tue, 15 Mar 2022 at 15:35, Joachim Breitner wrote: > Dear Commitee! > > https://github.com/ghc-proposals/ghc-proposals/pull/477 > > https://github.com/kindaro/ghc-proposals/blob/unicode-ellipsis/proposals/477-unicode-ellipsis.md > > It turns out this simple change isn’t so simple after all. Maybe just > Wadler’s law again… Anyways, it seems all arguments have been brought > before, and it’s up to us to make a decision. A concise summary could > be: > > Ignat suggests that under -XUnicodeSyntax, the `…` symbol can be used > instead of `..` (e.g. import Prelude (Maybe(…)), [1…10]). This is > roughly a very reasonable thing to do under -XUnicodeSyntax, at least > for the former use, where `..` clearly is an ellipsised omission. > > The wrinkle is the range syntax: Vlad researched that there the two-dot > syntax has historic precendent going back to Knuth and is used in other > languages, and that it is _not_ just a bad ASCII approximation of a > three dot … ellipsis, but really it’s own symbol, and pushed back > because of that. He does not contest the use of … in export/import > statements, though. > > A possible rebuttal is that despite the existence of a two-dot-range > notation in some contexts, it is not _that_ universal, and it is still > a form of omission for which an ellipsis (…) is a semantically suitable > symbol. > > Pragmatically, I’d argue it would be a bad idea to allow … instead of > .. only in import/export lists, but not range syntax. > > So my recommendation is as before (but maybe a bit more weakly): Don’t > let perfect get in the way of good and accept the proposal, despite the > history aspects of the [1..10] syntax, to improve -XUnicodeSyntax for > the Unicode fans out there, and keeping the mapping between Unicode > syntax and ASCII syntax in Haskell one-to-one. > > Vlad said on Github he is still opposed, but more weakly. The existence > of this surprisingly long discussion may be an indication that this > feature is not worth it. > > To avoid an out-of-proportion discussion (for a change of that relative > now implication), I suggest to simply vote. > > I have seen +1 from Arnaud, Richard, and SPJ, and a -1 from Vlad. Let > me know if any of you changed their mind, and the others: let me know > which way you are leaning. > > Cheers, > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Wed Mar 16 17:06:27 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 16 Mar 2022 18:06:27 +0100 Subject: [ghc-steering-committee] #477: Unicode ellipsis, recommendation: accept, please vote In-Reply-To: References: <174d7ad4b756ca192fec2f00775f7f8744bf81de.camel@joachim-breitner.de> Message-ID: I haven't changed my opinion. It's a trivial change. The whole discussion on two versus three dots has not been particularly clarifying for me. It sounds as though there is no perfect solution there, so I guess a regular ellipsis is a reasonable choice. On Tue, Mar 15, 2022 at 6:41 PM Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > I really don't have a well-informed opinion here. I'm happy to accept > provided it doesn't add an unreasonable complexity burden to the > implementation (which I doubt it will). > > Simon > > On Tue, 15 Mar 2022 at 15:35, Joachim Breitner > wrote: > >> Dear Commitee! >> >> https://github.com/ghc-proposals/ghc-proposals/pull/477 >> >> https://github.com/kindaro/ghc-proposals/blob/unicode-ellipsis/proposals/477-unicode-ellipsis.md >> >> It turns out this simple change isn’t so simple after all. Maybe just >> Wadler’s law again… Anyways, it seems all arguments have been brought >> before, and it’s up to us to make a decision. A concise summary could >> be: >> >> Ignat suggests that under -XUnicodeSyntax, the `…` symbol can be used >> instead of `..` (e.g. import Prelude (Maybe(…)), [1…10]). This is >> roughly a very reasonable thing to do under -XUnicodeSyntax, at least >> for the former use, where `..` clearly is an ellipsised omission. >> >> The wrinkle is the range syntax: Vlad researched that there the two-dot >> syntax has historic precendent going back to Knuth and is used in other >> languages, and that it is _not_ just a bad ASCII approximation of a >> three dot … ellipsis, but really it’s own symbol, and pushed back >> because of that. He does not contest the use of … in export/import >> statements, though. >> >> A possible rebuttal is that despite the existence of a two-dot-range >> notation in some contexts, it is not _that_ universal, and it is still >> a form of omission for which an ellipsis (…) is a semantically suitable >> symbol. >> >> Pragmatically, I’d argue it would be a bad idea to allow … instead of >> .. only in import/export lists, but not range syntax. >> >> So my recommendation is as before (but maybe a bit more weakly): Don’t >> let perfect get in the way of good and accept the proposal, despite the >> history aspects of the [1..10] syntax, to improve -XUnicodeSyntax for >> the Unicode fans out there, and keeping the mapping between Unicode >> syntax and ASCII syntax in Haskell one-to-one. >> >> Vlad said on Github he is still opposed, but more weakly. The existence >> of this surprisingly long discussion may be an indication that this >> feature is not worth it. >> >> To avoid an out-of-proportion discussion (for a change of that relative >> now implication), I suggest to simply vote. >> >> I have seen +1 from Arnaud, Richard, and SPJ, and a -1 from Vlad. Let >> me know if any of you changed their mind, and the others: let me know >> which way you are leaning. >> >> Cheers, >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlad.z.4096 at gmail.com Sat Mar 19 20:22:07 2022 From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index)) Date: Sat, 19 Mar 2022 23:22:07 +0300 Subject: [ghc-steering-committee] #475: New tuple and list syntax, rec: accept In-Reply-To: References: <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com> <010f017eff25a113-34a9d84d-399d-4252-a938-cbea1283cc96-000000@us-east-2.amazonses.com> <010f017f41a0b450-f6350d30-4226-4ca9-a9c4-8f969ea020a3-000000@us-east-2.amazonses.com> <010f017f470443e4-8d07440c-9668-49ba-b63c-e9e0018755cc-000000@us-east-2.amazonses.com> Message-ID: <09752975-A9CC-4FD1-A2F4-F44F854722DC@gmail.com> Dear Committee, it’s time to round up our discussion of #475. My impression of the discussion is as follows: • Arnaud is skeptical but does not veto. • Tom is in generally favor. • Simon, Richard, and Joachim are in favor and prefer Tuple (A, B, C) over Tuple [A, B, C] • Vitaly and I are in favor and prefer Tuple [A, B, C] over Tuple (A, B, C) • Everyone agrees to drop TupleN. Thus, the proposal requires the following modifications: 1. Move TupleN, CTupleN, TupleN#, and SumN# to Alternatives. 2. Move Tuple [A, B, C] to Alternatives, and move Tuple (A, B, C) from Alternatives to Proposed Change Specification. Then we can accept. Richard, could you do the necessary edits please? - Vlad From lists at richarde.dev Mon Mar 21 20:24:47 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Mon, 21 Mar 2022 20:24:47 +0000 Subject: [ghc-steering-committee] #475: New tuple and list syntax, rec: accept In-Reply-To: <09752975-A9CC-4FD1-A2F4-F44F854722DC@gmail.com> References: <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com> <010f017eff25a113-34a9d84d-399d-4252-a938-cbea1283cc96-000000@us-east-2.amazonses.com> <010f017f41a0b450-f6350d30-4226-4ca9-a9c4-8f969ea020a3-000000@us-east-2.amazonses.com> <010f017f470443e4-8d07440c-9668-49ba-b63c-e9e0018755cc-000000@us-east-2.amazonses.com> <09752975-A9CC-4FD1-A2F4-F44F854722DC@gmail.com> Message-ID: <010f017fae275517-82dda122-1148-4fa6-8bd0-dcad9964ef77-000000@us-east-2.amazonses.com> I have done this, and pushed. > On Mar 19, 2022, at 4:22 PM, Vladislav Zavialov (int-index) wrote: > > Dear Committee, > > it’s time to round up our discussion of #475. > > My impression of the discussion is as follows: > • Arnaud is skeptical but does not veto. > • Tom is in generally favor. > • Simon, Richard, and Joachim are in favor and prefer Tuple (A, B, C) over Tuple [A, B, C] > • Vitaly and I are in favor and prefer Tuple [A, B, C] over Tuple (A, B, C) > • Everyone agrees to drop TupleN. > > Thus, the proposal requires the following modifications: > 1. Move TupleN, CTupleN, TupleN#, and SumN# to Alternatives. > 2. Move Tuple [A, B, C] to Alternatives, and move Tuple (A, B, C) from Alternatives to Proposed Change Specification. > > Then we can accept. > > Richard, could you do the necessary edits please? > > - Vlad From mail at joachim-breitner.de Thu Mar 24 17:59:47 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 24 Mar 2022 18:59:47 +0100 Subject: [ghc-steering-committee] #475: New tuple and list syntax, rec: accept In-Reply-To: <010f017fae275517-82dda122-1148-4fa6-8bd0-dcad9964ef77-000000@us-east-2.amazonses.com> References: <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com> <010f017eff25a113-34a9d84d-399d-4252-a938-cbea1283cc96-000000@us-east-2.amazonses.com> <010f017f41a0b450-f6350d30-4226-4ca9-a9c4-8f969ea020a3-000000@us-east-2.amazonses.com> <010f017f470443e4-8d07440c-9668-49ba-b63c-e9e0018755cc-000000@us-east-2.amazonses.com> <09752975-A9CC-4FD1-A2F4-F44F854722DC@gmail.com> <010f017fae275517-82dda122-1148-4fa6-8bd0-dcad9964ef77-000000@us-east-2.amazonses.com> Message-ID: <41e5fbdfd7e35913f7895ca9e31c2344faec2110.camel@joachim-breitner.de> merged! thanks all Am Montag, dem 21.03.2022 um 20:24 +0000 schrieb Richard Eisenberg: > I have done this, and pushed. > > > On Mar 19, 2022, at 4:22 PM, Vladislav Zavialov (int-index) wrote: > > > > Dear Committee, > > > > it’s time to round up our discussion of #475. > > > > My impression of the discussion is as follows: > > • Arnaud is skeptical but does not veto. > > • Tom is in generally favor. > > • Simon, Richard, and Joachim are in favor and prefer Tuple (A, B, C) over Tuple [A, B, C] > > • Vitaly and I are in favor and prefer Tuple [A, B, C] over Tuple (A, B, C) > > • Everyone agrees to drop TupleN. > > > > Thus, the proposal requires the following modifications: > > 1. Move TupleN, CTupleN, TupleN#, and SumN# to Alternatives. > > 2. Move Tuple [A, B, C] to Alternatives, and move Tuple (A, B, C) from Alternatives to Proposed Change Specification. > > > > Then we can accept. > > > > Richard, could you do the necessary edits please? > > > > - Vlad > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From rae at richarde.dev Thu Mar 24 18:47:22 2022 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 24 Mar 2022 18:47:22 +0000 Subject: [ghc-steering-committee] #425: invisible binders in type declarations; rec: accept In-Reply-To: References: <010f017c9a6cb57b-e38b9e0a-f446-4435-8cb8-1cbf39b4861d-000000@us-east-2.amazonses.com> Message-ID: <010f017fbd4137d2-8baa4a75-360f-4195-9343-0e0ce10c3450-000000@us-east-2.amazonses.com> Hi committee, I re-recommend acceptance for this proposal. The main payload of the proposal is to allow definitions like > data Proxy @k (a :: k) = Proxy instead of today's > data Proxy (a :: k) = Proxy which has no explicit binding site for k. This new syntax solves a number of smallish syntax conundra, as very well outlined in the proposal. Along with this primary change, there is some cleanup of (loosely) related syntax: - a type synonym declaration is now required to mention all kind variables on its left-hand side (previously, you could introduce a kind variable only on the right in some circumstances) - arity inference for type synonyms and families with trailing invisible quantifiers is simplified (you've never written such a thing, I'm sure -- and yet GHC currently has special handling for this bit of esoterica) - a type family equation must now mention all kind variables on its left-hand side (just like the new rule for type synonyms) - a type family equation must now determine instantiation of all kind variables via the left-hand side patterns (this vastly increases readability and avoids some confusing behavior) The cleanups can all break existing code. And so I posted on Discourse seeking community feedback. The feedback did not suggest this breakage would cause wide harm. And thus this re-recommendation of acceptance. Please let us know what you think. I will go on holiday after April 4, so I hope to accept this proposal then. Thanks! Richard > On Oct 25, 2021, at 3:24 AM, Spiwack, Arnaud wrote: > > My weak objections are no match for Simon's strong keenness :-) . > > I should say that, egoistically, I'd also like 5,6,7 to happen. I was only expressing concerns about the price. > > On Fri, Oct 22, 2021 at 1:00 PM Simon Peyton Jones > wrote: > I’m in strong support. This tidies up the design nicely. > > > > I am particularly keen on 5,6,7; indeed I wrote a whole proposal about it, which Vlad has #included here > > > > https://github.com/ghc-proposals/ghc-proposals/pull/386 > > > Simon > > > > PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com will cease to work. Use simon.peytonjones at gmail.com instead. (For now, it just forwards to simonpj at microsoft.com .) > > > > From: ghc-steering-committee > On Behalf Of Spiwack, Arnaud > Sent: 21 October 2021 08:03 > To: Richard Eisenberg > > Cc: ghc-steering-committee > > Subject: Re: [ghc-steering-committee] #425: invisible binders in type declarations; rec: accept > > > > I'm generally in favour. But I'm not convinced that the secondary changes (points 4–7) are worth it. They are certainly better place than we are today, but are they worth breaking existing code for? Point 5–7 can probably be replaced by warnings. I don't know about 4. > > > > On Tue, Oct 19, 2021 at 11:20 PM Richard Eisenberg > wrote: > > Hi all, > > I am the shepherd for proposal #425, https://github.com/ghc-proposals/ghc-proposals/pull/425 , proposing to add invisible binders in type declarations. > > The main payload of the proposal is to allow definitions like > > > data Proxy @k (a :: k) = Proxy > > instead of today's > > > data Proxy (a :: k) = Proxy > > which has no explicit binding site for k. > > This new syntax solves a number of smallish syntax conundra, as very well outlined in the proposal. > > In addition, the proposal includes two small unrelated tweaks to the syntax of type family instances; these are points (6) and (7) in the proposal. Both changes will break some obscure (but still realistic, knowing Haskell) programs, but both fixes are backward compatible. > > --- > > I recommend acceptance. The proposal is motivated nicely (do check out the examples) and solves a real problem. The new syntax fits in with other similar features. The small cleanups to existing syntax will lead to better error messages. > > The one drawback, as I see it, is that this proposal includes point (5), which is a breaking change to the way type synonyms work. Right now, we can say > > > type P = (Proxy :: k -> Type) > > and GHC will infer P :: forall k. k -> Type. Under this proposal, you would have to write > > > type P @k = (Proxy :: k -> Type) > > bringing k into scope explicitly. The fix is not backward compatible, and so I think this proposal should come with a migration strategy, where we warn about the former version for some releases before banning it. (Continuing to support it is possible, but it's very awkward to have a variable mentioned only in a synonym's right-hand side.) > > Sorry for the delay in producing this recommendation! > Richard > _______________________________________________ > 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: From simon.peytonjones at gmail.com Thu Mar 24 22:27:24 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 24 Mar 2022 22:27:24 +0000 Subject: [ghc-steering-committee] #425: invisible binders in type declarations; rec: accept In-Reply-To: <010f017fbd4137d2-8baa4a75-360f-4195-9343-0e0ce10c3450-000000@us-east-2.amazonses.com> References: <010f017c9a6cb57b-e38b9e0a-f446-4435-8cb8-1cbf39b4861d-000000@us-east-2.amazonses.com> <010f017fbd4137d2-8baa4a75-360f-4195-9343-0e0ce10c3450-000000@us-east-2.amazonses.com> Message-ID: I strongly support Simon On Thu, 24 Mar 2022 at 18:47, Richard Eisenberg wrote: > Hi committee, > > I re-recommend acceptance for this proposal. > > The main payload of the proposal is to allow definitions like > > data Proxy @k (a :: k) = Proxy > > > instead of today's > > data Proxy (a :: k) = Proxy > > > which has no explicit binding site for k. > > This new syntax solves a number of smallish syntax conundra, as very well > outlined in the proposal. > > Along with this primary change, there is some cleanup of (loosely) related > syntax: > - a type synonym declaration is now required to mention all kind > variables on its left-hand side (previously, you could introduce a kind > variable only on the right in some circumstances) > - arity inference for type synonyms and families with trailing invisible > quantifiers is simplified (you've never written such a thing, I'm sure -- > and yet GHC currently has special handling for this bit of esoterica) > - a type family equation must now mention all kind variables on its > left-hand side (just like the new rule for type synonyms) > - a type family equation must now determine instantiation of all kind > variables via the left-hand side patterns (this vastly increases > readability and avoids some confusing behavior) > > The cleanups can all break existing code. And so I posted on Discourse > seeking > community feedback. The feedback did not suggest this breakage would cause > wide harm. And thus this re-recommendation of acceptance. > > Please let us know what you think. I will go on holiday after April 4, so > I hope to accept this proposal then. > > Thanks! > Richard > > On Oct 25, 2021, at 3:24 AM, Spiwack, Arnaud > wrote: > > My weak objections are no match for Simon's strong keenness :-) . > > I should say that, egoistically, I'd also like 5,6,7 to happen. I was only > expressing concerns about the price. > > On Fri, Oct 22, 2021 at 1:00 PM Simon Peyton Jones > wrote: > >> I’m in strong support. This tidies up the design nicely. >> >> >> >> I am particularly keen on 5,6,7; indeed I wrote a whole proposal about >> it, which Vlad has #included here >> >> >> >> https://github.com/ghc-proposals/ghc-proposals/pull/386 >> >> >> >> Simon >> >> >> >> PS: I am leaving Microsoft at the end of November 2021, at which point >> simonpj at microsoft.com will cease to work. Use >> simon.peytonjones at gmail.com instead. (For now, it just forwards to >> simonpj at microsoft.com.) >> >> >> >> *From:* ghc-steering-committee < >> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Spiwack, >> Arnaud >> *Sent:* 21 October 2021 08:03 >> *To:* Richard Eisenberg >> *Cc:* ghc-steering-committee >> *Subject:* Re: [ghc-steering-committee] #425: invisible binders in type >> declarations; rec: accept >> >> >> >> I'm generally in favour. But I'm not convinced that the secondary changes >> (points 4–7) are worth it. They are certainly better place than we are >> today, but are they worth breaking existing code for? Point 5–7 can >> probably be replaced by warnings. I don't know about 4. >> >> >> >> On Tue, Oct 19, 2021 at 11:20 PM Richard Eisenberg >> wrote: >> >> Hi all, >> >> I am the shepherd for proposal #425, >> https://github.com/ghc-proposals/ghc-proposals/pull/425 >> , >> proposing to add invisible binders in type declarations. >> >> The main payload of the proposal is to allow definitions like >> >> > data Proxy @k (a :: k) = Proxy >> >> instead of today's >> >> > data Proxy (a :: k) = Proxy >> >> which has no explicit binding site for k. >> >> This new syntax solves a number of smallish syntax conundra, as very well >> outlined in the proposal. >> >> In addition, the proposal includes two small unrelated tweaks to the >> syntax of type family instances; these are points (6) and (7) in the >> proposal. Both changes will break some obscure (but still realistic, >> knowing Haskell) programs, but both fixes are backward compatible. >> >> --- >> >> I recommend acceptance. The proposal is motivated nicely (do check out >> the examples) and solves a real problem. The new syntax fits in with other >> similar features. The small cleanups to existing syntax will lead to better >> error messages. >> >> The one drawback, as I see it, is that this proposal includes point (5), >> which is a breaking change to the way type synonyms work. Right now, we can >> say >> >> > type P = (Proxy :: k -> Type) >> >> and GHC will infer P :: forall k. k -> Type. Under this proposal, you >> would have to write >> >> > type P @k = (Proxy :: k -> Type) >> >> bringing k into scope explicitly. The fix is not backward compatible, and >> so I think this proposal should come with a migration strategy, where we >> warn about the former version for some releases before banning it. >> (Continuing to support it is possible, but it's very awkward to have a >> variable mentioned only in a synonym's right-hand side.) >> >> Sorry for the delay in producing this recommendation! >> Richard >> _______________________________________________ >> 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: From arnaud.spiwack at tweag.io Fri Mar 25 15:48:50 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Fri, 25 Mar 2022 16:48:50 +0100 Subject: [ghc-steering-committee] #425: invisible binders in type declarations; rec: accept In-Reply-To: References: <010f017c9a6cb57b-e38b9e0a-f446-4435-8cb8-1cbf39b4861d-000000@us-east-2.amazonses.com> <010f017fbd4137d2-8baa4a75-360f-4195-9343-0e0ce10c3450-000000@us-east-2.amazonses.com> Message-ID: I'm still in favour. Thinking back, this only breaks pretty advanced uses of type families and type synonyms that most users are unlikely to have stumbled across. There is a deprecation period which will make sure that we can transition most packages smoothly without holding the community back (some slow-changing packages will probably be missed, but hopefully not too many, in fact maybe it can be known by compiling all of hackage with the deprecation warning on and patched in time anyway). This should work. And the result is definitely much of an improvement compared to the current situation (which is a prototypical example of an aspect of Haskell where seasoned programmers show, with a smirk, to hardly-believing-it less experienced ones “did you know you could do this?”). /Arnaud On Thu, Mar 24, 2022 at 11:27 PM Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > I strongly support > > Simon > > On Thu, 24 Mar 2022 at 18:47, Richard Eisenberg wrote: > >> Hi committee, >> >> I re-recommend acceptance for this proposal. >> >> The main payload of the proposal is to allow definitions like >> >> data Proxy @k (a :: k) = Proxy >> >> >> instead of today's >> >> data Proxy (a :: k) = Proxy >> >> >> which has no explicit binding site for k. >> >> This new syntax solves a number of smallish syntax conundra, as very well >> outlined in the proposal. >> >> Along with this primary change, there is some cleanup of (loosely) >> related syntax: >> - a type synonym declaration is now required to mention all kind >> variables on its left-hand side (previously, you could introduce a kind >> variable only on the right in some circumstances) >> - arity inference for type synonyms and families with trailing invisible >> quantifiers is simplified (you've never written such a thing, I'm sure -- >> and yet GHC currently has special handling for this bit of esoterica) >> - a type family equation must now mention all kind variables on its >> left-hand side (just like the new rule for type synonyms) >> - a type family equation must now determine instantiation of all kind >> variables via the left-hand side patterns (this vastly increases >> readability and avoids some confusing behavior) >> >> The cleanups can all break existing code. And so I posted on Discourse >> seeking >> community feedback. The feedback did not suggest this breakage would cause >> wide harm. And thus this re-recommendation of acceptance. >> >> Please let us know what you think. I will go on holiday after April 4, so >> I hope to accept this proposal then. >> >> Thanks! >> Richard >> >> On Oct 25, 2021, at 3:24 AM, Spiwack, Arnaud >> wrote: >> >> My weak objections are no match for Simon's strong keenness :-) . >> >> I should say that, egoistically, I'd also like 5,6,7 to happen. I was >> only expressing concerns about the price. >> >> On Fri, Oct 22, 2021 at 1:00 PM Simon Peyton Jones >> wrote: >> >>> I’m in strong support. This tidies up the design nicely. >>> >>> >>> >>> I am particularly keen on 5,6,7; indeed I wrote a whole proposal about >>> it, which Vlad has #included here >>> >>> >>> >>> https://github.com/ghc-proposals/ghc-proposals/pull/386 >>> >>> >>> >>> Simon >>> >>> >>> >>> PS: I am leaving Microsoft at the end of November 2021, at which point >>> simonpj at microsoft.com will cease to work. Use >>> simon.peytonjones at gmail.com instead. (For now, it just forwards to >>> simonpj at microsoft.com.) >>> >>> >>> >>> *From:* ghc-steering-committee < >>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Spiwack, >>> Arnaud >>> *Sent:* 21 October 2021 08:03 >>> *To:* Richard Eisenberg >>> *Cc:* ghc-steering-committee >>> *Subject:* Re: [ghc-steering-committee] #425: invisible binders in type >>> declarations; rec: accept >>> >>> >>> >>> I'm generally in favour. But I'm not convinced that the secondary >>> changes (points 4–7) are worth it. They are certainly better place than we >>> are today, but are they worth breaking existing code for? Point 5–7 can >>> probably be replaced by warnings. I don't know about 4. >>> >>> >>> >>> On Tue, Oct 19, 2021 at 11:20 PM Richard Eisenberg >>> wrote: >>> >>> Hi all, >>> >>> I am the shepherd for proposal #425, >>> https://github.com/ghc-proposals/ghc-proposals/pull/425 >>> , >>> proposing to add invisible binders in type declarations. >>> >>> The main payload of the proposal is to allow definitions like >>> >>> > data Proxy @k (a :: k) = Proxy >>> >>> instead of today's >>> >>> > data Proxy (a :: k) = Proxy >>> >>> which has no explicit binding site for k. >>> >>> This new syntax solves a number of smallish syntax conundra, as very >>> well outlined in the proposal. >>> >>> In addition, the proposal includes two small unrelated tweaks to the >>> syntax of type family instances; these are points (6) and (7) in the >>> proposal. Both changes will break some obscure (but still realistic, >>> knowing Haskell) programs, but both fixes are backward compatible. >>> >>> --- >>> >>> I recommend acceptance. The proposal is motivated nicely (do check out >>> the examples) and solves a real problem. The new syntax fits in with other >>> similar features. The small cleanups to existing syntax will lead to better >>> error messages. >>> >>> The one drawback, as I see it, is that this proposal includes point (5), >>> which is a breaking change to the way type synonyms work. Right now, we can >>> say >>> >>> > type P = (Proxy :: k -> Type) >>> >>> and GHC will infer P :: forall k. k -> Type. Under this proposal, you >>> would have to write >>> >>> > type P @k = (Proxy :: k -> Type) >>> >>> bringing k into scope explicitly. The fix is not backward compatible, >>> and so I think this proposal should come with a migration strategy, where >>> we warn about the former version for some releases before banning it. >>> (Continuing to support it is possible, but it's very awkward to have a >>> variable mentioned only in a synonym's right-hand side.) >>> >>> Sorry for the delay in producing this recommendation! >>> Richard >>> _______________________________________________ >>> 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: From mail at joachim-breitner.de Sat Mar 26 15:10:22 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 26 Mar 2022 16:10:22 +0100 Subject: [ghc-steering-committee] #425: invisible binders in type declarations; rec: accept In-Reply-To: <010f017fbd4137d2-8baa4a75-360f-4195-9343-0e0ce10c3450-000000@us-east-2.amazonses.com> References: <010f017c9a6cb57b-e38b9e0a-f446-4435-8cb8-1cbf39b4861d-000000@us-east-2.amazonses.com> <010f017fbd4137d2-8baa4a75-360f-4195-9343-0e0ce10c3450-000000@us-east-2.amazonses.com> Message-ID: <94d6346982d52e7b208e54060d4766b1cd49e486.camel@joachim-breitner.de> Hi, sounds good to me, thanks for the good summary. Cheers, Joachim Am Donnerstag, dem 24.03.2022 um 18:47 +0000 schrieb Richard Eisenberg: > Hi committee, > > I re-recommend acceptance for this proposal. > > The main payload of the proposal is to allow definitions like > > > data Proxy @k (a :: k) = Proxy > > instead of today's > > > data Proxy (a :: k) = Proxy > > which has no explicit binding site for k. > > This new syntax solves a number of smallish syntax conundra, as very > well outlined in the proposal. > > Along with this primary change, there is some cleanup of (loosely) > related syntax: >  - a type synonym declaration is now required to mention all kind > variables on its left-hand side (previously, you could introduce a > kind variable only on the right in some circumstances) >  - arity inference for type synonyms and families with trailing > invisible quantifiers is simplified (you've never written such a > thing, I'm sure -- and yet GHC currently has special handling for > this bit of esoterica) >  - a type family equation must now mention all kind variables on its > left-hand side (just like the new rule for type synonyms) >  - a type family equation must now determine instantiation of all > kind variables via the left-hand side patterns (this vastly increases > readability and avoids some confusing behavior) > > The cleanups can all break existing code. And so I posted on > Discourse seeking community feedback. The feedback did not suggest > this breakage would cause wide harm. And thus this re-recommendation > of acceptance. > > Please let us know what you think. I will go on holiday after April > 4, so I hope to accept this proposal then. > > Thanks! > Richard > > > > On Oct 25, 2021, at 3:24 AM, Spiwack, Arnaud > > wrote: > > > > My weak objections are no match for Simon's strong keenness :-) . > > > > I should say that, egoistically, I'd also like 5,6,7 to happen. I > > was only expressing concerns about the price. > > > > On Fri, Oct 22, 2021 at 1:00 PM Simon Peyton Jones > > wrote: > > > I’m in strong support.  This tidies up the design nicely. > > >   > > > I am particularly keen on 5,6,7; indeed I wrote a whole proposal > > > about it, which Vlad has #included here > > >   > > > https://github.com/ghc-proposals/ghc-proposals/pull/386 > > >   > > > Simon > > >   > > > PS: I am leaving Microsoft at the end of November 2021, at which > > > pointsimonpj at microsoft.com will cease to work.  > > > Usesimon.peytonjones at gmail.com instead.  (For now, it just > > > forwards to simonpj at microsoft.com.) > > >   > > > From: ghc-steering-committee > > > On Behalf Of Spiwack, > > > Arnaud > > > Sent: 21 October 2021 08:03 > > > To: Richard Eisenberg > > > Cc: ghc-steering-committee > > > Subject: Re: [ghc-steering-committee] #425: invisible binders in > > > type declarations; rec: accept > > >   > > > I'm generally in favour. But I'm not convinced that the secondary > > > changes (points 4–7) are worth it. They are certainly better > > > place than we are today, but are they worth breaking existing > > > code for? Point 5–7 can probably be replaced by warnings. I don't > > > know about 4. > > >   > > > On Tue, Oct 19, 2021 at 11:20 PM Richard Eisenberg > > > wrote: > > > > Hi all, > > > > > > > > I am the shepherd for proposal #425, > > > > https://github.com/ghc-proposals/ghc-proposals/pull/425, > > > > proposing to add invisible binders in type declarations. > > > > > > > > The main payload of the proposal is to allow definitions like > > > > > > > > > data Proxy @k (a :: k) = Proxy > > > > > > > > instead of today's > > > > > > > > > data Proxy (a :: k) = Proxy > > > > > > > > which has no explicit binding site for k. > > > > > > > > This new syntax solves a number of smallish syntax conundra, as > > > > very well outlined in the proposal. > > > > > > > > In addition, the proposal includes two small unrelated tweaks > > > > to the syntax of type family instances; these are points (6) > > > > and (7) in the proposal. Both changes will break some obscure > > > > (but still realistic, knowing Haskell) programs, but both fixes > > > > are backward compatible. > > > > > > > > --- > > > > > > > > I recommend acceptance. The proposal is motivated nicely (do > > > > check out the examples) and solves a real problem. The new > > > > syntax fits in with other similar features. The small cleanups > > > > to existing syntax will lead to better error messages. > > > > > > > > The one drawback, as I see it, is that this proposal includes > > > > point (5), which is a breaking change to the way type synonyms > > > > work. Right now, we can say > > > > > > > > > type P = (Proxy :: k -> Type) > > > > > > > > and GHC will infer P :: forall k. k -> Type. Under this > > > > proposal, you would have to write > > > > > > > > > type P @k = (Proxy :: k -> Type) > > > > > > > > bringing k into scope explicitly. The fix is not backward > > > > compatible, and so I think this proposal should come with a > > > > migration strategy, where we warn about the former version for > > > > some releases before banning it. (Continuing to support it is > > > > possible, but it's very awkward to have a variable mentioned > > > > only in a synonym's right-hand side.) > > > > > > > > Sorry for the delay in producing this recommendation! > > > > Richard > > > > _______________________________________________ > > > > 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 -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From arnaud.spiwack at tweag.io Tue Mar 29 15:01:19 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Tue, 29 Mar 2022 17:01:19 +0200 Subject: [ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept Message-ID: Dear all, Let me bring to your attention the Modern Scoped Type Variables proposal, by our own Richard https://github.com/ghc-proposals/ghc-proposals/pull/448 . The proposal is a touch intimidating, because the text is large. But most of it comes from other, already accepted, proposals that this proposal is tidying up and tying together. What this proposal tries to achieve is to make a consistent text about all the recent changes to binding type variables. The proposal adds new principles to the `principles.rst` files which inform the changes proposed, of these, I have the following comments: - The Visibility Orthogonality Principle doesn't seem to have a very clear definition. It may be a sign that it's not something that is so important - The Explicit Binding Principle says that we need to be able to enforce that all type variables have a binding site. I think it's a bit strong: I would like Haskell to let me write a binding site for every type variable, but not necessarily to error out when that doesn't happen. That being said, I'm happy with warnings to help me along the way, but I don't think that this Explicit Binding Principle should be phrased in a way that requires adding extensions to control this behaviour. - The Contiguous Scoping Principle, which states that a binder binds in one contiguous region sounds dubious to me. I don't see a particular reason for this to be. --- In the proposed changes themselves: up to Section 5, the proposed changes are mostly existing accepted proposals, cleaned up with what was learnt since they were written, as well as to adhere to the new principles. These are mostly uncontroversial and the specification makes sense to me. I'm in favour of accepting all that. With the caveat that this proposal introduces quite a few extensions. And at this point, I'm still not quite sure what Richard recommends is the set of extensions that I should use (and I'm slightly dismayed that I believe that it will be a set of cardinal more than 1). I think this reflects a vision of extensions as switches to customise the behaviour of GHC. This vision, as I've stated before, is very alien to me: I see extensions as staging areas for features to become an integral part of Haskell. So I don't know what to think of all these extensions. I'm definitely not against splitting -XScopedTypeVariables into smaller components, if it is done so that they are reassembled in a different way in an alternative extension that would now be the recommended default (or at least is to become the next recommended default). Finally, there are Sections 6 to 8. These are entirely new. Though they are working towards the new principles (well, as far as I can tell, Section 6 doesn't contribute to the principles, but it is a stepping stone for both Sections 7 and 8). These sections are concerned with adding local let-bindings of type variables, in particular inside types and patterns. By the way, Section 7 proposes two syntaxes for let binders in patterns, and I *strongly* prefer the second syntax, which reads something like `f (let b = Bool) (True :: Bool) = …`. Anyway, these are new, I feel that they are a bit out of place in a proposal that is about tidying up the existing designs. That being said, they are here, and they seem like fairly uncontroversial to me, (except, probably the syntax `(let b = _)` to bind a variable to a type to be filled by the compiler). I'm fine with accepting these, though they may require a bit more scrutiny than the rest. Best, Arnaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Tue Mar 29 20:22:15 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 29 Mar 2022 20:22:15 +0000 Subject: [ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept In-Reply-To: References: Message-ID: Thanks Arnaud, I have responded on the GitHub discussion Simon On Tue, 29 Mar 2022 at 16:02, Spiwack, Arnaud wrote: > Dear all, > > Let me bring to your attention the Modern Scoped Type Variables proposal, > by our own Richard https://github.com/ghc-proposals/ghc-proposals/pull/448 > . > > The proposal is a touch intimidating, because the text is large. But most > of it comes from other, already accepted, proposals that this proposal is > tidying up and tying together. > > What this proposal tries to achieve is to make a consistent text about all > the recent changes to binding type variables. > > The proposal adds new principles to the `principles.rst` files which > inform the changes proposed, of these, I have the following comments: > - The Visibility Orthogonality Principle doesn't seem to have a very > clear definition. It may be a sign that it's not something that is so > important > - The Explicit Binding Principle says that we need to be able to enforce > that all type variables have a binding site. I think it's a bit strong: I > would like Haskell to let me write a binding site for every type variable, > but not necessarily to error out when that doesn't happen. That being said, > I'm happy with warnings to help me along the way, but I don't think that > this Explicit Binding Principle should be phrased in a way that requires > adding extensions to control this behaviour. > - The Contiguous Scoping Principle, which states that a binder binds in > one contiguous region sounds dubious to me. I don't see a particular reason > for this to be. > > --- > > In the proposed changes themselves: up to Section 5, the proposed changes > are mostly existing accepted proposals, cleaned up with what was learnt > since they were written, as well as to adhere to the new principles. > > These are mostly uncontroversial and the specification makes sense to me. > I'm in favour of accepting all that. > > With the caveat that this proposal introduces quite a few extensions. And > at this point, I'm still not quite sure what Richard recommends is the set > of extensions that I should use (and I'm slightly dismayed that I believe > that it will be a set of cardinal more than 1). I think this reflects a > vision of extensions as switches to customise the behaviour of GHC. This > vision, as I've stated before, is very alien to me: I see extensions as > staging areas for features to become an integral part of Haskell. So I > don't know what to think of all these extensions. I'm definitely not > against splitting -XScopedTypeVariables into smaller components, if it is > done so that they are reassembled in a different way in an alternative > extension that would now be the recommended default (or at least is to > become the next recommended default). > > Finally, there are Sections 6 to 8. These are entirely new. Though they > are working towards the new principles (well, as far as I can tell, Section > 6 doesn't contribute to the principles, but it is a stepping stone for both > Sections 7 and 8). These sections are concerned with adding local > let-bindings of type variables, in particular inside types and patterns. > > By the way, Section 7 proposes two syntaxes for let binders in patterns, > and I *strongly* prefer the second syntax, which reads something like `f > (let b = Bool) (True :: Bool) = …`. > > Anyway, these are new, I feel that they are a bit out of place in a > proposal that is about tidying up the existing designs. That being said, > they are here, and they seem like fairly uncontroversial to me, (except, > probably the syntax `(let b = _)` to bind a variable to a type to be filled > by the compiler). I'm fine with accepting these, though they may require a > bit more scrutiny than the rest. > > Best, > Arnaud > > _______________________________________________ > 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: From arnaud.spiwack at tweag.io Wed Mar 30 08:20:18 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 30 Mar 2022 10:20:18 +0200 Subject: [ghc-steering-committee] Please review: #454 Custom type warnings In-Reply-To: <010f017e55a3195b-b551e32d-6ee6-4a12-86f8-92d3a8085ade-000000@us-east-2.amazonses.com> References: <010f017e5569032d-97a2902a-b938-4137-b9a7-70a1ead09852-000000@us-east-2.amazonses.com> <53E9ABAB-B660-477A-83AE-9D3BD6B0FAB7@gmail.com> <010f017e55a3195b-b551e32d-6ee6-4a12-86f8-92d3a8085ade-000000@us-east-2.amazonses.com> Message-ID: I realise that I hadn't opined here. I'm in favour. On Thu, Jan 13, 2022 at 11:51 PM Richard Eisenberg wrote: > That's a really good point. Do you want to raise it on the PR? > > Richard > > > On Jan 13, 2022, at 4:56 PM, Vladislav Zavialov (int-index) < > vlad.z.4096 at gmail.com> wrote: > > > > Can we guarantee erasure? Is `Warning flag msg => t` the same > operationally as just `t`? > > > > The proposal does not say that. And it’s not what I would’ve expected > from a constraint. Yet it’s something I expect from a warning. > > > > I am not comfortable with a design where adding a custom warning, the > purpose of which is to improve developer experience, comes at a cost of > potential performance regression. > > > > This isn’t a trade off that users of GHC should be facing. > > > > - Vlad > > > >> On 14 Jan 2022, at 00:47, Richard Eisenberg wrote: > >> > >> I vote to accept. > >> > >> Thanks, > >> Richard > >> > >>> On Jan 13, 2022, at 11:19 AM, Tom Harding > wrote: > >>> > >>> Hi all, > >>> > >>> As Joachim noted, #454 is extracted from Adam’s previous efforts with > the Unsatisfiable constraint proposal (which has since been accepted). In > short, it covers an interface for custom warnings, and I can already think > of plenty of ways I’d use it. I’d therefore like to recommend acceptance, > and discuss any issues or changes. > >>> > >>> Thanks, > >>> Tom > >>> _______________________________________________ > >>> 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: From mail at joachim-breitner.de Wed Mar 30 09:30:51 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 30 Mar 2022 11:30:51 +0200 Subject: [ghc-steering-committee] #477: Unicode ellipsis, recommendation: accept, please vote In-Reply-To: <174d7ad4b756ca192fec2f00775f7f8744bf81de.camel@joachim-breitner.de> References: <174d7ad4b756ca192fec2f00775f7f8744bf81de.camel@joachim-breitner.de> Message-ID: <82d84f4d96c8af8a13e3a661da2a1a1f0f950898.camel@joachim-breitner.de> Hi, Am Dienstag, dem 15.03.2022 um 16:35 +0100 schrieb Joachim Breitner: > I have seen +1 from Arnaud, Richard, and SPJ, and a -1 from Vlad. Let > me know if any of you changed their mind, and the others: let me know > which way you are leaning. I got an additional +0.5 from Simon Marlow, so I’ll consider this accepted. I’d also explicitly encourage our new members to voice their opinions! No false modesty please, we voted you in because we _do_ want to hear them :-) Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/