December 2022 - ghc-steering-committee

Please review #512: NoFieldSelectors as datatype annotation, Shepherd: Baldur
by Joachim Breitner 02 Mar '23

02 Mar '23

Dear Committee, NoFieldSelectors as datatype annotation have been proposed by Matt Parsons https://github.com/ghc-proposals/ghc-proposals/pull/512 https://github.com/parsonsmatt/ghc-proposals/blob/matt/field-selectors-scop… I suggest Baldur to shepherd this proposal. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

9 29

Fwd: GHC2023
by Simon Peyton Jones 20 Jan '23

20 Jan '23

Dear Ghc-Steering-Committee, Here's an email from Tom Ellis about the GHC20xx thread. Please do read it. (Who, if anyone, is the moderator of the ghc-steering-committee mailing list?) Simon ---------- Forwarded message --------- From: Tom Ellis <tom-2019(a)jaguarpaw.co.uk> Date: Tue, 8 Nov 2022 at 08:04 Subject: Re: [ghc-steering-committee] GHC2023 To: Simon Peyton Jones <simon.peytonjones(a)gmail.com> Hello Simon, I sent this to the steering committee mailing list on Saturday but received an email in response saying it was "being held until the list moderator can review it for approval". Perhaps no moderator has had the chance to review it yet, as it hasn't yet appeared on the mailing list archive https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/thr… Perhaps you would be kind enough to forward it to the list for me directly. Thanks, Tom Thanks Simon. On reflection, I'm not particularly motivated to consult the community because the concerns I have impinge most strongly on members of the community who are distant from where a consultation could easily reach, and on non-but-potential-members of the community who are getting a false impression from afar. I will content myself with elaborating on my concerns and then leaving it to the steering committee to take them into account if they see fit. To set the scene, everything I write below is presented from the point of view of someone who wishes Haskell usage to increase and believes that we can't increase Haskell usage by appealing to people who are already comfortable with the way the Haskell ecosystem currently works: we've already got most of those people. For the ten years that I have been in the community, Haskell has had a (false) reputation, to outsiders, as a fragmented language with multiple mysterious things called "language extensions" each of which fractures the language in an incompatible way. "It's impossible to learn Haskell because there are so many incompatible Haskells" they say. It may be hard to believe that this perception exists: as users of GHC we know that there are very few extensions that introduce any incompatibility with others; extensions typically just remove unneccesary restrictions. But, for those of you who don't spend far-too-much of your time on discussion fora such as Hacker News and Reddit, I can guarantee to you that this objection to Haskell comes up *a lot*. Haskell also has, to both insiders and outsiders, a (true) reputation for being an unstable moving target. "It's impossible to learn or use Haskell because the language and libraries keep changing", they say. This one is easier to believe. GHC2021 is a wonderful way of dealing with all of the first and part of the second objection! I can now respond to complaints of language fragmentation and language instability by simply saying "Turn on GHC2021 and be happy". This is great news! (GHC2021 doesn't deal with instability in libraries of course, but I'm pleased that there are many people making efforts in that area too.) I am concerned that GHC2023 would weaken the power of my rejoinder "Turn on GHC2021 and be happy". Now I am at risk of the responses "But why not GHC2023?", "Haskell introduced a new, incompatible language just two years after standardising on GHC2021", "I just spent my precious time learning GHC2021, now I have to spend time learning GHC2023.". Sure, these responses are based on misunderstandings of the technical details. But perceptions really, really matter! If we want a large increase in Haskell usage then we have to take perceptions into account. We can't substantially increase Haskell usage any more by appealing just to our techncial excellence. If we choose to prioritise business-as-usual, that is, the incorporation of highly technically excellent features on a regular basis, with no thought to the costs, then the consequence will be Haskellers-as-usual: people who value that kind of thing in spite of the costs. We already have most of those people. We can't increase Haskell adoption that way. If we choose to change tack then we have the chance of changing the types of people we pick up as new Haskellers, from among those who would never otherwise have considered the language. To put it pithily, Joachim writes in a sibling thread "The point of the GHC20xx series is to get (proven, useful, uncontroversial) goodies into the hands of our users". Are members of the Haskell community, and indeed non-but-potential-members, screaming out for new "goodies"? Or are they screaming out for a brief respite from the unforgiving churn of the Haskell ecosystem, both real and not-real-but-perceived. My experience of the last ten years tells me it's the latter. To be clear, I personally am very much looking forward to more highly technically excellent features, including the exciting ongoing work on dependent types, WASM, GHCJS, and so on. It's one of the aspects of the community that really inspires and excites me! I personally can tolerate the churn. But I don't want those things at the *cost* of continuing to push away potential new users who are currently peering over the fence, discouraged because they can't tolerate the churn that they see, real or perceived. Now, with my stability hat on, looking from the point of view of process design, it's actually *better* for changes to happen in small increments, so maybe having GHC20xx every year is actually *better* than every five years. I don't wish to advocate for one choice or another. Rather I wish to advocate for the point of view that: Technical excellence matters. Stability and the perception of stability matter too. Tom On Tue, 1 Nov 2022 at 11:43, Simon Peyton Jones <simon.peytonjones(a)gmail.com> wrote: > Another year has passed, and if we are serious with the idea that >> GHC20xx is a continuous thing, we should probably start defining >> GHC2023 – even if it is just a small delta. >> > > Indeed, we originally said we'd review GHC20xx annually, but I think we > might want to consult the community to see if that is too often. There has > been an interesting thread > <https://discourse.haskell.org/t/quo-vadis-ghc2023/5220>on the Haskell > Discourse. > > The HF Stability Working Group discussed this on Monday, and I think Tom > Ellis (a member of the SWG) is willing to lead a consultation. I think > that would be great -- we have no axe to grind here, and I think we'll be > delighted to do whatever makes the maximal number of people happy. > > Tom (cc'd) will write with more info shortly. Sound OK? > > Simon > > On Mon, 24 Oct 2022 at 20:49, Joachim Breitner <mail(a)joachim-breitner.de> > wrote: > >> Hi Committee, >> >> when we defined the process for GHC20xx, as written in >> >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-g… >> we wrote >> >> Likely, the first iteration of this process will be vastly different >> from the following ones: The first one is expected to add a large >> number of uncontroversial extensions; so the next iteration will >> likely only make a smaller, but more controversial change. >> >> Therefore, this proposal does not commit to a fixed cadence. >> Instead, 6 months after the first release of a version of GHC that >> supports a GHC20xx set, we evaluate the outcome, the process, and >> the perceived need of a next release. At that time we will refine >> the processes, if needed, and set a cadence. >> >> The first version of GHC that supported GHC2021 was 9.2, released in >> October 2022. >> >> Last fall we said that not enough time has passed to do such an >> evaluation, and we skipped defining GHC2022. >> >> Another year has passed, and if we are serious with the idea that >> GHC20xx is a continuous thing, we should probably start defining >> GHC2023 – even if it is just a small delta. This e-mail tries to >> kickstart that process. >> >> >> Last time we did a relative elaborate thing where we voted on >> essentially _every_ extension. I think that made sense for the first >> iteration, where we had to winddow down the likely extensions. But now >> we have a base line (GHC2021), and are asked to find a suitable delta, >> and I’d go for a nomination-based approach: Committee members can >> propose adding (or removing, in theory) specific extensions, and then >> we vote only on those. Does that sound reasonable? >> >> Does anyone have any insight from the real world? Has GHC2021 helped >> our users? And if not, why not? >> >> What kind of hard data would you like to see, if any? >> >> (I’m a bit wary of spending too much time writing scripts to scrape >> hackage, for example to see which extensions people tend to enable _in >> addition_ to GHC2021, only to see that libraries on hackage are >> understandably slow to use default-language: GHC2021, as that’s not >> great for backward compat for now. But I am also not sure where to look >> for good data…)

6 21

Proposal #532: Clean up and simplify the treatment of implicit bindings. Recommendation: partially accept (maybe)
by Arnaud Spiwack 19 Jan '23

19 Jan '23

Dear all, Proposal https://github.com/ghc-proposals/ghc-proposals/pull/532 Rendered link for the proposal (although several other files are modified): https://github.com/Ericson2314/ghc-proposals/blob/type-variables/proposals/… John Ericson proposes to amend Richard's recent Modern Scoped Type Variables Proposal [ https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-t… ] There are two essential parts to the change: 1. The Explicit Binding Principle is modified 2. Change the two extensions introduced by Proposal #285 [ https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0285-n… ], -XImplicitForalls and -XPatternSignatureBinds (so that they can be deactivated), and consolidated in Richard's proposal (where -XPatternSignatureBinds is turned into a binding) into a single -XImplicitBinds extension --------- The new Explicit Binding Principle is now somewhat stronger, in that it requires that there is a form with an explicit binder which “regardless of the context, is unambiguously a binding site”. The Lexical Binding Principle is changed, as well, to refer to this new change but it's not substantial. I personally don't think this change to the principles is valuable, it simply blurs the distinction between the Explicit Binding Principle and the Lexical Binding Principle. I find the current phrasing more useful. And I don't think the semantics of the conjunction is actually changed. So I recommend that we reject the changes to the Principles. ------------ John makes a good point: `-XPatternSignature` being a warning has a limitation. This is pointed out in section “Unified Namespacing and extension monotonicity” of the patch to the Modern Scoped Type Variables Proposal. Namely that in t = Int (x :: t) = 0 The current semantics is to have `t` be a binder (because `t` is not bound in the type namespace). If we add a warning for pattern signatures binders, `t` will still be a binder. But we are starting to introduce a new semantics where failing to lookup `t` in the type namespace, we will fall back to look it up in the term namespace instead. The current semantics of considering `t` a binder in this case is at odds with the fallback strategy. (crucially for this recommendation, the same issue occurs in signatures where `forall`-s are implicitly inferred) (Context: At the time where #285 was proposed, I was in favour of a single extension. Simon PJ strongly pushed for two extensions.) My inclination today is that we have a choice: we can either - consider the problem above to be a serious issue, in which case we probably want to eventually deprecate both implicit foralls and pattern signature binds. If this is the case, then they should be gated behind an extension (see also the discussion on the meaning of extensions that we're currently having). I find it healthy to have a single extension for both features because the problem that the extension is solving is the same, hence, in this case, I recommend accepting the changes. - be happy that the semantics is a little quirky, with the fallback happening only when an explicit forall is specified (and never in pattern signatures). In which case both should probably be warnings, it makes sense for the warnings to be separate categories as these are two different features. In this case I recommend rejection of the proposed changes. ------------ I realise I'm leaving a big choice hanging. It's a big decision, I think, which we should weigh carefully (which is kind of funny because the proposed change itself is rather small). Personally, I'd be happy with all implicit foralls and pattern signature binds to be deprecated (so I'm actually taking a position I guess). But I'm not sure that it's super realistic considering the quantity of Haskell that has been written so far. I imagine that there are millions of implicit foralls on Hackage. PS: I'll be on holiday for the next three weeks (starting on Friday night), so you'll have a little while to debate this while I'm away.

2 2

Why not?, rather than, why?
by Joachim Breitner 03 Jan '23

03 Jan '23

Hello Committee and Community, occasionally we have meta-discussions about GHC language extensions: Should they be allowed to be fork-like, where some extensions are unlikely to be used together and some stay opt-in forever? Or should (ideally) every extension be on track to become on-by-default. Of course there are a few “old” extensions that by their very nature are not suitable to be on by default (SAFE, TRUSTWORTHY and CPP are the obvious candidates). Let’s put them aside for this discussion. I’d wager that if we’d introduce them these days, they wouldn’t be language extensions in the first place, but maybe modifiers on the module. I am mostly in the camp “every extension should be on track to become default (or be discarded)”. Once a language feature has been proven useful and reasonable stable, I see little value in requiring programmers to jump through hoops to use them. Is that the prevalent view here as well, or do we have a strong camp saying that our current “pick-and-choose” approach to language features is actually a good thing in its own (and not just a necessary nuisance)? If we assume the former, then maybe it would be worth to frame the discussion around new language extensions, and the discussion about which language extensions become default, around that vision. Concretely: * A new language proposal should not just be good enough for “worth building for those who explicitly turn it on”, but really ought convince as “this will make Haskell better for all” (and not just “a Haskell”). * Most new language features should probably not on by default initially, as usual, and are initially experimental. But then the proposal, and if accepted the documentation of the extension, should as explicit as possible explain why it is not yet default: What needs to happen for _this_ extension to be considered ready – or judged negatively and put on a track towards removal. This could be something like “been available for n releases, been stable for m releases”. (I wonder what other kind of criteria to expect here?) * The process for defining GHC20xx would then become very different: We’d go through all experimental extensions, check if the criteria are satisfied, maybe apply some common sense if the criteria are still good ones, and turn it on if so. This may turn the process to be more structured and maybe more predictable, and hopefully reduces the number of non-default extensions developers have to make a decision about (probably good). But it does raise the bar for new language features (is that good?). And, if applied consequently, it suggests to deprecate and eventually remove extensions that turn out to not be default-worthy after all (that’s kinda harsh)? As you can see I am a bit unsure about what the criteria are that we could put in the docs. Are they really different for different extensions? But the fact that its hard to come up right now with a concrete reason why extension X is not yet the default does point to a hole in our thinking and our process! And it is the same question that we face when discussing GHC20xx. So I guess what I am proposing here is: Have that discussion (when is it ready?) already when accepting a proposal, and document it in clear sight for our users, rather than have it over and over when debating GHC20xx. This is not a concrete (meta-)proposal, but hopefully tasty food for thought. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

7 22

#511 Deep Subsumption, recommendation: accept
by Spiwack, Arnaud 02 Jan '23

02 Jan '23

Dear all, The Deep Subsumption proposal [ https://github.com/ghc-proposals/ghc-proposals/pull/511 ] proposes a new extension, -XDeepSubsumption, which, when activated, partially reverts the changes from the Simplified Subsumption proposal. The Simplified Subsumption breaks more programs than anticipated. Many don't see any benefit from Simplified Subsumption, just the breakage, and don't like the eta-expansion that it forces. -XDeepSubsumption, when activated, restores deep skolemisation and co/contra-variance of the function arrow (but not deep instantiation, which doesn't affect the observed breakage). The patch already exists for it, and is about 400loc. There are two interesting highlights for me. - It is proposed that -XDeepSubsumption is activated by default in Haskell98 and Haskell2010, but not GHC2021. -XDeepSubsumption is orthogonal to Haskell2010, as far as I can tell, but it gives a cut-off point from which the recommended behaviour (-XNoDeepSubsumption) is the default. - Even with -XDeepSubsumption, the Quick Look algorithm assumes that the function arrow is invariant. The consequences of that are difficult to anticipate, but there is no known example of a bad behaviour due to that interaction yet. The authors also have one unresolved question that I'm bringing to the committee's attention: should `-XDeepSubsumption` be backported to GHC 9.2? --- Despite the fact that this extension is decidedly fork-like, and that it's a real possibility to see the community split around this (after all, the motivation for -XDeepSubsumption is a few libraries which were designed to leverage GHC's deep subsumption, and may very well stay that way in the foreseeable future). I recommend acceptance. Providing a path to backward compatibility seems to me like the right thing to do. I also recommend backporting to GHC 9.2. It should essentially be backward compatible, and providing an update path that doesn't go directly from 9.0 to 9.4 feels better to me.

5 8

#512: NoFieldSelectors as datatype annotation, Recommendation: reject
by Vladislav Zavialov 22 Dec '22

22 Dec '22

Dear Committee, Matt Parsons has proposed #512 "NoFieldSelectors as datatype annotation". Read it here: https://github.com/parsonsmatt/ghc-proposals/blob/matt/field-selectors-scop… Background: An older (accepted and implemented) GHC Proposal #160 "NoFieldSelectors" introduced a language extension flag to control whether top-level field selectors for record data types are generated. That is, when the programmer writes data R = MkR { fld :: Int }, shall we generate a top-level fld :: R -> Int or not? The answer in #160 is to make this controlled by the "FieldSelectors" language extension (enabled by default). Proposal Summary: In the new GHC Proposal #512, Matt argues that the control provided by the language extension introduced in #160 is insufficiently fine-grained, since it applies per-module, not per-definition. Matt has a use case where declarations are generated by Template Haskell and he would like to disable generation of field selectors for the generated declarations. The proposal introduces a new pragma-based annotation to declarations: data {-# NoFieldSelectors #-} R = MkR { fld :: Int } The proposal also introduces constructor-level and field-level annotations: data R = {-# NoFieldSelectors #-} MkR { fld :: Int } data R = MkR { fld :: {-# NoFieldSelectors #-} Int } Recommendation: I recommend rejecting this proposal on multiple grounds. 1. The first reason is the implementation (and maintenance) cost. GHC lacks generic infrastructure for pragmas, so every additional pragma means that we add at least the following: * special support in the parser (and the lexer) * data structures to represent it in the AST, together with TTG extension fields * data structures in the Template Haskell AST and the corresponding conversion logic between TH and GHC ASTs Maybe more, this is off the top of my head. And the proposal introduces not one but three places where a new pragma is allowed. This complexity needs to be justified. 2. The second reason is the existence of a more compelling alternative. I mentioned the lack of generic infrastructure for pragmas, but we do have an accepted proposal for generic annotations: it's #370 "Syntax for Modifiers". If the proposal switched to syntax introduced in #370, it would address the first objection. However, the author is unwilling to do so as long as #370 is not implemented (even though it's an accepted proposal). The author argues that we could switch to the modifiers syntax in the future, but it does not actually address my concern: if we get the pragma syntax, it's going to stay with us forever (that is how things typically work in GHC), and supporting *both* the pragma and modifiers would be worse still. 3. The third reason is ideological. Pragmas are syntactically similar to comments because (ideally) one should be able to ignore them. We use them to define rewrite rules, to mark fields unpacked, or to add cost centre annotations, because it only affects the performance/profiling, not the semantics of the code. But here, a pragma would affect what names are brought into scope, and as such, it shouldn't really be a pragma (syntactically). 4. The fourth reason is that an easy workaround is available. Just move declarations into a separate module with "NoFieldSelectors". I understand that it might be unsatisfactory and inconvenient, but it works and I'm weighing it against the maintenance cost mentioned in (1). To summarize, I'm not thrilled about adding a feature that (1) imposes maintenance costs on GHC, (2) could be done better, (3) uses inappropriate syntax, and (4) has a readily available workaround. I recognize the author's motivation but I believe their use case can be addressed in a more principled way using #370 Modifiers. Let me know what you think. Discussion period: 2 weeks. - Vlad

6 17

#451: WARNING pragma with category, Recommendation: accept
by Joachim Breitner 21 Dec '22

21 Dec '22

Dear all, Adam has submitted “WARNING pragmas with categories” for committee consideration: https://github.com/ghc-proposals/ghc-proposals/pull/541 https://github.com/adamgundry/ghc-proposals/blob/warning-pragmas/proposals/… I’m shepherding that one myself. WARNING pragmas can come with categories now: {-# WARNING [partial] head "This is a partial function, …" #-} so that one can sensible group them and allow the user to silence the warning (-Wno-x-partial) or make them errors (-Werror-x-partial), just like with the built-in warning categories. No language pragma is required (presumably since we are already in a GHC-specific pragma). These custom warnings categories need to be prefixed with `x-` on the command line to keep them separate from the built-in warnings. This is a decision where I am inviting the committee to bikeshed: * Do we really need a separator, or is it ok for library-defined warnings to join a built-in category? * Should it be used in syntax as well (WARNING [x-partial]) for easier predictability and later extension to other prefixes (see below)? All these custom warning categories are part of the severity group -Wdefault (on by default, not errors). I expect we eventually want to give the programmer control over the severity (off by default, error by default, part of -Wcompat, etc…), but it’s not immediately clear what to do here, so we can add it latter (another optional field in the pragma, a separate pragma, a naming convention like xe-foo, or something else). Please complain if you think this needs to be addressed here. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 11

Re: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept
by Joachim Breitner 15 Dec '22

15 Dec '22

(replying to the whole list, full quote) Am Donnerstag, dem 08.12.2022 um 11:23 +0300 schrieb Vladislav Zavialov: > I agree with your observation that namespaced imports are somewhat > different from simply specifying the namespace of a single name, so > they could be separated into their own extension. But if that is the > reasoning that we choose to follow, then the changes in #281 should > *definitely* go into their own extension: they affect not just names > but entire expressions and patterns, including their grammar (not > just namespacing). > > The only reason the changes in #270 and #281 are included in > ExplicitNamespaces is to reduce the amount of language flags. If you > prefer fine-grained control and immutable extensions, then both of > those changes need separate flags for them. > > So, if we are consistent, we have two options: > 1. Include changes in #270 and #281 in ExplicitNamespaces on the > grounds that they include explicitly specify a namespace (even though > that is not the only thing they do) > 2. Create separate language extension flags: NamespacedImports and > TypesInExpressions (names to be discussed) > > I happen to prefer (1), and that is the approach that the proposals > currently follow, but I am not opposed to (2) either. I don’t prefer fine-grained flags per se. In fact, my ideal world is one perfect language with no flags :-). So I think I’d prefer all under ExplicitNamespaces as well, and I think the only reason I am hesitant is that I believe the old ExplicitNamespaces should have been in GHC2021, so it should be in GHC2023, and am unsure if the (comprehensive) ExplicitNamespaces should be there. This gives us (at least) these options: 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, introduce one or two new extensions for the newer changes. 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, disregarding issue #551. 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, arguing that GHC20xx allows more liberal (backward-compatibile) changes than, say, Haskell2010 would allow. Certainly 1 is the least bold move. I am not sure what the best way forwards is, and welcome other opinions. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

6 17

Re: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept
by Adam Gundry 12 Dec '22

12 Dec '22

(Simon, I'm guessing this message should have gone to the committee list, so I'm including the full text below.) On 12/12/2022 13:04, Simon Peyton Jones wrote: > > The nested use is already possible with ExplicitNamespaces. > Currently it > > > Wow. I had no idea. The user manual is entirely silent on this point > <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/explicit_namespaces…>. > Is there some proposal that specifies this behaviour, which the user > manual is failing to document? Or is the implementation doing > something that is nowhere specified? > > I'm trying to understand what `import M type (MkT)` does > > > Well the proposal says > # With |type| specified in the import, only identifiers belonging to the > type namespace will be brought into the scope. > I took this saying "behave exactly as now, but post-filter the imports > to take only the ones from the type namespace". Today `import M( MkT > )` will be rejected; so I assume it'll still be rejected. > > I agree that this point could be more clearly articulated. > > Simon > > On Mon, 12 Dec 2022 at 12:22, Adam Gundry <adam(a)well-typed.com> wrote: > > On 12/12/2022 11:39, Simon Peyton Jones wrote: > > {-# LANGUAGE ExplicitNamespaces #-} > > module N where > > import M (T(type MkT)) -- NB "type" import of a data > constructor > > v = MkT -- usage at term level > > > > > > Crumbs. I had not realised the proposal is to allow *nested* > uses of > > 'type' in import lists, as you show above. > > The nested use is already possible with ExplicitNamespaces. > Currently it > allows > > import M (T(type MkT)) > import M (type MkT) > import M (pattern MkT) > > whereas the proposal extends it to add the possibility to write > > import M type (MkT) > import M data (MkT) > import M (data MkT) > > > > In general, I don't feel the extensions to > ExplicitNamespaces included > > in the proposal are very clearly specified. > > > > > > Actually isn't the proposal pretty clear on this, namely the first > > bullet of proposed change spec > > > <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support…>. > It only covers > > import M *type * > > import M *data *as MD > > where I have emboldened the new bits. Nothing about the > contents of > > import lists. Why did you think your example is covered by the > proposal? > > I'm trying to understand what > > import M type (MkT) > > means where MkT is a data constructor (or if it raises some kind of > error). This was by analogy to the existing > > import M (T(type MkT)) > > which means something today, albeit not necessarily a very sensible > thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581) > > I don't see a clear specification of the proposed (extended) > semantics > of ExplicitNamespaces in the proposal, but perhaps I've missed > something? > > Cheers, > > Adam > > > > On Mon, 12 Dec 2022 at 09:15, Adam Gundry <adam(a)well-typed.com > > <mailto:adam@well-typed.com>> wrote: > > > > Actually, reading > https://gitlab.haskell.org/ghc/ghc/-/issues/22581 > > <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> I > > realised I'm unclear how the proposed extensions to > ExplicitNamespaces > > are supposed to work. The existing situation is apparently > that for a > > (non-punned) data constructor, it is possible to use either a > > pattern or > > type qualifier in an import list (presumably because > DataKinds means > > the > > constructor is in scope at both the term and type levels), > and the > > imported constructor is then usable in both contexts. > > > > For example, the following is accepted at present: > > > > module M where > > data T = MkT > > > > {-# LANGUAGE ExplicitNamespaces #-} > > module N where > > import M (T(type MkT)) -- NB "type" import of a data > constructor > > v = MkT -- usage at term level > > > > The present proposal says "With type specified in the > import, only > > identifiers belonging to the type namespace will be brought > into the > > scope." I'm not exactly sure how to interpret this, does it > mean the > > following alternative will be accepted or rejected? > > > > module N where > > import M type (MkT) > > v = MkT > > > > I'm worried we will end up with a situation where > ExplicitNamespaces > > does subtly different things depending on the position of > the keyword. > > > > In general, I don't feel the extensions to > ExplicitNamespaces included > > in the proposal are very clearly specified. Given the > discussion about > > exactly which parts belong to > ExplicitNamespaces/PatternSynonyms versus > > separate extensions, perhaps we should accept the parts > relating to > > -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces > changes to be > > proposed separately? > > > > Cheers, > > > > Adam > > > > > > On 09/12/2022 11:11, Adam Gundry wrote: > > > I'm broadly in favour of accepting the proposal. I > realise the > > history > > > is complex here, so I don't think we should ask anyone to > rewrite > > things > > > further, though in general it would be nicer to have separate > > proposals > > > for -Wpuns/-Wpun-bindings (which is unambiguously fine) > and for the > > > changes to imports (which as Joachim points out raise > issues). > > > > > > I'm a bit concerned that the proposal does not motivate > or specify > > > -Wpattern-namespace-qualified very well. > > > > > > > > > On 08/12/2022 08:33, Joachim Breitner wrote: > > >> ... > > >> > > >> This gives us (at least) these options: > > >> > > >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to > > GHC2023, > > >> introduce one or two new extensions for the newer > changes. > > >> 2. Extend ExplicitNamespaces, and don’t add it already > to GHC2023, > > >> disregarding issue #551. > > >> 3. Add ExplicitNamespaces to GHC2023, and still add it > to GHC2023, > > >> arguing that GHC20xx allows more liberal > (backward-compatibile) > > >> changes than, say, Haskell2010 would allow. > > >> > > >> Certainly 1 is the least bold move. I am not sure what > the best way > > >> forwards is, and welcome other opinions. > > > > > > I would prefer a variant of 1: allow "data" as a keyword in > > import lists > > > under ExplicitNamespaces, but make the other changes > under other > > > extensions. > > > > > > As I've said previously, I have a general preference for > multiple > > small, > > > orthogonal extensions rather than changing existing > extensions to > > add > > > unrelated features that happen to be in similar > territory. I realise > > > this is controversial, of course. > > > > > > Cheers, > > > > > > Adam > -- 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

1 0

#556: multiple type variables in signatures in type applications in patterns, Recommendation: accept
by Joachim Breitner 09 Dec '22

09 Dec '22

Dear all, Vlad has submitted a bug fix amendment to #448, to fix the wording around type variables in signatures within explicit type annotations: https://github.com/ghc-proposals/ghc-proposals/pull/556/files I’m shepherding that one myself. The gist is that in data Proxy a = P g :: Proxy (Nothing @(a, a)) -> () g (P @(Nothing :: Maybe (x, x))) = () the multiple occurrences of `a` are non-linear patterns and disallowed, but the multiple patterns of `x` are fine, because that’s how type variables in signatures in patterns happen to work. Vlad fixed the wording with regard to that in #448. Simon and Richard already signaled support on the Github thread, which I recommend to follow. I don’t expect much further discussion around this and will happily merge after a week of silence (or after one or two additional confirmations). Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 1