From trupill at gmail.com Thu Apr 1 07:26:28 2021 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Thu, 1 Apr 2021 00:26:28 -0700 Subject: [ghc-steering-committee] Recommendation for #378: support the design for dependent types In-Reply-To: References: Message-ID: I agree with Vitaly on this not being a proper proposal. My main objection is that it indirectly brings all of https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell into the proposal, but in a sort of “we can still be wrong” mode. Personally, I’ll be happier to see the wiki page turned into a sort of “proposal roadmap” or something along those lines. Alejandro On 30 Mar 2021 at 15:08:42, Vitaly Bragilevsky wrote: > I don't see this proposal as a proper GHC proposal. I don't think we > should accept or reject it. We don't have a formal check for committee > criteria anyway. Am I in support of introducing DH into GHC? Yes, I am. But > then I'll be more inclined to support Richard's objections to any other > proposals if they contradict the DH design sketch. I don't need to swear to > follow these additional criteria. > > Vitaly > > > пн, 29 мар. 2021 г. в 15:17, Simon Peyton Jones via ghc-steering-committee > : > >> Dear GHC Steering Committee >> >> I’m recommending acceptance of Proposal #378: Support the design for >> dependent types >> >> As you’ll see, there is a lot of useful context, but the payload is >> pretty simple >> >> *When evaluating new proposals, the GHC committee would consider >> compatibility with the proposed design sketch of dependent types on the GHC >> wiki . >> Generally speaking, new proposals should be forward-compatible with the >> design sketch; that is, the new features proposed would continue to be at >> home when surrounded by other dependent-type features.* >> >> *Of course, the committee remains free to revise the design sketch or to >> accept proposals that encroach upon it (i.e. contradicting this guidance), >> but such choices should be made explicitly.* >> >> *See also the committee's Review Criteria >> : put >> another way, this proposal says that we consider the design sketch >> alongside other features of today's Haskell when assessing a new proposal's >> fit with the language.* >> >> *Note that compatibility with dependent types is far from the only >> criterion the committee would use to evaluate a proposal. Other review >> criteria, such as learnability, clarity of error messages, performance, >> etc., remain just as ever.* >> >> Any views? Let’s try to converge rapidly…. the proposal has been >> substantially refined by a lot of debate. >> >> Simon >> _______________________________________________ >> 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 trupill at gmail.com Thu Apr 1 07:33:20 2021 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Thu, 1 Apr 2021 00:33:20 -0700 Subject: [ghc-steering-committee] #371: Stop treating ~ magically. Rec: weak accept In-Reply-To: References: <010f017885c281e2-ddc4c62f-b5e8-4829-bdf2-aab06bbd99f3-000000@us-east-2.amazonses.com> Message-ID: Honestly, I don’t see the benefit of accepting this proposal. It’s clear that (~) is a special name anyway, because it does not respect the enforced convention on type constructors (in fact, I’m a bit surprised that you need to import (~~) and (~#), given their special status), and because the special role it plays in the language. I’m also concerned about the migration story: When the lookup for ~ fails because it is not in scope, assume it refers to > Data.Type.Equality.~. When this happens and -Wcompat is in effect, emit a > warning. > If we agreed that TypeOperators is almost always on (because of GHC2021), why not simply export this from the Prelude? Regards, Alejandro On 31 Mar 2021 at 16:29:32, Spiwack, Arnaud wrote: > This looks very minor. I'm not convinced that it is worth the hassle (that > being said, it is not hard to write code that is both forward and backward > compatible, so maybe there won't be much headache). > > The proposal says > > > The compiler internals are simplified, in particular things described in Note > [eqTyCon (~) is built-in syntax]. > > That's the really appetizing part (the fact that `~` will have a Haddock > documentation is not bad either). Those of us who have been involved in the > parts of the compiler that are touched here: do you think this is a > worthwhile simplification? That would secure my vote. > > On Wed, Mar 31, 2021 at 2:50 AM Richard Eisenberg > wrote: > >> Hi all, >> >> I am shepherding proposal #371. >> >> Proposal: >> https://github.com/int-index/ghc-proposals/blob/non-magical-eq/proposals/0000-non-magical-eq.md >> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/371 >> >> Summary: >> >> Currently, the type equality operator (~) is always in scope, but you can >> use it only if -XGADTs or -XTypeFamilies is enabled. The proposal instead >> changes this arrangement to export (~) from Data.Type.Equality (an existing >> module in `base`), and requiring -XTypeOperators to use it (as we do for >> all other infix operators in types). There is an 8-release migration plan, >> where for 6 releases, all uses of (~) that do not import it from >> Data.Type.Equality will get a warning telling the user to import >> Data.Type.Equality. >> >> The motivation for the proposal is uniformity: the goal is to treat (~) >> just like other type operators. >> >> Recommendation: >> >> I'm very much on the fence on this one, but in the end fall into the >> "accept" camp. The goal here is to achieve a simple cleanup in the language >> design (and implementation). It's a worthy goal, but it's disruptive. >> However, I think the disruption is small enough that it motivates the >> change. The fix for affected users is quite quick, and large-scale Haskell >> users probably already have a custom prelude that could make the change >> even easier to accommodate. Note also that TypeOperators is part of >> GHC2021, and so the change will likely only be a new import. >> >> What do others think? >> >> Without dissent, I will mark this proposal as accepted in two weeks. >> >> Thanks, >> 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 vlad.z.4096 at gmail.com Thu Apr 1 07:59:18 2021 From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index)) Date: Thu, 1 Apr 2021 10:59:18 +0300 Subject: [ghc-steering-committee] #371: Stop treating ~ magically. Rec: weak accept In-Reply-To: References: <010f017885c281e2-ddc4c62f-b5e8-4829-bdf2-aab06bbd99f3-000000@us-east-2.amazonses.com> Message-ID: <4F0B1081-DFAF-42CE-A3CF-F00BEFBF44B9@gmail.com> > It’s clear that (~) is a special name anyway, because it does not respect the enforced convention on type constructors To me, it is not clear at all. What convention do you have in mind? (~) is not that different from, say, (+), which is a valid type operator: class a + b -- accepted > If we agreed that TypeOperators is almost always on (because of GHC2021), why not simply export this from the Prelude? Exporting from Prelude is not a panacea: without a compatibility fallback, users of custom preludes will be affected. The proposed migration story means that for 8 releases, no existing code will break at all. Also, (~) is a special, magical constraint, like Coercible and Typeable. Since the proposal drops the requirement of GADTs and TypeFamilies to use it, the idea is to (eventually) require an explicit import of Data.Type.Equality to indicate the use of (~) in the code, for the same reason that we ask the users to import Data.Coerce and Data.Typeable/Type.Reflection - Vlad From trupill at gmail.com Thu Apr 1 13:59:47 2021 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Thu, 1 Apr 2021 06:59:47 -0700 Subject: [ghc-steering-committee] #371: Stop treating ~ magically. Rec: weak accept In-Reply-To: <4F0B1081-DFAF-42CE-A3CF-F00BEFBF44B9@gmail.com> References: <010f017885c281e2-ddc4c62f-b5e8-4829-bdf2-aab06bbd99f3-000000@us-east-2.amazonses.com> <4F0B1081-DFAF-42CE-A3CF-F00BEFBF44B9@gmail.com> Message-ID: On 1 Apr 2021 at 09:59:18, Vladislav Zavialov (int-index) < vlad.z.4096 at gmail.com> wrote: > It’s clear that (~) is a special name anyway, because it does not respect > the enforced convention on type constructors > > > To me, it is not clear at all. What convention do you have in mind? (~) is > not that different from, say, (+), which is a valid type operator: > > class a + b -- accepted > I meant the usual convention that type constructors must start with a capital letter or the : symbol. But in this case I had forgotten that with TypeOperators on, those conventions behave differently for types than for terms. > If we agreed that TypeOperators is almost always on (because of GHC2021), > why not simply export this from the Prelude? > > > Exporting from Prelude is not a panacea: without a compatibility fallback, > users of custom preludes will be affected. The proposed migration story > means that for 8 releases, no existing code will break at all. > But those custom preludes would have to be updated anyway, right? > Also, (~) is a special, magical constraint, like Coercible and Typeable. > Since the proposal drops the requirement of GADTs and TypeFamilies to use > it, the idea is to (eventually) require an explicit import of > Data.Type.Equality to indicate the use of (~) in the code, for the same > reason that we ask the users to import Data.Coerce and > Data.Typeable/Type.Reflection > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Thu Apr 1 18:37:21 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 1 Apr 2021 18:37:21 +0000 Subject: [ghc-steering-committee] #371: Stop treating ~ magically. Rec: weak accept In-Reply-To: <4F0B1081-DFAF-42CE-A3CF-F00BEFBF44B9@gmail.com> References: <010f017885c281e2-ddc4c62f-b5e8-4829-bdf2-aab06bbd99f3-000000@us-east-2.amazonses.com> <4F0B1081-DFAF-42CE-A3CF-F00BEFBF44B9@gmail.com> Message-ID: <010f01788eb9bfda-8728f034-a0f5-43f2-ac79-69c4e836a571-000000@us-east-2.amazonses.com> > On Apr 1, 2021, at 3:59 AM, Vladislav Zavialov (int-index) > wrote: > > Exporting from Prelude is not a panacea: without a compatibility fallback, users of custom preludes will be affected. The proposed migration story means that for 8 releases, no existing code will break at all. Right. I wasn't suggesting a change to the migration plan -- just that (~) would additionally be exported from the Prelude. The warning would trigger only when (~) isn't in scope, meaning that many users won't need to react to this change (given that -XTypeOperators is now on by default). As for the specialness of ~: yes, it's special, but we export other special things from the Prelude, like $ (which automatically enables -XImpredicativeTypes). > On Apr 1, 2021, at 9:59 AM, Alejandro Serrano Mena > wrote: > > I meant the usual convention that type constructors must start with a capital letter or the : symbol. But in this case I had forgotten that with TypeOperators on, those conventions behave differently for types than for terms. This used to be true, but the requirement that the first letter be a capital letter or : was dropped some time ago -- before I started using Haskell, in any case. It is independent of -XTypeOperators, which is necessary for any infix type level syntax. > > > But those custom preludes would have to be updated anyway, right? Yes, they would. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun Apr 4 10:34:29 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 04 Apr 2021 12:34:29 +0200 Subject: [ghc-steering-committee] Please review #409: Exportable named defaults, Shepherd: Eric Message-ID: Dear Committe, Exportable named defaults has been proposed by Mario https://github.com/ghc-proposals/ghc-proposals/pull/409 https://github.com/blamario/ghc-proposals/blob/exportable-named-default/proposals/0000-exportable-named-default.rst I propose Eric as the Shepherd. This did not gather a lot of attention on Github, or rather none, so Eric, maybe also consider whether this needs to be advertised more, or maybe who should be pointed to it. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Mon Apr 5 15:03:29 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 05 Apr 2021 17:03:29 +0200 Subject: [ghc-steering-committee] GHC Steering Comittee Status Message-ID: <85c5293b1fd3e4e7a80da0f0d1f3c9f383b030a8.camel@joachim-breitner.de> Dear Committee, an easterly status update. The last 1½ was relatively active, and we have a solit throughput. Keep it up! So here’s the delta since last month. * Vladislav joined! Also Iavor, Richard and me re-joined. * we were asked to review these proposals: #405: Split RecordDotSyntax, Shepherd: Simon PJ #403: lexical structure of numbers and identifiers, Shepherd: Arnaud #400: Constrained COMPLETE sets, Shepherd: Cale #402: Stable GADT constructor syntax, Shepherd: Richard #378: Support ergonomic dependent types, Shepherd: Simon PJ #283: Local modules, Shepherd: Arnaud #396: Defaulting plugins, Shepherd: Vladislav #371: Stop treating ~ magically, Shepherd: Richard #409: Exportable named defaults, Shepherd: Eric * we have a recommendation from the shepherd about: #390: Fine-grained pragmas, recommendation: accept #405: Split RecordDotSyntax, rec: accept #403: Cleanup lexical structure, recommendation: accept #367: Clarify primops using unboxed sums, rec: reject #402: Changes to GADT syntax; rec: accept #378: support the design for dependent types, rec: accept #371: Stop treating ~ magically. rec: weak accept * we have sent the following proposals back to revision #381: Visible 'forall' in types of terms #302: \of #390: Fine-grained pragmas * we decided about the following proposals #369: Add sumToTag# (accept) #403: Cleanup lexical structure (accept) #367: Clarify primops using unboxed sums (reject) #405: Split RecordDotSyntax (accept) #403: Cleanup lexical structure (accept) We currently have to act on the following 6 proposals, up by 1. ## Waiting for committee decision #402: Stable GADT constructor syntax, Shepherd: Richard Recommendation is to accept. There is some ongoing discussion if extra parents should be continued to be allowed. #371: Stop treating ~ magically, Shepherd: Richard Recommendation is to accept. Some ongoing discussion about whether exporting ~ might be pragmatic choice. #378: Support ergonomic dependent types, Shepherd: Simon PJ Recommendation is to accept, but there are some doubts that this is a proper proposal that should be addressed first. I expect some more soul-searching here. ## Waiting for Shepherd action #283: Local modules, Shepherd: Arnaud Waiting for recommendation. #400: Constrained COMPLETE sets, Shepherd: Cale Waiting for recommendation. #409: Exportable named defaults, Shepherd: Eric Waiting for recommendation. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simonpj at microsoft.com Tue Apr 6 12:57:59 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 6 Apr 2021 12:57:59 +0000 Subject: [ghc-steering-committee] Recommendation for #378: support the design for dependent types In-Reply-To: References: Message-ID: Richard and I have discussed this. We concluded that we'd put it back into "Needs revision" status. He's going to expand it (substantially) to include the proposed design sketch of dependent types on the GHC wiki. Then he'll resubmit in the hope of getting approval of the design in principle, subject to subsequent discussion of the fine detail. Simon From: Simon Peyton Jones Sent: 29 March 2021 13:17 To: ghc-steering-committee at haskell.org Cc: Simon Peyton Jones Subject: Recommendation for #378: support the design for dependent types Dear GHC Steering Committee I'm recommending acceptance of Proposal #378: Support the design for dependent types As you'll see, there is a lot of useful context, but the payload is pretty simple When evaluating new proposals, the GHC committee would consider compatibility with the proposed design sketch of dependent types on the GHC wiki. Generally speaking, new proposals should be forward-compatible with the design sketch; that is, the new features proposed would continue to be at home when surrounded by other dependent-type features. Of course, the committee remains free to revise the design sketch or to accept proposals that encroach upon it (i.e. contradicting this guidance), but such choices should be made explicitly. See also the committee's Review Criteria: put another way, this proposal says that we consider the design sketch alongside other features of today's Haskell when assessing a new proposal's fit with the language. Note that compatibility with dependent types is far from the only criterion the committee would use to evaluate a proposal. Other review criteria, such as learnability, clarity of error messages, performance, etc., remain just as ever. Any views? Let's try to converge rapidly.... the proposal has been substantially refined by a lot of debate. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Wed Apr 7 18:47:59 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 7 Apr 2021 18:47:59 +0000 Subject: [ghc-steering-committee] Updated #402 -- now with parentheses! In-Reply-To: References: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com> <010f01784bc8030b-9fbc0af7-d51f-4437-af11-e88b71b8461b-000000@us-east-2.amazonses.com> <010f01785a2ef1cc-13378a12-969b-47a8-93d0-31066ec87ea3-000000@us-east-2.amazonses.com> <8022cc7b-f5f6-4b6f-b339-83ae31f99d97@www.fastmail.com> Message-ID: <010f0178ada9a5a5-9be19463-f2c6-42f8-8eea-e0e1780131ab-000000@us-east-2.amazonses.com> Hi all, The author of #402 (our own Vladislav) has modified it to remove the bit about dropping parentheses. The proposal is now solely about liberalizing the existing syntax to allow arbitrary nesting of quantifiers in non-record constructors. My recommendation remains to accept. Are there other further thoughts here? Thanks, Richard From arnaud.spiwack at tweag.io Thu Apr 8 06:19:20 2021 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Thu, 8 Apr 2021 08:19:20 +0200 Subject: [ghc-steering-committee] Updated #402 -- now with parentheses! In-Reply-To: <010f0178ada9a5a5-9be19463-f2c6-42f8-8eea-e0e1780131ab-000000@us-east-2.amazonses.com> References: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com> <010f01784bc8030b-9fbc0af7-d51f-4437-af11-e88b71b8461b-000000@us-east-2.amazonses.com> <010f01785a2ef1cc-13378a12-969b-47a8-93d0-31066ec87ea3-000000@us-east-2.amazonses.com> <8022cc7b-f5f6-4b6f-b339-83ae31f99d97@www.fastmail.com> <010f0178ada9a5a5-9be19463-f2c6-42f8-8eea-e0e1780131ab-000000@us-east-2.amazonses.com> Message-ID: I didn't comment on the previous thread, I believe. It's because I really don't have much of an opinion on this issue. So do take my silence as assent to whatever the rest of us agree on. On Wed, Apr 7, 2021 at 8:48 PM Richard Eisenberg wrote: > Hi all, > > The author of #402 (our own Vladislav) has modified it to remove the bit > about dropping parentheses. The proposal is now solely about liberalizing > the existing syntax to allow arbitrary nesting of quantifiers in non-record > constructors. My recommendation remains to accept. > > Are there other further thoughts here? > > 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 eric at seidel.io Sun Apr 11 18:27:55 2021 From: eric at seidel.io (Eric Seidel) Date: Sun, 11 Apr 2021 14:27:55 -0400 Subject: [ghc-steering-committee] Updated #402 -- now with parentheses! In-Reply-To: <010f0178ada9a5a5-9be19463-f2c6-42f8-8eea-e0e1780131ab-000000@us-east-2.amazonses.com> References: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com> <010f01784bc8030b-9fbc0af7-d51f-4437-af11-e88b71b8461b-000000@us-east-2.amazonses.com> <010f01785a2ef1cc-13378a12-969b-47a8-93d0-31066ec87ea3-000000@us-east-2.amazonses.com> <8022cc7b-f5f6-4b6f-b339-83ae31f99d97@www.fastmail.com> <010f0178ada9a5a5-9be19463-f2c6-42f8-8eea-e0e1780131ab-000000@us-east-2.amazonses.com> Message-ID: Thanks, I'm happy with the proposal now. On Wed, Apr 7, 2021, at 14:47, Richard Eisenberg wrote: > Hi all, > > The author of #402 (our own Vladislav) has modified it to remove the > bit about dropping parentheses. The proposal is now solely about > liberalizing the existing syntax to allow arbitrary nesting of > quantifiers in non-record constructors. My recommendation remains to > accept. > > Are there other further thoughts here? > > Thanks, > Richard > _______________________________________________ > 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 Mon Apr 12 07:17:38 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 12 Apr 2021 09:17:38 +0200 Subject: [ghc-steering-committee] Updated #402 -- now with parentheses! In-Reply-To: References: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com> <010f01784bc8030b-9fbc0af7-d51f-4437-af11-e88b71b8461b-000000@us-east-2.amazonses.com> <010f01785a2ef1cc-13378a12-969b-47a8-93d0-31066ec87ea3-000000@us-east-2.amazonses.com> <8022cc7b-f5f6-4b6f-b339-83ae31f99d97@www.fastmail.com> <010f0178ada9a5a5-9be19463-f2c6-42f8-8eea-e0e1780131ab-000000@us-east-2.amazonses.com> Message-ID: I concur. Am Sonntag, den 11.04.2021, 14:27 -0400 schrieb Eric Seidel: > Thanks, I'm happy with the proposal now. > > On Wed, Apr 7, 2021, at 14:47, Richard Eisenberg wrote: > > Hi all, > > > > The author of #402 (our own Vladislav) has modified it to remove the > > bit about dropping parentheses. The proposal is now solely about > > liberalizing the existing syntax to allow arbitrary nesting of > > quantifiers in non-record constructors. My recommendation remains to > > accept. > > > > Are there other further thoughts here? > > > > Thanks, > > 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 trupill at gmail.com Tue Apr 13 19:25:44 2021 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Tue, 13 Apr 2021 12:25:44 -0700 Subject: [ghc-steering-committee] Updated #402 -- now with parentheses! In-Reply-To: References: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com> <010f01784bc8030b-9fbc0af7-d51f-4437-af11-e88b71b8461b-000000@us-east-2.amazonses.com> <010f01785a2ef1cc-13378a12-969b-47a8-93d0-31066ec87ea3-000000@us-east-2.amazonses.com> <8022cc7b-f5f6-4b6f-b339-83ae31f99d97@www.fastmail.com> <010f0178ada9a5a5-9be19463-f2c6-42f8-8eea-e0e1780131ab-000000@us-east-2.amazonses.com> Message-ID: I also agree with acceptance now. Alejandro On 12 Apr 2021 at 09:17:38, Joachim Breitner wrote: > I concur. > > Am Sonntag, den 11.04.2021, 14:27 -0400 schrieb Eric Seidel: > > Thanks, I'm happy with the proposal now. > > > On Wed, Apr 7, 2021, at 14:47, Richard Eisenberg wrote: > > > Hi all, > > > > > > The author of #402 (our own Vladislav) has modified it to remove the > > > bit about dropping parentheses. The proposal is now solely about > > > liberalizing the existing syntax to allow arbitrary nesting of > > > quantifiers in non-record constructors. My recommendation remains to > > > accept. > > > > > > Are there other further thoughts here? > > > > > > Thanks, > > > 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/ > > > _______________________________________________ > 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 Thu Apr 15 09:38:47 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 15 Apr 2021 09:38:47 +0000 Subject: [ghc-steering-committee] Recommendation for #378: support the design for dependent types Message-ID: Dear GHC steering committee OK Richard has now revised the "Design for Dependent Types" proposal, and has resubmitted it. As we asked, it now includes the design sketch that constitutes the direction of travel advocated in the proposal, rather than merely referring to it. Here it is once more I propose acceptance. Remember: * We would not be accepting every detail of the design in Section 4 - rather, we expect further specific proposals as we move in the direction described in the proposal. So we should not debate the fine print of Section 4. * We would be accepting that the proposal describes a direction of travel that we are happy with. That in turn gives people the confidence to invest efforts in those more detailed proposals. As the "Proposed change specification" says: "When evaluating new proposals, the GHC committee would consider compatibility with the design sketch below. Generally speaking, new proposals should be forward-compatible with the design sketch; that is, the new features proposed would continue to be at home when surrounded by other dependent-type features." Any views? Questions of clarification or technical questions belong on the comment stream. Thanks Simon From: ghc-steering-committee On Behalf Of Simon Peyton Jones via ghc-steering-committee Sent: 06 April 2021 13:58 To: ghc-steering-committee at haskell.org Subject: Re: [ghc-steering-committee] Recommendation for #378: support the design for dependent types Richard and I have discussed this. We concluded that we'd put it back into "Needs revision" status. He's going to expand it (substantially) to include the proposed design sketch of dependent types on the GHC wiki. Then he'll resubmit in the hope of getting approval of the design in principle, subject to subsequent discussion of the fine detail. Simon From: Simon Peyton Jones > Sent: 29 March 2021 13:17 To: ghc-steering-committee at haskell.org Cc: Simon Peyton Jones > Subject: Recommendation for #378: support the design for dependent types Dear GHC Steering Committee I'm recommending acceptance of Proposal #378: Support the design for dependent types As you'll see, there is a lot of useful context, but the payload is pretty simple When evaluating new proposals, the GHC committee would consider compatibility with the proposed design sketch of dependent types on the GHC wiki. Generally speaking, new proposals should be forward-compatible with the design sketch; that is, the new features proposed would continue to be at home when surrounded by other dependent-type features. Of course, the committee remains free to revise the design sketch or to accept proposals that encroach upon it (i.e. contradicting this guidance), but such choices should be made explicitly. See also the committee's Review Criteria: put another way, this proposal says that we consider the design sketch alongside other features of today's Haskell when assessing a new proposal's fit with the language. Note that compatibility with dependent types is far from the only criterion the committee would use to evaluate a proposal. Other review criteria, such as learnability, clarity of error messages, performance, etc., remain just as ever. Any views? Let's try to converge rapidly.... the proposal has been substantially refined by a lot of debate. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun Apr 18 09:26:14 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 18 Apr 2021 11:26:14 +0200 Subject: [ghc-steering-committee] Recommendation for #378: support the design for dependent types In-Reply-To: References: Message-ID: <03cab8e139267607b9406325ca8b07d7fcdc8b62.camel@joachim-breitner.de> Dear Committee, > Richard has now revised the “Design for Dependent Types” proposal, and has resubmitted it. I am in support of this proposal. I expect it will be painful at times to go that route, and it will creak at the edges, but my sense is that this eventual unification of types and terms is something that will become something we’d expect from a “modern language”, a bit like we expect function types and lambdas these days, and I have some hope that eventually, in a relatively far away future, Haskell will nicer and simpler because of this The alternative, sticking to a non-dependent design (and yes, getting some benefits from that too), could lead to Haskell becoming a “language of the 00s”. Useful, mature, great to get work done, still something that not everybody knows and you can still feel a bit special for knowing it. But no longer the language that is _both_ productively usable and at the same time incorporates new, research-close features. It might become a bit like Perl in that sense. (Ok, that’s a bit too gloomy … take it as hyperbole). I expect that discouraging punning will be maybe the most painful part of that route, for the wider community. import GHC.Tupe; swap :: Tuple [a,b] -> Tuple [b,a] just isn’t as smooth as `swap :: (a,b) -> (b,a)`. (And we can’t even cargo-cult from the ML family and use `(a * b) -> (b * a)` for the type of types…) I acknowledge that, I wish there was a better solution, but what’s in #378 seems to be the least bad. I am amused that this proposal rests on a PEP, and happy to see that the LSP gets a more central role in the language design ;-) Cheers, Joachim PS: Quick note about #291 (type variables in patterns), just to record my current thinking: I understand the reasoning, it would be nice to treat a `@(Maybe a)` argument like a `(Just x)` argument in patterns, binding `a`. But I am not convinced we can afford to toss out the ability to use an _occurence_ of a type `a`. My interpretation of #378’s implication on #291 is that we’ll have to find a way to distinguish binders from ocurrences that works independently of types and values (I believe we do need it for types, and I think we should have this for values as well anyways, as PatternSynonyms _should_ be able to abstract over patterns that have _required_ values, not just required constraints.) -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From trupill at gmail.com Mon Apr 19 07:03:23 2021 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Mon, 19 Apr 2021 00:03:23 -0700 Subject: [ghc-steering-committee] Recommendation for #378: support the design for dependent types In-Reply-To: <03cab8e139267607b9406325ca8b07d7fcdc8b62.camel@joachim-breitner.de> References: <03cab8e139267607b9406325ca8b07d7fcdc8b62.camel@joachim-breitner.de> Message-ID: Dear Committee, I still have mixed feeling about this, but they are more about the whole “Dependent Haskell” project as a whole than about this specific proposal, which I find now in really good shape. On the one hand, I fear that by introducing more and more DH features, the language will morph into something difficult to reconcile with “basic Haskell”. After all, if we have dependent features available, why not use it in the Prelude and other libraries? This would make Haskell harder to use in (1) teaching, since newcomers would need more time to understand those features, and (2) research, since to build a tool on top of Haskell (think of LiquidHaskell) you’ll need to buy the whole “dependent + linear paradigm” too. On the other hand, the status of type-level computation in GHC is less than ideal: too many separate extensions, each of them adding a tiny bit of expressiveness, and a handful of folklore tricks. On that regard, having a prospective design of the future is great, because (1) it allows for a more cohesive set of features, and (2) helps on focusing the goals of the broader community. And since GHC already have some of those features, it’s actually possible to stop the boat sailing on the direction of dependent + linear types? Is this the design we want? is yet another question. I am quite confident about the maturity of the design, knowing that the authors have been working on this problem for years (even more a decade?). Regards, Alejandro On 18 Apr 2021 at 11:26:14, Joachim Breitner wrote: > Dear Committee, > > Richard has now revised the “Design for Dependent Types” proposal, > > and has resubmitted it. > > I am in support of this proposal. I expect it will be painful at times > to go that route, and it will creak at the edges, but my sense is that > this eventual unification of types and terms is something that will > become something we’d expect from a “modern language”, a bit like we > expect function types and lambdas these days, and I have some hope that > eventually, in a relatively far away future, Haskell will nicer and > simpler because of this > > The alternative, sticking to a non-dependent design (and yes, getting > some benefits from that too), could lead to Haskell becoming a > “language of the 00s”. Useful, mature, great to get work done, still > something that not everybody knows and you can still feel a bit special > for knowing it. But no longer the language that is _both_ productively > usable and at the same time incorporates new, research-close features. > It might become a bit like Perl in that sense. (Ok, that’s a bit too > gloomy … take it as hyperbole). > > > I expect that discouraging punning will be maybe the most painful > part of that route, for the wider community. > import GHC.Tupe; swap :: > Tuple [a,b] -> Tuple [b,a] > just isn’t as smooth as `swap :: (a,b) -> > (b,a)`. > (And we can’t even cargo-cult from the ML family and use > `(a * b) -> (b * a)` for the type of types…) > I acknowledge that, I wish > there was a better solution, but what’s in #378 seems to be the least > bad. > > > I am amused that this proposal rests on a PEP, and happy to see that > the LSP gets a more central role in the language design ;-) > > Cheers, > Joachim > > > PS: Quick note about #291 (type variables in patterns), just to record > my current thinking: > > I understand the reasoning, it would be nice to > treat a `@(Maybe a)` argument like a `(Just x)` argument in patterns, > binding `a`. But I am not convinced we can afford to toss out the > ability to use an _occurence_ of a type `a`. My interpretation of > #378’s implication on #291 is that we’ll have to find a way to > distinguish binders from ocurrences that works independently of types > and values (I believe we do need it for types, and I think we should > have this for values as well anyways, as PatternSynonyms _should_ be > able to abstract over patterns that have _required_ values, not just > required constraints.) > > -- > 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 richarde.dev Mon Apr 19 16:03:44 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 19 Apr 2021 16:03:44 +0000 Subject: [ghc-steering-committee] Recommendation for #378: support the design for dependent types In-Reply-To: References: <03cab8e139267607b9406325ca8b07d7fcdc8b62.camel@joachim-breitner.de> Message-ID: <010f0178eadf967c-c0c47b2f-2ff9-4033-9b1d-06afc0edc145-000000@us-east-2.amazonses.com> > On Apr 19, 2021, at 3:03 AM, Alejandro Serrano Mena wrote: > > On the one hand, I fear that by introducing more and more DH features, the language will morph into something difficult to reconcile with “basic Haskell”. After all, if we have dependent features available, why not use it in the Prelude and other libraries? This would make Haskell harder to use in (1) teaching, since newcomers would need more time to understand those features, and (2) research, since to build a tool on top of Haskell (think of LiquidHaskell) you’ll need to buy the whole “dependent + linear paradigm” too. Both of these are great points to raise. For (1): we will have to continue to use good taste in designing the Prelude/`base` and other libraries. Lots of fancy features have existed in Haskell for decades, but we have been careful in how these are exposed to users. One small blunder happened a few years ago when `:t ($)` became very unwieldy (showing $'s levity polymorphism), and that got fixed before release. Another blunder (in my opinion) is that the type of length now requires understanding Foldable -- but the code around Foldable & Traversable is all Haskell98 anyway. It remains vitally important that error messages and GHCi interactions remain understandable to beginners. I personally would consider it a failure of this project if that were not to be the case. I have added some thoughts around this to the proposal at https://github.com/goldfirere/ghc-proposals/blob/dependent-types/proposals/0000-dependent-type-design.rst#learnability-of-haskell For (2): This is harder. I suppose a researcher could consider Haskell without -XLinearTypes -XDependentTypes, but any GHC-based implementation would be out of reach, then. Regardless, many Haskell-based research papers already choose a slice of GHC/Haskell to study, and I expect that to continue to be the case. However, I acknowledge that research accessibility may decrease with this change. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From bravit111 at gmail.com Mon Apr 19 16:29:06 2021 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Mon, 19 Apr 2021 19:29:06 +0300 Subject: [ghc-steering-committee] Recommendation for #378: support the design for dependent types In-Reply-To: <010f0178eadf967c-c0c47b2f-2ff9-4033-9b1d-06afc0edc145-000000@us-east-2.amazonses.com> References: <03cab8e139267607b9406325ca8b07d7fcdc8b62.camel@joachim-breitner.de> <010f0178eadf967c-c0c47b2f-2ff9-4033-9b1d-06afc0edc145-000000@us-east-2.amazonses.com> Message-ID: Dear Committee, I support this proposal. I think, that the hardest problem when teaching Haskell is not to get through the basics. Many of us who have teaching experience all know how to get that done. The real problems come with type-level magic and workarounds involving singletons. I often find that it's much easier to explain and solve the very same problems in Idris than in Haskell. If we want to use the corresponding features in Haskell (and many of Haskellers really want that), we must make them clearer. I believe that DH (as sketched in this proposal) is the right way to do that. Every now and then I hear the question if we are going to get dependent types in Haskell. I'm sure, Richard answers this question on a daily basis. I consider accepting this proposal as a clear statement to those who wait for dependent types in Haskell. So, let's do that! Vitaly пн, 19 апр. 2021 г. в 19:04, Richard Eisenberg : > > > On Apr 19, 2021, at 3:03 AM, Alejandro Serrano Mena > wrote: > > On the one hand, I fear that by introducing more and more DH features, the > language will morph into something difficult to reconcile with “basic > Haskell”. After all, if we have dependent features available, why not use > it in the Prelude and other libraries? This would make Haskell harder to > use in (1) teaching, since newcomers would need more time to understand > those features, and (2) research, since to build a tool on top of Haskell > (think of LiquidHaskell) you’ll need to buy the whole “dependent + linear > paradigm” too. > > > Both of these are great points to raise. For (1): we will have to continue > to use good taste in designing the Prelude/`base` and other libraries. Lots > of fancy features have existed in Haskell for decades, but we have been > careful in how these are exposed to users. One small blunder happened a few > years ago when `:t ($)` became very unwieldy (showing $'s levity > polymorphism), and that got fixed before release. Another blunder (in my > opinion) is that the type of length now requires understanding Foldable -- > but the code around Foldable & Traversable is all Haskell98 anyway. It > remains vitally important that error messages and GHCi interactions remain > understandable to beginners. I personally would consider it a failure of > this project if that were not to be the case. I have added some thoughts > around this to the proposal at > https://github.com/goldfirere/ghc-proposals/blob/dependent-types/proposals/0000-dependent-type-design.rst#learnability-of-haskell > > For (2): This is harder. I suppose a researcher could consider Haskell > without -XLinearTypes -XDependentTypes, but any GHC-based implementation > would be out of reach, then. Regardless, many Haskell-based research papers > already choose a slice of GHC/Haskell to study, and I expect that to > continue to be the case. However, I acknowledge that research accessibility > may decrease with this change. > > 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 Wed Apr 21 06:40:29 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 21 Apr 2021 08:40:29 +0200 Subject: [ghc-steering-committee] Please review #415: OPAQUE pragma, Shepherd: Tom Message-ID: <5ff728d27bd506f90ce1201ea62764dfb458764f.camel@joachim-breitner.de> Dear Committe, OPAQUE pragma has been proposed by Christiaan Baaij https://github.com/ghc-proposals/ghc-proposals/pull/415 https://github.com/christiaanb/ghc-proposals/blob/master/proposals/0000-opaque-pragma.md I’ll propose Tom as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simonpj at microsoft.com Wed Apr 21 09:07:14 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 21 Apr 2021 09:07:14 +0000 Subject: [ghc-steering-committee] Please review #415: OPAQUE pragma, Shepherd: Tom In-Reply-To: <5ff728d27bd506f90ce1201ea62764dfb458764f.camel@joachim-breitner.de> References: <5ff728d27bd506f90ce1201ea62764dfb458764f.camel@joachim-breitner.de> Message-ID: Tom, I'm in support of this. It's simple, useful, driven by a real application need, and easy to implement. (There a small patch that does it already.) Simon | -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 21 April 2021 07:40 | To: ghc-steering-committee | Subject: [ghc-steering-committee] Please review #415: OPAQUE pragma, | Shepherd: Tom | | Dear Committe, | | OPAQUE pragma | has been proposed by Christiaan Baaij | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2Fghc-proposals%2Fghc- | proposals%2Fpull%2F415&data=04%7C01%7Csimonpj%40microsoft.com%7C06 | 54777eb2f74eeff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1% | 7C0%7C637545841499459221%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL | CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wm44ph5 | Int4gqu6JKkedaAKqE0DJOcqjqK3%2BT%2BHEXcA%3D&reserved=0 | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2Fchristiaanb%2Fghc- | proposals%2Fblob%2Fmaster%2Fproposals%2F0000-opaque- | pragma.md&data=04%7C01%7Csimonpj%40microsoft.com%7C0654777eb2f74ee | ff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375458 | 41499459221%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MD9R%2FGRTR8j8blj%2F | o2cCc6JFpbgPiGakqGkZoSoQkeg%3D&reserved=0 | | | I'll propose Tom as the shepherd. | | Please guide us to a conclusion as outlined in | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2Fghc-proposals%2Fghc-proposals%23committee- | process&data=04%7C01%7Csimonpj%40microsoft.com%7C0654777eb2f74eeff | 5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637545841 | 499459221%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi | LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VEiKysJyP4hRJ3J%2FIAQ0 | k2t9qm7qhreZF%2FMfA31Ct1k%3D&reserved=0 | | Thanks, | Joachim | -- | -- | Joachim Breitner | mail at joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0654777eb2 | f74eeff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 | 7545841499469214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zURoYM0rQvnF%2F | j0EngntoTDt2cG7aSPEResXA4i6m%2FE%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0654777eb2f74ee | ff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375458 | 41499469214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TEQsWPaCoHIvcGy%2FH1 | te1tmgRGe%2BHeYwhU1FcoZ4TVM%3D&reserved=0 From rae at richarde.dev Wed Apr 21 17:44:19 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 21 Apr 2021 17:44:19 +0000 Subject: [ghc-steering-committee] Updated #402 -- now with parentheses! In-Reply-To: References: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com> <010f01784bc8030b-9fbc0af7-d51f-4437-af11-e88b71b8461b-000000@us-east-2.amazonses.com> <010f01785a2ef1cc-13378a12-969b-47a8-93d0-31066ec87ea3-000000@us-east-2.amazonses.com> <8022cc7b-f5f6-4b6f-b339-83ae31f99d97@www.fastmail.com> <010f0178ada9a5a5-9be19463-f2c6-42f8-8eea-e0e1780131ab-000000@us-east-2.amazonses.com> Message-ID: <010f0178f5886170-87fcf52b-1b83-46a5-940e-f593e6bbff15-000000@us-east-2.amazonses.com> I have now accepted this proposal by completing the steps at https://github.com/ghc-proposals/ghc-proposals/blob/master/acceptance.rst Thanks all! Richard > On Apr 13, 2021, at 3:25 PM, Alejandro Serrano Mena wrote: > > I also agree with acceptance now. > > Alejandro > > On 12 Apr 2021 at 09:17:38, Joachim Breitner > wrote: > I concur. > > Am Sonntag, den 11.04.2021, 14:27 -0400 schrieb Eric Seidel: >> Thanks, I'm happy with the proposal now. >> >> On Wed, Apr 7, 2021, at 14:47, Richard Eisenberg wrote: >> > Hi all, >> > >> > The author of #402 (our own Vladislav) has modified it to remove the >> > bit about dropping parentheses. The proposal is now solely about >> > liberalizing the existing syntax to allow arbitrary nesting of >> > quantifiers in non-record constructors. My recommendation remains to >> > accept. >> > >> > Are there other further thoughts here? >> > >> > Thanks, >> > 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/ > > > _______________________________________________ > 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 trupill at gmail.com Wed Apr 21 19:54:11 2021 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Wed, 21 Apr 2021 12:54:11 -0700 Subject: [ghc-steering-committee] Please review #415: OPAQUE pragma, Shepherd: Tom In-Reply-To: References: <5ff728d27bd506f90ce1201ea62764dfb458764f.camel@joachim-breitner.de> Message-ID: That seems reasonable and with a direct application, so I’m in favor of acceptance. Alejandro On 21 Apr 2021 at 11:07:14, Simon Peyton Jones via ghc-steering-committee < ghc-steering-committee at haskell.org> wrote: > Tom, I'm in support of this. It's simple, useful, driven by a real > application need, and easy to implement. (There a small patch that does it > already.) > > Simon > > | -----Original Message----- > | From: ghc-steering-committee | bounces at haskell.org> On Behalf Of Joachim Breitner > | Sent: 21 April 2021 07:40 > | To: ghc-steering-committee > | Subject: [ghc-steering-committee] Please review #415: OPAQUE pragma, > | Shepherd: Tom > | > | Dear Committe, > | > | OPAQUE pragma > | has been proposed by Christiaan Baaij > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > | ub.com%2Fghc-proposals%2Fghc- > | proposals%2Fpull%2F415&data=04%7C01%7Csimonpj%40microsoft.com%7C06 > | 54777eb2f74eeff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1% > | 7C0%7C637545841499459221%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL > | CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wm44ph5 > | Int4gqu6JKkedaAKqE0DJOcqjqK3%2BT%2BHEXcA%3D&reserved=0 > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > | ub.com%2Fchristiaanb%2Fghc- > | proposals%2Fblob%2Fmaster%2Fproposals%2F0000-opaque- > | pragma.md&data=04%7C01%7Csimonpj%40microsoft.com%7C0654777eb2f74ee > | ff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375458 > | 41499459221%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz > | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MD9R%2FGRTR8j8blj%2F > | o2cCc6JFpbgPiGakqGkZoSoQkeg%3D&reserved=0 > | > | > | I'll propose Tom as the shepherd. > | > | Please guide us to a conclusion as outlined in > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > | ub.com%2Fghc-proposals%2Fghc-proposals%23committee- > | process&data=04%7C01%7Csimonpj%40microsoft.com%7C0654777eb2f74eeff > | 5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637545841 > | 499459221%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi > | LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VEiKysJyP4hRJ3J%2FIAQ0 > | k2t9qm7qhreZF%2FMfA31Ct1k%3D&reserved=0 > | > | Thanks, > | Joachim > | -- > | -- > | Joachim Breitner > | mail at joachim-breitner.de > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j > | oachim- > | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0654777eb2 > | f74eeff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 > | 7545841499469214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV > | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zURoYM0rQvnF%2F > | j0EngntoTDt2cG7aSPEResXA4i6m%2FE%3D&reserved=0 > | > | > | _______________________________________________ > | ghc-steering-committee mailing list > | ghc-steering-committee at haskell.org > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail > | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0654777eb2f74ee > | ff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375458 > | 41499469214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz > | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TEQsWPaCoHIvcGy%2FH1 > | te1tmgRGe%2BHeYwhU1FcoZ4TVM%3D&reserved=0 > _______________________________________________ > 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 richarde.dev Thu Apr 22 02:10:28 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 22 Apr 2021 02:10:28 +0000 Subject: [ghc-steering-committee] #371: Stop treating ~ magically. Rec: weak accept In-Reply-To: <010f01788eb9bfda-8728f034-a0f5-43f2-ac79-69c4e836a571-000000@us-east-2.amazonses.com> References: <010f017885c281e2-ddc4c62f-b5e8-4829-bdf2-aab06bbd99f3-000000@us-east-2.amazonses.com> <4F0B1081-DFAF-42CE-A3CF-F00BEFBF44B9@gmail.com> <010f01788eb9bfda-8728f034-a0f5-43f2-ac79-69c4e836a571-000000@us-east-2.amazonses.com> Message-ID: <010f0178f757c6b8-f8c61c40-cf70-439a-9357-2ff90e9fa0e9-000000@us-east-2.amazonses.com> Hi committee, This proposal has been updated to include exporting (~) from the Prelude. This means that migration is much easier than it was previously, likely not requiring any import changes (or just in a project's custom Prelude). Users will have to enable -XTypeOperators (and could choose to disable -XGADTs or -XTypeFamilies). With this new export, I'm more firmly in favor of cleaning up this one little corner: let's accept. I will wait one week for any comments, and then will accept this proposal. Thanks, Richard > On Apr 1, 2021, at 2:37 PM, Richard Eisenberg wrote: > > > >> On Apr 1, 2021, at 3:59 AM, Vladislav Zavialov (int-index) > wrote: >> >> Exporting from Prelude is not a panacea: without a compatibility fallback, users of custom preludes will be affected. The proposed migration story means that for 8 releases, no existing code will break at all. > > Right. I wasn't suggesting a change to the migration plan -- just that (~) would additionally be exported from the Prelude. The warning would trigger only when (~) isn't in scope, meaning that many users won't need to react to this change (given that -XTypeOperators is now on by default). > > As for the specialness of ~: yes, it's special, but we export other special things from the Prelude, like $ (which automatically enables -XImpredicativeTypes). > >> On Apr 1, 2021, at 9:59 AM, Alejandro Serrano Mena > wrote: >> >> I meant the usual convention that type constructors must start with a capital letter or the : symbol. But in this case I had forgotten that with TypeOperators on, those conventions behave differently for types than for terms. > > This used to be true, but the requirement that the first letter be a capital letter or : was dropped some time ago -- before I started using Haskell, in any case. It is independent of -XTypeOperators, which is necessary for any infix type level syntax. > >> >> >> But those custom preludes would have to be updated anyway, right? > > Yes, they would. > > 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 arnaud.spiwack at tweag.io Thu Apr 22 09:25:32 2021 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Thu, 22 Apr 2021 11:25:32 +0200 Subject: [ghc-steering-committee] #371: Stop treating ~ magically. Rec: weak accept In-Reply-To: <010f0178f757c6b8-f8c61c40-cf70-439a-9357-2ff90e9fa0e9-000000@us-east-2.amazonses.com> References: <010f017885c281e2-ddc4c62f-b5e8-4829-bdf2-aab06bbd99f3-000000@us-east-2.amazonses.com> <4F0B1081-DFAF-42CE-A3CF-F00BEFBF44B9@gmail.com> <010f01788eb9bfda-8728f034-a0f5-43f2-ac79-69c4e836a571-000000@us-east-2.amazonses.com> <010f0178f757c6b8-f8c61c40-cf70-439a-9357-2ff90e9fa0e9-000000@us-east-2.amazonses.com> Message-ID: I'm still not sure what problem this proposal solves. The proposal alludes to some code simplification but doesn't give me a good idea of how much simpler this would make the code. Also note that -XGADT becomes mostly vacuous with this proposal: -XGADTSyntax + -XExistentialTypes imply GADTs (both are in -XGHC2021). Not that I mind, really, I actually probably prefer it this way. But it's worthy of notice. On Thu, Apr 22, 2021 at 4:10 AM Richard Eisenberg wrote: > Hi committee, > > This proposal has been updated to include exporting (~) from the Prelude. > This means that migration is much easier than it was previously, likely not > requiring any import changes (or just in a project's custom Prelude). Users > will have to enable -XTypeOperators (and could choose to disable -XGADTs or > -XTypeFamilies). With this new export, I'm more firmly in favor of cleaning > up this one little corner: let's accept. > > I will wait one week for any comments, and then will accept this proposal. > > Thanks, > Richard > > On Apr 1, 2021, at 2:37 PM, Richard Eisenberg wrote: > > > > On Apr 1, 2021, at 3:59 AM, Vladislav Zavialov (int-index) < > vlad.z.4096 at gmail.com> wrote: > > Exporting from Prelude is not a panacea: without a compatibility fallback, > users of custom preludes will be affected. The proposed migration story > means that for 8 releases, no existing code will break at all. > > > Right. I wasn't suggesting a change to the migration plan -- just that (~) > would additionally be exported from the Prelude. The warning would trigger > only when (~) isn't in scope, meaning that many users won't need to react > to this change (given that -XTypeOperators is now on by default). > > As for the specialness of ~: yes, it's special, but we export other > special things from the Prelude, like $ (which automatically enables > -XImpredicativeTypes). > > On Apr 1, 2021, at 9:59 AM, Alejandro Serrano Mena > wrote: > > I meant the usual convention that type constructors must start with a > capital letter or the : symbol. But in this case I had forgotten that with > TypeOperators on, those conventions behave differently for types than for > terms. > > > This used to be true, but the requirement that the first letter be a > capital letter or : was dropped some time ago -- before I started using > Haskell, in any case. It is independent of -XTypeOperators, which is > necessary for any infix type level syntax. > > > > But those custom preludes would have to be updated anyway, right? > > > Yes, they would. > > 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 simonpj at microsoft.com Thu Apr 22 09:39:36 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 22 Apr 2021 09:39:36 +0000 Subject: [ghc-steering-committee] #371: Stop treating ~ magically. Rec: weak accept In-Reply-To: <010f0178f757c6b8-f8c61c40-cf70-439a-9357-2ff90e9fa0e9-000000@us-east-2.amazonses.com> References: <010f017885c281e2-ddc4c62f-b5e8-4829-bdf2-aab06bbd99f3-000000@us-east-2.amazonses.com> <4F0B1081-DFAF-42CE-A3CF-F00BEFBF44B9@gmail.com> <010f01788eb9bfda-8728f034-a0f5-43f2-ac79-69c4e836a571-000000@us-east-2.amazonses.com> <010f0178f757c6b8-f8c61c40-cf70-439a-9357-2ff90e9fa0e9-000000@us-east-2.amazonses.com> Message-ID: I don't feel strongly about this one. Happy to accept Richard's recommendation. Simon From: ghc-steering-committee On Behalf Of Richard Eisenberg Sent: 22 April 2021 03:10 To: Vladislav Zavialov (int-index) Cc: Simon Peyton Jones via ghc-steering-committee Subject: Re: [ghc-steering-committee] #371: Stop treating ~ magically. Rec: weak accept Hi committee, This proposal has been updated to include exporting (~) from the Prelude. This means that migration is much easier than it was previously, likely not requiring any import changes (or just in a project's custom Prelude). Users will have to enable -XTypeOperators (and could choose to disable -XGADTs or -XTypeFamilies). With this new export, I'm more firmly in favor of cleaning up this one little corner: let's accept. I will wait one week for any comments, and then will accept this proposal. Thanks, Richard On Apr 1, 2021, at 2:37 PM, Richard Eisenberg > wrote: On Apr 1, 2021, at 3:59 AM, Vladislav Zavialov (int-index) > wrote: Exporting from Prelude is not a panacea: without a compatibility fallback, users of custom preludes will be affected. The proposed migration story means that for 8 releases, no existing code will break at all. Right. I wasn't suggesting a change to the migration plan -- just that (~) would additionally be exported from the Prelude. The warning would trigger only when (~) isn't in scope, meaning that many users won't need to react to this change (given that -XTypeOperators is now on by default). As for the specialness of ~: yes, it's special, but we export other special things from the Prelude, like $ (which automatically enables -XImpredicativeTypes). On Apr 1, 2021, at 9:59 AM, Alejandro Serrano Mena > wrote: I meant the usual convention that type constructors must start with a capital letter or the : symbol. But in this case I had forgotten that with TypeOperators on, those conventions behave differently for types than for terms. This used to be true, but the requirement that the first letter be a capital letter or : was dropped some time ago -- before I started using Haskell, in any case. It is independent of -XTypeOperators, which is necessary for any infix type level syntax. But those custom preludes would have to be updated anyway, right? Yes, they would. 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 Thu Apr 22 10:08:26 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 22 Apr 2021 12:08:26 +0200 Subject: [ghc-steering-committee] #371: Stop treating ~ magically. Rec: weak accept In-Reply-To: <010f0178f757c6b8-f8c61c40-cf70-439a-9357-2ff90e9fa0e9-000000@us-east-2.amazonses.com> References: <010f017885c281e2-ddc4c62f-b5e8-4829-bdf2-aab06bbd99f3-000000@us-east-2.amazonses.com> <4F0B1081-DFAF-42CE-A3CF-F00BEFBF44B9@gmail.com> <010f01788eb9bfda-8728f034-a0f5-43f2-ac79-69c4e836a571-000000@us-east-2.amazonses.com> <010f0178f757c6b8-f8c61c40-cf70-439a-9357-2ff90e9fa0e9-000000@us-east-2.amazonses.com> Message-ID: <512bac3d2500473cfd3981f2bf72898b4a6fbf53.camel@joachim-breitner.de> Hi, Am Donnerstag, den 22.04.2021, 02:10 +0000 schrieb Richard Eisenberg: > This proposal has been updated to include exporting (~) from the > Prelude. This means that migration is much easier than it was > previously, likely not requiring any import changes (or just in a > project's custom Prelude). Users will have to enable -XTypeOperators > (and could choose to disable -XGADTs or -XTypeFamilies). With this > new export, I'm more firmly in favor of cleaning up this one little > corner: let's accept. > > I will wait one week for any comments, and then will accept this > proposal. with the less invasive migration, in favor. Just along the fact that haddock and LSP stuff will treat it like any other type operator is enough justification for this clean up for me. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From trupill at gmail.com Thu Apr 22 15:23:43 2021 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Thu, 22 Apr 2021 08:23:43 -0700 Subject: [ghc-steering-committee] Recommendation for #378: support the design for dependent types In-Reply-To: References: <03cab8e139267607b9406325ca8b07d7fcdc8b62.camel@joachim-breitner.de> <010f0178eadf967c-c0c47b2f-2ff9-4033-9b1d-06afc0edc145-000000@us-east-2.amazonses.com> Message-ID: Hi, Thanks Richard and Vitaly for your answers. I am happy with the opt-in principle as a guideline, and I pretty much appreciate having this written down. Hopefully the Core Libraries Committee also follows this path, and ensures that the base libraries in the ecosystem can still be used without opting into DH. In summary: I am in favor of this proposal. Regards, Alejandro On 19 Apr 2021 at 18:29:06, Vitaly Bragilevsky wrote: > Dear Committee, > > I support this proposal. I think, that the hardest problem when teaching > Haskell is not to get through the basics. Many of us who have teaching > experience all know how to get that done. The real problems come with > type-level magic and workarounds involving singletons. I often find that > it's much easier to explain and solve the very same problems in Idris than > in Haskell. If we want to use the corresponding features in Haskell (and > many of Haskellers really want that), we must make them clearer. I believe > that DH (as sketched in this proposal) is the right way to do that. > > Every now and then I hear the question if we are going to get dependent > types in Haskell. I'm sure, Richard answers this question on a daily basis. > I consider accepting this proposal as a clear statement to those who wait > for dependent types in Haskell. So, let's do that! > > Vitaly > > пн, 19 апр. 2021 г. в 19:04, Richard Eisenberg : > >> >> >> On Apr 19, 2021, at 3:03 AM, Alejandro Serrano Mena >> wrote: >> >> On the one hand, I fear that by introducing more and more DH features, >> the language will morph into something difficult to reconcile with “basic >> Haskell”. After all, if we have dependent features available, why not use >> it in the Prelude and other libraries? This would make Haskell harder to >> use in (1) teaching, since newcomers would need more time to understand >> those features, and (2) research, since to build a tool on top of Haskell >> (think of LiquidHaskell) you’ll need to buy the whole “dependent + linear >> paradigm” too. >> >> >> Both of these are great points to raise. For (1): we will have to >> continue to use good taste in designing the Prelude/`base` and other >> libraries. Lots of fancy features have existed in Haskell for decades, but >> we have been careful in how these are exposed to users. One small blunder >> happened a few years ago when `:t ($)` became very unwieldy (showing $'s >> levity polymorphism), and that got fixed before release. Another blunder >> (in my opinion) is that the type of length now requires understanding >> Foldable -- but the code around Foldable & Traversable is all Haskell98 >> anyway. It remains vitally important that error messages and GHCi >> interactions remain understandable to beginners. I personally would >> consider it a failure of this project if that were not to be the case. I >> have added some thoughts around this to the proposal at >> https://github.com/goldfirere/ghc-proposals/blob/dependent-types/proposals/0000-dependent-type-design.rst#learnability-of-haskell >> >> For (2): This is harder. I suppose a researcher could consider Haskell >> without -XLinearTypes -XDependentTypes, but any GHC-based implementation >> would be out of reach, then. Regardless, many Haskell-based research papers >> already choose a slice of GHC/Haskell to study, and I expect that to >> continue to be the case. However, I acknowledge that research accessibility >> may decrease with this change. >> >> 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 vlad.z.4096 at gmail.com Fri Apr 23 18:47:36 2021 From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index)) Date: Fri, 23 Apr 2021 21:47:36 +0300 Subject: [ghc-steering-committee] Recommendation for #378: support the design for dependent types In-Reply-To: References: Message-ID: <89DFE6D1-CA8C-460E-A1B9-809BCC99EC21@gmail.com> Good, this addresses the concern I voiced earlier about the design being separated from the proposal. I’m in support now. - Vlad > On 15 Apr 2021, at 12:38, Simon Peyton Jones via ghc-steering-committee wrote: > > Dear GHC steering committee > > OK Richard has now revised the “Design for Dependent Types” proposal, and has resubmitted it. As we asked, it now includes the design sketch that constitutes the direction of travel advocated in the proposal, rather than merelyreferring to it. > > Simon > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From vlad.z.4096 at gmail.com Fri Apr 23 18:54:10 2021 From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index)) Date: Fri, 23 Apr 2021 21:54:10 +0300 Subject: [ghc-steering-committee] #371: Stop treating ~ magically. Rec: weak accept In-Reply-To: References: <010f017885c281e2-ddc4c62f-b5e8-4829-bdf2-aab06bbd99f3-000000@us-east-2.amazonses.com> <4F0B1081-DFAF-42CE-A3CF-F00BEFBF44B9@gmail.com> <010f01788eb9bfda-8728f034-a0f5-43f2-ac79-69c4e836a571-000000@us-east-2.amazonses.com> <010f0178f757c6b8-f8c61c40-cf70-439a-9357-2ff90e9fa0e9-000000@us-east-2.amazonses.com> Message-ID: <0A7BA6AB-BDF3-41E3-8195-4CA89CB160DC@gmail.com> While the use of (~) itself no longer requires -XGADTs, the usual desugaring of GADTs still does. So this will require the extension: data G a where MkG :: G Int even though this will not: data T a where MkT :: (a~Int) => T a Perhaps that is what you meant by ‘vacuous’, but I wouldn’t go as far as to say that -XGADTs becomes implied by -XGADTSyntax and -XExistentialTypes. - Vlad > On 22 Apr 2021, at 12:25, Spiwack, Arnaud wrote: > > I'm still not sure what problem this proposal solves. The proposal alludes to some code simplification but doesn't give me a good idea of how much simpler this would make the code. > > Also note that -XGADT becomes mostly vacuous with this proposal: -XGADTSyntax + -XExistentialTypes imply GADTs (both are in -XGHC2021). Not that I mind, really, I actually probably prefer it this way. But it's worthy of notice. > > _______________________________________________ > 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 richarde.dev Fri Apr 23 20:17:03 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Fri, 23 Apr 2021 20:17:03 +0000 Subject: [ghc-steering-committee] #371: Stop treating ~ magically. Rec: weak accept In-Reply-To: <0A7BA6AB-BDF3-41E3-8195-4CA89CB160DC@gmail.com> References: <010f017885c281e2-ddc4c62f-b5e8-4829-bdf2-aab06bbd99f3-000000@us-east-2.amazonses.com> <4F0B1081-DFAF-42CE-A3CF-F00BEFBF44B9@gmail.com> <010f01788eb9bfda-8728f034-a0f5-43f2-ac79-69c4e836a571-000000@us-east-2.amazonses.com> <010f0178f757c6b8-f8c61c40-cf70-439a-9357-2ff90e9fa0e9-000000@us-east-2.amazonses.com> <0A7BA6AB-BDF3-41E3-8195-4CA89CB160DC@gmail.com> Message-ID: <010f01790060f099-e40f648d-47b3-4053-a1a5-9200e2d338f3-000000@us-east-2.amazonses.com> To my deep surprise, the following program is accepted: > {-# LANGUAGE GADTSyntax, ExistentialQuantification #-} > > module Bug where > > data G a where > MkG :: a -> G Int but the following additional definition is rejected: > foo :: G a -> a > foo (MkG _) = 5 Adding -XTypeFamilies fixes that last piece, though. Looking through the source code, GADTs implies GADTSyntax and MonoLocalBinds, either GADTs or ExistentialQuantification allows the declaration of existential variables or a refined return type, either GADTs or TypeFamilies allows the use of the `~` syntax, and either GADTs or TypeFamilies allows pattern-matching on a constructor with an equality in its context. So, GADTSyntax, ExistentialQuantification, and TypeFamilies together imply all the functionality of GADTs. This is all very strange, though, and should probably be tidied up. Not in this proposal though. Richard > On Apr 23, 2021, at 2:54 PM, Vladislav Zavialov (int-index) wrote: > > While the use of (~) itself no longer requires -XGADTs, the usual desugaring of GADTs still does. So this will require the extension: > > data G a where > MkG :: G Int > > even though this will not: > > data T a where > MkT :: (a~Int) => T a > > Perhaps that is what you meant by ‘vacuous’, but I wouldn’t go as far as to say that -XGADTs becomes implied by -XGADTSyntax and -XExistentialTypes. > > - Vlad > >> On 22 Apr 2021, at 12:25, Spiwack, Arnaud wrote: >> >> I'm still not sure what problem this proposal solves. The proposal alludes to some code simplification but doesn't give me a good idea of how much simpler this would make the code. >> >> Also note that -XGADT becomes mostly vacuous with this proposal: -XGADTSyntax + -XExistentialTypes imply GADTs (both are in -XGHC2021). Not that I mind, really, I actually probably prefer it this way. But it's worthy of notice. >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > From tomjharding at live.co.uk Tue Apr 27 09:21:26 2021 From: tomjharding at live.co.uk (Tom Harding) Date: Tue, 27 Apr 2021 09:21:26 +0000 Subject: [ghc-steering-committee] Please review #415: OPAQUE pragma, Shepherd: Tom In-Reply-To: References: <5ff728d27bd506f90ce1201ea62764dfb458764f.camel@joachim-breitner.de> Message-ID: <7A0D6A9B-6F3C-4642-8F26-0675D7283445@live.co.uk> Hi all, I’ve read the proposal: the change is well-motivated, and seems to solve a problem that doesn’t have another pre-existing ergonomic or reliable solution. Given this, I recommend that we accept. Alejandro and Simon have already given their support; does anyone else have any strong opinions either way? Thanks, Tom On 21 Apr 2021, at 20:54, Alejandro Serrano Mena > wrote: That seems reasonable and with a direct application, so I’m in favor of acceptance. Alejandro On 21 Apr 2021 at 11:07:14, Simon Peyton Jones via ghc-steering-committee > wrote: Tom, I'm in support of this. It's simple, useful, driven by a real application need, and easy to implement. (There a small patch that does it already.) Simon | -----Original Message----- | From: ghc-steering-committee > On Behalf Of Joachim Breitner | Sent: 21 April 2021 07:40 | To: ghc-steering-committee > | Subject: [ghc-steering-committee] Please review #415: OPAQUE pragma, | Shepherd: Tom | | Dear Committe, | | OPAQUE pragma | has been proposed by Christiaan Baaij | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2Fghc-proposals%2Fghc- | proposals%2Fpull%2F415&data=04%7C01%7Csimonpj%40microsoft.com%7C06 | 54777eb2f74eeff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1% | 7C0%7C637545841499459221%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL | CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wm44ph5 | Int4gqu6JKkedaAKqE0DJOcqjqK3%2BT%2BHEXcA%3D&reserved=0 | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2Fchristiaanb%2Fghc- | proposals%2Fblob%2Fmaster%2Fproposals%2F0000-opaque- | pragma.md&data=04%7C01%7Csimonpj%40microsoft.com%7C0654777eb2f74ee | ff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375458 | 41499459221%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MD9R%2FGRTR8j8blj%2F | o2cCc6JFpbgPiGakqGkZoSoQkeg%3D&reserved=0 | | | I'll propose Tom as the shepherd. | | Please guide us to a conclusion as outlined in | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2Fghc-proposals%2Fghc-proposals%23committee- | process&data=04%7C01%7Csimonpj%40microsoft.com%7C0654777eb2f74eeff | 5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637545841 | 499459221%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi | LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VEiKysJyP4hRJ3J%2FIAQ0 | k2t9qm7qhreZF%2FMfA31Ct1k%3D&reserved=0 | | Thanks, | Joachim | -- | -- | Joachim Breitner | mail at joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0654777eb2 | f74eeff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 | 7545841499469214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zURoYM0rQvnF%2F | j0EngntoTDt2cG7aSPEResXA4i6m%2FE%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0654777eb2f74ee | ff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375458 | 41499469214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TEQsWPaCoHIvcGy%2FH1 | te1tmgRGe%2BHeYwhU1FcoZ4TVM%3D&reserved=0 _______________________________________________ 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 Wed Apr 28 15:08:32 2021 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 28 Apr 2021 17:08:32 +0200 Subject: [ghc-steering-committee] Please review #415: OPAQUE pragma, Shepherd: Tom In-Reply-To: <7A0D6A9B-6F3C-4642-8F26-0675D7283445@live.co.uk> References: <5ff728d27bd506f90ce1201ea62764dfb458764f.camel@joachim-breitner.de> <7A0D6A9B-6F3C-4642-8F26-0675D7283445@live.co.uk> Message-ID: It occurs to me that this OPAQUE keyword may be useful for vanilla GHC as well. GHC could provide trivial implementation of some primitive functions that it defines (such as the recently discussed `withDict` function) and use the OPAQUE keyword to make sure that it can always substitute this function by its low-level implementation possibly even at the STG level if the primitive doesn't admit a Core implementation. I don't really have a strong opinion either way, but it sounds reasonable. On Tue, Apr 27, 2021 at 11:22 AM Tom Harding wrote: > Hi all, > > I’ve read the proposal: the change is well-motivated, and seems to solve a > problem that doesn’t have another pre-existing ergonomic or reliable > solution. > Given this, I recommend that we accept. Alejandro and Simon have already > given their support; does anyone else have any strong opinions either way? > > Thanks, > Tom > > On 21 Apr 2021, at 20:54, Alejandro Serrano Mena > wrote: > > That seems reasonable and with a direct application, so I’m in favor of > acceptance. > > Alejandro > > On 21 Apr 2021 at 11:07:14, Simon Peyton Jones via ghc-steering-committee < > ghc-steering-committee at haskell.org> wrote: > >> Tom, I'm in support of this. It's simple, useful, driven by a real >> application need, and easy to implement. (There a small patch that does it >> already.) >> >> Simon >> >> | -----Original Message----- >> | From: ghc-steering-committee > | bounces at haskell.org> On Behalf Of Joachim Breitner >> | Sent: 21 April 2021 07:40 >> | To: ghc-steering-committee >> | Subject: [ghc-steering-committee] Please review #415: OPAQUE pragma, >> | Shepherd: Tom >> | >> | Dear Committe, >> | >> | OPAQUE pragma >> | has been proposed by Christiaan Baaij >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith >> | ub.com%2Fghc-proposals%2Fghc- >> | proposals%2Fpull%2F415&data=04%7C01%7Csimonpj%40microsoft.com%7C06 >> | 54777eb2f74eeff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1% >> | 7C0%7C637545841499459221%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL >> | CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wm44ph5 >> | Int4gqu6JKkedaAKqE0DJOcqjqK3%2BT%2BHEXcA%3D&reserved=0 >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith >> | ub.com%2Fchristiaanb%2Fghc- >> | proposals%2Fblob%2Fmaster%2Fproposals%2F0000-opaque- >> | pragma.md&data=04%7C01%7Csimonpj%40microsoft.com%7C0654777eb2f74ee >> | ff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375458 >> | 41499459221%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz >> | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MD9R%2FGRTR8j8blj%2F >> | o2cCc6JFpbgPiGakqGkZoSoQkeg%3D&reserved=0 >> | >> | >> | I'll propose Tom as the shepherd. >> | >> | Please guide us to a conclusion as outlined in >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith >> | ub.com%2Fghc-proposals%2Fghc-proposals%23committee- >> | process&data=04%7C01%7Csimonpj%40microsoft.com%7C0654777eb2f74eeff >> | 5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637545841 >> | 499459221%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi >> | LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VEiKysJyP4hRJ3J%2FIAQ0 >> | k2t9qm7qhreZF%2FMfA31Ct1k%3D&reserved=0 >> | >> | Thanks, >> | Joachim >> | -- >> | -- >> | Joachim Breitner >> | mail at joachim-breitner.de >> | >> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j >> | oachim- >> | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0654777eb2 >> | f74eeff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 >> | 7545841499469214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV >> | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zURoYM0rQvnF%2F >> | j0EngntoTDt2cG7aSPEResXA4i6m%2FE%3D&reserved=0 >> | >> | >> | _______________________________________________ >> | ghc-steering-committee mailing list >> | ghc-steering-committee at haskell.org >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail >> | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- >> | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0654777eb2f74ee >> | ff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375458 >> | 41499469214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz >> | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TEQsWPaCoHIvcGy%2FH1 >> | te1tmgRGe%2BHeYwhU1FcoZ4TVM%3D&reserved=0 >> _______________________________________________ >> 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 rae at richarde.dev Wed Apr 28 18:12:34 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 28 Apr 2021 18:12:34 +0000 Subject: [ghc-steering-committee] Please review #415: OPAQUE pragma, Shepherd: Tom In-Reply-To: References: <5ff728d27bd506f90ce1201ea62764dfb458764f.camel@joachim-breitner.de> <7A0D6A9B-6F3C-4642-8F26-0675D7283445@live.co.uk> Message-ID: <010f017919aec35b-ee84f52b-5d71-431c-9492-9015dd903c67-000000@us-east-2.amazonses.com> I don't personally understand the details behind the motivation, but I trust the people who have supported and will throw my lot in with them. +1 from me. > On Apr 28, 2021, at 11:08 AM, Spiwack, Arnaud wrote: > > It occurs to me that this OPAQUE keyword may be useful for vanilla GHC as well. GHC could provide trivial implementation of some primitive functions that it defines (such as the recently discussed `withDict` function) and use the OPAQUE keyword to make sure that it can always substitute this function by its low-level implementation possibly even at the STG level if the primitive doesn't admit a Core implementation. > > I don't really have a strong opinion either way, but it sounds reasonable. > > On Tue, Apr 27, 2021 at 11:22 AM Tom Harding > wrote: > Hi all, > > I’ve read the proposal: the change is well-motivated, and seems to solve a problem that doesn’t have another pre-existing ergonomic or reliable solution. > Given this, I recommend that we accept. Alejandro and Simon have already given their support; does anyone else have any strong opinions either way? > > Thanks, > Tom > >> On 21 Apr 2021, at 20:54, Alejandro Serrano Mena > wrote: >> >> That seems reasonable and with a direct application, so I’m in favor of acceptance. >> >> Alejandro >> >> On 21 Apr 2021 at 11:07:14, Simon Peyton Jones via ghc-steering-committee > wrote: >> Tom, I'm in support of this. It's simple, useful, driven by a real application need, and easy to implement. (There a small patch that does it already.) >> >> Simon >> >> | -----Original Message----- >> | From: ghc-steering-committee > | bounces at haskell.org > On Behalf Of Joachim Breitner >> | Sent: 21 April 2021 07:40 >> | To: ghc-steering-committee > >> | Subject: [ghc-steering-committee] Please review #415: OPAQUE pragma, >> | Shepherd: Tom >> | >> | Dear Committe, >> | >> | OPAQUE pragma >> | has been proposed by Christiaan Baaij >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith >> | ub.com %2Fghc-proposals%2Fghc- >> | proposals%2Fpull%2F415&data=04%7C01%7Csimonpj%40microsoft.com %7C06 >> | 54777eb2f74eeff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1% >> | 7C0%7C637545841499459221%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL >> | CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wm44ph5 >> | Int4gqu6JKkedaAKqE0DJOcqjqK3%2BT%2BHEXcA%3D&reserved=0 >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith >> | ub.com %2Fchristiaanb%2Fghc- >> | proposals%2Fblob%2Fmaster%2Fproposals%2F0000-opaque- >> | pragma.md&data=04%7C01%7Csimonpj%40microsoft.com %7C0654777eb2f74ee >> | ff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375458 >> | 41499459221%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz >> | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MD9R%2FGRTR8j8blj%2F >> | o2cCc6JFpbgPiGakqGkZoSoQkeg%3D&reserved=0 >> | >> | >> | I'll propose Tom as the shepherd. >> | >> | Please guide us to a conclusion as outlined in >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith >> | ub.com %2Fghc-proposals%2Fghc-proposals%23committee- >> | process&data=04%7C01%7Csimonpj%40microsoft.com %7C0654777eb2f74eeff >> | 5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637545841 >> | 499459221%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi >> | LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VEiKysJyP4hRJ3J%2FIAQ0 >> | k2t9qm7qhreZF%2FMfA31Ct1k%3D&reserved=0 >> | >> | Thanks, >> | Joachim >> | -- >> | -- >> | Joachim Breitner >> | mail at joachim-breitner.de >> | >> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j >> | oachim- >> | breitner.de %2F&data=04%7C01%7Csimonpj%40microsoft.com %7C0654777eb2 >> | f74eeff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 >> | 7545841499469214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV >> | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zURoYM0rQvnF%2F >> | j0EngntoTDt2cG7aSPEResXA4i6m%2FE%3D&reserved=0 >> | >> | >> | _______________________________________________ >> | ghc-steering-committee mailing list >> | ghc-steering-committee at haskell.org >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail >> | .haskell.org %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- >> | committee&data=04%7C01%7Csimonpj%40microsoft.com %7C0654777eb2f74ee >> | ff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375458 >> | 41499469214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz >> | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TEQsWPaCoHIvcGy%2FH1 >> | te1tmgRGe%2BHeYwhU1FcoZ4TVM%3D&reserved=0 >> _______________________________________________ >> 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 > _______________________________________________ > 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 Fri Apr 30 07:22:05 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 30 Apr 2021 09:22:05 +0200 Subject: [ghc-steering-committee] Please review #412: splice imports, Shepherd: Vladislav Message-ID: <8f9bf832e5aa04f448ee0e19d75ee9f60c7b0360.camel@joachim-breitner.de> Dear Committe, Explicit Splice Imports has been proposed by Matthew Pickering https://github.com/ghc-proposals/ghc-proposals/pull/412 https://github.com/mpickering/ghc-proposals/blob/splice-imports/proposals/0000-splice-imports.rst I’ll propose Vladislav as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/