From lists at richarde.dev Mon May 1 01:56:10 2023 From: lists at richarde.dev (Richard Eisenberg) Date: Mon, 1 May 2023 01:56:10 +0000 Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?= =?utf-8?b?4oCTIFJvdW5kIDI=?= In-Reply-To: References: Message-ID: <010f0187d50642b9-e0fe510e-9093-41a0-b4ca-27c3ab769b67-000000@us-east-2.amazonses.com> Thanks, Arnaud, for organizing this for us! > On Apr 19, 2023, at 8:20 AM, Arnaud Spiwack wrote: > > X.1: do you believe that this a use-case that GHC should support? (yes/no) I'm going to interpret "GHC" as "the Haskell toolchain". That is, I'll answer whether some official tool should support the use-case, but my answer to X.2.N may say that some other part of the ecosystem is better suited than GHC. > X.2: regardless of your answer in X.1, if GHC supports this use-case, > do you believe that this use-case is best served by extensions. (yes/no) > X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no) > X.2.N: if you've answered “no” to X.2: what mechanism would you rather > see supporting this use-case (free form) > > 1. Gain early access to experimental or unstable features > (e.g. because they're working on a research prototype, or because > the feature is valuable enough to them to forgo some stability) 1.1. Yes. 1.2. Yes 1.2.Y. Not really. Experimental extensions need to be fine-grained. > 2. Restrict the use of more complex features (e.g. for easier > onboarding of new developers or as educators to teach a > well-delimited subset of the language) 2.1. Yes (but not in GHC itself) 2.2. No 2.2.N. This is better suited for non-GHC tools, such as a linter or an IDE. The fine-grained approach to extensions is not so helpful here. > 3. Restrict the use of novel features since the last established > standard/report. 3.1. No -- it's just too expensive to keep doing this 3.2. No 3.2.N. GHC could have a Haskell2010 mode that meets the standard, and then a normal mode that doesn't. There is no need for a slew of extensions. > 4. Restrict the use to features that they don't like (e.g. controversial > features like RecordWildcard or ImplicitParameters) 4.1. Yes (but not in GHC itself) 4.2. No 4.2.N. See 2.2.N. I don't see the difference between 2 and 4. > 5. Name/refer to a particular feature when talking/writing/searching > about it. 5.1. Yes 5.2. No 5.2.N. Careful documentation in the manual and consistent text in error messages. > 6. Restrict the use of features which require support from outside > the Haskell ecosystem that can't be taken for granted (I think this > concerns only UnicodeSyntax) 6.1. Yes 6.2. No 6.2.N. This sounds like a ./configure -time flag, if GHC is being built on a platform lacking some critical support. (Programmers may want to avoid using a non-universal feature, but that sounds more like 2 or 4 than this question.) > 7. As library authors, to signal which features the library actually > uses, hence which version of GHC the library is compatible with. 7.1. Yes (but not in GHC itself) 7.2. No 7.2.N. This sounds like something a package installer should do. In some perfect world, a package could just name a set of features and then the tool finds a GHC that has those features, but GHC is just too complex in the real world -- people will just have to use version numbers. > 8. Retain access to deprecated features to smooth out migration over > the deprecation period. 8.1. Yes 8.2. Sometimes, yes 8.2.Y. No; this is essentially the dual to (1), and it wants a fine-grained approach 8.2.N. In some cases, this could be better achieved through warnings and other mechanisms. But sometimes a proper extension will be needed. > 9. Retain access to deprecated features indefinitely. 9.1. No. If we're going to deprecate a feature, let's have the courage of our convictions. 9.2. Sometimes, yes 9.2.Y/N. Just like 8.2.Y/N. > 10. Change the default behaviour of (part of) the language > (e.g. StrictData, I think some of the dependent Haskell work falls > in this category, but I can't pinpoint an example) 10.1. Yes, but very sparingly 10.2. No 10.2.N. These are not language *extensions*. These are language *alterations*. There should be a different mechanism. But, really, we should try very hard to avoid doing this, because it makes reading code much harder -- you can read and understand code only after looking at all of these settings. In practice, this might still end up fitting into the existing language-extensions framework, but I'd rather see a way of specifying these kinds of changes locally in a region of code, so that the choice is manifest in the source file. > 11. Extend the language in a way that is not backward compatible > (e.g. OverloadedList, probably some dependent Haskell things too) I can't see the difference between 11 and 10. > 12. Enable features whose mere presence has a performance impact > (e.g. Template Haskell, and that's probably it) 12.1. Yes 12.2. Sure. 12.2.Y. No, because you want fine-grained control. > 13. CPP (this one is very unique isn't it?) 13.1. Yes 13.2. No 13.2.N. This should be a compiler flag. It's not about the language really. Richard > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From lists at richarde.dev Mon May 1 02:05:41 2023 From: lists at richarde.dev (Richard Eisenberg) Date: Mon, 1 May 2023 02:05:41 +0000 Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?= =?utf-8?b?4oCTIFJvdW5kIDI=?= In-Reply-To: <645c23058bff47264e49fdecd16d3eedce2167bd.camel@joachim-breitner.de> References: <645c23058bff47264e49fdecd16d3eedce2167bd.camel@joachim-breitner.de> Message-ID: <010f0187d50efae1-7ff2c457-95dc-4f22-9e75-400eb068952d-000000@us-east-2.amazonses.com> > On Apr 28, 2023, at 7:20 AM, Joachim Breitner wrote: > > I believe [the idea about using warnings] was Richard’s. I indeed have been the one to advocate for this previously, and I still do. I think the current system of extensions presents a bewildering array of complexity to users, and (I claim) a big source of why people say Haskell is so complicated. Haskell, at its core, is beautifully simple! But this fact easily gets lost. So my goal in advocating using warnings is to try to reduce the number of language extensions. We would then have one big language, but users have ways of subsetting if they like. In some sense, this is just about marketing (it doesn't change expressiveness) but marketing is important. It would be easy to interpret existing -X flags as warning twiddles, so the idea is backward compatible. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Mon May 1 12:59:00 2023 From: adam at well-typed.com (Adam Gundry) Date: Mon, 1 May 2023 13:59:00 +0100 Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?= =?utf-8?b?4oCTIFJvdW5kIDI=?= In-Reply-To: <010f0187d50efae1-7ff2c457-95dc-4f22-9e75-400eb068952d-000000@us-east-2.amazonses.com> References: <645c23058bff47264e49fdecd16d3eedce2167bd.camel@joachim-breitner.de> <010f0187d50efae1-7ff2c457-95dc-4f22-9e75-400eb068952d-000000@us-east-2.amazonses.com> Message-ID: <0b6911af-db25-b510-1074-6bd1765e82c8@well-typed.com> Thanks, I think I'm beginning to understand the position more clearly now. I can see the argument that we should be more opinionated about presenting features as one of * recommended (part of the language, fairly stable); * experimental (not yet resolved one way or the other); or * discouraged (supported primarily for backwards compatibility). To some extent GHC2021 already acts as a recommendation, but there are still many extensions that it doesn't include, and it doesn't draw a line between "experimental" and "discouraged". So perhaps one path forward would be to try to expand the set of extensions in the next GHC20xx and at the same time try to be more explicit about "discouraged" extensions that are unlikely to make it into a future GHC20xx iteration? I'm worried, however, that there are in practice many "dialects" of Haskell and hence it may be difficult to establish consensus about how to categorise many extensions. GHC2021 is described in the user's guide as "stable and conservative". Should we instead aim for "stable and liberal", i.e. adding extensions when they are unlikely to change and are useful to some people, even if others dislike them? (For example, RecordWildCards might fit into this category.) That would move us towards "one big language", but I'm not yet wholly convinced that is desirable. After all it would make the "recommended" language bigger and more complicated, and potentially constrain future evolution in ways that are hard to predict now. I think all this is mostly separable from the mechanics of warnings vs LANGUAGE pragmas vs other compiler flags. The idea that we might replace `-XNoFoo` with `-Werror=foo` is (for me at least) a distraction from the main point. (Thus, concretely, I still argue we should accept #536.) Cheers, Adam On 01/05/2023 03:05, Richard Eisenberg wrote: > > >> On Apr 28, 2023, at 7:20 AM, Joachim Breitner >> > wrote: >> >> I believe [the idea about using warnings] was Richard’s. > > I indeed have been the one to advocate for this previously, and I still do. > > I think the current system of extensions presents a bewildering array of > complexity to users, and (I claim) a big source of why people say > Haskell is so complicated. Haskell, at its core, is beautifully simple! > But this fact easily gets lost. > > So my goal in advocating using warnings is to try to reduce the number > of language extensions. We would then have one big language, but users > have ways of subsetting if they like. In some sense, this is just about > marketing (it doesn't change expressiveness) but marketing is important. > It would be easy to interpret existing -X flags as warning twiddles, so > the idea is backward compatible. > > Richard -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England From adam at well-typed.com Mon May 1 13:17:22 2023 From: adam at well-typed.com (Adam Gundry) Date: Mon, 1 May 2023 14:17:22 +0100 Subject: [ghc-steering-committee] #536: Type-level literals as a separate language extension, rec: accept In-Reply-To: References: <010f0186c72d3aa5-5163b078-0956-46e8-9e41-c2d206f6273c-000000@us-east-2.amazonses.com> <882d3cac-00e6-7dfd-b32d-69968856b8ba@well-typed.com> <010f0186fbb4bf37-10d8c856-9c2e-47c0-9edf-e0af23097fbc-000000@us-east-2.amazonses.com> Message-ID: <2fc76f16-4ab6-210b-7396-9b06c10ec9e5@well-typed.com> Thanks for your comments Iavor, your input is appreciated. The ongoing discussion on language extensions made me think about proposal #536 again. With due respect to Richard, I still think we should accept it, for the following reasons: * We owe it to proposal authors to make decisions in a reasonably prompt fashion. The ongoing discussion is unlikely to be resolved extremely quickly, and the extension split in the proposal accords with the de facto approach to language extensions as feature flags. * Even if we accept the premise that we have too many extensions, accepting the proposal doesn't really make things worse (if we already have a hundred extensions too many, what harm one more?). * As Iavor says, there is no deep reason for type literals and DataKinds to be grouped as part of the same feature; it is merely a historical accident. If we later move to a model where features are enabled by default and controlled using warnings, it would be equally reasonable to have separate warnings for type literals and DataKinds. * The proposed change is simple, low effort to implement and maintain, and is clearly desired by some users. * The workaround with -Werror=unticked-promoted-constructors doesn't accurately characterise the language with type literals but not DataKinds. Feel free to object, of course. :-) Adam On 20/03/2023 17:59, Iavor Diatchki wrote: > Hello, > > I am not on the committee but as the original author of the type > literals extensions I thought I'd give my 2c.  I am strongly in favor of > separating type literals from DataKinds, they are not really together > for any deep reason. > > For me the separate extension would be useful because it makes it > possible to use type literals with the `TypeData` extension, which for > me, is a much nicer way to work with type level things than `DataKinds`. > > -Iavor > > > > On Mon, Mar 20, 2023 at 10:08 AM Chris Dornan > wrote: > > I am also in favour of extensions that focus on solving a single > problem well and giving users precise control over what extensions > they deploy. If we get this right then we should be able discover > which extensions people want and those that are free of unintended > consequences, and can put them on track to be included in a GHC and > then Haskell standard. > > This proposal isn't ambitious but it does otherwise appear to > qualify so I am in favour. > > Chris > > > > >> On 20 Mar 2023, at 08:43, Simon Peyton Jones >> > >> wrote: >> >> Personally I'm happy with having orthogonal extensions that enable >> just one thing.  That allows our users to do what they want, >> rather than telling them what they want. >> >> On this particular proposal I don't think it's a big deal either >> way, but I'd vote in favour.  It's not exactly true to say that it >> duplicates an existing feature.  I think Richard's point is that >> you can get a warning for using an unticked constructor (but >> nothing for using a ticked one).  That's different from getting an >> error if you use a constructor in a type, ticked or not. >> >> This particular proposal is easy to describe and easy to >> implement.  But I don't think we should burn a lot of cycles on >> it... it's a matter of taste, so we could just vote. >> >> Simon >> >> On Sun, 19 Mar 2023 at 21:09, Richard Eisenberg >> > wrote: >> >> This argument gave me pause. Thanks, Adam. I think, for me, it >> comes down to this: what do we think will be more useful to >> more of our users? A notion of a core language -- perhaps >> implemented by different compilers -- with extensions? Or a >> unified language GHC/Haskell which allows subsetting? I tend >> to think the latter, though I'm not sure. >> >> Regarding this particular proposal: I remain against the >> proposal, as it duplicates an existing feature. That's a >> simple reason to be against a proposal. >> >> Richard >> >> > On Mar 10, 2023, at 9:15 AM, Adam Gundry >> > wrote: >> > >> > This proposal is very helpful in exposing some of the >> divisions about the interpretation of extensions that exist >> within the committee! "Let a thousand flowers bloom" vs >> "more-extensions-make-me-wince", if you like. >> > >> > For what it's worth I tend to be in the former camp. I think >> we should strive for orthogonality and avoid bundling together >> distinct features merely because they have related effects. >> Instead we should construct our language via composition of >> simple components. And I think it's reasonable to say that >> TypeLevelLiterals and (the rest of) DataKinds are clearly >> distinct and can be understood in isolation. >> > >> > If the number of extensions is a problem, that points to the >> need to better structure our documentation and gather coherent >> subsets of extensions into manageable pieces (much as GHC2021 >> tries to do). Beyond that I'd like to understand the downsides >> better (e.g. what costs does it actually impose on HLS to have >> another extension?). >> > >> > A conversation with one of the authors of Helium this week >> made me think that in the GHC proposals process we have tended >> to neglect the possible presence of other Haskell >> implementations. It's not realistic to expect that anyone will >> reimplement the whole of GHC Haskell, but perhaps there is a >> fragment large enough to be useful for a fair number of >> Haskell programs but also small enough to be independently >> implemented (e.g. by Helium). It would strike me as plausible >> that such an implementation might want to support >> TypeData+TypeLevelLiterals but not DataKinds. >> > >> > Adam >> > >> > >> > On 09/03/2023 16:21, Richard Eisenberg wrote: >> >> Though I see the arguments in the other direction, I vote >> against this proposal. As Joachim argues, adding an extension >> puts a tax on the entire ecosystem by adding one more bit of >> context a reader has to have to understand code. In addition, >> HLS will have to be aware of this extension. And the benefits >> seem pretty marginal here. >> >> Can we instead simply provide a warning? The warning here >> would be something like the -Wpuns idea, in that it helps the >> author keep to a particular subset of the language. (We might >> want to collect such warnings somehow in our documentation.) >> >> Actually, it occurs to me we already have the warning: >> -Wunticked-promoted-constructors. We've put that warning in >> the -Weverything bin (not even -Wall) because in the past >> we've decided that we shouldn't recommend/require the ' when >> using a constructor in a type. But actually, setting >> -Werror=unticked-promoted-constructors would seem to be a >> perfect substitute for -XTypeLevelLiterals -XNoDataKinds. OK, >> not perfect: you could still use a constructor in a type with >> a ' mark. But I think that's great, actually, because perhaps >> an author wary of constructors in types still might need to >> use one, in one place, in a 2,000-line file. This ticks all >> the boxes (ha ha). >> >> Having discovered this replacement, I'm now pretty strongly >> against this proposal. I'll also post on GitHub. >> >> Richard >> >>> On Mar 9, 2023, at 4:26 AM, Arnaud Spiwack >> >> > >> wrote: >> >>> >> >>> I can see where the author is coming from. But as Joachim, >> I find myself unconvinced that it is worth yet one extra >> extension (but then again, I'm the >> more-extensions-make-me-wince member of this committee). >> >>> >> >>> On Wed, 8 Mar 2023 at 13:56, Joachim Breitner >> >> > >> wrote: >> >>> >> >>>    Hi, >> >>> >> >>>    Am Mittwoch, dem 08.03.2023 um 14:58 +0300 schrieb >> Vladislav Zavialov: >> >>>    > DataKinds is indeed a "bad" extension because it >> introduces >> >>>    ambiguity >> >>>    > to name resolution. >> >>>    > >> >>>    > There are two ways to avoid this issue: >> >>>    > 1. Keep namespaces separate and double down on using >> punned >> >>>    > constructor names. >> >>>    > 2. Merge terms and types, discouraging punned >> constructor names. >> >>>    > >> >>>    > Each approach could indeed lead to a "dialect" of sorts. >> >>>    > >> >>>    > * The (accepted and recently implemented) TypeData >> extension >> >>>    moves us >> >>>    > in the direction of option (1), and I imagine the >> proposed >> >>>    > TypeLevelLiterals would be often used in conjunction >> with TypeData. >> >>>    > This carves out a limited, conservative language >> subset for type- >> >>>    > level programming. >> >>>    > * At the same time, #270 "Support pun-free code" >> moves us in the >> >>>    > direction of option (2), and I expect it to be the >> better option >> >>>    when >> >>>    > it comes to fully fledged dependently-typed programming >> >>>    envisioned by >> >>>    > #378. >> >>>    > >> >>>    > If I had to choose, I'd go with option (2). I don't >> see myself using >> >>>    > TypeData, nor TypeLevelLiterals for that matter. But >> I am of a >> >>>    "let a >> >>>    > thousand flowers bloom" persuasion, hence my >> recommendation to >> >>>    > accept. >> >>> >> >>> >> >>>    Thanks for putting this into a clearer context. >> >>> >> >>>    Where does DataKind fit in? Is it a natural part of >> approach (2) >> >>>    (which >> >>>    is the general direction outlined by #378), or is yet >> another take on >> >>>    the issue? >> >>>    If DataKinds was not what we want according to #378, >> but the fragment >> >>>    carved out by TypeLevelLiterals was, then that would be >> a strong >> >>>    reason >> >>>    for me to acccept TypeLevelLiterals. >> >>>    But if DataKinds is the goal (or at least “the” goal), >> then I >> >>>    think I’d >> >>>    like to see stronger arguments for why it should be split. >> >>> >> >>> >> >>>    Cheers, >> >>>    Joachim -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England From simon.peytonjones at gmail.com Mon May 1 18:18:24 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 1 May 2023 19:18:24 +0100 Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?= =?utf-8?b?4oCTIFJvdW5kIDI=?= In-Reply-To: <0b6911af-db25-b510-1074-6bd1765e82c8@well-typed.com> References: <645c23058bff47264e49fdecd16d3eedce2167bd.camel@joachim-breitner.de> <010f0187d50efae1-7ff2c457-95dc-4f22-9e75-400eb068952d-000000@us-east-2.amazonses.com> <0b6911af-db25-b510-1074-6bd1765e82c8@well-typed.com> Message-ID: I'm in the "stable and liberal" camp. My general view is that we should offer extensions and let our users decide which ones they want to use. I can see the argument that we should be more opinionated about > presenting features as one of > * recommended (part of the language, fairly stable); > * experimental (not yet resolved one way or the other); or > * discouraged (supported primarily for backwards compatibility). > I'd be fine with that. - I see the GHC20xx series as a way of codifying "recommended". - I'd add a category for "language variation" or something: things like -XStrict and -XRebindableSyntax which *change* rather than *extend* the language. Simon On Mon, 1 May 2023 at 13:59, Adam Gundry wrote: > Thanks, I think I'm beginning to understand the position more clearly > now. I can see the argument that we should be more opinionated about > presenting features as one of > > * recommended (part of the language, fairly stable); > > * experimental (not yet resolved one way or the other); or > > * discouraged (supported primarily for backwards compatibility). > > To some extent GHC2021 already acts as a recommendation, but there are > still many extensions that it doesn't include, and it doesn't draw a > line between "experimental" and "discouraged". So perhaps one path > forward would be to try to expand the set of extensions in the next > GHC20xx and at the same time try to be more explicit about "discouraged" > extensions that are unlikely to make it into a future GHC20xx iteration? > > I'm worried, however, that there are in practice many "dialects" of > Haskell and hence it may be difficult to establish consensus about how > to categorise many extensions. > > GHC2021 is described in the user's guide as "stable and conservative". > Should we instead aim for "stable and liberal", i.e. adding extensions > when they are unlikely to change and are useful to some people, even if > others dislike them? (For example, RecordWildCards might fit into this > category.) That would move us towards "one big language", but I'm not > yet wholly convinced that is desirable. After all it would make the > "recommended" language bigger and more complicated, and potentially > constrain future evolution in ways that are hard to predict now. > > I think all this is mostly separable from the mechanics of warnings vs > LANGUAGE pragmas vs other compiler flags. The idea that we might replace > `-XNoFoo` with `-Werror=foo` is (for me at least) a distraction from the > main point. (Thus, concretely, I still argue we should accept #536.) > > Cheers, > > Adam > > > On 01/05/2023 03:05, Richard Eisenberg wrote: > > > > > >> On Apr 28, 2023, at 7:20 AM, Joachim Breitner > >> > wrote: > >> > >> I believe [the idea about using warnings] was Richard’s. > > > > I indeed have been the one to advocate for this previously, and I still > do. > > > > I think the current system of extensions presents a bewildering array of > > complexity to users, and (I claim) a big source of why people say > > Haskell is so complicated. Haskell, at its core, is beautifully simple! > > But this fact easily gets lost. > > > > So my goal in advocating using warnings is to try to reduce the number > > of language extensions. We would then have one big language, but users > > have ways of subsetting if they like. In some sense, this is just about > > marketing (it doesn't change expressiveness) but marketing is important. > > It would be easy to interpret existing -X flags as warning twiddles, so > > the idea is backward compatible. > > > > Richard > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Mon May 1 18:19:27 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 1 May 2023 19:19:27 +0100 Subject: [ghc-steering-committee] #536: Type-level literals as a separate language extension, rec: accept In-Reply-To: <2fc76f16-4ab6-210b-7396-9b06c10ec9e5@well-typed.com> References: <010f0186c72d3aa5-5163b078-0956-46e8-9e41-c2d206f6273c-000000@us-east-2.amazonses.com> <882d3cac-00e6-7dfd-b32d-69968856b8ba@well-typed.com> <010f0186fbb4bf37-10d8c856-9c2e-47c0-9edf-e0af23097fbc-000000@us-east-2.amazonses.com> <2fc76f16-4ab6-210b-7396-9b06c10ec9e5@well-typed.com> Message-ID: I am also in favour for the reasons Adam gives. Simon On Mon, 1 May 2023 at 14:17, Adam Gundry wrote: > Thanks for your comments Iavor, your input is appreciated. > > The ongoing discussion on language extensions made me think about > proposal #536 again. With due respect to Richard, I still think we > should accept it, for the following reasons: > > * We owe it to proposal authors to make decisions in a reasonably > prompt fashion. The ongoing discussion is unlikely to be resolved > extremely quickly, and the extension split in the proposal accords with > the de facto approach to language extensions as feature flags. > > * Even if we accept the premise that we have too many extensions, > accepting the proposal doesn't really make things worse (if we already > have a hundred extensions too many, what harm one more?). > > * As Iavor says, there is no deep reason for type literals and > DataKinds to be grouped as part of the same feature; it is merely a > historical accident. If we later move to a model where features are > enabled by default and controlled using warnings, it would be equally > reasonable to have separate warnings for type literals and DataKinds. > > * The proposed change is simple, low effort to implement and maintain, > and is clearly desired by some users. > > * The workaround with -Werror=unticked-promoted-constructors doesn't > accurately characterise the language with type literals but not DataKinds. > > Feel free to object, of course. :-) > > Adam > > > > On 20/03/2023 17:59, Iavor Diatchki wrote: > > Hello, > > > > I am not on the committee but as the original author of the type > > literals extensions I thought I'd give my 2c. I am strongly in favor of > > separating type literals from DataKinds, they are not really together > > for any deep reason. > > > > For me the separate extension would be useful because it makes it > > possible to use type literals with the `TypeData` extension, which for > > me, is a much nicer way to work with type level things than `DataKinds`. > > > > -Iavor > > > > > > > > On Mon, Mar 20, 2023 at 10:08 AM Chris Dornan > > wrote: > > > > I am also in favour of extensions that focus on solving a single > > problem well and giving users precise control over what extensions > > they deploy. If we get this right then we should be able discover > > which extensions people want and those that are free of unintended > > consequences, and can put them on track to be included in a GHC and > > then Haskell standard. > > > > This proposal isn't ambitious but it does otherwise appear to > > qualify so I am in favour. > > > > Chris > > > > > > > > > >> On 20 Mar 2023, at 08:43, Simon Peyton Jones > >> > > >> wrote: > >> > >> Personally I'm happy with having orthogonal extensions that enable > >> just one thing. That allows our users to do what they want, > >> rather than telling them what they want. > >> > >> On this particular proposal I don't think it's a big deal either > >> way, but I'd vote in favour. It's not exactly true to say that it > >> duplicates an existing feature. I think Richard's point is that > >> you can get a warning for using an unticked constructor (but > >> nothing for using a ticked one). That's different from getting an > >> error if you use a constructor in a type, ticked or not. > >> > >> This particular proposal is easy to describe and easy to > >> implement. But I don't think we should burn a lot of cycles on > >> it... it's a matter of taste, so we could just vote. > >> > >> Simon > >> > >> On Sun, 19 Mar 2023 at 21:09, Richard Eisenberg > >> > wrote: > >> > >> This argument gave me pause. Thanks, Adam. I think, for me, it > >> comes down to this: what do we think will be more useful to > >> more of our users? A notion of a core language -- perhaps > >> implemented by different compilers -- with extensions? Or a > >> unified language GHC/Haskell which allows subsetting? I tend > >> to think the latter, though I'm not sure. > >> > >> Regarding this particular proposal: I remain against the > >> proposal, as it duplicates an existing feature. That's a > >> simple reason to be against a proposal. > >> > >> Richard > >> > >> > On Mar 10, 2023, at 9:15 AM, Adam Gundry > >> > wrote: > >> > > >> > This proposal is very helpful in exposing some of the > >> divisions about the interpretation of extensions that exist > >> within the committee! "Let a thousand flowers bloom" vs > >> "more-extensions-make-me-wince", if you like. > >> > > >> > For what it's worth I tend to be in the former camp. I think > >> we should strive for orthogonality and avoid bundling together > >> distinct features merely because they have related effects. > >> Instead we should construct our language via composition of > >> simple components. And I think it's reasonable to say that > >> TypeLevelLiterals and (the rest of) DataKinds are clearly > >> distinct and can be understood in isolation. > >> > > >> > If the number of extensions is a problem, that points to the > >> need to better structure our documentation and gather coherent > >> subsets of extensions into manageable pieces (much as GHC2021 > >> tries to do). Beyond that I'd like to understand the downsides > >> better (e.g. what costs does it actually impose on HLS to have > >> another extension?). > >> > > >> > A conversation with one of the authors of Helium this week > >> made me think that in the GHC proposals process we have tended > >> to neglect the possible presence of other Haskell > >> implementations. It's not realistic to expect that anyone will > >> reimplement the whole of GHC Haskell, but perhaps there is a > >> fragment large enough to be useful for a fair number of > >> Haskell programs but also small enough to be independently > >> implemented (e.g. by Helium). It would strike me as plausible > >> that such an implementation might want to support > >> TypeData+TypeLevelLiterals but not DataKinds. > >> > > >> > Adam > >> > > >> > > >> > On 09/03/2023 16:21, Richard Eisenberg wrote: > >> >> Though I see the arguments in the other direction, I vote > >> against this proposal. As Joachim argues, adding an extension > >> puts a tax on the entire ecosystem by adding one more bit of > >> context a reader has to have to understand code. In addition, > >> HLS will have to be aware of this extension. And the benefits > >> seem pretty marginal here. > >> >> Can we instead simply provide a warning? The warning here > >> would be something like the -Wpuns idea, in that it helps the > >> author keep to a particular subset of the language. (We might > >> want to collect such warnings somehow in our documentation.) > >> >> Actually, it occurs to me we already have the warning: > >> -Wunticked-promoted-constructors. We've put that warning in > >> the -Weverything bin (not even -Wall) because in the past > >> we've decided that we shouldn't recommend/require the ' when > >> using a constructor in a type. But actually, setting > >> -Werror=unticked-promoted-constructors would seem to be a > >> perfect substitute for -XTypeLevelLiterals -XNoDataKinds. OK, > >> not perfect: you could still use a constructor in a type with > >> a ' mark. But I think that's great, actually, because perhaps > >> an author wary of constructors in types still might need to > >> use one, in one place, in a 2,000-line file. This ticks all > >> the boxes (ha ha). > >> >> Having discovered this replacement, I'm now pretty strongly > >> against this proposal. I'll also post on GitHub. > >> >> Richard > >> >>> On Mar 9, 2023, at 4:26 AM, Arnaud Spiwack > >> > >> >> >> wrote: > >> >>> > >> >>> I can see where the author is coming from. But as Joachim, > >> I find myself unconvinced that it is worth yet one extra > >> extension (but then again, I'm the > >> more-extensions-make-me-wince member of this committee). > >> >>> > >> >>> On Wed, 8 Mar 2023 at 13:56, Joachim Breitner > >> > >> >> >> wrote: > >> >>> > >> >>> Hi, > >> >>> > >> >>> Am Mittwoch, dem 08.03.2023 um 14:58 +0300 schrieb > >> Vladislav Zavialov: > >> >>> > DataKinds is indeed a "bad" extension because it > >> introduces > >> >>> ambiguity > >> >>> > to name resolution. > >> >>> > > >> >>> > There are two ways to avoid this issue: > >> >>> > 1. Keep namespaces separate and double down on using > >> punned > >> >>> > constructor names. > >> >>> > 2. Merge terms and types, discouraging punned > >> constructor names. > >> >>> > > >> >>> > Each approach could indeed lead to a "dialect" of > sorts. > >> >>> > > >> >>> > * The (accepted and recently implemented) TypeData > >> extension > >> >>> moves us > >> >>> > in the direction of option (1), and I imagine the > >> proposed > >> >>> > TypeLevelLiterals would be often used in conjunction > >> with TypeData. > >> >>> > This carves out a limited, conservative language > >> subset for type- > >> >>> > level programming. > >> >>> > * At the same time, #270 "Support pun-free code" > >> moves us in the > >> >>> > direction of option (2), and I expect it to be the > >> better option > >> >>> when > >> >>> > it comes to fully fledged dependently-typed programming > >> >>> envisioned by > >> >>> > #378. > >> >>> > > >> >>> > If I had to choose, I'd go with option (2). I don't > >> see myself using > >> >>> > TypeData, nor TypeLevelLiterals for that matter. But > >> I am of a > >> >>> "let a > >> >>> > thousand flowers bloom" persuasion, hence my > >> recommendation to > >> >>> > accept. > >> >>> > >> >>> > >> >>> Thanks for putting this into a clearer context. > >> >>> > >> >>> Where does DataKind fit in? Is it a natural part of > >> approach (2) > >> >>> (which > >> >>> is the general direction outlined by #378), or is yet > >> another take on > >> >>> the issue? > >> >>> If DataKinds was not what we want according to #378, > >> but the fragment > >> >>> carved out by TypeLevelLiterals was, then that would be > >> a strong > >> >>> reason > >> >>> for me to acccept TypeLevelLiterals. > >> >>> But if DataKinds is the goal (or at least “the” goal), > >> then I > >> >>> think I’d > >> >>> like to see stronger arguments for why it should be > split. > >> >>> > >> >>> > >> >>> Cheers, > >> >>> Joachim > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > > _______________________________________________ > 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 lists at richarde.dev Mon May 8 11:48:08 2023 From: lists at richarde.dev (Richard Eisenberg) Date: Mon, 8 May 2023 11:48:08 +0000 Subject: [ghc-steering-committee] #536: Type-level literals as a separate language extension, rec: accept In-Reply-To: References: <010f0186c72d3aa5-5163b078-0956-46e8-9e41-c2d206f6273c-000000@us-east-2.amazonses.com> <882d3cac-00e6-7dfd-b32d-69968856b8ba@well-typed.com> <010f0186fbb4bf37-10d8c856-9c2e-47c0-9edf-e0af23097fbc-000000@us-east-2.amazonses.com> <2fc76f16-4ab6-210b-7396-9b06c10ec9e5@well-typed.com> Message-ID: <010f0187fb30bcd6-d2e296f7-0464-4ff9-be5b-91c4bb869a19-000000@us-east-2.amazonses.com> I remain opposed, but I understand that I'm in the minority here. Richard > On May 1, 2023, at 2:19 PM, Simon Peyton Jones wrote: > > I am also in favour for the reasons Adam gives. > > Simon > > On Mon, 1 May 2023 at 14:17, Adam Gundry > wrote: > Thanks for your comments Iavor, your input is appreciated. > > The ongoing discussion on language extensions made me think about > proposal #536 again. With due respect to Richard, I still think we > should accept it, for the following reasons: > > * We owe it to proposal authors to make decisions in a reasonably > prompt fashion. The ongoing discussion is unlikely to be resolved > extremely quickly, and the extension split in the proposal accords with > the de facto approach to language extensions as feature flags. > > * Even if we accept the premise that we have too many extensions, > accepting the proposal doesn't really make things worse (if we already > have a hundred extensions too many, what harm one more?). > > * As Iavor says, there is no deep reason for type literals and > DataKinds to be grouped as part of the same feature; it is merely a > historical accident. If we later move to a model where features are > enabled by default and controlled using warnings, it would be equally > reasonable to have separate warnings for type literals and DataKinds. > > * The proposed change is simple, low effort to implement and maintain, > and is clearly desired by some users. > > * The workaround with -Werror=unticked-promoted-constructors doesn't > accurately characterise the language with type literals but not DataKinds. > > Feel free to object, of course. :-) > > Adam > > > > On 20/03/2023 17:59, Iavor Diatchki wrote: > > Hello, > > > > I am not on the committee but as the original author of the type > > literals extensions I thought I'd give my 2c. I am strongly in favor of > > separating type literals from DataKinds, they are not really together > > for any deep reason. > > > > For me the separate extension would be useful because it makes it > > possible to use type literals with the `TypeData` extension, which for > > me, is a much nicer way to work with type level things than `DataKinds`. > > > > -Iavor > > > > > > > > On Mon, Mar 20, 2023 at 10:08 AM Chris Dornan > > >> wrote: > > > > I am also in favour of extensions that focus on solving a single > > problem well and giving users precise control over what extensions > > they deploy. If we get this right then we should be able discover > > which extensions people want and those that are free of unintended > > consequences, and can put them on track to be included in a GHC and > > then Haskell standard. > > > > This proposal isn't ambitious but it does otherwise appear to > > qualify so I am in favour. > > > > Chris > > > > > > > > > >> On 20 Mar 2023, at 08:43, Simon Peyton Jones > >> >> > >> wrote: > >> > >> Personally I'm happy with having orthogonal extensions that enable > >> just one thing. That allows our users to do what they want, > >> rather than telling them what they want. > >> > >> On this particular proposal I don't think it's a big deal either > >> way, but I'd vote in favour. It's not exactly true to say that it > >> duplicates an existing feature. I think Richard's point is that > >> you can get a warning for using an unticked constructor (but > >> nothing for using a ticked one). That's different from getting an > >> error if you use a constructor in a type, ticked or not. > >> > >> This particular proposal is easy to describe and easy to > >> implement. But I don't think we should burn a lot of cycles on > >> it... it's a matter of taste, so we could just vote. > >> > >> Simon > >> > >> On Sun, 19 Mar 2023 at 21:09, Richard Eisenberg > >> >> wrote: > >> > >> This argument gave me pause. Thanks, Adam. I think, for me, it > >> comes down to this: what do we think will be more useful to > >> more of our users? A notion of a core language -- perhaps > >> implemented by different compilers -- with extensions? Or a > >> unified language GHC/Haskell which allows subsetting? I tend > >> to think the latter, though I'm not sure. > >> > >> Regarding this particular proposal: I remain against the > >> proposal, as it duplicates an existing feature. That's a > >> simple reason to be against a proposal. > >> > >> Richard > >> > >> > On Mar 10, 2023, at 9:15 AM, Adam Gundry > >> >> wrote: > >> > > >> > This proposal is very helpful in exposing some of the > >> divisions about the interpretation of extensions that exist > >> within the committee! "Let a thousand flowers bloom" vs > >> "more-extensions-make-me-wince", if you like. > >> > > >> > For what it's worth I tend to be in the former camp. I think > >> we should strive for orthogonality and avoid bundling together > >> distinct features merely because they have related effects. > >> Instead we should construct our language via composition of > >> simple components. And I think it's reasonable to say that > >> TypeLevelLiterals and (the rest of) DataKinds are clearly > >> distinct and can be understood in isolation. > >> > > >> > If the number of extensions is a problem, that points to the > >> need to better structure our documentation and gather coherent > >> subsets of extensions into manageable pieces (much as GHC2021 > >> tries to do). Beyond that I'd like to understand the downsides > >> better (e.g. what costs does it actually impose on HLS to have > >> another extension?). > >> > > >> > A conversation with one of the authors of Helium this week > >> made me think that in the GHC proposals process we have tended > >> to neglect the possible presence of other Haskell > >> implementations. It's not realistic to expect that anyone will > >> reimplement the whole of GHC Haskell, but perhaps there is a > >> fragment large enough to be useful for a fair number of > >> Haskell programs but also small enough to be independently > >> implemented (e.g. by Helium). It would strike me as plausible > >> that such an implementation might want to support > >> TypeData+TypeLevelLiterals but not DataKinds. > >> > > >> > Adam > >> > > >> > > >> > On 09/03/2023 16:21, Richard Eisenberg wrote: > >> >> Though I see the arguments in the other direction, I vote > >> against this proposal. As Joachim argues, adding an extension > >> puts a tax on the entire ecosystem by adding one more bit of > >> context a reader has to have to understand code. In addition, > >> HLS will have to be aware of this extension. And the benefits > >> seem pretty marginal here. > >> >> Can we instead simply provide a warning? The warning here > >> would be something like the -Wpuns idea, in that it helps the > >> author keep to a particular subset of the language. (We might > >> want to collect such warnings somehow in our documentation.) > >> >> Actually, it occurs to me we already have the warning: > >> -Wunticked-promoted-constructors. We've put that warning in > >> the -Weverything bin (not even -Wall) because in the past > >> we've decided that we shouldn't recommend/require the ' when > >> using a constructor in a type. But actually, setting > >> -Werror=unticked-promoted-constructors would seem to be a > >> perfect substitute for -XTypeLevelLiterals -XNoDataKinds. OK, > >> not perfect: you could still use a constructor in a type with > >> a ' mark. But I think that's great, actually, because perhaps > >> an author wary of constructors in types still might need to > >> use one, in one place, in a 2,000-line file. This ticks all > >> the boxes (ha ha). > >> >> Having discovered this replacement, I'm now pretty strongly > >> against this proposal. I'll also post on GitHub. > >> >> Richard > >> >>> On Mar 9, 2023, at 4:26 AM, Arnaud Spiwack > >> > > >> > >> >>> wrote: > >> >>> > >> >>> I can see where the author is coming from. But as Joachim, > >> I find myself unconvinced that it is worth yet one extra > >> extension (but then again, I'm the > >> more-extensions-make-me-wince member of this committee). > >> >>> > >> >>> On Wed, 8 Mar 2023 at 13:56, Joachim Breitner > >> > > >> > >> >>> wrote: > >> >>> > >> >>> Hi, > >> >>> > >> >>> Am Mittwoch, dem 08.03.2023 um 14:58 +0300 schrieb > >> Vladislav Zavialov: > >> >>> > DataKinds is indeed a "bad" extension because it > >> introduces > >> >>> ambiguity > >> >>> > to name resolution. > >> >>> > > >> >>> > There are two ways to avoid this issue: > >> >>> > 1. Keep namespaces separate and double down on using > >> punned > >> >>> > constructor names. > >> >>> > 2. Merge terms and types, discouraging punned > >> constructor names. > >> >>> > > >> >>> > Each approach could indeed lead to a "dialect" of sorts. > >> >>> > > >> >>> > * The (accepted and recently implemented) TypeData > >> extension > >> >>> moves us > >> >>> > in the direction of option (1), and I imagine the > >> proposed > >> >>> > TypeLevelLiterals would be often used in conjunction > >> with TypeData. > >> >>> > This carves out a limited, conservative language > >> subset for type- > >> >>> > level programming. > >> >>> > * At the same time, #270 "Support pun-free code" > >> moves us in the > >> >>> > direction of option (2), and I expect it to be the > >> better option > >> >>> when > >> >>> > it comes to fully fledged dependently-typed programming > >> >>> envisioned by > >> >>> > #378. > >> >>> > > >> >>> > If I had to choose, I'd go with option (2). I don't > >> see myself using > >> >>> > TypeData, nor TypeLevelLiterals for that matter. But > >> I am of a > >> >>> "let a > >> >>> > thousand flowers bloom" persuasion, hence my > >> recommendation to > >> >>> > accept. > >> >>> > >> >>> > >> >>> Thanks for putting this into a clearer context. > >> >>> > >> >>> Where does DataKind fit in? Is it a natural part of > >> approach (2) > >> >>> (which > >> >>> is the general direction outlined by #378), or is yet > >> another take on > >> >>> the issue? > >> >>> If DataKinds was not what we want according to #378, > >> but the fragment > >> >>> carved out by TypeLevelLiterals was, then that would be > >> a strong > >> >>> reason > >> >>> for me to acccept TypeLevelLiterals. > >> >>> But if DataKinds is the goal (or at least “the” goal), > >> then I > >> >>> think I’d > >> >>> like to see stronger arguments for why it should be split. > >> >>> > >> >>> > >> >>> Cheers, > >> >>> Joachim > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > > _______________________________________________ > 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 lists at richarde.dev Mon May 8 11:59:23 2023 From: lists at richarde.dev (Richard Eisenberg) Date: Mon, 8 May 2023 11:59:23 +0000 Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?= =?utf-8?b?4oCTIFJvdW5kIDI=?= In-Reply-To: <0b6911af-db25-b510-1074-6bd1765e82c8@well-typed.com> References: <645c23058bff47264e49fdecd16d3eedce2167bd.camel@joachim-breitner.de> <010f0187d50efae1-7ff2c457-95dc-4f22-9e75-400eb068952d-000000@us-east-2.amazonses.com> <0b6911af-db25-b510-1074-6bd1765e82c8@well-typed.com> Message-ID: <010f0187fb3b0c6c-f138abf5-e3b9-415b-811d-f3b74b24e595-000000@us-east-2.amazonses.com> > On May 1, 2023, at 8:59 AM, Adam Gundry wrote: > > > * recommended (part of the language, fairly stable); > > * experimental (not yet resolved one way or the other); or > > * discouraged (supported primarily for backwards compatibility). Yes! And also Simon's addition of "language variation". My stance is (I claim) it is hard for users to navigate the current extension maze (e.g. it's pretty hard for someone to know that scary-sounding UndecidableInstances is safe to use in practice but that TypeFamilies may break their type inference, even if they never write a type family). We should strive to simplify this maze so that it's easier for our users to write effective Haskell. One way to phrase this is "stable and liberal". Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue May 9 12:57:01 2023 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 09 May 2023 14:57:01 +0200 Subject: [ghc-steering-committee] #536: Type-level literals as a separate language extension, rec: accept In-Reply-To: <010f0187fb30bcd6-d2e296f7-0464-4ff9-be5b-91c4bb869a19-000000@us-east-2.amazonses.com> References: <010f0186c72d3aa5-5163b078-0956-46e8-9e41-c2d206f6273c-000000@us-east-2.amazonses.com> <882d3cac-00e6-7dfd-b32d-69968856b8ba@well-typed.com> <010f0186fbb4bf37-10d8c856-9c2e-47c0-9edf-e0af23097fbc-000000@us-east-2.amazonses.com> <2fc76f16-4ab6-210b-7396-9b06c10ec9e5@well-typed.com> <010f0187fb30bcd6-d2e296f7-0464-4ff9-be5b-91c4bb869a19-000000@us-east-2.amazonses.com> Message-ID: <36314aa6ed4a0b1d35f8b5f0fa0d57ef1118f1cd.camel@joachim-breitner.de> Hi, I am also part of that minority, but at least until and unless we come to a clear policy that we want to wean off fine-grined language pragmas, I don’t want to block the enthusiasm of those who have stronger opinions in favor of this particular one. As Adam says, we already have very many extensions, so YOLO. Cheers, Joachim Am Montag, dem 08.05.2023 um 11:48 +0000 schrieb Richard Eisenberg: > I remain opposed, but I understand that I'm in the minority here. > > Richard > > > On May 1, 2023, at 2:19 PM, Simon Peyton Jones > > wrote: > > > > I am also in favour for the reasons Adam gives. > > > > Simon > > > > On Mon, 1 May 2023 at 14:17, Adam Gundry > > wrote: > > > Thanks for your comments Iavor, your input is appreciated. > > > > > > The ongoing discussion on language extensions made me think about > > > proposal #536 again. With due respect to Richard, I still think > > > we > > > should accept it, for the following reasons: > > > > > >   * We owe it to proposal authors to make decisions in a > > > reasonably > > > prompt fashion. The ongoing discussion is unlikely to be resolved > > > extremely quickly, and the extension split in the proposal > > > accords with > > > the de facto approach to language extensions as feature flags. > > > > > >   * Even if we accept the premise that we have too many > > > extensions, > > > accepting the proposal doesn't really make things worse (if we > > > already > > > have a hundred extensions too many, what harm one more?). > > > > > >   * As Iavor says, there is no deep reason for type literals and > > > DataKinds to be grouped as part of the same feature; it is merely > > > a > > > historical accident. If we later move to a model where features > > > are > > > enabled by default and controlled using warnings, it would be > > > equally > > > reasonable to have separate warnings for type literals and > > > DataKinds. > > > > > >   * The proposed change is simple, low effort to implement and > > > maintain, > > > and is clearly desired by some users. > > > > > >   * The workaround with -Werror=unticked-promoted-constructors > > > doesn't > > > accurately characterise the language with type literals but not > > > DataKinds. > > > > > > Feel free to object, of course. :-) > > > > > > Adam > > > > > > > > > > > > On 20/03/2023 17:59, Iavor Diatchki wrote: > > > > Hello, > > > > > > > > I am not on the committee but as the original author of the > > > > type > > > > literals extensions I thought I'd give my 2c.  I am strongly in > > > > favor of > > > > separating type literals from DataKinds, they are not really > > > > together > > > > for any deep reason. > > > > > > > > For me the separate extension would be useful because it makes > > > > it > > > > possible to use type literals with the `TypeData` extension, > > > > which for > > > > me, is a much nicer way to work with type level things than > > > > `DataKinds`. > > > > > > > > -Iavor > > > > > > > > > > > > > > > > On Mon, Mar 20, 2023 at 10:08 AM Chris Dornan > > > > > > > > wrote: > > > > > > > >      I am also in favour of extensions that focus on solving a > > > > single > > > >      problem well and giving users precise control over what > > > > extensions > > > >      they deploy. If we get this right then we should be able > > > > discover > > > >      which extensions people want and those that are free of > > > > unintended > > > >      consequences, and can put them on track to be included in > > > > a GHC and > > > >      then Haskell standard. > > > > > > > >      This proposal isn't ambitious but it does otherwise appear > > > > to > > > >      qualify so I am in favour. > > > > > > > >      Chris > > > > > > > > > > > > > > > > > > > > >      On 20 Mar 2023, at 08:43, Simon Peyton Jones > > > > >       > > > > > > > > > >      wrote: > > > > > > > > > >      Personally I'm happy with having orthogonal extensions > > > > > that enable > > > > >      just one thing.  That allows our users to do what they > > > > > want, > > > > >      rather than telling them what they want. > > > > > > > > > >      On this particular proposal I don't think it's a big > > > > > deal either > > > > >      way, but I'd vote in favour.  It's not exactly true to > > > > > say that it > > > > >      duplicates an existing feature.  I think Richard's point > > > > > is that > > > > >      you can get a warning for using an unticked constructor > > > > > (but > > > > >      nothing for using a ticked one).  That's different from > > > > > getting an > > > > >      error if you use a constructor in a type, ticked or not. > > > > > > > > > >      This particular proposal is easy to describe and easy to > > > > >      implement.  But I don't think we should burn a lot of > > > > > cycles on > > > > >      it... it's a matter of taste, so we could just vote. > > > > > > > > > >      Simon > > > > > > > > > >      On Sun, 19 Mar 2023 at 21:09, Richard Eisenberg > > > > >      > wrote: > > > > > > > > > >          This argument gave me pause. Thanks, Adam. I think, > > > > > for me, it > > > > >          comes down to this: what do we think will be more > > > > > useful to > > > > >          more of our users? A notion of a core language -- > > > > > perhaps > > > > >          implemented by different compilers -- with > > > > > extensions? Or a > > > > >          unified language GHC/Haskell which allows > > > > > subsetting? I tend > > > > >          to think the latter, though I'm not sure. > > > > > > > > > >          Regarding this particular proposal: I remain against > > > > > the > > > > >          proposal, as it duplicates an existing feature. > > > > > That's a > > > > >          simple reason to be against a proposal. > > > > > > > > > >          Richard > > > > > > > > > >          > On Mar 10, 2023, at 9:15 AM, Adam Gundry > > > > >          > > > > > > wrote: > > > > >          > > > > > >          > This proposal is very helpful in exposing some of > > > > > the > > > > >          divisions about the interpretation of extensions > > > > > that exist > > > > >          within the committee! "Let a thousand flowers bloom" > > > > > vs > > > > >          "more-extensions-make-me-wince", if you like. > > > > >          > > > > > >          > For what it's worth I tend to be in the former > > > > > camp. I think > > > > >          we should strive for orthogonality and avoid > > > > > bundling together > > > > >          distinct features merely because they have related > > > > > effects. > > > > >          Instead we should construct our language via > > > > > composition of > > > > >          simple components. And I think it's reasonable to > > > > > say that > > > > >          TypeLevelLiterals and (the rest of) DataKinds are > > > > > clearly > > > > >          distinct and can be understood in isolation. > > > > >          > > > > > >          > If the number of extensions is a problem, that > > > > > points to the > > > > >          need to better structure our documentation and > > > > > gather coherent > > > > >          subsets of extensions into manageable pieces (much > > > > > as GHC2021 > > > > >          tries to do). Beyond that I'd like to understand the > > > > > downsides > > > > >          better (e.g. what costs does it actually impose on > > > > > HLS to have > > > > >          another extension?). > > > > >          > > > > > >          > A conversation with one of the authors of Helium > > > > > this week > > > > >          made me think that in the GHC proposals process we > > > > > have tended > > > > >          to neglect the possible presence of other Haskell > > > > >          implementations. It's not realistic to expect that > > > > > anyone will > > > > >          reimplement the whole of GHC Haskell, but perhaps > > > > > there is a > > > > >          fragment large enough to be useful for a fair number > > > > > of > > > > >          Haskell programs but also small enough to be > > > > > independently > > > > >          implemented (e.g. by Helium). It would strike me as > > > > > plausible > > > > >          that such an implementation might want to support > > > > >          TypeData+TypeLevelLiterals but not DataKinds. > > > > >          > > > > > >          > Adam > > > > >          > > > > > >          > > > > > >          > On 09/03/2023 16:21, Richard Eisenberg wrote: > > > > >          >> Though I see the arguments in the other > > > > > direction, I vote > > > > >          against this proposal. As Joachim argues, adding an > > > > > extension > > > > >          puts a tax on the entire ecosystem by adding one > > > > > more bit of > > > > >          context a reader has to have to understand code. In > > > > > addition, > > > > >          HLS will have to be aware of this extension. And the > > > > > benefits > > > > >          seem pretty marginal here. > > > > >          >> Can we instead simply provide a warning? The > > > > > warning here > > > > >          would be something like the -Wpuns idea, in that it > > > > > helps the > > > > >          author keep to a particular subset of the language. > > > > > (We might > > > > >          want to collect such warnings somehow in our > > > > > documentation.) > > > > >          >> Actually, it occurs to me we already have the > > > > > warning: > > > > >          -Wunticked-promoted-constructors. We've put that > > > > > warning in > > > > >          the -Weverything bin (not even -Wall) because in the > > > > > past > > > > >          we've decided that we shouldn't recommend/require > > > > > the ' when > > > > >          using a constructor in a type. But actually, setting > > > > >          -Werror=unticked-promoted-constructors would seem to > > > > > be a > > > > >          perfect substitute for -XTypeLevelLiterals - > > > > > XNoDataKinds. OK, > > > > >          not perfect: you could still use a constructor in a > > > > > type with > > > > >          a ' mark. But I think that's great, actually, > > > > > because perhaps > > > > >          an author wary of constructors in types still might > > > > > need to > > > > >          use one, in one place, in a 2,000-line file. This > > > > > ticks all > > > > >          the boxes (ha ha). > > > > >          >> Having discovered this replacement, I'm now > > > > > pretty strongly > > > > >          against this proposal. I'll also post on GitHub. > > > > >          >> Richard > > > > >          >>> On Mar 9, 2023, at 4:26 AM, Arnaud Spiwack > > > > >           > > > > > > > > >           > > > >          >> wrote: > > > > >          >>> > > > > >          >>> I can see where the author is coming from. But > > > > > as Joachim, > > > > >          I find myself unconvinced that it is worth yet one > > > > > extra > > > > >          extension (but then again, I'm the > > > > >          more-extensions-make-me-wince member of this > > > > > committee). > > > > >          >>> > > > > >          >>> On Wed, 8 Mar 2023 at 13:56, Joachim Breitner > > > > >           > > > > > > > > >           > > > >          >> wrote: > > > > >          >>> > > > > >          >>>    Hi, > > > > >          >>> > > > > >          >>>    Am Mittwoch, dem 08.03.2023 um 14:58 +0300 > > > > > schrieb > > > > >          Vladislav Zavialov: > > > > >          >>>    > DataKinds is indeed a "bad" extension > > > > > because it > > > > >          introduces > > > > >          >>>    ambiguity > > > > >          >>>    > to name resolution. > > > > >          >>>    > > > > > >          >>>    > There are two ways to avoid this issue: > > > > >          >>>    > 1. Keep namespaces separate and double down > > > > > on using > > > > >          punned > > > > >          >>>    > constructor names. > > > > >          >>>    > 2. Merge terms and types, discouraging > > > > > punned > > > > >          constructor names. > > > > >          >>>    > > > > > >          >>>    > Each approach could indeed lead to a > > > > > "dialect" of sorts. > > > > >          >>>    > > > > > >          >>>    > * The (accepted and recently implemented) > > > > > TypeData > > > > >          extension > > > > >          >>>    moves us > > > > >          >>>    > in the direction of option (1), and I > > > > > imagine the > > > > >          proposed > > > > >          >>>    > TypeLevelLiterals would be often used in > > > > > conjunction > > > > >          with TypeData. > > > > >          >>>    > This carves out a limited, conservative > > > > > language > > > > >          subset for type- > > > > >          >>>    > level programming. > > > > >          >>>    > * At the same time, #270 "Support pun-free > > > > > code" > > > > >          moves us in the > > > > >          >>>    > direction of option (2), and I expect it to > > > > > be the > > > > >          better option > > > > >          >>>    when > > > > >          >>>    > it comes to fully fledged dependently-typed > > > > > programming > > > > >          >>>    envisioned by > > > > >          >>>    > #378. > > > > >          >>>    > > > > > >          >>>    > If I had to choose, I'd go with option (2). > > > > > I don't > > > > >          see myself using > > > > >          >>>    > TypeData, nor TypeLevelLiterals for that > > > > > matter. But > > > > >          I am of a > > > > >          >>>    "let a > > > > >          >>>    > thousand flowers bloom" persuasion, hence > > > > > my > > > > >          recommendation to > > > > >          >>>    > accept. > > > > >          >>> > > > > >          >>> > > > > >          >>>    Thanks for putting this into a clearer > > > > > context. > > > > >          >>> > > > > >          >>>    Where does DataKind fit in? Is it a natural > > > > > part of > > > > >          approach (2) > > > > >          >>>    (which > > > > >          >>>    is the general direction outlined by #378), > > > > > or is yet > > > > >          another take on > > > > >          >>>    the issue? > > > > >          >>>    If DataKinds was not what we want according > > > > > to #378, > > > > >          but the fragment > > > > >          >>>    carved out by TypeLevelLiterals was, then > > > > > that would be > > > > >          a strong > > > > >          >>>    reason > > > > >          >>>    for me to acccept TypeLevelLiterals. > > > > >          >>>    But if DataKinds is the goal (or at least > > > > > “the” goal), > > > > >          then I > > > > >          >>>    think I’d > > > > >          >>>    like to see stronger arguments for why it > > > > > should be split. > > > > >          >>> > > > > >          >>> > > > > >          >>>    Cheers, > > > > >          >>>    Joachim > > > > > > -- > > > Adam Gundry, Haskell Consultant > > > Well-Typed LLP, https://www.well-typed.com/ > > > > > > Registered in England & Wales, OC335890 > > > 27 Old Gloucester Street, London WC1N 3AX, England > > > > > > _______________________________________________ > > > 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 -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Wed May 17 06:21:57 2023 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 17 May 2023 08:21:57 +0200 Subject: [ghc-steering-committee] Please review #579: Backward compat proposal section, Shepherd: Simon PJ In-Reply-To: References: <2267dc569fc36e121a5372fae16f23089f4c68cd.camel@joachim-breitner.de> Message-ID: <547e8c6550a39c6e33ca433c0d9b91f7a2bc6e41.camel@joachim-breitner.de> Hi, Am Donnerstag, dem 30.03.2023 um 11:13 +0200 schrieb Arnaud Spiwack: > Asked for a few questions to be answered on Github. Other than that, > this sounds absolutely a positive change to me. > > On Thu, 30 Mar 2023 at 10:58, Simon Peyton Jones > wrote: > > Dear Steering Commitee > > > > Please review > > https://github.com/ghc-proposals/ghc-proposals/pull/579 > > > > I propose acceptance.  On this one I'll take silence as assent. > > > > Please reply by Tuesday 4 April Arnaud, did your questions get resolved? Could you maybe update the proposal with a possible answer to your question? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Wed May 17 06:28:17 2023 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 17 May 2023 08:28:17 +0200 Subject: [ghc-steering-committee] Please review #493: SPECIALISE with expressions, Shepherd: Adam Message-ID: Dear Committee, Richard proposes that the SPECIALIZE pragma should understand expressions, not just types: https://github.com/ghc-proposals/ghc-proposals/pull/493 https://github.com/goldfirere/ghc-proposals/blob/specialise/proposals/0000-specialise-expressions.rst I’d like to ask Adam to shepherd this proposal. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Wed May 17 06:34:47 2023 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 17 May 2023 08:34:47 +0200 Subject: [ghc-steering-committee] GHC Steering Committee Status Message-ID: <3993c8921d5c9084e267cdcfb3aea1d94bf7d397.camel@joachim-breitner.de> Dear Committee, we had some relatively quiet two weeks on this mailing list, but that quiet doesn’t really fit to the relatively long backlog. Let’s clear it out a bit, if we can! What has happened since the last one update (March 16)? * Arnaud continues the quest to understand the roles of Extensions. * we were asked to review these proposals: #579: Backward compat proposal section, Shepherd: Simon PJ #575: Deprecated instances, Shepherd: Moritz #585: Amend Or Patterns, Shepherd: Richard #493: SPECIALISE with expressions, Shepherd: Adam * we have a recommendation from the shepherd about: #536: Type-level literals as a separate language extension, rec: accept #579: Backward compat proposal section, rec: accept * we have sent the following proposals back to revision #330: Decorate exceptions with backtrace information, Shepherd: Vlad * we decided about the following proposals #540: parallelism semaphores, rec: accept So we currently have to act on the following 8 proposals, up again by 2: ## Waiting for committee decision #532: Clean up implicit binding, Shepherd: Arnaud 2022-08-23: Assigned to Arnaud Sent back for revision 2022-11-27: Resubmitted 2022-12-14: Arnaud recommends acceptance 2023-01-17: Arnaud picks up the conversation again. Silence since. #512: NoFieldSelectors as datatype annotation, Shepherd: Vlad 2022-09-03: Assigned to Baldur 2022-10-02: Reassignd to Vlad 2022-11-30: Vlad recommends rejection Turned into a discussion of Modifiers, and then into silence. Where are we on this one? #536: Type-level literals as a sep language extension, Shepherd: Vlad 2023-02-16 Assigned to Vlad 2023-03-06 Vlad recommends acceptance Some hesitancy in the committee to introduce this extension, the ongoing policy clarification process might guide us, but maybe we can resolve this earlier? #579: Backward compat proposal section, Shepherd: Simon PJ 2023-03-30: Assigned to Simon 2023-03-30: Simon recommends acceptance Adam had a question that went unanswerd. Can we resolve this? ## Waiting for shepherd recommendation #526: Applicative Comprehensions, Shepherd: Simon M 2022-10-08: Assigned to Simon M Simon, can you cast your recommendation? #585: Amend Or Patterns, Shepherd: Richard 2023-04-11: Assigned to Richard #575: Deprecated instances, Shepherd: Moritz 2023-04-06: Assigned to Moritz #493: SPECIALISE with expressions, Shepherd: Adam 2023-05-17: Assigned to Adam Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simon.peytonjones at gmail.com Wed May 17 07:30:18 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 17 May 2023 08:30:18 +0100 Subject: [ghc-steering-committee] Please review #579: Backward compat proposal section, Shepherd: Simon PJ In-Reply-To: <547e8c6550a39c6e33ca433c0d9b91f7a2bc6e41.camel@joachim-breitner.de> References: <2267dc569fc36e121a5372fae16f23089f4c68cd.camel@joachim-breitner.de> <547e8c6550a39c6e33ca433c0d9b91f7a2bc6e41.camel@joachim-breitner.de> Message-ID: Thanks for reminding, Joachim. Let's get this done. Arnaud? On Wed, 17 May 2023 at 07:22, Joachim Breitner wrote: > Hi, > > Am Donnerstag, dem 30.03.2023 um 11:13 +0200 schrieb Arnaud Spiwack: > > Asked for a few questions to be answered on Github. Other than that, > > this sounds absolutely a positive change to me. > > > > On Thu, 30 Mar 2023 at 10:58, Simon Peyton Jones > > wrote: > > > Dear Steering Commitee > > > > > > Please review > > > https://github.com/ghc-proposals/ghc-proposals/pull/579 > > > > > > I propose acceptance. On this one I'll take silence as assent. > > > > > > Please reply by Tuesday 4 April > > > Arnaud, did your questions get resolved? Could you maybe update the > proposal with a possible answer to your question? > > Cheers, > Joachim > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz.angermann at gmail.com Fri May 19 09:05:31 2023 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Fri, 19 May 2023 17:05:31 +0800 Subject: [ghc-steering-committee] Please consider GHC Proposal #575 for acceptance. Message-ID: Dear Steering Committee, I strongly endorse GHC Proposal #575 , which suggests the introduction of deprecation pragmas on instances. The proposal is a logical extension of Haskell's existing deprecation facilities. Its implementation would fill a notable gap in the language's current deprecation capabilities. The lack of instance deprecation hinders controlled evolution of libraries and codebases, often leading to unexpected changes for users. By allowing instance deprecation, we can enhance the stability and predictability of Haskell codebases and improve the user experience. In summary, Proposal #575 represents a valuable improvement for Haskell. I urge the committee to give it favorable consideration. Best Regards, Moritz -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at chrisdornan.com Fri May 19 09:45:12 2023 From: chris at chrisdornan.com (Chris Dornan) Date: Fri, 19 May 2023 10:45:12 +0100 Subject: [ghc-steering-committee] Please consider GHC Proposal #575 for acceptance. In-Reply-To: References: Message-ID: LGTM +1 > On 19 May 2023, at 10:05, Moritz Angermann wrote: > > Dear Steering Committee, > > I strongly endorse GHC Proposal #575 , which suggests the introduction of deprecation pragmas on instances. > > The proposal is a logical extension of Haskell's existing deprecation facilities. Its implementation would fill a notable gap in the language's current deprecation capabilities. > > The lack of instance deprecation hinders controlled evolution of libraries and codebases, often leading to unexpected changes for users. By allowing instance deprecation, we can enhance the stability and predictability of Haskell codebases and improve the user experience. > > In summary, Proposal #575 represents a valuable improvement for Haskell. I urge the committee to give it favorable consideration. > > Best Regards, Moritz > > _______________________________________________ > 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 Sat May 20 18:06:18 2023 From: eric at seidel.io (Eric Seidel) Date: Sat, 20 May 2023 14:06:18 -0400 Subject: [ghc-steering-committee] Please consider GHC Proposal #575 foracceptance. In-Reply-To: References: Message-ID: <8442e104-affc-4dba-a18a-b601c341c25c@app.fastmail.com> This mostly seems like an obvious win. Evolvability demands that any artifact that we produce support deprecations warnings. The one concern I have that is somewhat unique to deprecating instances is that users don't *explicitly* use an instance. There's an implicit chain of resolutions that leads to the use of a deprecated instance. Will that make it hard for users to understand *why* their program is bad, and *how* to fix it? It might just be brevity on Vlad's part, but I found it notable that the NFData example[1] just says "Don't use NFData (a -> b)." It gives no advice on what to do instead. With function deprecations it's usually easy to suggest replacements. I don't think this is a reason to reject the proposal, probably just something that library authors will need to be careful about when deprecating instances. [1]: https://github.com/int-index/ghc-proposals/blob/int-index/deprecated-instances/proposals/0000-deprecated-instances.rst#4examples On Fri, May 19, 2023, at 05:05, Moritz Angermann wrote: > Dear Steering Committee, > > I strongly endorse GHC Proposal #575 > , which > suggests the introduction of deprecation pragmas on instances. > > The proposal is a logical extension of Haskell's existing deprecation > facilities. Its implementation would fill a notable gap in the > language's current deprecation capabilities. > > The lack of instance deprecation hinders controlled evolution of > libraries and codebases, often leading to unexpected changes for users. > By allowing instance deprecation, we can enhance the stability and > predictability of Haskell codebases and improve the user experience. > > In summary, Proposal #575 represents a valuable improvement for > Haskell. I urge the committee to give it favorable consideration. > > Best Regards, Moritz > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From simon.peytonjones at gmail.com Wed May 24 08:22:32 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 24 May 2023 09:22:32 +0100 Subject: [ghc-steering-committee] GHC Steering Committee Status In-Reply-To: <3993c8921d5c9084e267cdcfb3aea1d94bf7d397.camel@joachim-breitner.de> References: <3993c8921d5c9084e267cdcfb3aea1d94bf7d397.camel@joachim-breitner.de> Message-ID: Vlad, Joachim It'd be easy to miss this but Ben resubmitted the exceptions proposal #330 to the committee 5 days ago. Vlad: you are the shepherd: can you make a recommendation and guide us to a decision. FWIW, my personal view is that this long-running proposal has had a lot of scrutiny, and is widely awaited. Unless there are technical objections (which we should understand and evaluate) I think we should just get it done. But you are the shepherd! Simon On Wed, 17 May 2023 at 07:35, Joachim Breitner wrote: > Dear Committee, > > we had some relatively quiet two weeks on this mailing list, but that > quiet doesn’t really fit to the relatively long backlog. Let’s clear it > out a bit, if we can! > > What has happened since the last one update (March 16)? > > * Arnaud continues the quest to understand the roles of Extensions. > > * we were asked to review these proposals: > > #579: Backward compat proposal section, Shepherd: Simon PJ > #575: Deprecated instances, Shepherd: Moritz > #585: Amend Or Patterns, Shepherd: Richard > #493: SPECIALISE with expressions, Shepherd: Adam > > * we have a recommendation from the shepherd about: > > #536: Type-level literals as a separate language extension, rec: accept > #579: Backward compat proposal section, rec: accept > > * we have sent the following proposals back to revision > > #330: Decorate exceptions with backtrace information, Shepherd: Vlad > > * we decided about the following proposals > > #540: parallelism semaphores, rec: accept > > > So we currently have to act on the following 8 proposals, up again by 2: > > ## Waiting for committee decision > > #532: Clean up implicit binding, Shepherd: Arnaud > 2022-08-23: Assigned to Arnaud > Sent back for revision > 2022-11-27: Resubmitted > 2022-12-14: Arnaud recommends acceptance > 2023-01-17: Arnaud picks up the conversation again. > Silence since. > > #512: NoFieldSelectors as datatype annotation, Shepherd: Vlad > 2022-09-03: Assigned to Baldur > 2022-10-02: Reassignd to Vlad > 2022-11-30: Vlad recommends rejection > Turned into a discussion of Modifiers, and then > into silence. Where are we on this one? > > #536: Type-level literals as a sep language extension, Shepherd: Vlad > 2023-02-16 Assigned to Vlad > 2023-03-06 Vlad recommends acceptance > Some hesitancy in the committee to introduce this extension, > the ongoing policy clarification process might guide us, > but maybe we can resolve this earlier? > > #579: Backward compat proposal section, Shepherd: Simon PJ > 2023-03-30: Assigned to Simon > 2023-03-30: Simon recommends acceptance > Adam had a question that went unanswerd. Can we resolve this? > > ## Waiting for shepherd recommendation > > #526: Applicative Comprehensions, Shepherd: Simon M > 2022-10-08: Assigned to Simon M > Simon, can you cast your recommendation? > > #585: Amend Or Patterns, Shepherd: Richard > 2023-04-11: Assigned to Richard > > #575: Deprecated instances, Shepherd: Moritz > 2023-04-06: Assigned to Moritz > > #493: SPECIALISE with expressions, Shepherd: Adam > 2023-05-17: Assigned to Adam > > Cheers, > Joachim > > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Wed May 24 08:25:31 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 24 May 2023 09:25:31 +0100 Subject: [ghc-steering-committee] Please review #579: Backward compat proposal section, Shepherd: Simon PJ In-Reply-To: References: <2267dc569fc36e121a5372fae16f23089f4c68cd.camel@joachim-breitner.de> <547e8c6550a39c6e33ca433c0d9b91f7a2bc6e41.camel@joachim-breitner.de> Message-ID: RE https://github.com/ghc-proposals/ghc-proposals/pull/579 (Back-compat words in proposal specification) No reply from Arnaud. I don't think it was a big deal anyway, and the proposal is no more than modifying our guidance. Let's declare it accepted. Joachim please merge. Simon On Wed, 17 May 2023 at 08:30, Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > Thanks for reminding, Joachim. Let's get this done. Arnaud? > > On Wed, 17 May 2023 at 07:22, Joachim Breitner > wrote: > >> Hi, >> >> Am Donnerstag, dem 30.03.2023 um 11:13 +0200 schrieb Arnaud Spiwack: >> > Asked for a few questions to be answered on Github. Other than that, >> > this sounds absolutely a positive change to me. >> > >> > On Thu, 30 Mar 2023 at 10:58, Simon Peyton Jones >> > wrote: >> > > Dear Steering Commitee >> > > >> > > Please review >> > > https://github.com/ghc-proposals/ghc-proposals/pull/579 >> > > >> > > I propose acceptance. On this one I'll take silence as assent. >> > > >> > > Please reply by Tuesday 4 April >> >> >> Arnaud, did your questions get resolved? Could you maybe update the >> proposal with a possible answer to your question? >> >> Cheers, >> Joachim >> >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Wed May 24 09:12:23 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 24 May 2023 10:12:23 +0100 Subject: [ghc-steering-committee] Please consider GHC Proposal #575 for acceptance. In-Reply-To: References: Message-ID: I support acceptance, but I have asked a question about syntax. Simon On Fri, 19 May 2023 at 10:05, Moritz Angermann wrote: > Dear Steering Committee, > > I strongly endorse GHC Proposal #575 > , which suggests > the introduction of deprecation pragmas on instances. > > The proposal is a logical extension of Haskell's existing deprecation > facilities. Its implementation would fill a notable gap in the language's > current deprecation capabilities. > > The lack of instance deprecation hinders controlled evolution of libraries > and codebases, often leading to unexpected changes for users. By allowing > instance deprecation, we can enhance the stability and predictability of > Haskell codebases and improve the user experience. > > In summary, Proposal #575 represents a valuable improvement for Haskell. I > urge the committee to give it favorable consideration. > > Best Regards, Moritz > _______________________________________________ > 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 May 24 09:13:55 2023 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 24 May 2023 11:13:55 +0200 Subject: [ghc-steering-committee] Please review #579: Backward compat proposal section, Shepherd: Simon PJ In-Reply-To: References: <2267dc569fc36e121a5372fae16f23089f4c68cd.camel@joachim-breitner.de> <547e8c6550a39c6e33ca433c0d9b91f7a2bc6e41.camel@joachim-breitner.de> Message-ID: <09af40599bbd9eb23282ed646edf4dd390cef83a.camel@joachim-breitner.de> Hi, Am Mittwoch, dem 24.05.2023 um 09:25 +0100 schrieb Simon Peyton Jones: > Let's declare it accepted.  Joachim please merge. done. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From vlad.z.4096 at gmail.com Wed May 24 11:20:27 2023 From: vlad.z.4096 at gmail.com (Vladislav Zavialov) Date: Wed, 24 May 2023 13:20:27 +0200 Subject: [ghc-steering-committee] #330: Decorate exceptions with backtrace information, rec: accept In-Reply-To: References: Message-ID: Dear Committee, Back in March I recommended to accept GHC Proposal #330 "Decorate exceptions with backtrace information". It appears to me that we all agree that the proposed change is a good idea. There were a couple of technical suggestions that the author readily incorporated into the proposal text (the most important addition: nested `WhileHandling` annotations). I've skimmed the proposal one more time before writing this message and I find that it is in a very good state now. I'm about to declare it accepted, any last moment objections? Vlad On Fri, Mar 10, 2023 at 8:47 AM Arnaud Spiwack wrote: > My questions have been addressed, I'm now content with the proposal. > > On Thu, 9 Mar 2023 at 18:03, Arnaud Spiwack > wrote: > >> On Thu, 9 Mar 2023 at 12:52, Simon Marlow wrote: >> >>> Out of interest, why? >>> >> >> I'm not sure that I can quite say. The idea of annotations being >> somewhat implicitly passed, the symmetry with `HasCallStack`: it appeals to >> me. I guess it's not a very strong preference. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell-ml at tryp.io Wed May 24 15:40:55 2023 From: haskell-ml at tryp.io (Torsten Schmits) Date: Wed, 24 May 2023 17:40:55 +0200 Subject: [ghc-steering-committee] Advice for MRs about ImplicitForAll/ImplicitBinds Message-ID: <84880868-1eef-0254-682a-cb92d4177478@tryp.io> Dear members of the committee, I'm struggling to make a decision about whether to merge a proposal implementation that could wait for an amendment. Please have a look at my post on Gitlab for an explanation: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8629#note_500738 Thanks for your time, Torsten From mail at joachim-breitner.de Thu May 25 05:55:59 2023 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 25 May 2023 07:55:59 +0200 Subject: [ghc-steering-committee] Please review #194: Updated partial type signatures, Shepherd: Eric Message-ID: <360e9bcad56908e7e3d77e3320de6cd06050928a.camel@joachim-breitner.de> Dear Committee, Richard resubmits updated partial type signatures: https://github.com/ghc-proposals/ghc-proposals/pull/194 https://github.com/goldfirere/ghc-proposals/blob/updated-partial-type-sigs/proposals/0000-updated-partial-type-sigs.rst I’d like to ask Eric to shepherd this proposal. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Thu May 25 05:57:47 2023 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 25 May 2023 07:57:47 +0200 Subject: [ghc-steering-committee] Please review #581: Namespaces-specified Imports, Shepherd: Moritz Message-ID: <8e9fb4b2f626109d917a899eb2f5d6b252760ea1.camel@joachim-breitner.de> Dear Committee, Adam Gundry, Artyom Kuznetsov and Chris Dornan propose Namespace-specified imports: https://github.com/ghc-proposals/ghc-proposals/pull/581 https://github.com/adamgundry/ghc-proposals/blob/namespace-specified-imports/proposals/0000-namespace-specified-imports.rst I’d like to ask Moritz to shepherd this proposal. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From vlad.z.4096 at gmail.com Thu May 25 07:10:43 2023 From: vlad.z.4096 at gmail.com (Vladislav Zavialov) Date: Thu, 25 May 2023 09:10:43 +0200 Subject: [ghc-steering-committee] #330: Decorate exceptions with backtrace information, rec: accept In-Reply-To: References: Message-ID: I marked #330 as accepted and merged it. On Wed, May 24, 2023 at 1:20 PM Vladislav Zavialov wrote: > Dear Committee, > > Back in March I recommended to accept GHC Proposal #330 "Decorate > exceptions with backtrace information". It appears to me that we all > agree that the proposed change is a good idea. There were a couple of > technical suggestions that the author readily incorporated into the > proposal text (the most important addition: nested `WhileHandling` > annotations). I've skimmed the proposal one more time before writing this > message and I find that it is in a very good state now. > > I'm about to declare it accepted, any last moment objections? > > Vlad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu May 25 11:18:20 2023 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 25 May 2023 13:18:20 +0200 Subject: [ghc-steering-committee] Please review#586: split -Wunused-imports, Shepherd: Chris Message-ID: Dear Committee, Georgi Lyubenov and Torsten Schmits propose to split -Wunused-imports. https://github.com/ghc-proposals/ghc-proposals/pull/586 https://github.com/googleson78/ghc-proposals/blob/split-unused-imports/proposals/0000-split-wunused-imports.md I’d like to ask Chris to shepherd this proposal. Note that the authors became luke warm about the “meta warning” part of the proposal, and thus asks us (and hence foremost Chris) to cast a judgement call on it. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simon.peytonjones at gmail.com Fri May 26 16:19:04 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 26 May 2023 17:19:04 +0100 Subject: [ghc-steering-committee] Advice for MRs about ImplicitForAll/ImplicitBinds In-Reply-To: <84880868-1eef-0254-682a-cb92d4177478@tryp.io> References: <84880868-1eef-0254-682a-cb92d4177478@tryp.io> Message-ID: Thanks for working on this Torsten. I have replied on !8629. Simon On Wed, 24 May 2023 at 16:41, Torsten Schmits via ghc-steering-committee < ghc-steering-committee at haskell.org> wrote: > Dear members of the committee, I'm struggling to make a decision about > whether to merge a proposal implementation that > could wait for an amendment. > > Please have a look at my post on Gitlab for an explanation: > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8629#note_500738 > > Thanks for your time, > Torsten > > _______________________________________________ > 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: