From mail at joachim-breitner.de Wed Dec 6 02:35:18 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 05 Dec 2017 21:35:18 -0500 Subject: [ghc-steering-committee] Proposal: BlockArguments (Shepherd: Joachim) In-Reply-To: <1511794006.1011.18.camel@joachim-breitner.de> References: <1511794006.1011.18.camel@joachim-breitner.de> Message-ID: <1512527718.3545.8.camel@joachim-breitner.de> Hi, Am Montag, den 27.11.2017, 09:46 -0500 schrieb Joachim Breitner: > Therefore, I suggest that we accept this proposal. I heared lots of positive opinions and no negative ones. I conclude that the committee follows the suggestion and mark this proposal as accepted. 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 Wed Dec 6 02:40:19 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 05 Dec 2017 21:40:19 -0500 Subject: [ghc-steering-committee] Underscores in literals In-Reply-To: References: Message-ID: <1512528019.3545.11.camel@joachim-breitner.de> Hi, Am Dienstag, den 07.11.2017, 18:11 +0000 schrieb Iavor Diatchki: > Many other languages have a similar feature (especially hardware > specification languages) and I see no downsides to it, so I think we > should accept it. the silent majority of the committee approves of this, so consider this accepted. 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 Wed Dec 6 02:41:11 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 05 Dec 2017 21:41:11 -0500 Subject: [ghc-steering-committee] Underscores in literals In-Reply-To: <1512528019.3545.11.camel@joachim-breitner.de> References: <1512528019.3545.11.camel@joachim-breitner.de> Message-ID: <1512528071.3545.12.camel@joachim-breitner.de> Hi, Am Dienstag, den 05.12.2017, 21:40 -0500 schrieb Joachim Breitner: > Am Dienstag, den 07.11.2017, 18:11 +0000 schrieb Iavor Diatchki: > > Many other languages have a similar feature (especially hardware > > specification languages) and I see no downsides to it, so I think we > > should accept it. > > the silent majority of the committee approves of this, so consider this > accepted. ignore this mail, Yavor had already done that 21 days ago. 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 Wed Dec 6 02:44:34 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 05 Dec 2017 21:44:34 -0500 Subject: [ghc-steering-committee] Status Message-ID: <1512528274.3545.16.camel@joachim-breitner.de> Dear Commmittteee, Since the last status update, we * were asked to review these proposals: - visible dependent quantification - Deprecate STM invariant mechanism - add incomplete-uni-patterns and incomplete-record-updates to -Wall - Block arguments * accepted the following proposals: - underscores in literals - Block arguments * sent the following proposals back for further refinement - /none/ * rejected the following proposals: - /none/ * Had a discussion how to scale the committee process to “big” proposals like linear types. 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: Manuel suggests acceptance, committee deliberation ongoing Visible dependent quantification (TL;DR: forall k -> k -> *) https://github.com/ghc-proposals/ghc-proposals/pull/81 Shepherd: Roman Leshchinskiy Status: Waiting for Roman to make a recommendation 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 Dear shepherds, there is work waiting for you! 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 Tue Dec 19 02:53:14 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 18 Dec 2017 21:53:14 -0500 Subject: [ghc-steering-committee] Please review: embrace Type::Type, Shepherd: Iavor Message-ID: <1513651994.10094.21.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: Richards proposes to merge -XTypeInType into -XPolyKinds and -XDataKinds https://github.com/ghc-proposals/ghc-proposals/pull/83 I propose Yavor Diatchki as the Shepherd. Yavor, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. 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 simonpj at microsoft.com Tue Dec 19 09:01:00 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 19 Dec 2017 09:01:00 +0000 Subject: [ghc-steering-committee] Please review: embrace Type::Type, Shepherd: Iavor In-Reply-To: <1513651994.10094.21.camel@joachim-breitner.de> References: <1513651994.10094.21.camel@joachim-breitner.de> Message-ID: I'm strongly in favour of this proposal. There are really two bits * Stop distinguishing -XPolyKinds and -XTypeInType. This is a straight win. I implement GHC and I could not tell you the precise description. The distinction serves no useful purpose: the ONLY reason for retaining it is to avoid back-compat worries, and that is not a good reason to perpetuate special cases into the indefinite future * Stop treating '*' specially, with a flag to get the old behaviour. I support this plan too. It was really a mistake to use an operator symbol as a type name in the first place. Having a flag to recover the current behaviour is a reasonable mitigation path. Let's do it! Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Joachim Breitner | Sent: 19 December 2017 02:53 | To: ghc-steering-committee at haskell.org | Subject: [ghc-steering-committee] Please review: embrace Type::Type, | Shepherd: Iavor | | Dear Committee, | | this is your secretary speaking: | | Richards proposes to merge -XTypeInType into -XPolyKinds and -XDataKinds | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% | 2Fghc-proposals%2Fghc- | proposals%2Fpull%2F83&data=02%7C01%7Csimonpj%40microsoft.com%7C3c755ac86e034 | 0422c0508d5468badbf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63649248810 | 8056862&sdata=TcjDdAfP3cDMWfiKMNjzTG98iKzoCIeG6SoDvAdpSHs%3D&reserved=0 | | I propose Yavor Diatchki as the Shepherd. | | Yavor, please reach consensus as described in | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% | 2Fghc-proposals%2Fghc-proposals%23committee- | process&data=02%7C01%7Csimonpj%40microsoft.com%7C3c755ac86e0340422c0508d5468 | badbf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492488108056862&sdata= | 7tIMsZ3f1ywmuHTJXqlA%2BtGKfUV5X3rRMcNxtyJDeSQ%3D&reserved=0 | | I suggest you make a recommendation about the decision, maybe point out | debatable points, and assume that anyone who stays quiet agrees with you. | | Thanks, | Joachim | -- | Joachim Breitner | mail at joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C3c755ac86e0340422c05 | 08d5468badbf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492488108056862 | &sdata=jGkyiDO6oIs2kidTiRSqp0o1J0kZRrgpPbyA4%2FwdkSI%3D&reserved=0 From rleshchinskiy at gmail.com Wed Dec 20 20:35:37 2017 From: rleshchinskiy at gmail.com (Roman Leshchinskiy) Date: Wed, 20 Dec 2017 20:35:37 +0000 Subject: [ghc-steering-committee] Proposal: Syntax for visible dependent quantification (#81) Message-ID: 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 From simonpj at microsoft.com Thu Dec 21 12:09:09 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 21 Dec 2017 12:09:09 +0000 Subject: [ghc-steering-committee] Proposal: Syntax for visible dependent quantification (#81) In-Reply-To: References: Message-ID: I support the proposal, because it allows the programmer to say things that we want to be able to say. Notably, given data T k (a :: k) what is the kind of T? Writing down that kind should be possible, and should tell you how to use it. We can't say T :: forall k. k -> * because then we'd expect to be able to write (T Maybe), with the kind argument filled in implicitly. We need some way to specify this when giving kind signatures. I'm all for sketching the big picture, as a way to indicate that we aren't painting ourselves into a corner. The table in one of the github comments is useful, and would be useful as a way to describe the landscape. Really the only thing at issue is the syntax. In forall a -> blah the thing on the left of the arrow isn't a type at all, unlike normal uses of arrow. It's more like forall a. blah forall a% blah that is, two related constructs with a syntactic signal about whether the argument is explicit or not. On the whole I'm happy with the "->". We are used to supplying arguments for things on the LHS of an arrow. I'm not clear about abstraction...I'll put a question on the github trail. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Roman Leshchinskiy | Sent: 20 December 2017 20:36 | To: ghc-steering-committee at haskell.org | Subject: [ghc-steering-committee] Proposal: Syntax for visible dependent | quantification (#81) | | Hi everyone, | | The proposal is about adding support for dependent quantification to kind | signatures: | | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% | 2Fghc-proposals%2Fghc- | proposals%2Fpull%2F81&data=02%7C01%7Csimonpj%40microsoft.com%7Cf4bcb638ccb04 | 882991608d547e94370%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63649398954 | 3774014&sdata=Zvjdonwoja%2FlKZ14CND4nxVZur8a4Um867wsvtZr6%2FQ%3D&reserved=0 | | 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://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.cis.upen | n.edu%2F~sweirich%2Fpapers%2Feisenberg- | thesis.pdf&data=02%7C01%7Csimonpj%40microsoft.com%7Cf4bcb638ccb04882991608d5 | 47e94370%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636493989543774014&sda | ta=1U0KSOBPJ5p%2Byr6dYNtmZmXF0rq%2BEls7CJFDCmCCRmA%3D&reserved=0). | 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com | %2Fghc-proposals%2Fghc-proposals%2Fpull%2F81%23issuecomment- | 336892922&data=02%7C01%7Csimonpj%40microsoft.com%7Cf4bcb638ccb04882991608d54 | 7e94370%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636493989543774014&sdat | a=kuDAxA3Tf1sKoA4CSllCp66sxvBo6nLMLQYCWBainzQ%3D&reserved=0). | | 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 From rae at cs.brynmawr.edu Thu Dec 21 14:15:03 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Thu, 21 Dec 2017 09:15:03 -0500 Subject: [ghc-steering-committee] Proposal: Syntax for visible dependent quantification (#81) In-Reply-To: References: Message-ID: <30B357D6-E03C-4A03-8D6C-F5BF22BF0E13@cs.brynmawr.edu> 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