From mail at joachim-breitner.de Fri Jan 5 20:55:43 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 05 Jan 2018 21:55:43 +0100 Subject: [ghc-steering-committee] Proposal: Syntax for visible dependent quantification (#81) In-Reply-To: References: Message-ID: <1515185743.3425.11.camel@joachim-breitner.de> Hi, thanks for the recommendation. Am Mittwoch, den 20.12.2017, 20:35 +0000 schrieb Roman Leshchinskiy: > If we decide to discuss just the proposal as is, though, then I'd be > weakly against the proposed syntax as it is too subtle for my taste > and abuses familiar mathematical notation somewhat. I'd probably > prefer something like: > > type a -> t I am not saying that the proposed “forall a ->” syntax is great, but I think it is still better than “type a -> …”. The reason is that we already use prefixing “type”, e.g. in export lists (“type Bool”), to say “this thing is a type” if there is ambiguity. So if anything, then ifThenElse :: Bool -> a -> a -> a should be also allowed to be written as ifThenElse :: type Bool -> a -> a -> a and hence, in consequence ifThenElse :: type Bool -> type a -> type a -> a In other words, “type foo” just clarifies “I mean the _type_ foo”. Can we get more input? > Because of this, my recommendation is to strongly encourage the author > to submit an extended proposal which reserves (but doesn't specify the > semantics of) the above syntax wholesale. I’d be on board deciding on that syntax all in one go. Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Fri Jan 5 21:02:07 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 05 Jan 2018 22:02:07 +0100 Subject: [ghc-steering-committee] Proposal: Or patterns (#43) In-Reply-To: <5921AD3F-5DE1-4E9E-A963-B292F41C186E@justtesting.org> References: <90AB84AA-2917-49E6-B4A9-DF5E634A722F@justtesting.org> <5921AD3F-5DE1-4E9E-A963-B292F41C186E@justtesting.org> Message-ID: <1515186127.3425.16.camel@joachim-breitner.de> Hi Manuel, not much discussion has happened here. Do you want to tell the authors about the changes that we would like to have fleshed out, so that we can get a better proposal back? Based on the discussion, I expect that a satisfactorially extended proposal to be accepted. Cheers, Joachim Am Freitag, den 03.11.2017, 10:40 +1100 schrieb Manuel M T Chakravarty: > You are right, the proposal must be complete before we can accept it. > What I would like to suggest is the following: > > * If we all agree that *so far* this proposal is acceptable, we > bounce it back to the authors saying that if they are able to fill in > the gaps (especially, the treatment of GADTs) in a satisfactory > manner, we will accept the proposal. > > * If we decide to reject the proposal, the authors can save > themselves the effort of completing the specification. > > I know that this deviates from our usual procedure, but for a rather > large piece of work that does show promise, I think, it is worthwhile > to show some respect and appreciation for the effort spent. > > Cheers, > Manuel > > > Simon Peyton Jones : > > > > In general I'm ok with this proposal. > > > > But I've just added a comment explaining some things that really need fleshing out. > > > > > > > > * The proposal should specify that in (p1 | p2) the patterns in p1 and p2 must bind the same set of variables, with the same types. Nothing else makes sense; but it is nowhere specified. > > > > * I'm concerned that the specification is incomplete. Certainly when it comes to GADTs there is some muttering about the prototype implementation, but no specification. > > > > * For GADTs it's clear to me that in (p1 | p2) the patterns p1 and p2 should bind the same set of existentials and the same set of type constraints (including class constraints), just as they must bind the same set of variables with the same types. Just write out the typing rules for patterns (which should be part of the proposal) and it'll all become clear! > > > > * I'm bothered by the stuff about view patterns, lazy patterns etc in the proposal. The point is: or-patterns has NO interaction with these patterns. We should just say that and stop! By having (quite long) sections about these features, but not (say) about tuple patterns, the implication is that there is something special to say. But there isn't. > > > > > My reason for insisting on the first semantics is that it is a simple > > > extension of the existing pattern semantics in the Report, whereas the > > > second semantics requires a more profound, non-local change. > > > > Definitely non-backtracking. The backtracking thing opens up a whole new can of worms. > > > > > quite elaborate and quite some work has gone into it. Hence, I think, > > > we owe it the authors of the proposal to at least make a preliminary > > > determination at this point. (In particular, if it is not going to fly > > > regardless of how GADTs are handled, we should say so now.) > > > > I agree with that... but I'd be reluctant to actually accept it into GHC unless it was fully compositional, including GADTs. So it'd be a conditional acceptance, subject to satisfactory resolution of the GADT question. I'm not sure how the implementation works out... let's see; probably fine. > > > > > > Simon > > > > > -----Original Message----- > > > From: ghc-steering-committee [mailto:ghc-steering-committee- > > > bounces at haskell.org] On Behalf Of Manuel M T Chakravarty > > > Sent: 01 November 2017 23:58 > > > To: ghc-steering-committee at haskell.org > > > Subject: [ghc-steering-committee] Proposal: Or patterns (#43) > > > > > > Folks, > > > > > > I am sorry for taking a long time to get us going on this proposal. > > > > > > The ”Or pattern” proposal is about an extension to pattern matching: > > > > > > (formatted) > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > > > b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- > > > or- > > > patterns.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad54503 > > > 0e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177 > > > 4805951860&sdata=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3D& > > > reserved=0 > > > (PR thread) > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > > > b.com%2Fghc-proposals%2Fghc- > > > proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be > > > 72ad545030e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7 > > > C636451774805951860&sdata=x0Xn%2BOS6mHZBWYolcaJfa5JCkbHa1pl552fNI1Swmh > > > w%3D&reserved=0 > > > > > > Its basic idea is simple: allow multiple alternative patterns for each > > > alternative during pattern matching. Unfortunately, the interaction > > > with guards and some other languages features makes it significantly > > > less straight forward than one might initially think. > > > > > > I propose to accept this proposal provided we can agree to use the > > > ”first semantics” (aka single-match semantics) — see > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > > > b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- > > > or-patterns.rst%23interaction-with- > > > guards&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c08 > > > d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480595 > > > 1860&sdata=Z5JJApLfReiCl0dKD2R%2Fvbs3pTZt84iEXDRhdbeVICA%3D&reserved=0 > > > > > > My reason for insisting on the first semantics is that it is a simple > > > extension of the existing pattern semantics in the Report, whereas the > > > second semantics requires a more profound, non-local change. This, in > > > particular, also makes it easier to understand the implications of the > > > first semantics. (Also, OCaml has made that same choice.) > > > > > > However, even with the first semantics, I still have one concern about > > > this proposal. The story about the interaction with existential types > > > is currently only partial and there is no discussion of the > > > interaction with GADTs. It might be reasonable to ask for a complete > > > specification of the interaction with these features before making a > > > final determination on this proposal. Nevertheless, this proposal is > > > quite elaborate and quite some work has gone into it. Hence, I think, > > > we owe it the authors of the proposal to at least make a preliminary > > > determination at this point. (In particular, if it is not going to fly > > > regardless of how GADTs are handled, we should say so now.) > > > > > > Cheers, > > > Manuel > > > > > > PS: It is worth noting that Swift solved the problem of deciding > > > between the first and second semantics by choosing a syntax that > > > avoids the ambiguity: > > > > > loper.apple.com%2Flibrary%2Fcontent%2Fdocumentation%2FSwift%2FConceptu > > > al%2FSwift_Programming_Language%2FStatements.html%23%2F%2Fapple_ref%2F > > > swift%2Fgrammar%2Fswitch- > > > statement&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3 > > > c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480 > > > 5951860&sdata=ax1RcoY80ERbid5inoe%2BCRYg%2FC4t0hVL5oGBasVTfhM%3D&reser > > > ved=0>. It is difficult to adapt this syntax to Haskell. If it where > > > possible, I think, this would be the best solution. > > > _______________________________________________ > > > 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Fri Jan 5 21:02:24 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 05 Jan 2018 22:02:24 +0100 Subject: [ghc-steering-committee] Status Message-ID: <1515186144.3425.18.camel@joachim-breitner.de> Dear Committee, welcome to the new year 2018. Since the last status update, we * were asked to review these proposals: - merge -XTypeInType * accepted the following proposals: - /none/ * sent the following proposals back for further refinement - /none/ * rejected the following proposals: - /none/ On our table at the moment are: Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Shepherd: Ryan Newton Status: Still waiting for Ryan to make a recommendation. Mutable constructor fields https://github.com/ghc-proposals/ghc-proposals/pull/8 Shepherd: Ryan Newton Status: Still waiting for Ryan to make a recommendation. Or Patterns https://github.com/ghc-proposals/ghc-proposals/pull/43 Shepherd: Manuel Chakravarty Status: Committee deliberation ongoing, likely expecting changes. Visible dependent quantification (TL;DR: forall k -> k -> *) https://github.com/ghc-proposals/ghc-proposals/pull/81 Shepherd: Roman Leshchinskiy Status: Roman suggested changes, a slow discussion is happening. Deprecate STM invariant mechanism https://github.com/ghc-proposals/ghc-proposals/pull/77 Shepherd: Manuel Chakravarty Status: Waiting for Manuel to make a recommendation -Wall to include incomplete-uni-patterns and incomplete-record-updates https://github.com/ghc-proposals/ghc-proposals/pull/71 Shepherd: Simon Marlow Status: Waiting for Simon to make a recommendation Embrace (Type :: Type) https://github.com/ghc-proposals/ghc-proposals/pull/83 Shepherd: Iavor Diatchki Status: Waiting for Iavor to make a recommendation Besides these, there are some proposals actively under discussion. You can always check them out at https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+no%3Alabel Greetings, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Fri Jan 5 21:06:55 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 05 Jan 2018 22:06:55 +0100 Subject: [ghc-steering-committee] Deadlines for Shepherds? Message-ID: <1515186415.3425.23.camel@joachim-breitner.de> Hi, you know that I like slim smooth processes with not too many rules, and our current process worked pretty nicely for the first few proposals. But now it seems that we lost some steam, and a fair number of proposals are stuck waiting for their Shepherd to make progress. Does this mean that people simply need deadlines for work to be done? Do you want deadlines? Also, I am happy to re-assign some stalled proposals to new shepherds. Does anyone want to volunteer recommending a decision for one or more of these proposals: Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Mutable constructor fields https://github.com/ghc-proposals/ghc-proposals/pull/8 Deprecate STM invariant mechanism https://github.com/ghc-proposals/ghc-proposals/pull/77 -Wall to include incomplete-uni-patterns and incomplete-record-updates https://github.com/ghc-proposals/ghc-proposals/pull/71 Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From iavor.diatchki at gmail.com Fri Jan 5 22:17:18 2018 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 05 Jan 2018 22:17:18 +0000 Subject: [ghc-steering-committee] Deadlines for Shepherds? In-Reply-To: <1515186415.3425.23.camel@joachim-breitner.de> References: <1515186415.3425.23.camel@joachim-breitner.de> Message-ID: Hi, I didn't send out an e-mail about the TypeInType proposal yet, as I was travelling around the holidays, and I figured other folks might be also. I'll send out something to kick off the discussion pretty soon. Sorry for the delay. -Iavor On Fri, Jan 5, 2018 at 1:07 PM Joachim Breitner wrote: > Hi, > > you know that I like slim smooth processes with not too many rules, and > our current process worked pretty nicely for the first few proposals. > But now it seems that we lost some steam, and a fair number of > proposals are stuck waiting for their Shepherd to make progress. > > Does this mean that people simply need deadlines for work to be done? > > Do you want deadlines? > > > Also, I am happy to re-assign some stalled proposals to new shepherds. > Does anyone want to volunteer recommending a decision for one or more > of these proposals: > > Lazy unboxed tuples > https://github.com/ghc-proposals/ghc-proposals/pull/35 > > Mutable constructor fields > https://github.com/ghc-proposals/ghc-proposals/pull/8 > > Deprecate STM invariant mechanism > https://github.com/ghc-proposals/ghc-proposals/pull/77 > > -Wall to include incomplete-uni-patterns and incomplete-record-updates > https://github.com/ghc-proposals/ghc-proposals/pull/71 > > Thanks, > Joachim > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Sat Jan 6 01:37:45 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Fri, 5 Jan 2018 20:37:45 -0500 Subject: [ghc-steering-committee] Proposal: Syntax for visible dependent quantification (#81) In-Reply-To: <30B357D6-E03C-4A03-8D6C-F5BF22BF0E13@cs.brynmawr.edu> References: <30B357D6-E03C-4A03-8D6C-F5BF22BF0E13@cs.brynmawr.edu> Message-ID: <88AAAB4F-4C45-43EF-B4A4-D095982FCBDF@cs.brynmawr.edu> OK. I've posted proposal #102 (https://github.com/goldfirere/ghc-proposals/blob/pi/proposals/0000-pi.rst ) which describes the full set of quantifiers for Dependent Haskell. I continue to think that #81 can stand alone, but those who want a larger picture can see #102 for that larger picture. Thanks, Richard > On Dec 21, 2017, at 9:15 AM, Richard Eisenberg wrote: > > These are good suggestions. Thanks. While I'm writing all these proposals, it's about time I introduce pi proper -- the proposal for pi can go further than reserve syntax, because there are already places in the language that support real pi-types (the kinds of type families [assuming #54 is accepted] and the kinds of datatypes). > > I'll put together yet another proposal. :) > > Regardless, I don't want to shut down debate on this proposal in isolation. In particular, I'd love new syntax suggestions, as I agree that the proposed syntax is a little subtle. > > Thanks, > Richard > >> On Dec 20, 2017, at 3:35 PM, Roman Leshchinskiy wrote: >> >> Hi everyone, >> >> The proposal is about adding support for dependent quantification to >> kind signatures: >> >> https://github.com/ghc-proposals/ghc-proposals/pull/81 >> >> Consider the following declaration (example lifted from the proposal): >> >> data T k (a :: k) >> >> GHC accepts this but it can't be given an explicit kind. Internally, >> it is assigned a kind which is rendered as >> >> forall k -> k -> * >> >> but this isn't accepted in source code. Note that in applications of >> T, k must be specified explicitly (e.g., T Type Int) which is why T >> does *not* have the kind >> >> forall k. k -> * >> >> Moreover, k is mentioned later in the kind which is why something like >> Type -> k -> * doesn't work, either. >> >> The proposal is to allow forall k -> k -> * and similar kinds to >> appear in source code. >> >> This is actually intended as the first in a series of proposals >> driving us towards dependent types in Haskell as described in >> Richard's thesis >> (https://www.cis.upenn.edu/~sweirich/papers/eisenberg-thesis.pdf). >> Ultimately, the intention is to have all of the following (cf. Chapter >> 4 of the thesis): >> >> forall a. t >> forall a -> t >> pi a. t >> pi a -> t >> >> Here, forall and pi express relevance (does it exist at runtime) and . >> and -> express visibility (does it have to be specified explicitly). >> >> Because of this, my recommendation is to strongly encourage the author >> to submit an extended proposal which reserves (but doesn't specify the >> semantics of) the above syntax wholesale. >> >> This would allow us to ensure that various bits of Dependent Haskell >> use consistent syntax and language extensions once implemented. I find >> it quite difficult to discuss just this specific bit of syntax in >> isolation. Indeed, the public discussion was rather confused without >> an explanation of the roadmap >> (https://github.com/ghc-proposals/ghc-proposals/pull/81#issuecomment-336892922). >> >> Alternatively, we could just agree on the roadmap ourselves, without >> public discussion. This would somewhat circumvent the process, though. >> >> If we decide to discuss just the proposal as is, though, then I'd be >> weakly against the proposed syntax as it is too subtle for my taste >> and abuses familiar mathematical notation somewhat. I'd probably >> prefer something like: >> >> type a -> t >> >> The proposal also doesn't specify what language extension would turn >> on support for the syntax so this would have to be rectified. >> >> Thanks, >> >> Roman >> _______________________________________________ >> 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 chak at justtesting.org Mon Jan 8 04:18:58 2018 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Mon, 8 Jan 2018 15:18:58 +1100 Subject: [ghc-steering-committee] Deadlines for Shepherds? In-Reply-To: <1515186415.3425.23.camel@joachim-breitner.de> References: <1515186415.3425.23.camel@joachim-breitner.de> Message-ID: Sorry about the delay. It is summer holidays in Australia :) I am not sure that deadlines with re-assigning proposals will work better. In fact, I think, you current way of sending regular reminders/status emails is very good and I very much appreciate the effort that this surely takes on your side. Cheers Manuel > Am 06.01.2018 um 08:06 schrieb Joachim Breitner : > > Hi, > > you know that I like slim smooth processes with not too many rules, and > our current process worked pretty nicely for the first few proposals. > But now it seems that we lost some steam, and a fair number of > proposals are stuck waiting for their Shepherd to make progress. > > Does this mean that people simply need deadlines for work to be done? > > Do you want deadlines? > > > Also, I am happy to re-assign some stalled proposals to new shepherds. > Does anyone want to volunteer recommending a decision for one or more > of these proposals: > > Lazy unboxed tuples > https://github.com/ghc-proposals/ghc-proposals/pull/35 > > Mutable constructor fields > https://github.com/ghc-proposals/ghc-proposals/pull/8 > > Deprecate STM invariant mechanism > https://github.com/ghc-proposals/ghc-proposals/pull/77 > > -Wall to include incomplete-uni-patterns and incomplete-record-updates > https://github.com/ghc-proposals/ghc-proposals/pull/71 > > Thanks, > Joachim > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From chak at justtesting.org Mon Jan 8 04:20:30 2018 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Mon, 8 Jan 2018 15:20:30 +1100 Subject: [ghc-steering-committee] Proposal: Or patterns (#43) In-Reply-To: <1515186127.3425.16.camel@joachim-breitner.de> References: <90AB84AA-2917-49E6-B4A9-DF5E634A722F@justtesting.org> <5921AD3F-5DE1-4E9E-A963-B292F41C186E@justtesting.org> <1515186127.3425.16.camel@joachim-breitner.de> Message-ID: <77ED1805-6EC5-4E88-A91C-1E18595FB8E0@justtesting.org> Yes, I will do that. Thanks for the reminder. Cheers, Manuel > Am 06.01.2018 um 08:02 schrieb Joachim Breitner : > > Hi Manuel, > > not much discussion has happened here. Do you want to tell the authors > about the changes that we would like to have fleshed out, so that we > can get a better proposal back? Based on the discussion, I expect that > a satisfactorially extended proposal to be accepted. > > Cheers, > Joachim > > Am Freitag, den 03.11.2017, 10:40 +1100 schrieb Manuel M T Chakravarty: >> You are right, the proposal must be complete before we can accept it. >> What I would like to suggest is the following: >> >> * If we all agree that *so far* this proposal is acceptable, we >> bounce it back to the authors saying that if they are able to fill in >> the gaps (especially, the treatment of GADTs) in a satisfactory >> manner, we will accept the proposal. >> >> * If we decide to reject the proposal, the authors can save >> themselves the effort of completing the specification. >> >> I know that this deviates from our usual procedure, but for a rather >> large piece of work that does show promise, I think, it is worthwhile >> to show some respect and appreciation for the effort spent. >> >> Cheers, >> Manuel >> >>> Simon Peyton Jones : >>> >>> In general I'm ok with this proposal. >>> >>> But I've just added a comment explaining some things that really need fleshing out. >>> >>> >>> >>> * The proposal should specify that in (p1 | p2) the patterns in p1 and p2 must bind the same set of variables, with the same types. Nothing else makes sense; but it is nowhere specified. >>> >>> * I'm concerned that the specification is incomplete. Certainly when it comes to GADTs there is some muttering about the prototype implementation, but no specification. >>> >>> * For GADTs it's clear to me that in (p1 | p2) the patterns p1 and p2 should bind the same set of existentials and the same set of type constraints (including class constraints), just as they must bind the same set of variables with the same types. Just write out the typing rules for patterns (which should be part of the proposal) and it'll all become clear! >>> >>> * I'm bothered by the stuff about view patterns, lazy patterns etc in the proposal. The point is: or-patterns has NO interaction with these patterns. We should just say that and stop! By having (quite long) sections about these features, but not (say) about tuple patterns, the implication is that there is something special to say. But there isn't. >>> >>>> My reason for insisting on the first semantics is that it is a simple >>>> extension of the existing pattern semantics in the Report, whereas the >>>> second semantics requires a more profound, non-local change. >>> >>> Definitely non-backtracking. The backtracking thing opens up a whole new can of worms. >>> >>>> quite elaborate and quite some work has gone into it. Hence, I think, >>>> we owe it the authors of the proposal to at least make a preliminary >>>> determination at this point. (In particular, if it is not going to fly >>>> regardless of how GADTs are handled, we should say so now.) >>> >>> I agree with that... but I'd be reluctant to actually accept it into GHC unless it was fully compositional, including GADTs. So it'd be a conditional acceptance, subject to satisfactory resolution of the GADT question. I'm not sure how the implementation works out... let's see; probably fine. >>> >>> >>> Simon >>> >>>> -----Original Message----- >>>> From: ghc-steering-committee [mailto:ghc-steering-committee- >>>> bounces at haskell.org] On Behalf Of Manuel M T Chakravarty >>>> Sent: 01 November 2017 23:58 >>>> To: ghc-steering-committee at haskell.org >>>> Subject: [ghc-steering-committee] Proposal: Or patterns (#43) >>>> >>>> Folks, >>>> >>>> I am sorry for taking a long time to get us going on this proposal. >>>> >>>> The ”Or pattern” proposal is about an extension to pattern matching: >>>> >>>> (formatted) >>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu >>>> b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- >>>> or- >>>> patterns.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad54503 >>>> 0e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177 >>>> 4805951860&sdata=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3D& >>>> reserved=0 >>>> (PR thread) >>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu >>>> b.com%2Fghc-proposals%2Fghc- >>>> proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be >>>> 72ad545030e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7 >>>> C636451774805951860&sdata=x0Xn%2BOS6mHZBWYolcaJfa5JCkbHa1pl552fNI1Swmh >>>> w%3D&reserved=0 >>>> >>>> Its basic idea is simple: allow multiple alternative patterns for each >>>> alternative during pattern matching. Unfortunately, the interaction >>>> with guards and some other languages features makes it significantly >>>> less straight forward than one might initially think. >>>> >>>> I propose to accept this proposal provided we can agree to use the >>>> ”first semantics” (aka single-match semantics) — see >>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu >>>> b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- >>>> or-patterns.rst%23interaction-with- >>>> guards&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c08 >>>> d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480595 >>>> 1860&sdata=Z5JJApLfReiCl0dKD2R%2Fvbs3pTZt84iEXDRhdbeVICA%3D&reserved=0 >>>> >>>> My reason for insisting on the first semantics is that it is a simple >>>> extension of the existing pattern semantics in the Report, whereas the >>>> second semantics requires a more profound, non-local change. This, in >>>> particular, also makes it easier to understand the implications of the >>>> first semantics. (Also, OCaml has made that same choice.) >>>> >>>> However, even with the first semantics, I still have one concern about >>>> this proposal. The story about the interaction with existential types >>>> is currently only partial and there is no discussion of the >>>> interaction with GADTs. It might be reasonable to ask for a complete >>>> specification of the interaction with these features before making a >>>> final determination on this proposal. Nevertheless, this proposal is >>>> quite elaborate and quite some work has gone into it. Hence, I think, >>>> we owe it the authors of the proposal to at least make a preliminary >>>> determination at this point. (In particular, if it is not going to fly >>>> regardless of how GADTs are handled, we should say so now.) >>>> >>>> Cheers, >>>> Manuel >>>> >>>> PS: It is worth noting that Swift solved the problem of deciding >>>> between the first and second semantics by choosing a syntax that >>>> avoids the ambiguity: >>>> >>> loper.apple.com%2Flibrary%2Fcontent%2Fdocumentation%2FSwift%2FConceptu >>>> al%2FSwift_Programming_Language%2FStatements.html%23%2F%2Fapple_ref%2F >>>> swift%2Fgrammar%2Fswitch- >>>> statement&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3 >>>> c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480 >>>> 5951860&sdata=ax1RcoY80ERbid5inoe%2BCRYg%2FC4t0hVL5oGBasVTfhM%3D&reser >>>> ved=0>. It is difficult to adapt this syntax to Haskell. If it where >>>> possible, I think, this would be the best solution. >>>> _______________________________________________ >>>> 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/ > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From marlowsd at gmail.com Mon Jan 8 10:23:54 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 8 Jan 2018 10:23:54 +0000 Subject: [ghc-steering-committee] Proposal: accept "add incomplete-uni-patterns and incomplete-record-updates to -Wall" Message-ID: I propose that we accept the proposal add incomplete-uni-patterns and incomplete-record-updates to -Wall https://github.com/ghc-proposals/ghc-proposals/pull/71 Both warnings are avoidable and considered bad style, which makes them appropriate to include in -Wall. The reason that -Wincomplete-uni-patterns wasn't originally made part of -Wall was due to worries about noisiness ( https://ghc.haskell.org/trac/ghc/ticket/4905), but that's not a valid concern. -Wall is intentionally a moving target, if you want to stay Wall-clean you accept that new compiler releases may entail some work. Basically I think this is a no-brainer. Cheers Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Mon Jan 8 10:29:30 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 8 Jan 2018 10:29:30 +0000 Subject: [ghc-steering-committee] Deadlines for Shepherds? In-Reply-To: <1515186415.3425.23.camel@joachim-breitner.de> References: <1515186415.3425.23.camel@joachim-breitner.de> Message-ID: Just sent an email about the -Wall proposal. Thanks for the reminder! On 5 January 2018 at 21:06, Joachim Breitner wrote: > Hi, > > you know that I like slim smooth processes with not too many rules, and > our current process worked pretty nicely for the first few proposals. > But now it seems that we lost some steam, and a fair number of > proposals are stuck waiting for their Shepherd to make progress. > > Does this mean that people simply need deadlines for work to be done? > > Do you want deadlines? > > > Also, I am happy to re-assign some stalled proposals to new shepherds. > Does anyone want to volunteer recommending a decision for one or more > of these proposals: > > Lazy unboxed tuples > https://github.com/ghc-proposals/ghc-proposals/pull/35 > > Mutable constructor fields > https://github.com/ghc-proposals/ghc-proposals/pull/8 > > Deprecate STM invariant mechanism > https://github.com/ghc-proposals/ghc-proposals/pull/77 > > -Wall to include incomplete-uni-patterns and incomplete-record-updates > https://github.com/ghc-proposals/ghc-proposals/pull/71 > > Thanks, > Joachim > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Jan 8 12:57:21 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 8 Jan 2018 12:57:21 +0000 Subject: [ghc-steering-committee] Proposal: accept "add incomplete-uni-patterns and incomplete-record-updates to -Wall" In-Reply-To: References: Message-ID: OK by me. Simon From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Simon Marlow Sent: 08 January 2018 10:24 To: ghc-steering-committee at haskell.org Subject: [ghc-steering-committee] Proposal: accept "add incomplete-uni-patterns and incomplete-record-updates to -Wall" I propose that we accept the proposal add incomplete-uni-patterns and incomplete-record-updates to -Wall https://github.com/ghc-proposals/ghc-proposals/pull/71 Both warnings are avoidable and considered bad style, which makes them appropriate to include in -Wall. The reason that -Wincomplete-uni-patterns wasn't originally made part of -Wall was due to worries about noisiness (https://ghc.haskell.org/trac/ghc/ticket/4905), but that's not a valid concern. -Wall is intentionally a moving target, if you want to stay Wall-clean you accept that new compiler releases may entail some work. Basically I think this is a no-brainer. Cheers Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Mon Jan 8 21:16:11 2018 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 08 Jan 2018 21:16:11 +0000 Subject: [ghc-steering-committee] Proposal: accept "add incomplete-uni-patterns and incomplete-record-updates to -Wall" In-Reply-To: References: Message-ID: I agree that we should accept #71 On Mon, Jan 8, 2018 at 2:24 AM Simon Marlow wrote: > I propose that we accept the proposal > > add incomplete-uni-patterns and incomplete-record-updates to -Wall > > https://github.com/ghc-proposals/ghc-proposals/pull/71 > > > Both warnings are avoidable and considered bad style, which makes them > appropriate to include in -Wall. > > The reason that -Wincomplete-uni-patterns wasn't originally made part of > -Wall was due to worries about noisiness ( > https://ghc.haskell.org/trac/ghc/ticket/4905), but that's not a valid > concern. -Wall is intentionally a moving target, if you want to stay > Wall-clean you accept that new compiler releases may entail some work. > > Basically I think this is a no-brainer. > > Cheers > Simon > > _______________________________________________ > 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 chak at justtesting.org Tue Jan 9 02:06:38 2018 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Tue, 9 Jan 2018 13:06:38 +1100 Subject: [ghc-steering-committee] Proposal: accept "add incomplete-uni-patterns and incomplete-record-updates to -Wall" In-Reply-To: References: Message-ID: +1 > 08.01.2018 21:23 Simon Marlow : > > I propose that we accept the proposal > > add incomplete-uni-patterns and incomplete-record-updates to -Wall > > https://github.com/ghc-proposals/ghc-proposals/pull/71 > > > > Both warnings are avoidable and considered bad style, which makes them appropriate to include in -Wall. > > The reason that -Wincomplete-uni-patterns wasn't originally made part of -Wall was due to worries about noisiness (https://ghc.haskell.org/trac/ghc/ticket/4905 ), but that's not a valid concern. -Wall is intentionally a moving target, if you want to stay Wall-clean you accept that new compiler releases may entail some work. > > Basically I think this is a no-brainer. > > Cheers > Simon > > _______________________________________________ > 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 chak at justtesting.org Wed Jan 17 03:52:16 2018 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Wed, 17 Jan 2018 14:52:16 +1100 Subject: [ghc-steering-committee] Proposal: Or patterns (#43) In-Reply-To: <90AB84AA-2917-49E6-B4A9-DF5E634A722F@justtesting.org> References: <90AB84AA-2917-49E6-B4A9-DF5E634A722F@justtesting.org> Message-ID: <33B04538-3A6B-45C7-AE1B-BF52C3E6F5D9@justtesting.org> Dear Committee, Please excuse my tardiness in wrapping up the review of this proposal. As we discussed, I suggested to the author to fill in the remaining gaps and indicated that we are likely to accept the proposal if the gaps can be filled in satisfactorily. For details, see https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-358189327 Cheers, Manuel > 02.11.2017 10:57 Manuel M T Chakravarty : > > Folks, > > I am sorry for taking a long time to get us going on this proposal. > > The ”Or pattern” proposal is about an extension to pattern matching: > > (formatted) https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or-patterns.rst > (PR thread) https://github.com/ghc-proposals/ghc-proposals/pull/43 > > Its basic idea is simple: allow multiple alternative patterns for each alternative during pattern matching. Unfortunately, the interaction with guards and some other languages features makes it significantly less straight forward than one might initially think. > > I propose to accept this proposal provided we can agree to use the ”first semantics” (aka single-match semantics) — see https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or-patterns.rst#interaction-with-guards > > My reason for insisting on the first semantics is that it is a simple extension of the existing pattern semantics in the Report, whereas the second semantics requires a more profound, non-local change. This, in particular, also makes it easier to understand the implications of the first semantics. (Also, OCaml has made that same choice.) > > However, even with the first semantics, I still have one concern about this proposal. The story about the interaction with existential types is currently only partial and there is no discussion of the interaction with GADTs. It might be reasonable to ask for a complete specification of the interaction with these features before making a final determination on this proposal. Nevertheless, this proposal is quite elaborate and quite some work has gone into it. Hence, I think, we owe it the authors of the proposal to at least make a preliminary determination at this point. (In particular, if it is not going to fly regardless of how GADTs are handled, we should say so now.) > > Cheers, > Manuel > > PS: It is worth noting that Swift solved the problem of deciding between the first and second semantics by choosing a syntax that avoids the ambiguity: . It is difficult to adapt this syntax to Haskell. If it where possible, I think, this would be the best solution. > _______________________________________________ > 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 iavor.diatchki at gmail.com Thu Jan 25 21:45:07 2018 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu, 25 Jan 2018 21:45:07 +0000 Subject: [ghc-steering-committee] Proposal: Embrace Type in Type Message-ID: Hello, I am the shepherd for pull request #83 "Embrace Type in Type" ( https://github.com/ghc-proposals/ghc-proposals/pull/83), and so I'd like to hear your thoughts about the proposal. In short, the proposal has two parts: 1. Deprecate the use of `*` for the kind of inhabited Haskell types, and replace it with `Type`. 2. Deprecate extension `TypeInType`, and move its functionality to extension `PolyKinds`. At first I was quite skeptical about both of these, but after some thought I've realized that most of my concerns are not so much about Type in Type, but rather about the data promotion mechanism, and so I won't discuss them in this e-mail. As such, I think I would be OK with part 2. In particular, I like that when using TypeInType, one is explicit about kind parameters, as the implicit parameters of `PolyKinds` can be quite confusing. Technically, being explicit about kind parameters is an orthogonal issue to mixing up types and kinds, but this is where we are at the moment, and I think `PolyKinds` is probably more useful with `TypeInType`. Part 1 of the proposal is obviously just a syntactic thing, but I am a bit concerned about it. In part because I actually tried for a while to use `Type` instead of `*`, and I found that the resulting kind signatures looked much more complicated. Quite possibly this is because I am very used to using `*` and eventually I would adjust, but things just ended up being much longer. It also seems unfortunate that this would break quite a lot of code, and obsolete a bunch of documentation and tutorials online. So while I understand the reason for the proposal (the confusion between `*` the type function, and `*` the kind), I am not very keen on making this change. The proposal also suggests another extension, `StarIsType`, and when enabled `*` will always refer to the kind, and never to the type function. I am even less keen about this option, as I think it is better to pick a single notation and stick with it. I'd love to hear what others think! -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu Jan 25 22:10:33 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 25 Jan 2018 17:10:33 -0500 Subject: [ghc-steering-committee] Proposal: Embrace Type in Type In-Reply-To: References: Message-ID: <1516918233.13203.2.camel@joachim-breitner.de> Hi, Am Donnerstag, den 25.01.2018, 21:45 +0000 schrieb Iavor Diatchki: > In part because I actually tried for a while to use `Type` instead of > `*`, and I found that the resulting kind signatures looked much more > complicated. How do you feel about the variant where * is a synonym for Type, but no special parsing rules apply, which means you get to write class Monad (m :: (*) -> (*)) instead of class Monad (m :: * -> *) -- now or class Monad (m :: Type -> Type) -- proposed This way, people who want (*) to not refer to Type can hide the import with the usual mechanisms. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Thu Jan 25 22:11:04 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 25 Jan 2018 22:11:04 +0000 Subject: [ghc-steering-committee] Proposal: Embrace Type in Type In-Reply-To: References: Message-ID: Thanks Iavor * I strongly support collapsing TypeInType and PolyKinds. * I can never remember the precise differences. * Having the distinction carries no user benefit; it is grounded in history not user benefit * …but maintaining the distinction has very significant costs in the compiler. * I also support using Type instead of *. Think of it like this: if were designing Haskell today, would we really pick a binary operator and use it as a nullary type constructor? Surely not. It’s a huge wart. E.g. If you write (a :: *->*) GHC gets confused because it thinks *->* is one lexeme. And * is a jolly useful infix binary type constructor!! (Or in type-level arithmetic.) Yes, * is familiar to us old guys. But you just get used to things. If you want brevity, say type T = Type. I think you’d adjust quickly. I think we should just bit the bullet on this one. Simon From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Iavor Diatchki Sent: 25 January 2018 21:45 To: ghc-steering-committee at haskell.org Subject: [ghc-steering-committee] Proposal: Embrace Type in Type Hello, I am the shepherd for pull request #83 "Embrace Type in Type" ( https://github.com/ghc-proposals/ghc-proposals/pull/83), and so I'd like to hear your thoughts about the proposal. In short, the proposal has two parts: 1. Deprecate the use of `*` for the kind of inhabited Haskell types, and replace it with `Type`. 2. Deprecate extension `TypeInType`, and move its functionality to extension `PolyKinds`. At first I was quite skeptical about both of these, but after some thought I've realized that most of my concerns are not so much about Type in Type, but rather about the data promotion mechanism, and so I won't discuss them in this e-mail. As such, I think I would be OK with part 2. In particular, I like that when using TypeInType, one is explicit about kind parameters, as the implicit parameters of `PolyKinds` can be quite confusing. Technically, being explicit about kind parameters is an orthogonal issue to mixing up types and kinds, but this is where we are at the moment, and I think `PolyKinds` is probably more useful with `TypeInType`. Part 1 of the proposal is obviously just a syntactic thing, but I am a bit concerned about it. In part because I actually tried for a while to use `Type` instead of `*`, and I found that the resulting kind signatures looked much more complicated. Quite possibly this is because I am very used to using `*` and eventually I would adjust, but things just ended up being much longer. It also seems unfortunate that this would break quite a lot of code, and obsolete a bunch of documentation and tutorials online. So while I understand the reason for the proposal (the confusion between `*` the type function, and `*` the kind), I am not very keen on making this change. The proposal also suggests another extension, `StarIsType`, and when enabled `*` will always refer to the kind, and never to the type function. I am even less keen about this option, as I think it is better to pick a single notation and stick with it. I'd love to hear what others think! -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Fri Jan 26 18:14:04 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Fri, 26 Jan 2018 13:14:04 -0500 Subject: [ghc-steering-committee] Proposal: Embrace Type in Type In-Reply-To: References: Message-ID: <1D04510D-A344-4F48-8CA2-C88E6837794C@cs.brynmawr.edu> I (the proposer) also want to clarify that the proposal leaves some wiggle room about the deprecation of *: - We could continue to support *-as-Type into perpetuity, as long as -XTypeOperators is not on. - We could continue to print * in error messages, perhaps depending on various extensions. Or perhaps we have a -fprint-star-for-type or some such, which would perhaps be used by instructors of courses that use materials mentioning *. - We could continue to support Unicode \bigstar (as we do today) as Type. This doesn't conflict with *-the-multiplication-operator. I would love some guidance from the committee on the above points. Lastly, the proposal does not include any plans for full removal of *, as it will leave GHC in a state where supporting *-as-type (with -XStarIsType) is not burdensome. One final alternative (just added to the proposal, as I had forgotten about it previously) that may be appealing is to use "type" to mean "Type". Because "type" is a keyword, there are no scoping issues, and so it can be always in scope, making the transition from * easier. I'm sorry if adding this alternative late in the game is disruptive, but I thought it worthy of consideration. Thanks, Richard > On Jan 25, 2018, at 5:11 PM, Simon Peyton Jones wrote: > > Thanks Iavor > I strongly support collapsing TypeInType and PolyKinds. > I can never remember the precise differences. > Having the distinction carries no user benefit; it is grounded in history not user benefit > …but maintaining the distinction has very significant costs in the compiler. > > I also support using Type instead of *. Think of it like this: if were designing Haskell today, would we really pick a binary operator and use it as a nullary type constructor? Surely not. It’s a huge wart. E.g. If you write (a :: *->*) GHC gets confused because it thinks *->* is one lexeme. And * is a jolly useful infix binary type constructor!! (Or in type-level arithmetic.) > > Yes, * is familiar to us old guys. But you just get used to things. If you want brevity, say type T = Type. I think you’d adjust quickly. > > I think we should just bit the bullet on this one. > > Simon > >   <> > From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Iavor Diatchki > Sent: 25 January 2018 21:45 > To: ghc-steering-committee at haskell.org > Subject: [ghc-steering-committee] Proposal: Embrace Type in Type > > Hello, > > > > I am the shepherd for pull request #83 "Embrace Type in Type" ( https://github.com/ghc-proposals/ghc-proposals/pull/83 ), and so I'd like to hear your thoughts about the proposal. > > > > In short, the proposal has two parts: > > 1. Deprecate the use of `*` for the kind of inhabited Haskell types, and replace it with `Type`. > > 2. Deprecate extension `TypeInType`, and move its functionality to extension `PolyKinds`. > > > > At first I was quite skeptical about both of these, but after some thought I've realized that most of my concerns are not so much about Type in Type, but rather about the data promotion mechanism, and so I won't discuss them in this e-mail. > > > > As such, I think I would be OK with part 2. In particular, I like that when using TypeInType, one is explicit about kind parameters, as the implicit parameters of `PolyKinds` can be quite confusing. Technically, being explicit about kind parameters is an orthogonal issue to mixing up types and kinds, but this is where we are at the moment, and I think `PolyKinds` is probably more useful with `TypeInType`. > > > > Part 1 of the proposal is obviously just a syntactic thing, but I am a bit concerned about it. In part because I actually tried for a while to use `Type` instead of `*`, and I found that the resulting kind signatures looked much more complicated. Quite possibly this is because I am very used to using `*` and eventually I would adjust, but things just ended up being much longer. It also seems unfortunate that this would break quite a lot of code, and obsolete a bunch of documentation and tutorials online. > > > So while I understand the reason for the proposal (the confusion between `*` the type function, and `*` the kind), I am not very keen on making this change. The proposal also suggests another extension, `StarIsType`, and when enabled `*` will always refer to the kind, and never to the type function. I am even less keen about this option, as I think it is better to pick a single notation and stick with it. > > > > I'd love to hear what others think! > > > > -Iavor > > > > > > > > > > _______________________________________________ > 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 iavor.diatchki at gmail.com Mon Jan 29 17:49:36 2018 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 29 Jan 2018 17:49:36 +0000 Subject: [ghc-steering-committee] Proposal: Embrace Type in Type In-Reply-To: <1D04510D-A344-4F48-8CA2-C88E6837794C@cs.brynmawr.edu> References: <1D04510D-A344-4F48-8CA2-C88E6837794C@cs.brynmawr.edu> Message-ID: My vote would be to either keep `*` or stick with `Type` as originally intended. I am not sure that the other alternatives are any better, as they are almost as long as `Type` and would require yet more special case explaining, for little readability value, I think. Does anyone else have any input on either part of the proposal? -Iavor On Fri, Jan 26, 2018 at 10:14 AM Richard Eisenberg wrote: > I (the proposer) also want to clarify that the proposal leaves some wiggle > room about the deprecation of *: > - We could continue to support *-as-Type into perpetuity, as long as > -XTypeOperators is not on. > - We could continue to print * in error messages, perhaps depending on > various extensions. Or perhaps we have a -fprint-star-for-type or some > such, which would perhaps be used by instructors of courses that use > materials mentioning *. > - We could continue to support Unicode \bigstar (as we do today) as Type. > This doesn't conflict with *-the-multiplication-operator. > > I would love some guidance from the committee on the above points. > > Lastly, the proposal does not include any plans for full removal of *, as > it will leave GHC in a state where supporting *-as-type (with -XStarIsType) > is not burdensome. > > One final alternative (just added to the proposal, as I had forgotten > about it previously) that may be appealing is to use "type" to mean "Type". > Because "type" is a keyword, there are no scoping issues, and so it can be > always in scope, making the transition from * easier. > > I'm sorry if adding this alternative late in the game is disruptive, but I > thought it worthy of consideration. > > Thanks, > Richard > > On Jan 25, 2018, at 5:11 PM, Simon Peyton Jones > wrote: > > Thanks Iavor > > - I strongly support collapsing TypeInType and PolyKinds. > - I can never remember the precise differences. > - Having the distinction carries no user benefit; it is grounded in > history not user benefit > - …but maintaining the distinction has very significant costs in > the compiler. > > > > - I also support using Type instead of *. Think of it like this: if > were designing Haskell today, would we really pick a binary operator and > use it as a nullary type constructor? Surely not. It’s a huge wart. > E.g. If you write (a :: *->*) GHC gets confused because it thinks *->* is > one lexeme. And * is a jolly useful infix binary type constructor!! (Or > in type-level arithmetic.) > > > Yes, * is familiar to us old guys. But you just get used to things. If > you want brevity, say type T = Type. I think you’d adjust quickly. > > I think we should just bit the bullet on this one. > > Simon > > > *From:* ghc-steering-committee [ > mailto:ghc-steering-committee-bounces at haskell.org > ] *On Behalf Of *Iavor > Diatchki > *Sent:* 25 January 2018 21:45 > *To:* ghc-steering-committee at haskell.org > *Subject:* [ghc-steering-committee] Proposal: Embrace Type in Type > > > Hello, > > > > I am the shepherd for pull request #83 "Embrace Type in Type" ( > https://github.com/ghc-proposals/ghc-proposals/pull/83 > ), > and so I'd like to hear your thoughts about the proposal. > > > > In short, the proposal has two parts: > > 1. Deprecate the use of `*` for the kind of inhabited Haskell types, > and replace it with `Type`. > > 2. Deprecate extension `TypeInType`, and move its functionality to > extension `PolyKinds`. > > > > At first I was quite skeptical about both of these, but after some thought > I've realized that most of my concerns are not so much about Type in Type, > but rather about the data promotion mechanism, and so I won't discuss them > in this e-mail. > > > > As such, I think I would be OK with part 2. In particular, I like that > when using TypeInType, one is explicit about kind parameters, as the > implicit parameters of `PolyKinds` can be quite confusing. Technically, > being explicit about kind parameters is an orthogonal issue to mixing up > types and kinds, but this is where we are at the moment, and I think > `PolyKinds` is probably more useful with `TypeInType`. > > > > Part 1 of the proposal is obviously just a syntactic thing, but I am a bit > concerned about it. In part because I actually tried for a while to use > `Type` instead of `*`, and I found that the resulting kind signatures > looked much more complicated. Quite possibly this is because I am very > used to using `*` and eventually I would adjust, but things just ended up > being much longer. It also seems unfortunate that this would break quite a > lot of code, and obsolete a bunch of documentation and tutorials online. > > > So while I understand the reason for the proposal (the confusion between > `*` the type function, and `*` the kind), I am not very keen on making this > change. The proposal also suggests another extension, `StarIsType`, and > when enabled `*` will always refer to the kind, and never to the type > function. I am even less keen about this option, as I think it is better > to pick a single notation and stick with it. > > > > I'd love to hear what others think! > > > > -Iavor > > > > > > > > > > _______________________________________________ > > > 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: