From arnaud.spiwack at tweag.io Mon Mar 3 06:52:27 2025 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Mon, 3 Mar 2025 15:52:27 +0900 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: <20250205191643.60ec5f23d8b4571b8cf14ece@mega-nerd.com> <20250207100114.c0dd8b72c6dc9167a58bff43@mega-nerd.com> Message-ID: There may have been delivery issues last week to the committee mailing list. Did everybody get this email by Simon and mine below? On Fri, 21 Feb 2025 at 17:23, Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > Syntax is always troublesome, and best resolved by a vote. I think you > are asking us to vote on: > > - (A) splice/quote keywords only before the module name > - (B) splice/quote keywords either before or after the module name > > I vote (A). My opinion is not a strong one. Let's see what other > committee members think. RSVP > > Simon > > On Fri, 21 Feb 2025 at 07:17, Arnaud Spiwack > wrote: > >> So, let me recap the situation. >> >> The authors favourite syntax is >> `import splice A` >> `import quote B` >> >> But some community members in the thread (most vocally Matt Parsons, e.g. >> here >> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2651558160 >> ) feel that there should be more options, that is that all of >> `import splice A` / `import A splice` >> `import quote B` / `import A quote` >> >> Be available, lest people prefer the right-hand positions and do a >> proposal to add an extra extension later. >> >> The authors are ok (but evidently not ecstatic >> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2671436455 >> ) with allowing both positions for their keyword. It turns out not to be >> too big of a hassle to implement. Which I propose to be the resolution. >> Very non-committal on our part, but because it isn't costly, we might as >> well. >> >> This hasn't been a very busy thread, so… let me backtrack: I'll be on >> holiday next week, so I'll accept the changes as I'm back, this means that >> you have one week to disagree. Now, this hasn't been a very busy thread so >> I expect nobody has strong opinions. But, let me propose a protocol. If >> (and only if) someone is of the strong opinion that only in front is a much >> better solution. Let them state “I strongly think that `import splice A` >> should be the only syntax`. One of us says that, let each of you vote, I'll >> tally the vote when I'm back. >> >> PS: I'm excluding only `import A splice` as an option because the authors >> don't want that and it would require an overwhelming majority to force that >> on the authors, which evidently doesn't exist, so let's not muddy the >> water. So the two options are “only in front” and “both position” >> >> >> Speak to you all in a week, >> Arnaud >> >> On Fri, 14 Feb 2025 at 14:19, Arnaud Spiwack >> wrote: >> >>> There's a little bit of a debate going on in the Github thread on the >>> topic of syntax. I'll give this one one last push. If the authors decide >>> that they are ok with specifying the keywords before and after the module >>> name, then we can accept immediately, as there's no voice against this. >>> Otherwise I'll recapitulate everybody's argument here and call for a quick >>> vote. >>> >>> On Mon, 10 Feb 2025 at 15:25, Arnaud Spiwack >>> wrote: >>> >>>> For the record, the syntactic alternatives can be found in [§8.5 >>>> Syntactic alternatives]( >>>> https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/proposals/0000-splice-imports.rst#syntactic-alternatives >>>> ) >>>> >>>> Malte seems to be uncomfortable with the fact that the proposed syntax >>>> is >>>> >>>> import slice Foo >>>> import quote Bar >>>> >>>> Even when ImportQualifiedPost, which enables the syntax >>>> >>>> import Foo qualified [as …] >>>> >>>> is enabled. >>>> >>>> The proposal offers alternative syntaxes like >>>> >>>> import Foo slice >>>> Import Bar quote >>>> >>>> or (to sound more English) >>>> >>>> import Foo for slice >>>> import Bar for quote >>>> >>>> Richard Eisenberg, in the thread, suggests that the motivation for >>>> ImportQualifiedPost doesn't apply to slice/quote because he believes that >>>> there's going to be one block of import slice, one block of import >>>> (nothing), one block of import quote, and they aren't going to be mixed >>>> together. Them being more visually distinguished by starting with the >>>> keyword is an asset in this view. Many seem convinced >>>> >>>> My understanding of Malte's point is that this is not intuitive enough >>>> that it can be left implicit in the proposal, and he'd like the proposal to >>>> at least state explicitly that it ignores ImportQualifiedPost. >>>> >>>> Malte, let me know if I misrepresent your point of view (or anybody >>>> else's). >>>> >>>> On Sat, 8 Feb 2025 at 01:19, Simon Peyton Jones < >>>> simon.peytonjones at gmail.com> wrote: >>>> >>>>> I don’t think we were finished >>>>> with bikeshedding the syntax. At least I think the proposal should >>>>> state what >>>>> the syntax is when ImportQualifiedPost is enabled and voiced that on >>>>> the GitHub >>>>> thread. >>>>> >>>>> >>>>> OK -- but I suspect that most of us have lost context. >>>>> >>>>> Would you like to post (on the Github) a message explaining: >>>>> >>>>> - what the syntactic alternatives are >>>>> - what you recommend >>>>> >>>>> That will help to focus the discussion >>>>> >>>>> Thanks! >>>>> >>>>> Simon >>>>> >>>>> >>>>> On Fri, 7 Feb 2025 at 12:16, Malte Ott wrote: >>>>> >>>>>> I do not object to accepting the proposal, but I don’t think we were >>>>>> finished >>>>>> with bikeshedding the syntax. At least I think the proposal should >>>>>> state what >>>>>> the syntax is when ImportQualifiedPost is enabled and voiced that on >>>>>> the GitHub >>>>>> thread. >>>>>> >>>>>> I know we all dread wasting our time with syntax discussions but lets >>>>>> at least >>>>>> think about it for 5 minutes. >>>>>> >>>>>> Best, >>>>>> Malte >>>>>> >>>>>> On 2025-02-07 15:48, Arnaud Spiwack wrote: >>>>>> > Ok, we have enough of a quorum at this point. If everybody else >>>>>> voted 1 >>>>>> > extension this would come at a rough draw. It can't be a strong >>>>>> enough >>>>>> > push to overrule the preference of the authors. >>>>>> > >>>>>> > I'll give it a handful more day, say until next Wednesday 12th >>>>>> > February. If someone has a strong objection, please voice it very >>>>>> > loudly. Otherwise I'll declare the proposal as accepted in its >>>>>> current >>>>>> > state. >>>>>> > >>>>>> > Best, >>>>>> > Arnaud >>>>>> > >>>>>> > On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo >>>>>> > <[1]erikd at mega-nerd.com> wrote: >>>>>> > >>>>>> > OK, slightly in favor of two extensions. >>>>>> > >>>>>> > Erik >>>>>> > >>>>>> > Erik de Castro Lopo wrote: >>>>>> > >>>>>> > > Hi, >>>>>> > > >>>>>> > > I have read through the proposal, but there is something I am >>>>>> > still unsure >>>>>> > > of. For the LANGUAGE pragma's is there any utility in using >>>>>> one >>>>>> > separately >>>>>> > > form the other? It seems there isn't. In any one file you >>>>>> would >>>>>> > use either >>>>>> > > one or the other. >>>>>> > > >>>>>> > > Thanks, >>>>>> > > Erik >>>>>> > > >>>>>> > > Arnaud Spiwack wrote: >>>>>> > > >>>>>> > > > Sorry I disappeared for a while. I second Simon's call, >>>>>> let's >>>>>> > vote. Let me >>>>>> > > > repost a link to Simon's pro and cons post >>>>>> > > > >>>>>> > [2] >>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm >>>>>> > ent-2609199731 >>>>>> > > > >>>>>> > > > So far, we have the following votes >>>>>> > > > >>>>>> > > > - Simon: 1 extension >>>>>> > > > - Adam: 2 extension (feels quite strongly about it) >>>>>> > > > - Sebastian: 1 extension (on the Github thread, but I'll >>>>>> count >>>>>> > it as a vote >>>>>> > > > anyway) >>>>>> > > > >>>>>> > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you >>>>>> think? >>>>>> > > > >>>>>> > > > --- >>>>>> > > > >>>>>> > > > Beyond that we have a single piece of community feedback >>>>>> on the >>>>>> > Github >>>>>> > > > thread. It's from Michael Peyton Jones who is in favour of >>>>>> 2 >>>>>> > extensions, >>>>>> > > > find it here >>>>>> > > > >>>>>> > [3] >>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm >>>>>> > ent-2609583126 >>>>>> > > > >>>>>> > > > --- >>>>>> > > > >>>>>> > > > For the record, I hadn't commented about it in my >>>>>> > recommendation, despite >>>>>> > > > my well-known and desperately public distaste for micro >>>>>> > extensions. I have >>>>>> > > > a couple of reasons: >>>>>> > > > - I dislike micro-extensions less now that we are doing the >>>>>> > GHC20XX (the >>>>>> > > > last one was very modest, I'm in favour, by the way, of >>>>>> doing a >>>>>> > much more >>>>>> > > > ambitious language edition soon, otherwise my distaste >>>>>> will come >>>>>> > back with >>>>>> > > > a vengeance) >>>>>> > > > - While I consider every proposal with several extensions >>>>>> in it >>>>>> > with >>>>>> > > > suspicion, the authors did argue for their second >>>>>> extension, I >>>>>> > found the >>>>>> > > > argument mildly convincing, and thought it wasn't worth >>>>>> fighting >>>>>> > against. >>>>>> > > > >>>>>> > > > Now, even like this my preference is mildly for one >>>>>> extension. >>>>>> > Adam says >>>>>> > > > that it's easier to implement warnings with both the new >>>>>> syntax >>>>>> > on and >>>>>> > > > implicit stage persistence left turned on, than to >>>>>> implement >>>>>> > errors when >>>>>> > > > implicit stage persistence is turned off. It may be so, >>>>>> but I >>>>>> > don't think >>>>>> > > > we can avoid implementing the errors anyway, so I don't >>>>>> feel >>>>>> > that it's a >>>>>> > > > particularly compelling argument. I don't feel strongly. >>>>>> But >>>>>> > that's >>>>>> > > > presumably where my vote goes. >>>>>> > > > >>>>>> > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones >>>>>> > <[4]simon.peytonjones at gmail.com> >>>>>> > > > wrote: >>>>>> > > > >>>>>> > > > > Yes: all members of the steering committee, please vote. >>>>>> > Evaluating >>>>>> > > > > proposals is what we all signed up to do! >>>>>> > > > > >>>>>> > > > > Thanks >>>>>> > > > > >>>>>> > > > > Simon >>>>>> > > > > >>>>>> > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry >>>>>> > <[5]adam at well-typed.com> wrote: >>>>>> > > > > >>>>>> > > > >> I'm (unsurprisingly) in favour of acceptance, and I >>>>>> vote for >>>>>> > two >>>>>> > > > >> extensions. As I commented on the GitHub thread: >>>>>> > > > >> >>>>>> > > > >> > We shouldn't unnecessarily conflate a syntactic >>>>>> extension >>>>>> > > > >> (ExplicitLevelImports) with a semantic one >>>>>> > (NoImplicitStagePersistence) >>>>>> > > > >> just because the common case is to want both and we >>>>>> want to >>>>>> > keep the >>>>>> > > > >> number of extensions lower. >>>>>> > > > >> >>>>>> > > > >> If there are reasons why having two extensions is >>>>>> actually >>>>>> > problematic, >>>>>> > > > >> I'd like to hear them. >>>>>> > > > >> >>>>>> > > > >> Also, at the risk of opening another avenue of >>>>>> discussion, we >>>>>> > also need >>>>>> > > > >> to resolve the syntax question (see >>>>>> > > > >> >>>>>> > > > >> >>>>>> > [6] >>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio >>>>>> > n_r1849123243). >>>>>> > > > >> >>>>>> > > > >> I don't have a very strong opinion here, but given that >>>>>> some >>>>>> > people do, >>>>>> > > > >> perhaps we should make ImportQualifiedPost affect splice >>>>>> > imports so we >>>>>> > > > >> have >>>>>> > > > >> >>>>>> > > > >> import splice qualified A -- By default >>>>>> > > > >> import A splice qualified -- Under ImportQualifiedPost >>>>>> > > > >> >>>>>> > > > >> In any case, please do vote! It would be good to get >>>>>> this >>>>>> > proposal done. >>>>>> > > > >> >>>>>> > > > >> Cheers, >>>>>> > > > >> >>>>>> > > > >> Adam >>>>>> > > > >> >>>>>> > > > >> >>>>>> > > > >> >>>>>> > > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: >>>>>> > > > >> > Arnaud >>>>>> > > > >> > >>>>>> > > > >> > OK, following my call and some further iteration, the >>>>>> > proposal is much >>>>>> > > > >> > improved. See here >>>>>> > > > >> > >>>>>> > <[7]https://github.com/ghc-proposals/ghc-proposals/pull/682>. >>>>>> > Please >>>>>> > > > >> read >>>>>> > > > >> > the new "Proposed Change Specification" which has had >>>>>> a >>>>>> > large rewrite. >>>>>> > > > >> > >>>>>> > > > >> > I vote to accept. >>>>>> > > > >> > >>>>>> > > > >> > BUT there is one point that the committee must >>>>>> resolve: >>>>>> > *one extension >>>>>> > > > >> > of two?* It's just a judgement call and I lay out the >>>>>> > choices in this >>>>>> > > > >> > post >>>>>> > > > >> > < >>>>>> > > > >> >>>>>> > [8] >>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm >>>>>> > ent-2609199731>. >>>>>> > > > >> I doubt that we'll get much community feedback. I >>>>>> suggest >>>>>> > that we just >>>>>> > > > >> vote. I vote for one, not two. As does Sebastian. >>>>>> > > > >> > >>>>>> > > > >> > Over to you Arnaud. Let's get this one done. Matthew >>>>>> is >>>>>> > busy >>>>>> > > > >> > implementing it for a customer and it has been on our >>>>>> to-do >>>>>> > list for >>>>>> > > > >> > some time now. (Partly my fault.) >>>>>> > > > >> > >>>>>> > > > >> > Simon >>>>>> > > > >> > >>>>>> > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones >>>>>> > > > >> > <[9]simon.peytonjones at gmail.com >>>>>> > > >>>>>> > > > >> wrote: >>>>>> > > > >> > >>>>>> > > > >> > Matthew and I had a good conversation. Some notes >>>>>> here >>>>>> > > > >> > < >>>>>> > > > >> >>>>>> > [11] >>>>>> https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R >>>>>> > Phk5MslruY7yXD0/edit?usp=sharing >>>>>> > > > >> >. >>>>>> > > > >> > >>>>>> > > > >> > He's going to work on a revision to the proposal >>>>>> which >>>>>> > I'll iterate >>>>>> > > > >> > with him. >>>>>> > > > >> > >>>>>> > > > >> > Simon >>>>>> > > > >> > >>>>>> > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack >>>>>> > > > >> > <[12]arnaud.spiwack at tweag.io >>>>>> > > wrote: >>>>>> > > > >> > >>>>>> > > > >> > Then, let's wait until your call with Matthew >>>>>> and >>>>>> > decide how to >>>>>> > > > >> > act then. >>>>>> > > > >> > >>>>>> > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton >>>>>> Jones >>>>>> > > > >> > <[14]simon.peytonjones at gmail.com >>>>>> > > > >> > > >>>>>> wrote: >>>>>> > > > >> > >>>>>> > > > >> > Arnaud >>>>>> > > > >> > >>>>>> > > > >> > I have responded with a lot of feedback >>>>>> on the >>>>>> > Github thread >>>>>> > > > >> > < >>>>>> > > > >> >>>>>> > [16] >>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ >>>>>> > estreview-2562175116 >>>>>> > > > >> >. >>>>>> > > > >> > >>>>>> > > > >> > TL:DR: I like the direction of travel but >>>>>> have >>>>>> > too many >>>>>> > > > >> > questions of detail to be ready to accept >>>>>> it >>>>>> > just yet. >>>>>> > > > >> > >>>>>> > > > >> > I have arranged a call with Matthew. >>>>>> > > > >> > >>>>>> > > > >> > Simon >>>>>> > > > >> > >>>>>> > > > >> > On Thu, 9 Jan 2025 at 06:31, Arnaud >>>>>> Spiwack >>>>>> > > > >> > <[17]arnaud.spiwack at tweag.io >>>>>> > > >>>>>> > > > >> > wrote: >>>>>> > > > >> > >>>>>> > > > >> > >>>>>> > > > >> > Mathew Pickering, Rodrigo Mesquita, >>>>>> and our >>>>>> > own Adam >>>>>> > > > >> > Gundry put forward a new proposal for >>>>>> the >>>>>> > perenial >>>>>> > > > >> > problem of dependencies and Template >>>>>> > Haskell >>>>>> > > > >> > >>>>>> > [19]https://github.com/ghc-proposals/ghc-proposals/pull/682 >>>>>> > > > >> > < >>>>>> > > > >> [20] >>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682> >>>>>> > > > >> > >>>>>> > > > >> > I've got to be honest, I'm not fully >>>>>> > convinced by the >>>>>> > > > >> > proposal. More on that in a minute, >>>>>> but it >>>>>> > learns a >>>>>> > > > >> > lesson from previous attempts at the >>>>>> same >>>>>> > problem by >>>>>> > > > >> > solving the absolute minimal problem, >>>>>> but >>>>>> > this leads to >>>>>> > > > >> > a somewhat fork-like situation for >>>>>> which it >>>>>> > isn't clear >>>>>> > > > >> > whether it will be resolved in the >>>>>> future. >>>>>> > That being >>>>>> > > > >> > said, it solves a real problem which >>>>>> has >>>>>> > plagued GHC >>>>>> > > > >> > compilation forever. And I'm inclined >>>>>> to >>>>>> > believe that we >>>>>> > > > >> > can't really do much better. >>>>>> > > > >> > >>>>>> > > > >> > But I'm getting ahead of myself. The >>>>>> > problem is that >>>>>> > > > >> > when you have -XTemplateHaskell in a >>>>>> file, >>>>>> > all the >>>>>> > > > >> > dependencies' compiled code must >>>>>> suddenly >>>>>> > be available >>>>>> > > > >> > for typechecking. This breaks >>>>>> `-fno-code` >>>>>> > and wounds >>>>>> > > > >> > recompilation avoidance. This is >>>>>> probably >>>>>> > the main >>>>>> > > > >> > reason why it's a widely held belief >>>>>> that >>>>>> > Template >>>>>> > > > >> > Haskell is slow: you use Template >>>>>> Haskell >>>>>> > in a few >>>>>> > > > >> > modules, and suddenly your IDE is >>>>>> much less >>>>>> > responsive >>>>>> > > > >> > and you recompile more files. Yay? >>>>>> > > > >> > >>>>>> > > > >> > Anyway, the general gist of the >>>>>> solution is >>>>>> > clear: we >>>>>> > > > >> > must be able to specify that we don't >>>>>> want >>>>>> > to import a >>>>>> > > > >> > module for Template Haskell (there is >>>>>> > subtleties in this >>>>>> > > > >> > too as you will want a little more >>>>>> control >>>>>> > than that for >>>>>> > > > >> > cross-compilation reasons which I'm >>>>>> not >>>>>> > competent about >>>>>> > > > >> > to comment on). But the devil is in >>>>>> the >>>>>> > many details. >>>>>> > > > >> > There's this thing called implicit >>>>>> > cross-stage >>>>>> > > > >> > persistence which says that anything >>>>>> you >>>>>> > import >>>>>> > > > >> > not-for-template-haskell is going to >>>>>> be >>>>>> > available in >>>>>> > > > >> > quotes and splices anyway. Sigh… So >>>>>> you >>>>>> > have to turn >>>>>> > > > >> > this off. This is what the proposal >>>>>> does. >>>>>> > And pretty >>>>>> > > > >> > much only. >>>>>> > > > >> > >>>>>> > > > >> > They introduce a new >>>>>> > > > >> > extension-XNoImplicitStagePersistence >>>>>> which >>>>>> > disables >>>>>> > > > >> > that, and a little bit of syntax to >>>>>> specify >>>>>> > the stage of >>>>>> > > > >> > imports. That's it. >>>>>> > > > >> > >>>>>> > > > >> > But it comes with severe limitations, >>>>>> most >>>>>> > importantly: >>>>>> > > > >> > you can't ever use a symbol defined >>>>>> in the >>>>>> > current >>>>>> > > > >> > module in a quote or splice of this >>>>>> current >>>>>> > module, >>>>>> > > > >> > typed template Haskell is turned off. >>>>>> > > > >> > >>>>>> > > > >> > For these situations, the proposal >>>>>> kind of >>>>>> > advertises >>>>>> > > > >> > using `-XImplicitStagePersistence`. >>>>>> Which >>>>>> > does seem like >>>>>> > > > >> > a fork-like situation to me. Not >>>>>> cool. Yet… >>>>>> > yet Template >>>>>> > > > >> > Haskell is a big messy ball of yarn, >>>>>> and I >>>>>> > don't think >>>>>> > > > >> > it's fair to ask of any proposal to >>>>>> > entangle it >>>>>> > > > >> > completely. The failure of past >>>>>> attempts >>>>>> > seem to support >>>>>> > > > >> > this case. And I believe the authors >>>>>> are >>>>>> > correct when >>>>>> > > > >> > they claim that this proposal, in >>>>>> practice, >>>>>> > covers a >>>>>> > > > >> > vast majority of the uses of Template >>>>>> > Haskell out there. >>>>>> > > > >> > So maybe we can see that as a new >>>>>> > foundation for >>>>>> > > > >> > Template Haskell. I'm not thrilled >>>>>> about >>>>>> > it, but it's >>>>>> > > > >> > probably the most reasonable way >>>>>> forward. >>>>>> > > > >> > >>>>>> > > > >> > The real problem with this sort of >>>>>> proposal >>>>>> > is that then >>>>>> > > > >> > I get to write way too long an email >>>>>> to the >>>>>> > committee. >>>>>> > > > >> > Hopefully this didn't deter you. Read >>>>>> the >>>>>> > proposal, and >>>>>> > > > >> > let's vote. >>>>>> > > > >> > >>>>>> > > > >> > -- >>>>>> > > > >> > Arnaud Spiwack >>>>>> > > > >> > Director, Research at >>>>>> > [21]https://moduscreate.com >>>>>> > > > >> > <[22]https://moduscreate.com> and >>>>>> > [23]https://tweag.io >>>>>> > > > >> > <[24]https://tweag.io>. >>>>>> > > > >> >>>>>> > > > >> >>>>>> > > > >> -- >>>>>> > > > >> Adam Gundry, Haskell Consultant >>>>>> > > > >> Well-Typed LLP, [25]https://www.well-typed.com/ >>>>>> > > > >> >>>>>> > > > >> Registered in England & Wales, OC335890 >>>>>> > > > >> 27 Old Gloucester Street, London WC1N 3AX, England >>>>>> > > > >> >>>>>> > > > >> _______________________________________________ >>>>>> > > > >> ghc-steering-committee mailing list >>>>>> > > > >> [26]ghc-steering-committee at haskell.org >>>>>> > > > >> >>>>>> > [27] >>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c >>>>>> > ommittee >>>>>> > > > >> >>>>>> > > > > _______________________________________________ >>>>>> > > > > ghc-steering-committee mailing list >>>>>> > > > > [28]ghc-steering-committee at haskell.org >>>>>> > > > > >>>>>> > [29] >>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c >>>>>> > ommittee >>>>>> > > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > -- >>>>>> > > > Arnaud Spiwack >>>>>> > > > Director, Research at [30]https://moduscreate.com and >>>>>> > [31]https://tweag.io. >>>>>> > > >>>>>> > > >>>>>> > > -- >>>>>> > > >>>>>> > >>>>>> -------------------------------------------------------------------- >>>>>> > -- >>>>>> > > Erik de Castro Lopo >>>>>> > > [32]http://www.mega-nerd.com/ >>>>>> > > >>>>>> > >>>>>> > -- >>>>>> > >>>>>> -------------------------------------------------------------------- >>>>>> > -- >>>>>> > Erik de Castro Lopo >>>>>> > [33]http://www.mega-nerd.com/ >>>>>> > _______________________________________________ >>>>>> > ghc-steering-committee mailing list >>>>>> > [34]ghc-steering-committee at haskell.org >>>>>> > [35] >>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c >>>>>> > ommittee >>>>>> > >>>>>> > -- >>>>>> > >>>>>> > Arnaud Spiwack >>>>>> > Director, Research at [36]https://moduscreate.com and >>>>>> > [37]https://tweag.io. >>>>>> > >>>>>> > References >>>>>> > >>>>>> > 1. mailto:erikd at mega-nerd.com >>>>>> > 2. >>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 >>>>>> > 3. >>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126 >>>>>> > 4. mailto:simon.peytonjones at gmail.com >>>>>> > 5. mailto:adam at well-typed.com >>>>>> > 6. >>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243 >>>>>> > 7. https://github.com/ghc-proposals/ghc-proposals/pull/682 >>>>>> > 8. >>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 >>>>>> > 9. mailto:simon.peytonjones at gmail.com >>>>>> > 10. mailto:simon.peytonjones at gmail.com >>>>>> > 11. >>>>>> https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing >>>>>> > 12. mailto:arnaud.spiwack at tweag.io >>>>>> > 13. mailto:arnaud.spiwack at tweag.io >>>>>> > 14. mailto:simon.peytonjones at gmail.com >>>>>> > 15. mailto:simon.peytonjones at gmail.com >>>>>> > 16. >>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116 >>>>>> > 17. mailto:arnaud.spiwack at tweag.io >>>>>> > 18. mailto:arnaud.spiwack at tweag.io >>>>>> > 19. https://github.com/ghc-proposals/ghc-proposals/pull/682 >>>>>> > 20. https://github.com/ghc-proposals/ghc-proposals/pull/682 >>>>>> > 21. https://moduscreate.com/ >>>>>> > 22. https://moduscreate.com/ >>>>>> > 23. https://tweag.io/ >>>>>> > 24. https://tweag.io/ >>>>>> > 25. https://www.well-typed.com/ >>>>>> > 26. mailto:ghc-steering-committee at haskell.org >>>>>> > 27. >>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>>>> > 28. mailto:ghc-steering-committee at haskell.org >>>>>> > 29. >>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>>>> > 30. https://moduscreate.com/ >>>>>> > 31. https://tweag.io/ >>>>>> > 32. http://www.mega-nerd.com/ >>>>>> > 33. http://www.mega-nerd.com/ >>>>>> > 34. mailto:ghc-steering-committee at haskell.org >>>>>> > 35. >>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>>>> > 36. https://moduscreate.com/ >>>>>> > 37. https://tweag.io/ >>>>>> >>>>>> > _______________________________________________ >>>>>> > 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 >>>>> >>>> >>>> >>>> -- >>>> Arnaud Spiwack >>>> Director, Research at https://moduscreate.com and https://tweag.io. >>>> >>> >>> >>> -- >>> Arnaud Spiwack >>> Director, Research at https://moduscreate.com and https://tweag.io. >>> >> >> >> -- >> Arnaud Spiwack >> Director, Research at https://moduscreate.com and https://tweag.io. >> > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From malte.ott at maralorn.de Mon Mar 3 10:03:53 2025 From: malte.ott at maralorn.de (Malte Ott) Date: Mon, 3 Mar 2025 11:03:53 +0100 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: <20250205191643.60ec5f23d8b4571b8cf14ece@mega-nerd.com> <20250207100114.c0dd8b72c6dc9167a58bff43@mega-nerd.com> Message-ID: I for my part are kinda dissatisfied by both options. And I am very much sympathetic to the position that a committee shouldn’t settle alternatives by allowing all of them. That being said I am still in favor of leaving the proposal like it is now, which is (B). My dream would be to rename ImportQualifiedPost to ImportAnnotationsPost or something similar and then treat splice exactly as qualified. Seeing that that’s much too much trouble I would consider doing that but not changing the extension name. I can also see the reasoning that we should just go with (A) now without blocking the proposal any longer because it will always be possible to convert it to (B) later. Best Malte On 2025-03-03 15:52, Arnaud Spiwack wrote: > There may have been delivery issues last week to the committee mailing > list. Did everybody get this email by Simon and mine below? > > On Fri, 21 Feb 2025 at 17:23, Simon Peyton Jones > <[1]simon.peytonjones at gmail.com> wrote: > > Syntax is always troublesome, and best resolved by a vote. I think you > are asking us to vote on: > * (A) splice/quote keywords only before the module name > * (B) splice/quote keywords either before or after the module name > > I vote (A). My opinion is not a strong one. Let's see what other > committee members think. RSVP > > Simon > > On Fri, 21 Feb 2025 at 07:17, Arnaud Spiwack > <[2]arnaud.spiwack at tweag.io> wrote: > > So, let me recap the situation. > > The authors favourite syntax is > `import splice A` > `import quote B` > > But some community members in the thread (most vocally Matt Parsons, > e.g. here > [3]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment > -2651558160 ) feel that there should be more options, that is that all > of > `import splice A` / `import A splice` > `import quote B` / `import A quote` > > Be available, lest people prefer the right-hand positions and do a > proposal to add an extra extension later. > > The authors are ok (but evidently not ecstatic > [4]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment > -2671436455 ) with allowing both positions for their keyword. It turns > out not to be too big of a hassle to implement. Which I propose to be > the resolution. Very non-committal on our part, but because it isn't > costly, we might as well. > > This hasn't been a very busy thread, so… let me backtrack: I'll be on > holiday next week, so I'll accept the changes as I'm back, this means > that you have one week to disagree. Now, this hasn't been a very busy > thread so I expect nobody has strong opinions. But, let me propose a > protocol. If (and only if) someone is of the strong opinion that only > in front is a much better solution. Let them state “I strongly think > that `import splice A` should be the only syntax`. One of us says that, > let each of you vote, I'll tally the vote when I'm back. > > PS: I'm excluding only `import A splice` as an option because the > authors don't want that and it would require an overwhelming majority > to force that on the authors, which evidently doesn't exist, so let's > not muddy the water. So the two options are “only in front” and “both > position” > > Speak to you all in a week, > Arnaud > > On Fri, 14 Feb 2025 at 14:19, Arnaud Spiwack > <[5]arnaud.spiwack at tweag.io> wrote: > > There's a little bit of a debate going on in the Github thread on the > topic of syntax. I'll give this one one last push. If the authors > decide that they are ok with specifying the keywords before and after > the module name, then we can accept immediately, as there's no voice > against this. Otherwise I'll recapitulate everybody's argument here and > call for a quick vote. > > On Mon, 10 Feb 2025 at 15:25, Arnaud Spiwack > <[6]arnaud.spiwack at tweag.io> wrote: > > For the record, the syntactic alternatives can be found in [§8.5 > Syntactic > alternatives]([7]https://github.com/well-typed/ghc-proposals/blob/wip/l > evel-imports-2024/proposals/0000-splice-imports.rst#syntactic-alternati > ves) > > Malte seems to be uncomfortable with the fact that the proposed syntax > is > > import slice Foo > import quote Bar > > Even when ImportQualifiedPost, which enables the syntax > > import Foo qualified [as …] > > is enabled. > > The proposal offers alternative syntaxes like > > import Foo slice > Import Bar quote > > or (to sound more English) > > import Foo for slice > import Bar for quote > > Richard Eisenberg, in the thread, suggests that the motivation for > ImportQualifiedPost doesn't apply to slice/quote because he believes > that there's going to be one block of import slice, one block of import > (nothing), one block of import quote, and they aren't going to be mixed > together. Them being more visually distinguished by starting with the > keyword is an asset in this view. Many seem convinced > > My understanding of Malte's point is that this is not intuitive enough > that it can be left implicit in the proposal, and he'd like the > proposal to at least state explicitly that it ignores > ImportQualifiedPost. > > Malte, let me know if I misrepresent your point of view (or anybody > else's). > > On Sat, 8 Feb 2025 at 01:19, Simon Peyton Jones > <[8]simon.peytonjones at gmail.com> wrote: > > I don’t think we were finished > with bikeshedding the syntax. At least I think the proposal should > state what > the syntax is when ImportQualifiedPost is enabled and voiced that on > the GitHub > thread. > > OK -- but I suspect that most of us have lost context. > > Would you like to post (on the Github) a message explaining: > * what the syntactic alternatives are > * what you recommend > > That will help to focus the discussion > > Thanks! > > Simon > > On Fri, 7 Feb 2025 at 12:16, Malte Ott <[9]malte.ott at maralorn.de> > wrote: > > I do not object to accepting the proposal, but I don’t think we were > finished > with bikeshedding the syntax. At least I think the proposal should > state what > the syntax is when ImportQualifiedPost is enabled and voiced that on > the GitHub > thread. > > I know we all dread wasting our time with syntax discussions but > lets at least > think about it for 5 minutes. > > Best, > Malte > > On 2025-02-07 15:48, Arnaud Spiwack wrote: > > Ok, we have enough of a quorum at this point. If everybody else > voted 1 > > extension this would come at a rough draw. It can't be a strong > enough > > push to overrule the preference of the authors. > > > > I'll give it a handful more day, say until next Wednesday 12th > > February. If someone has a strong objection, please voice it > very > > loudly. Otherwise I'll declare the proposal as accepted in its > current > > state. > > > > Best, > > Arnaud > > > > On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo > > <[1][10]erikd at mega-nerd.com> wrote: > > > > OK, slightly in favor of two extensions. > > > > Erik > > > > Erik de Castro Lopo wrote: > > > > > Hi, > > > > > > I have read through the proposal, but there is something I > am > > still unsure > > > of. For the LANGUAGE pragma's is there any utility in using > one > > separately > > > form the other? It seems there isn't. In any one file you > would > > use either > > > one or the other. > > > > > > Thanks, > > > Erik > > > > > > Arnaud Spiwack wrote: > > > > > > > Sorry I disappeared for a while. I second Simon's call, > let's > > vote. Let me > > > > repost a link to Simon's pro and cons post > > > > > > > [2][11]https://github.com/ghc-proposals/ghc-proposals/pull/682#issue > comm > > ent-2609199731 > > > > > > > > So far, we have the following votes > > > > > > > > - Simon: 1 extension > > > > - Adam: 2 extension (feels quite strongly about it) > > > > - Sebastian: 1 extension (on the Github thread, but I'll > count > > it as a vote > > > > anyway) > > > > > > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you > think? > > > > > > > > --- > > > > > > > > Beyond that we have a single piece of community feedback > on the > > Github > > > > thread. It's from Michael Peyton Jones who is in favour > of 2 > > extensions, > > > > find it here > > > > > > > [3][12]https://github.com/ghc-proposals/ghc-proposals/pull/682#issue > comm > > ent-2609583126 > > > > > > > > --- > > > > > > > > For the record, I hadn't commented about it in my > > recommendation, despite > > > > my well-known and desperately public distaste for micro > > extensions. I have > > > > a couple of reasons: > > > > - I dislike micro-extensions less now that we are doing > the > > GHC20XX (the > > > > last one was very modest, I'm in favour, by the way, of > doing a > > much more > > > > ambitious language edition soon, otherwise my distaste > will come > > back with > > > > a vengeance) > > > > - While I consider every proposal with several extensions > in it > > with > > > > suspicion, the authors did argue for their second > extension, I > > found the > > > > argument mildly convincing, and thought it wasn't worth > fighting > > against. > > > > > > > > Now, even like this my preference is mildly for one > extension. > > Adam says > > > > that it's easier to implement warnings with both the new > syntax > > on and > > > > implicit stage persistence left turned on, than to > implement > > errors when > > > > implicit stage persistence is turned off. It may be so, > but I > > don't think > > > > we can avoid implementing the errors anyway, so I don't > feel > > that it's a > > > > particularly compelling argument. I don't feel strongly. > But > > that's > > > > presumably where my vote goes. > > > > > > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones > > <[4][13]simon.peytonjones at gmail.com> > > > > wrote: > > > > > > > > > Yes: all members of the steering committee, please > vote. > > Evaluating > > > > > proposals is what we all signed up to do! > > > > > > > > > > Thanks > > > > > > > > > > Simon > > > > > > > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry > > <[5][14]adam at well-typed.com> wrote: > > > > > > > > > >> I'm (unsurprisingly) in favour of acceptance, and I > vote for > > two > > > > >> extensions. As I commented on the GitHub thread: > > > > >> > > > > >> > We shouldn't unnecessarily conflate a syntactic > extension > > > > >> (ExplicitLevelImports) with a semantic one > > (NoImplicitStagePersistence) > > > > >> just because the common case is to want both and we > want to > > keep the > > > > >> number of extensions lower. > > > > >> > > > > >> If there are reasons why having two extensions is > actually > > problematic, > > > > >> I'd like to hear them. > > > > >> > > > > >> Also, at the risk of opening another avenue of > discussion, we > > also need > > > > >> to resolve the syntax question (see > > > > >> > > > > >> > > > [6][15]https://github.com/ghc-proposals/ghc-proposals/pull/682#discu > ssio > > n_r1849123243). > > > > >> > > > > >> I don't have a very strong opinion here, but given > that some > > people do, > > > > >> perhaps we should make ImportQualifiedPost affect > splice > > imports so we > > > > >> have > > > > >> > > > > >> import splice qualified A -- By default > > > > >> import A splice qualified -- Under > ImportQualifiedPost > > > > >> > > > > >> In any case, please do vote! It would be good to get > this > > proposal done. > > > > >> > > > > >> Cheers, > > > > >> > > > > >> Adam > > > > >> > > > > >> > > > > >> > > > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > > > > >> > Arnaud > > > > >> > > > > > >> > OK, following my call and some further iteration, > the > > proposal is much > > > > >> > improved. See here > > > > >> > > > > <[7][16]https://github.com/ghc-proposals/ghc-proposals/pull/682>. > > Please > > > > >> read > > > > >> > the new "Proposed Change Specification" which has > had a > > large rewrite. > > > > >> > > > > > >> > I vote to accept. > > > > >> > > > > > >> > BUT there is one point that the committee must > resolve: > > *one extension > > > > >> > of two?* It's just a judgement call and I lay out > the > > choices in this > > > > >> > post > > > > >> > < > > > > >> > > > [8][17]https://github.com/ghc-proposals/ghc-proposals/pull/682#issue > comm > > ent-2609199731>. > > > > >> I doubt that we'll get much community feedback. I > suggest > > that we just > > > > >> vote. I vote for one, not two. As does Sebastian. > > > > >> > > > > > >> > Over to you Arnaud. Let's get this one done. > Matthew is > > busy > > > > >> > implementing it for a customer and it has been on > our to-do > > list for > > > > >> > some time now. (Partly my fault.) > > > > >> > > > > > >> > Simon > > > > >> > > > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > > > >> > <[9][18]simon.peytonjones at gmail.com > > > > > > > >> wrote: > > > > >> > > > > > >> > Matthew and I had a good conversation. Some > notes here > > > > >> > < > > > > >> > > > [11][20]https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQ > R58R > > Phk5MslruY7yXD0/edit?usp=sharing > > > > >> >. > > > > >> > > > > > >> > He's going to work on a revision to the proposal > which > > I'll iterate > > > > >> > with him. > > > > >> > > > > > >> > Simon > > > > >> > > > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > > > >> > <[12][21]arnaud.spiwack at tweag.io > > > wrote: > > > > >> > > > > > >> > Then, let's wait until your call with > Matthew and > > decide how to > > > > >> > act then. > > > > >> > > > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton > Jones > > > > >> > <[14][23]simon.peytonjones at gmail.com > > > > >> > > > wrote: > > > > >> > > > > > >> > Arnaud > > > > >> > > > > > >> > I have responded with a lot of feedback > on the > > Github thread > > > > >> > < > > > > >> > > > [16][25]https://github.com/ghc-proposals/ghc-proposals/pull/682#pull > requ > > estreview-2562175116 > > > > >> >. > > > > >> > > > > > >> > TL:DR: I like the direction of travel > but have > > too many > > > > >> > questions of detail to be ready to > accept it > > just yet. > > > > >> > > > > > >> > I have arranged a call with Matthew. > > > > >> > > > > > >> > Simon > > > > >> > > > > > >> > On Thu, 9 Jan 2025 at 06:31, Arnaud > Spiwack > > > > >> > <[17][26]arnaud.spiwack at tweag.io > > > > > > > >> > wrote: > > > > >> > > > > > >> > > > > > >> > Mathew Pickering, Rodrigo Mesquita, > and our > > own Adam > > > > >> > Gundry put forward a new proposal > for the > > perenial > > > > >> > problem of dependencies and Template > > Haskell > > > > >> > > > > [19][28]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > > > >> > < > > > > >> > [20][29]https://github.com/ghc-proposals/ghc-proposals/pull/682> > > > > >> > > > > > >> > I've got to be honest, I'm not fully > > convinced by the > > > > >> > proposal. More on that in a minute, > but it > > learns a > > > > >> > lesson from previous attempts at the > same > > problem by > > > > >> > solving the absolute minimal > problem, but > > this leads to > > > > >> > a somewhat fork-like situation for > which it > > isn't clear > > > > >> > whether it will be resolved in the > future. > > That being > > > > >> > said, it solves a real problem which > has > > plagued GHC > > > > >> > compilation forever. And I'm > inclined to > > believe that we > > > > >> > can't really do much better. > > > > >> > > > > > >> > But I'm getting ahead of myself. The > > problem is that > > > > >> > when you have -XTemplateHaskell in a > file, > > all the > > > > >> > dependencies' compiled code must > suddenly > > be available > > > > >> > for typechecking. This breaks > `-fno-code` > > and wounds > > > > >> > recompilation avoidance. This is > probably > > the main > > > > >> > reason why it's a widely held belief > that > > Template > > > > >> > Haskell is slow: you use Template > Haskell > > in a few > > > > >> > modules, and suddenly your IDE is > much less > > responsive > > > > >> > and you recompile more files. Yay? > > > > >> > > > > > >> > Anyway, the general gist of the > solution is > > clear: we > > > > >> > must be able to specify that we > don't want > > to import a > > > > >> > module for Template Haskell (there > is > > subtleties in this > > > > >> > too as you will want a little more > control > > than that for > > > > >> > cross-compilation reasons which I'm > not > > competent about > > > > >> > to comment on). But the devil is in > the > > many details. > > > > >> > There's this thing called implicit > > cross-stage > > > > >> > persistence which says that anything > you > > import > > > > >> > not-for-template-haskell is going to > be > > available in > > > > >> > quotes and splices anyway. Sigh… So > you > > have to turn > > > > >> > this off. This is what the proposal > does. > > And pretty > > > > >> > much only. > > > > >> > > > > > >> > They introduce a new > > > > >> > > extension-XNoImplicitStagePersistence which > > disables > > > > >> > that, and a little bit of syntax to > specify > > the stage of > > > > >> > imports. That's it. > > > > >> > > > > > >> > But it comes with severe > limitations, most > > importantly: > > > > >> > you can't ever use a symbol defined > in the > > current > > > > >> > module in a quote or splice of this > current > > module, > > > > >> > typed template Haskell is turned > off. > > > > >> > > > > > >> > For these situations, the proposal > kind of > > advertises > > > > >> > using `-XImplicitStagePersistence`. > Which > > does seem like > > > > >> > a fork-like situation to me. Not > cool. Yet… > > yet Template > > > > >> > Haskell is a big messy ball of yarn, > and I > > don't think > > > > >> > it's fair to ask of any proposal to > > entangle it > > > > >> > completely. The failure of past > attempts > > seem to support > > > > >> > this case. And I believe the authors > are > > correct when > > > > >> > they claim that this proposal, in > practice, > > covers a > > > > >> > vast majority of the uses of > Template > > Haskell out there. > > > > >> > So maybe we can see that as a new > > foundation for > > > > >> > Template Haskell. I'm not thrilled > about > > it, but it's > > > > >> > probably the most reasonable way > forward. > > > > >> > > > > > >> > The real problem with this sort of > proposal > > is that then > > > > >> > I get to write way too long an email > to the > > committee. > > > > >> > Hopefully this didn't deter you. > Read the > > proposal, and > > > > >> > let's vote. > > > > >> > > > > > >> > -- > > > > >> > Arnaud Spiwack > > > > >> > Director, Research at > > [21][30]https://moduscreate.com > > > > >> > <[22][31]https://moduscreate.com> > and > > [23][32]https://tweag.io > > > > >> > <[24][33]https://tweag.io>. > > > > >> > > > > >> > > > > >> -- > > > > >> Adam Gundry, Haskell Consultant > > > > >> Well-Typed LLP, [25][34]https://www.well-typed.com/ > > > > >> > > > > >> Registered in England & Wales, OC335890 > > > > >> 27 Old Gloucester Street, London WC1N 3AX, England > > > > >> > > > > >> _______________________________________________ > > > > >> ghc-steering-committee mailing list > > > > >> [26][35]ghc-steering-committee at haskell.org > > > > >> > > > [27][36]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri > ng-c > > ommittee > > > > >> > > > > > _______________________________________________ > > > > > ghc-steering-committee mailing list > > > > > [28][37]ghc-steering-committee at haskell.org > > > > > > > > [29][38]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri > ng-c > > ommittee > > > > > > > > > > > > > > > > > -- > > > > Arnaud Spiwack > > > > Director, Research at [30][39]https://moduscreate.com and > > [31][40]https://tweag.io. > > > > > > > > > -- > > > > > > -------------------------------------------------------------------- > > -- > > > Erik de Castro Lopo > > > [32][41]http://www.mega-nerd.com/ > > > > > > > -- > > > -------------------------------------------------------------------- > > -- > > Erik de Castro Lopo > > [33][42]http://www.mega-nerd.com/ > > _______________________________________________ > > ghc-steering-committee mailing list > > [34][43]ghc-steering-committee at haskell.org > > > [35][44]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri > ng-c > > ommittee > > > > -- > > > > Arnaud Spiwack > > Director, Research at [36][45]https://moduscreate.com and > > [37][46]https://tweag.io. > > > > References > > > > 1. mailto:[47]erikd at mega-nerd.com > > 2. > [48]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom > ment-2609199731 > > 3. > [49]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom > ment-2609583126 > > 4. mailto:[50]simon.peytonjones at gmail.com > > 5. mailto:[51]adam at well-typed.com > > 6. > [52]https://github.com/ghc-proposals/ghc-proposals/pull/682#discussi > on_r1849123243 > > 7. [53]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > 8. > [54]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom > ment-2609199731 > > 9. mailto:[55]simon.peytonjones at gmail.com > > 10. mailto:[56]simon.peytonjones at gmail.com > > 11. > [57]https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R > Phk5MslruY7yXD0/edit?usp=sharing > > 12. mailto:[58]arnaud.spiwack at tweag.io > > 13. mailto:[59]arnaud.spiwack at tweag.io > > 14. mailto:[60]simon.peytonjones at gmail.com > > 15. mailto:[61]simon.peytonjones at gmail.com > > 16. > [62]https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ > estreview-2562175116 > > 17. mailto:[63]arnaud.spiwack at tweag.io > > 18. mailto:[64]arnaud.spiwack at tweag.io > > 19. [65]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > 20. [66]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > 21. [67]https://moduscreate.com/ > > 22. [68]https://moduscreate.com/ > > 23. [69]https://tweag.io/ > > 24. [70]https://tweag.io/ > > 25. [71]https://www.well-typed.com/ > > 26. mailto:[72]ghc-steering-committee at haskell.org > > 27. > [73]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > 28. mailto:[74]ghc-steering-committee at haskell.org > > 29. > [75]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > 30. [76]https://moduscreate.com/ > > 31. [77]https://tweag.io/ > > 32. [78]http://www.mega-nerd.com/ > > 33. [79]http://www.mega-nerd.com/ > > 34. mailto:[80]ghc-steering-committee at haskell.org > > 35. > [81]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > 36. [82]https://moduscreate.com/ > > 37. [83]https://tweag.io/ > > > _______________________________________________ > > ghc-steering-committee mailing list > > [84]ghc-steering-committee at haskell.org > > > [85]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > _______________________________________________ > ghc-steering-committee mailing list > [86]ghc-steering-committee at haskell.org > [87]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > _______________________________________________ > ghc-steering-committee mailing list > [88]ghc-steering-committee at haskell.org > [89]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > -- > Arnaud Spiwack > Director, Research at [90]https://moduscreate.com and > [91]https://tweag.io. > > -- > > Arnaud Spiwack > Director, Research at [92]https://moduscreate.com and > [93]https://tweag.io. > > -- > > Arnaud Spiwack > Director, Research at [94]https://moduscreate.com and > [95]https://tweag.io. > > -- > Arnaud Spiwack > Director, Research at [96]https://moduscreate.com and > [97]https://tweag.io. > > References > > 1. mailto:simon.peytonjones at gmail.com > 2. mailto:arnaud.spiwack at tweag.io > 3. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2651558160 > 4. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2671436455 > 5. mailto:arnaud.spiwack at tweag.io > 6. mailto:arnaud.spiwack at tweag.io > 7. https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/proposals/0000-splice-imports.rst#syntactic-alternatives > 8. mailto:simon.peytonjones at gmail.com > 9. mailto:malte.ott at maralorn.de > 10. mailto:erikd at mega-nerd.com > 11. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > 12. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > 13. mailto:simon.peytonjones at gmail.com > 14. mailto:adam at well-typed.com > 15. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio > 16. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 17. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > 18. mailto:simon.peytonjones at gmail.com > 19. mailto:simon.peytonjones at gmail.com > 20. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R > 21. mailto:arnaud.spiwack at tweag.io > 22. mailto:arnaud.spiwack at tweag.io > 23. mailto:simon.peytonjones at gmail.com > 24. mailto:simon.peytonjones at gmail.com > 25. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ > 26. mailto:arnaud.spiwack at tweag.io > 27. mailto:arnaud.spiwack at tweag.io > 28. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 29. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 30. https://moduscreate.com/ > 31. https://moduscreate.com/ > 32. https://tweag.io/ > 33. https://tweag.io/ > 34. https://www.well-typed.com/ > 35. mailto:ghc-steering-committee at haskell.org > 36. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > 37. mailto:ghc-steering-committee at haskell.org > 38. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > 39. https://moduscreate.com/ > 40. https://tweag.io/ > 41. http://www.mega-nerd.com/ > 42. http://www.mega-nerd.com/ > 43. mailto:ghc-steering-committee at haskell.org > 44. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > 45. https://moduscreate.com/ > 46. https://tweag.io/ > 47. mailto:erikd at mega-nerd.com > 48. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > 49. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126 > 50. mailto:simon.peytonjones at gmail.com > 51. mailto:adam at well-typed.com > 52. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243 > 53. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 54. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > 55. mailto:simon.peytonjones at gmail.com > 56. mailto:simon.peytonjones at gmail.com > 57. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing > 58. mailto:arnaud.spiwack at tweag.io > 59. mailto:arnaud.spiwack at tweag.io > 60. mailto:simon.peytonjones at gmail.com > 61. mailto:simon.peytonjones at gmail.com > 62. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116 > 63. mailto:arnaud.spiwack at tweag.io > 64. mailto:arnaud.spiwack at tweag.io > 65. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 66. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 67. https://moduscreate.com/ > 68. https://moduscreate.com/ > 69. https://tweag.io/ > 70. https://tweag.io/ > 71. https://www.well-typed.com/ > 72. mailto:ghc-steering-committee at haskell.org > 73. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 74. mailto:ghc-steering-committee at haskell.org > 75. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 76. https://moduscreate.com/ > 77. https://tweag.io/ > 78. http://www.mega-nerd.com/ > 79. http://www.mega-nerd.com/ > 80. mailto:ghc-steering-committee at haskell.org > 81. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 82. https://moduscreate.com/ > 83. https://tweag.io/ > 84. mailto:ghc-steering-committee at haskell.org > 85. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 86. mailto:ghc-steering-committee at haskell.org > 87. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 88. mailto:ghc-steering-committee at haskell.org > 89. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 90. https://moduscreate.com/ > 91. https://tweag.io/ > 92. https://moduscreate.com/ > 93. https://tweag.io/ > 94. https://moduscreate.com/ > 95. https://tweag.io/ > 96. https://moduscreate.com/ > 97. https://tweag.io/ From adam at well-typed.com Tue Mar 4 16:26:53 2025 From: adam at well-typed.com (Adam Gundry) Date: Tue, 4 Mar 2025 16:26:53 +0000 Subject: [ghc-steering-committee] Please review #686: Fix spec for string gaps in multiline strings Message-ID: <295c651e-cbc2-44d6-88b4-8eba761f1b17@well-typed.com> Dear Committee, Brandon Chinn proposes to amend proposal #569, which introduced MultilineStrings, to correct its interaction with string gaps: https://github.com/ghc-proposals/ghc-proposals/pull/686 I'd like to nominate Malte as the shepherd, since he already engaged on the proposal thread. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process 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 From malte.ott at maralorn.de Thu Mar 6 11:30:38 2025 From: malte.ott at maralorn.de (Malte Ott) Date: Thu, 6 Mar 2025 12:30:38 +0100 Subject: [ghc-steering-committee] #686: Amendment to MultilineStrings, recommendation: accept Message-ID: <5rffpmymva3ejtbipgivtu5hyd4l6nvkvhlkktmjdnrhi6z7mw@hera.m-0.eu> Dear committee, in https://github.com/ghc-proposals/ghc-proposals/pull/686 Brandon Chinn proposes to slightly modify the recently accepted MultilineStrings proposal: "For the calculation of whitespace prefix removal string gaps (i.e. the / / syntax) should be regarded as non-whitespace." This is technically a breaking change so we should deliberate on it, but I don’t see why anyone would come into this situation in the first place, so I don’t think we should dwell on this. A motivation for the change is that it is easier to implement. I am torn whether it is more or less surprising to users, with maybe a small tendency to less surprising, so I recommend we go with it. The committee could decide to be annoying about this. This is a not strongly motivated change which theoretically changes the semantics of a released extension without warnings or compile errors. However, the extension would surely count as experimental if we were already using the classification we agreed upon. And this tiny change has already been merged as part of a bug fix and I think we should let this pass out of respect to our implementors. Please voice your opinions, I aim to declare this proposal accepted in 7 days. Best Malte From arnaud.spiwack at tweag.io Thu Mar 6 12:55:50 2025 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Thu, 6 Mar 2025 21:55:50 +0900 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: <20250205191643.60ec5f23d8b4571b8cf14ece@mega-nerd.com> <20250207100114.c0dd8b72c6dc9167a58bff43@mega-nerd.com> Message-ID: > > My dream would be to rename ImportQualifiedPost to ImportAnnotationsPost or > something similar and then treat splice exactly as qualified. > Seeing that that’s much too much trouble I would consider doing that but > not > changing the extension name. (aside: with ImportQualifiedPost turned, both the `qualified` keyword before and the `qualified` keyword after are accepted). --- Nobody seems to have an opinion. Owing to various illnesses traversing my households (and my lungs…) this week, I let that slide a bit longer than I wanted. But anyway. I'll interpret silence as assent, and mark the proposal as accepted. We've waited too long already. On Mon, 3 Mar 2025 at 19:03, Malte Ott wrote: > I for my part are kinda dissatisfied by both options. > And I am very much sympathetic to the position that a committee shouldn’t > settle > alternatives by allowing all of them. > That being said I am still in favor of leaving the proposal like it is > now, which is (B). > > My dream would be to rename ImportQualifiedPost to ImportAnnotationsPost or > something similar and then treat splice exactly as qualified. > Seeing that that’s much too much trouble I would consider doing that but > not > changing the extension name. > > I can also see the reasoning that we should just go with (A) now without > blocking the proposal any longer because it will always be possible to > convert > it to (B) later. > > Best > Malte > > On 2025-03-03 15:52, Arnaud Spiwack wrote: > > There may have been delivery issues last week to the committee mailing > > list. Did everybody get this email by Simon and mine below? > > > > On Fri, 21 Feb 2025 at 17:23, Simon Peyton Jones > > <[1]simon.peytonjones at gmail.com> wrote: > > > > Syntax is always troublesome, and best resolved by a vote. I think > you > > are asking us to vote on: > > * (A) splice/quote keywords only before the module name > > * (B) splice/quote keywords either before or after the module name > > > > I vote (A). My opinion is not a strong one. Let's see what other > > committee members think. RSVP > > > > Simon > > > > On Fri, 21 Feb 2025 at 07:17, Arnaud Spiwack > > <[2]arnaud.spiwack at tweag.io> wrote: > > > > So, let me recap the situation. > > > > The authors favourite syntax is > > `import splice A` > > `import quote B` > > > > But some community members in the thread (most vocally Matt Parsons, > > e.g. here > > [3] > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment > > -2651558160 ) feel that there should be more options, that is that all > > of > > `import splice A` / `import A splice` > > `import quote B` / `import A quote` > > > > Be available, lest people prefer the right-hand positions and do a > > proposal to add an extra extension later. > > > > The authors are ok (but evidently not ecstatic > > [4] > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment > > -2671436455 ) with allowing both positions for their keyword. It turns > > out not to be too big of a hassle to implement. Which I propose to be > > the resolution. Very non-committal on our part, but because it isn't > > costly, we might as well. > > > > This hasn't been a very busy thread, so… let me backtrack: I'll be on > > holiday next week, so I'll accept the changes as I'm back, this means > > that you have one week to disagree. Now, this hasn't been a very busy > > thread so I expect nobody has strong opinions. But, let me propose a > > protocol. If (and only if) someone is of the strong opinion that only > > in front is a much better solution. Let them state “I strongly think > > that `import splice A` should be the only syntax`. One of us says > that, > > let each of you vote, I'll tally the vote when I'm back. > > > > PS: I'm excluding only `import A splice` as an option because the > > authors don't want that and it would require an overwhelming majority > > to force that on the authors, which evidently doesn't exist, so let's > > not muddy the water. So the two options are “only in front” and “both > > position” > > > > Speak to you all in a week, > > Arnaud > > > > On Fri, 14 Feb 2025 at 14:19, Arnaud Spiwack > > <[5]arnaud.spiwack at tweag.io> wrote: > > > > There's a little bit of a debate going on in the Github thread on the > > topic of syntax. I'll give this one one last push. If the authors > > decide that they are ok with specifying the keywords before and after > > the module name, then we can accept immediately, as there's no voice > > against this. Otherwise I'll recapitulate everybody's argument here > and > > call for a quick vote. > > > > On Mon, 10 Feb 2025 at 15:25, Arnaud Spiwack > > <[6]arnaud.spiwack at tweag.io> wrote: > > > > For the record, the syntactic alternatives can be found in [§8.5 > > Syntactic > > alternatives]([7] > https://github.com/well-typed/ghc-proposals/blob/wip/l > > > evel-imports-2024/proposals/0000-splice-imports.rst#syntactic-alternati > > ves) > > > > Malte seems to be uncomfortable with the fact that the proposed syntax > > is > > > > import slice Foo > > import quote Bar > > > > Even when ImportQualifiedPost, which enables the syntax > > > > import Foo qualified [as …] > > > > is enabled. > > > > The proposal offers alternative syntaxes like > > > > import Foo slice > > Import Bar quote > > > > or (to sound more English) > > > > import Foo for slice > > import Bar for quote > > > > Richard Eisenberg, in the thread, suggests that the motivation for > > ImportQualifiedPost doesn't apply to slice/quote because he believes > > that there's going to be one block of import slice, one block of > import > > (nothing), one block of import quote, and they aren't going to be > mixed > > together. Them being more visually distinguished by starting with the > > keyword is an asset in this view. Many seem convinced > > > > My understanding of Malte's point is that this is not intuitive enough > > that it can be left implicit in the proposal, and he'd like the > > proposal to at least state explicitly that it ignores > > ImportQualifiedPost. > > > > Malte, let me know if I misrepresent your point of view (or anybody > > else's). > > > > On Sat, 8 Feb 2025 at 01:19, Simon Peyton Jones > > <[8]simon.peytonjones at gmail.com> wrote: > > > > I don’t think we were finished > > with bikeshedding the syntax. At least I think the proposal should > > state what > > the syntax is when ImportQualifiedPost is enabled and voiced that on > > the GitHub > > thread. > > > > OK -- but I suspect that most of us have lost context. > > > > Would you like to post (on the Github) a message explaining: > > * what the syntactic alternatives are > > * what you recommend > > > > That will help to focus the discussion > > > > Thanks! > > > > Simon > > > > On Fri, 7 Feb 2025 at 12:16, Malte Ott <[9]malte.ott at maralorn.de> > > wrote: > > > > I do not object to accepting the proposal, but I don’t think we were > > finished > > with bikeshedding the syntax. At least I think the proposal should > > state what > > the syntax is when ImportQualifiedPost is enabled and voiced that on > > the GitHub > > thread. > > > > I know we all dread wasting our time with syntax discussions but > > lets at least > > think about it for 5 minutes. > > > > Best, > > Malte > > > > On 2025-02-07 15:48, Arnaud Spiwack wrote: > > > Ok, we have enough of a quorum at this point. If everybody else > > voted 1 > > > extension this would come at a rough draw. It can't be a strong > > enough > > > push to overrule the preference of the authors. > > > > > > I'll give it a handful more day, say until next Wednesday 12th > > > February. If someone has a strong objection, please voice it > > very > > > loudly. Otherwise I'll declare the proposal as accepted in its > > current > > > state. > > > > > > Best, > > > Arnaud > > > > > > On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo > > > <[1][10]erikd at mega-nerd.com> wrote: > > > > > > OK, slightly in favor of two extensions. > > > > > > Erik > > > > > > Erik de Castro Lopo wrote: > > > > > > > Hi, > > > > > > > > I have read through the proposal, but there is something I > > am > > > still unsure > > > > of. For the LANGUAGE pragma's is there any utility in using > > one > > > separately > > > > form the other? It seems there isn't. In any one file you > > would > > > use either > > > > one or the other. > > > > > > > > Thanks, > > > > Erik > > > > > > > > Arnaud Spiwack wrote: > > > > > > > > > Sorry I disappeared for a while. I second Simon's call, > > let's > > > vote. Let me > > > > > repost a link to Simon's pro and cons post > > > > > > > > > > [2][11] > https://github.com/ghc-proposals/ghc-proposals/pull/682#issue > > comm > > > ent-2609199731 > > > > > > > > > > So far, we have the following votes > > > > > > > > > > - Simon: 1 extension > > > > > - Adam: 2 extension (feels quite strongly about it) > > > > > - Sebastian: 1 extension (on the Github thread, but I'll > > count > > > it as a vote > > > > > anyway) > > > > > > > > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you > > think? > > > > > > > > > > --- > > > > > > > > > > Beyond that we have a single piece of community feedback > > on the > > > Github > > > > > thread. It's from Michael Peyton Jones who is in favour > > of 2 > > > extensions, > > > > > find it here > > > > > > > > > > [3][12] > https://github.com/ghc-proposals/ghc-proposals/pull/682#issue > > comm > > > ent-2609583126 > > > > > > > > > > --- > > > > > > > > > > For the record, I hadn't commented about it in my > > > recommendation, despite > > > > > my well-known and desperately public distaste for micro > > > extensions. I have > > > > > a couple of reasons: > > > > > - I dislike micro-extensions less now that we are doing > > the > > > GHC20XX (the > > > > > last one was very modest, I'm in favour, by the way, of > > doing a > > > much more > > > > > ambitious language edition soon, otherwise my distaste > > will come > > > back with > > > > > a vengeance) > > > > > - While I consider every proposal with several extensions > > in it > > > with > > > > > suspicion, the authors did argue for their second > > extension, I > > > found the > > > > > argument mildly convincing, and thought it wasn't worth > > fighting > > > against. > > > > > > > > > > Now, even like this my preference is mildly for one > > extension. > > > Adam says > > > > > that it's easier to implement warnings with both the new > > syntax > > > on and > > > > > implicit stage persistence left turned on, than to > > implement > > > errors when > > > > > implicit stage persistence is turned off. It may be so, > > but I > > > don't think > > > > > we can avoid implementing the errors anyway, so I don't > > feel > > > that it's a > > > > > particularly compelling argument. I don't feel strongly. > > But > > > that's > > > > > presumably where my vote goes. > > > > > > > > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones > > > <[4][13]simon.peytonjones at gmail.com> > > > > > wrote: > > > > > > > > > > > Yes: all members of the steering committee, please > > vote. > > > Evaluating > > > > > > proposals is what we all signed up to do! > > > > > > > > > > > > Thanks > > > > > > > > > > > > Simon > > > > > > > > > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry > > > <[5][14]adam at well-typed.com> wrote: > > > > > > > > > > > >> I'm (unsurprisingly) in favour of acceptance, and I > > vote for > > > two > > > > > >> extensions. As I commented on the GitHub thread: > > > > > >> > > > > > >> > We shouldn't unnecessarily conflate a syntactic > > extension > > > > > >> (ExplicitLevelImports) with a semantic one > > > (NoImplicitStagePersistence) > > > > > >> just because the common case is to want both and we > > want to > > > keep the > > > > > >> number of extensions lower. > > > > > >> > > > > > >> If there are reasons why having two extensions is > > actually > > > problematic, > > > > > >> I'd like to hear them. > > > > > >> > > > > > >> Also, at the risk of opening another avenue of > > discussion, we > > > also need > > > > > >> to resolve the syntax question (see > > > > > >> > > > > > >> > > > > > [6][15] > https://github.com/ghc-proposals/ghc-proposals/pull/682#discu > > ssio > > > n_r1849123243). > > > > > >> > > > > > >> I don't have a very strong opinion here, but given > > that some > > > people do, > > > > > >> perhaps we should make ImportQualifiedPost affect > > splice > > > imports so we > > > > > >> have > > > > > >> > > > > > >> import splice qualified A -- By default > > > > > >> import A splice qualified -- Under > > ImportQualifiedPost > > > > > >> > > > > > >> In any case, please do vote! It would be good to get > > this > > > proposal done. > > > > > >> > > > > > >> Cheers, > > > > > >> > > > > > >> Adam > > > > > >> > > > > > >> > > > > > >> > > > > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > > > > > >> > Arnaud > > > > > >> > > > > > > >> > OK, following my call and some further iteration, > > the > > > proposal is much > > > > > >> > improved. See here > > > > > >> > > > > > > <[7][16]https://github.com/ghc-proposals/ghc-proposals/pull/682>. > > > Please > > > > > >> read > > > > > >> > the new "Proposed Change Specification" which has > > had a > > > large rewrite. > > > > > >> > > > > > > >> > I vote to accept. > > > > > >> > > > > > > >> > BUT there is one point that the committee must > > resolve: > > > *one extension > > > > > >> > of two?* It's just a judgement call and I lay out > > the > > > choices in this > > > > > >> > post > > > > > >> > < > > > > > >> > > > > > [8][17] > https://github.com/ghc-proposals/ghc-proposals/pull/682#issue > > comm > > > ent-2609199731>. > > > > > >> I doubt that we'll get much community feedback. I > > suggest > > > that we just > > > > > >> vote. I vote for one, not two. As does Sebastian. > > > > > >> > > > > > > >> > Over to you Arnaud. Let's get this one done. > > Matthew is > > > busy > > > > > >> > implementing it for a customer and it has been on > > our to-do > > > list for > > > > > >> > some time now. (Partly my fault.) > > > > > >> > > > > > > >> > Simon > > > > > >> > > > > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > > > > >> > <[9][18]simon.peytonjones at gmail.com > > > > > > > > > >> wrote: > > > > > >> > > > > > > >> > Matthew and I had a good conversation. Some > > notes here > > > > > >> > < > > > > > >> > > > > > [11][20] > https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQ > > R58R > > > Phk5MslruY7yXD0/edit?usp=sharing > > > > > >> >. > > > > > >> > > > > > > >> > He's going to work on a revision to the proposal > > which > > > I'll iterate > > > > > >> > with him. > > > > > >> > > > > > > >> > Simon > > > > > >> > > > > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > > > > >> > <[12][21]arnaud.spiwack at tweag.io > > > > wrote: > > > > > >> > > > > > > >> > Then, let's wait until your call with > > Matthew and > > > decide how to > > > > > >> > act then. > > > > > >> > > > > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton > > Jones > > > > > >> > <[14][23]simon.peytonjones at gmail.com > > > > > >> > > > > wrote: > > > > > >> > > > > > > >> > Arnaud > > > > > >> > > > > > > >> > I have responded with a lot of feedback > > on the > > > Github thread > > > > > >> > < > > > > > >> > > > > > [16][25] > https://github.com/ghc-proposals/ghc-proposals/pull/682#pull > > requ > > > estreview-2562175116 > > > > > >> >. > > > > > >> > > > > > > >> > TL:DR: I like the direction of travel > > but have > > > too many > > > > > >> > questions of detail to be ready to > > accept it > > > just yet. > > > > > >> > > > > > > >> > I have arranged a call with Matthew. > > > > > >> > > > > > > >> > Simon > > > > > >> > > > > > > >> > On Thu, 9 Jan 2025 at 06:31, Arnaud > > Spiwack > > > > > >> > <[17][26]arnaud.spiwack at tweag.io > > > > > > > > > >> > wrote: > > > > > >> > > > > > > >> > > > > > > >> > Mathew Pickering, Rodrigo Mesquita, > > and our > > > own Adam > > > > > >> > Gundry put forward a new proposal > > for the > > > perenial > > > > > >> > problem of dependencies and Template > > > Haskell > > > > > >> > > > > > > [19][28]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > > > > >> > < > > > > > >> > > [20][29]https://github.com/ghc-proposals/ghc-proposals/pull/682> > > > > > >> > > > > > > >> > I've got to be honest, I'm not fully > > > convinced by the > > > > > >> > proposal. More on that in a minute, > > but it > > > learns a > > > > > >> > lesson from previous attempts at the > > same > > > problem by > > > > > >> > solving the absolute minimal > > problem, but > > > this leads to > > > > > >> > a somewhat fork-like situation for > > which it > > > isn't clear > > > > > >> > whether it will be resolved in the > > future. > > > That being > > > > > >> > said, it solves a real problem which > > has > > > plagued GHC > > > > > >> > compilation forever. And I'm > > inclined to > > > believe that we > > > > > >> > can't really do much better. > > > > > >> > > > > > > >> > But I'm getting ahead of myself. The > > > problem is that > > > > > >> > when you have -XTemplateHaskell in a > > file, > > > all the > > > > > >> > dependencies' compiled code must > > suddenly > > > be available > > > > > >> > for typechecking. This breaks > > `-fno-code` > > > and wounds > > > > > >> > recompilation avoidance. This is > > probably > > > the main > > > > > >> > reason why it's a widely held belief > > that > > > Template > > > > > >> > Haskell is slow: you use Template > > Haskell > > > in a few > > > > > >> > modules, and suddenly your IDE is > > much less > > > responsive > > > > > >> > and you recompile more files. Yay? > > > > > >> > > > > > > >> > Anyway, the general gist of the > > solution is > > > clear: we > > > > > >> > must be able to specify that we > > don't want > > > to import a > > > > > >> > module for Template Haskell (there > > is > > > subtleties in this > > > > > >> > too as you will want a little more > > control > > > than that for > > > > > >> > cross-compilation reasons which I'm > > not > > > competent about > > > > > >> > to comment on). But the devil is in > > the > > > many details. > > > > > >> > There's this thing called implicit > > > cross-stage > > > > > >> > persistence which says that anything > > you > > > import > > > > > >> > not-for-template-haskell is going to > > be > > > available in > > > > > >> > quotes and splices anyway. Sigh… So > > you > > > have to turn > > > > > >> > this off. This is what the proposal > > does. > > > And pretty > > > > > >> > much only. > > > > > >> > > > > > > >> > They introduce a new > > > > > >> > > > extension-XNoImplicitStagePersistence which > > > disables > > > > > >> > that, and a little bit of syntax to > > specify > > > the stage of > > > > > >> > imports. That's it. > > > > > >> > > > > > > >> > But it comes with severe > > limitations, most > > > importantly: > > > > > >> > you can't ever use a symbol defined > > in the > > > current > > > > > >> > module in a quote or splice of this > > current > > > module, > > > > > >> > typed template Haskell is turned > > off. > > > > > >> > > > > > > >> > For these situations, the proposal > > kind of > > > advertises > > > > > >> > using `-XImplicitStagePersistence`. > > Which > > > does seem like > > > > > >> > a fork-like situation to me. Not > > cool. Yet… > > > yet Template > > > > > >> > Haskell is a big messy ball of yarn, > > and I > > > don't think > > > > > >> > it's fair to ask of any proposal to > > > entangle it > > > > > >> > completely. The failure of past > > attempts > > > seem to support > > > > > >> > this case. And I believe the authors > > are > > > correct when > > > > > >> > they claim that this proposal, in > > practice, > > > covers a > > > > > >> > vast majority of the uses of > > Template > > > Haskell out there. > > > > > >> > So maybe we can see that as a new > > > foundation for > > > > > >> > Template Haskell. I'm not thrilled > > about > > > it, but it's > > > > > >> > probably the most reasonable way > > forward. > > > > > >> > > > > > > >> > The real problem with this sort of > > proposal > > > is that then > > > > > >> > I get to write way too long an email > > to the > > > committee. > > > > > >> > Hopefully this didn't deter you. > > Read the > > > proposal, and > > > > > >> > let's vote. > > > > > >> > > > > > > >> > -- > > > > > >> > Arnaud Spiwack > > > > > >> > Director, Research at > > > [21][30]https://moduscreate.com > > > > > >> > <[22][31]https://moduscreate.com> > > and > > > [23][32]https://tweag.io > > > > > >> > <[24][33]https://tweag.io>. > > > > > >> > > > > > >> > > > > > >> -- > > > > > >> Adam Gundry, Haskell Consultant > > > > > >> Well-Typed LLP, [25][34]https://www.well-typed.com/ > > > > > >> > > > > > >> Registered in England & Wales, OC335890 > > > > > >> 27 Old Gloucester Street, London WC1N 3AX, England > > > > > >> > > > > > >> _______________________________________________ > > > > > >> ghc-steering-committee mailing list > > > > > >> [26][35]ghc-steering-committee at haskell.org > > > > > >> > > > > > [27][36] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri > > ng-c > > > ommittee > > > > > >> > > > > > > _______________________________________________ > > > > > > ghc-steering-committee mailing list > > > > > > [28][37]ghc-steering-committee at haskell.org > > > > > > > > > > > [29][38] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri > > ng-c > > > ommittee > > > > > > > > > > > > > > > > > > > > > -- > > > > > Arnaud Spiwack > > > > > Director, Research at [30][39]https://moduscreate.com > and > > > [31][40]https://tweag.io. > > > > > > > > > > > > -- > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > > Erik de Castro Lopo > > > > [32][41]http://www.mega-nerd.com/ > > > > > > > > > > -- > > > > > -------------------------------------------------------------------- > > > -- > > > Erik de Castro Lopo > > > [33][42]http://www.mega-nerd.com/ > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > [34][43]ghc-steering-committee at haskell.org > > > > > [35][44] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri > > ng-c > > > ommittee > > > > > > -- > > > > > > Arnaud Spiwack > > > Director, Research at [36][45]https://moduscreate.com and > > > [37][46]https://tweag.io. > > > > > > References > > > > > > 1. mailto:[47]erikd at mega-nerd.com > > > 2. > > [48] > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom > > ment-2609199731 > > > 3. > > [49] > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom > > ment-2609583126 > > > 4. mailto:[50]simon.peytonjones at gmail.com > > > 5. mailto:[51]adam at well-typed.com > > > 6. > > [52] > https://github.com/ghc-proposals/ghc-proposals/pull/682#discussi > > on_r1849123243 > > > 7. [53]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > > 8. > > [54] > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom > > ment-2609199731 > > > 9. mailto:[55]simon.peytonjones at gmail.com > > > 10. mailto:[56]simon.peytonjones at gmail.com > > > 11. > > [57] > https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R > > Phk5MslruY7yXD0/edit?usp=sharing > > > 12. mailto:[58]arnaud.spiwack at tweag.io > > > 13. mailto:[59]arnaud.spiwack at tweag.io > > > 14. mailto:[60]simon.peytonjones at gmail.com > > > 15. mailto:[61]simon.peytonjones at gmail.com > > > 16. > > [62] > https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ > > estreview-2562175116 > > > 17. mailto:[63]arnaud.spiwack at tweag.io > > > 18. mailto:[64]arnaud.spiwack at tweag.io > > > 19. [65]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > > 20. [66]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > > 21. [67]https://moduscreate.com/ > > > 22. [68]https://moduscreate.com/ > > > 23. [69]https://tweag.io/ > > > 24. [70]https://tweag.io/ > > > 25. [71]https://www.well-typed.com/ > > > 26. mailto:[72]ghc-steering-committee at haskell.org > > > 27. > > [73] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > > ommittee > > > 28. mailto:[74]ghc-steering-committee at haskell.org > > > 29. > > [75] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > > ommittee > > > 30. [76]https://moduscreate.com/ > > > 31. [77]https://tweag.io/ > > > 32. [78]http://www.mega-nerd.com/ > > > 33. [79]http://www.mega-nerd.com/ > > > 34. mailto:[80]ghc-steering-committee at haskell.org > > > 35. > > [81] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > > ommittee > > > 36. [82]https://moduscreate.com/ > > > 37. [83]https://tweag.io/ > > > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > [84]ghc-steering-committee at haskell.org > > > > > [85] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > > ommittee > > > > _______________________________________________ > > ghc-steering-committee mailing list > > [86]ghc-steering-committee at haskell.org > > [87] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > > ommittee > > > > _______________________________________________ > > ghc-steering-committee mailing list > > [88]ghc-steering-committee at haskell.org > > [89] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > > ommittee > > > > -- > > Arnaud Spiwack > > Director, Research at [90]https://moduscreate.com and > > [91]https://tweag.io. > > > > -- > > > > Arnaud Spiwack > > Director, Research at [92]https://moduscreate.com and > > [93]https://tweag.io. > > > > -- > > > > Arnaud Spiwack > > Director, Research at [94]https://moduscreate.com and > > [95]https://tweag.io. > > > > -- > > Arnaud Spiwack > > Director, Research at [96]https://moduscreate.com and > > [97]https://tweag.io. > > > > References > > > > 1. mailto:simon.peytonjones at gmail.com > > 2. mailto:arnaud.spiwack at tweag.io > > 3. > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2651558160 > > 4. > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2671436455 > > 5. mailto:arnaud.spiwack at tweag.io > > 6. mailto:arnaud.spiwack at tweag.io > > 7. > https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/proposals/0000-splice-imports.rst#syntactic-alternatives > > 8. mailto:simon.peytonjones at gmail.com > > 9. mailto:malte.ott at maralorn.de > > 10. mailto:erikd at mega-nerd.com > > 11. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > > 12. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > > 13. mailto:simon.peytonjones at gmail.com > > 14. mailto:adam at well-typed.com > > 15. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio > > 16. https://github.com/ghc-proposals/ghc-proposals/pull/682 > > 17. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > > 18. mailto:simon.peytonjones at gmail.com > > 19. mailto:simon.peytonjones at gmail.com > > 20. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R > > 21. mailto:arnaud.spiwack at tweag.io > > 22. mailto:arnaud.spiwack at tweag.io > > 23. mailto:simon.peytonjones at gmail.com > > 24. mailto:simon.peytonjones at gmail.com > > 25. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ > > 26. mailto:arnaud.spiwack at tweag.io > > 27. mailto:arnaud.spiwack at tweag.io > > 28. https://github.com/ghc-proposals/ghc-proposals/pull/682 > > 29. https://github.com/ghc-proposals/ghc-proposals/pull/682 > > 30. https://moduscreate.com/ > > 31. https://moduscreate.com/ > > 32. https://tweag.io/ > > 33. https://tweag.io/ > > 34. https://www.well-typed.com/ > > 35. mailto:ghc-steering-committee at haskell.org > > 36. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > > 37. mailto:ghc-steering-committee at haskell.org > > 38. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > > 39. https://moduscreate.com/ > > 40. https://tweag.io/ > > 41. http://www.mega-nerd.com/ > > 42. http://www.mega-nerd.com/ > > 43. mailto:ghc-steering-committee at haskell.org > > 44. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > > 45. https://moduscreate.com/ > > 46. https://tweag.io/ > > 47. mailto:erikd at mega-nerd.com > > 48. > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > > 49. > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126 > > 50. mailto:simon.peytonjones at gmail.com > > 51. mailto:adam at well-typed.com > > 52. > https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243 > > 53. https://github.com/ghc-proposals/ghc-proposals/pull/682 > > 54. > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > > 55. mailto:simon.peytonjones at gmail.com > > 56. mailto:simon.peytonjones at gmail.com > > 57. > https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing > > 58. mailto:arnaud.spiwack at tweag.io > > 59. mailto:arnaud.spiwack at tweag.io > > 60. mailto:simon.peytonjones at gmail.com > > 61. mailto:simon.peytonjones at gmail.com > > 62. > https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116 > > 63. mailto:arnaud.spiwack at tweag.io > > 64. mailto:arnaud.spiwack at tweag.io > > 65. https://github.com/ghc-proposals/ghc-proposals/pull/682 > > 66. https://github.com/ghc-proposals/ghc-proposals/pull/682 > > 67. https://moduscreate.com/ > > 68. https://moduscreate.com/ > > 69. https://tweag.io/ > > 70. https://tweag.io/ > > 71. https://www.well-typed.com/ > > 72. mailto:ghc-steering-committee at haskell.org > > 73. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 74. mailto:ghc-steering-committee at haskell.org > > 75. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 76. https://moduscreate.com/ > > 77. https://tweag.io/ > > 78. http://www.mega-nerd.com/ > > 79. http://www.mega-nerd.com/ > > 80. mailto:ghc-steering-committee at haskell.org > > 81. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 82. https://moduscreate.com/ > > 83. https://tweag.io/ > > 84. mailto:ghc-steering-committee at haskell.org > > 85. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 86. mailto:ghc-steering-committee at haskell.org > > 87. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 88. mailto:ghc-steering-committee at haskell.org > > 89. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 90. https://moduscreate.com/ > > 91. https://tweag.io/ > > 92. https://moduscreate.com/ > > 93. https://tweag.io/ > > 94. https://moduscreate.com/ > > 95. https://tweag.io/ > > 96. https://moduscreate.com/ > > 97. https://tweag.io/ > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From malte.ott at maralorn.de Thu Mar 6 13:35:43 2025 From: malte.ott at maralorn.de (Malte Ott) Date: Thu, 6 Mar 2025 14:35:43 +0100 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: Message-ID: On 2025-03-06 21:55, Arnaud Spiwack wrote: > My dream would be to rename ImportQualifiedPost to > ImportAnnotationsPost or > something similar and then treat splice exactly as qualified. > Seeing that that’s much too much trouble I would consider doing that > but not > changing the extension name. > > (aside: with ImportQualifiedPost turned, both the `qualified` keyword > before and the `qualified` keyword after are accepted). Oh, thank you. And I see now that that it has to be that way since we enabled it with GHC2021. This makes me less sceptical about the proposed solution. Great, let’s accept it. Best Malte From adam at well-typed.com Fri Mar 7 13:24:55 2025 From: adam at well-typed.com (Adam Gundry) Date: Fri, 7 Mar 2025 13:24:55 +0000 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: Message-ID: <3c574d89-2e15-417a-8a27-b725d6553d39@well-typed.com> I've just discovered that there were a bunch of messages to the mailing list regarding this proposal that were somehow not delivered to me. So apologies for my apparent silence on the syntax question! Regardless, I've marked this proposal as accepted at Arnaud's request (https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2703780627). Cheers, Adam On 09/01/2025 06:31, Arnaud Spiwack wrote: > > Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward > a new proposal for the perenial problem of dependencies and Template > Haskell https://github.com/ghc-proposals/ghc-proposals/pull/682 > > > I've got to be honest, I'm not fully convinced by the proposal. More on > that in a minute, but it learns a lesson from previous attempts at the > same problem by solving the absolute minimal problem, but this leads to > a somewhat fork-like situation for which it isn't clear whether it will > be resolved in the future. That being said, it solves a real problem > which has plagued GHC compilation forever. And I'm inclined to believe > that we can't really do much better. > > But I'm getting ahead of myself. The problem is that when you have > -XTemplateHaskell in a file, all the dependencies' compiled code must > suddenly be available for typechecking. This breaks `-fno-code` and > wounds recompilation avoidance. This is probably the main reason why > it's a widely held belief that Template Haskell is slow: you use > Template Haskell in a few modules, and suddenly your IDE is much less > responsive and you recompile more files. Yay? > > Anyway, the general gist of the solution is clear: we must be able to > specify that we don't want to import a module for Template Haskell > (there is subtleties in this too as you will want a little more control > than that for cross-compilation reasons which I'm not competent about to > comment on). But the devil is in the many details. There's this thing > called implicit cross-stage persistence which says that anything you > import not-for-template-haskell is going to be available in quotes and > splices anyway. Sigh… So you have to turn this off. This is what the > proposal does. And pretty much only. > > They introduce a new extension-XNoImplicitStagePersistence which > disables that, and a little bit of syntax to specify the stage of > imports. That's it. > > But it comes with severe limitations, most importantly: you can't ever > use a symbol defined in the current module in a quote or splice of this > current module, typed template Haskell is turned off. > > For these situations, the proposal kind of advertises using > `-XImplicitStagePersistence`. Which does seem like a fork-like situation > to me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, > and I don't think it's fair to ask of any proposal to entangle it > completely. The failure of past attempts seem to support this case. And > I believe the authors are correct when they claim that this proposal, in > practice, covers a vast majority of the uses of Template Haskell out > there. So maybe we can see that as a new foundation for Template > Haskell. I'm not thrilled about it, but it's probably the most > reasonable way forward. > > The real problem with this sort of proposal is that then I get to write > way too long an email to the committee. Hopefully this didn't deter you. > Read the proposal, and let's vote. > > -- > Arnaud Spiwack > Director, Research at https://moduscreate.com > and https://tweag.io . -- 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 Fri Mar 7 16:43:58 2025 From: adam at well-typed.com (Adam Gundry) Date: Fri, 7 Mar 2025 16:43:58 +0000 Subject: [ghc-steering-committee] ghc-steering-committee mailing list deliverability issues Message-ID: <4ad505be-29c7-413b-ae97-e6157980cfaa@well-typed.com> Hi everyone, It has come to my attention that there are email deliverability issues affecting the ghc-steering-committee at haskell.org mailing list (and probably other haskell.org mailing lists). At least, I have personally not received most email sent to haskell.org lists since mid-February. Has anyone else been affected? You can see what you may have missed in the online list archives: https://mail.haskell.org/pipermail/ghc-steering-committee/ I'm trying to get the issues resolved at the haskell.org level, but it may take some time given limited volunteer administrator bandwidth. Cheers, Adam P.S. Apologies if you receive this twice, as I'm BCCing the whole committee individually. -- 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 mpg at mpg.is Fri Mar 7 17:57:04 2025 From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=) Date: Fri, 7 Mar 2025 18:57:04 +0100 Subject: [ghc-steering-committee] ghc-steering-committee mailing list deliverability issues In-Reply-To: <4ad505be-29c7-413b-ae97-e6157980cfaa@well-typed.com> References: <4ad505be-29c7-413b-ae97-e6157980cfaa@well-typed.com> Message-ID: I have not been receiving any either, and only got this email once! Sorry for my silence. I will review the thread and get back to you all. On Fri, 7 Mar 2025 at 17:43, Adam Gundry wrote: > Hi everyone, > > It has come to my attention that there are email deliverability issues > affecting the ghc-steering-committee at haskell.org mailing list (and > probably other haskell.org mailing lists). At least, I have personally > not received most email sent to haskell.org lists since mid-February. > > Has anyone else been affected? You can see what you may have missed in > the online list archives: > > https://mail.haskell.org/pipermail/ghc-steering-committee/ > > I'm trying to get the issues resolved at the haskell.org level, but it > may take some time given limited volunteer administrator bandwidth. > > Cheers, > > Adam > > P.S. Apologies if you receive this twice, as I'm BCCing the whole > committee individually. > > > -- > 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 > -- -- Matthías Páll Gissurarson -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Mon Mar 10 01:09:53 2025 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Mon, 10 Mar 2025 10:09:53 +0900 Subject: [ghc-steering-committee] ghc-steering-committee mailing list deliverability issues In-Reply-To: <4ad505be-29c7-413b-ae97-e6157980cfaa@well-typed.com> References: <4ad505be-29c7-413b-ae97-e6157980cfaa@well-typed.com> Message-ID: For what it's worth, I've received all of the emails in our archive. (Possibly relatedly, though, a couple of weeks ago, this email of mine [ https://mail.haskell.org/pipermail/ghc-steering-committee/2025-February/004084.html ] appear to have taken a day or so to be received by the mailing list) On Sat, 8 Mar 2025 at 01:44, Adam Gundry wrote: > Hi everyone, > > It has come to my attention that there are email deliverability issues > affecting the ghc-steering-committee at haskell.org mailing list (and > probably other haskell.org mailing lists). At least, I have personally > not received most email sent to haskell.org lists since mid-February. > > Has anyone else been affected? You can see what you may have missed in > the online list archives: > > https://mail.haskell.org/pipermail/ghc-steering-committee/ > > I'm trying to get the issues resolved at the haskell.org level, but it > may take some time given limited volunteer administrator bandwidth. > > Cheers, > > Adam > > P.S. Apologies if you receive this twice, as I'm BCCing the whole > committee individually. > > > -- > 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 > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob.bruenker at gmail.com Mon Mar 10 18:44:48 2025 From: jakob.bruenker at gmail.com (=?UTF-8?Q?Jakob_Br=C3=BCnker?=) Date: Mon, 10 Mar 2025 19:44:48 +0100 Subject: [ghc-steering-committee] ghc-steering-committee mailing list deliverability issues In-Reply-To: <4ad505be-29c7-413b-ae97-e6157980cfaa@well-typed.com> References: <4ad505be-29c7-413b-ae97-e6157980cfaa@well-typed.com> Message-ID: Hi, I can confirm it from my side; just in this thread I got the original email (once) but did not get the followup emails in this thread. I'll keep an eye on the archive for the foreseeable future. Jakob -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Mon Mar 10 20:25:17 2025 From: adam at well-typed.com (Adam Gundry) Date: Mon, 10 Mar 2025 20:25:17 +0000 Subject: [ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept In-Reply-To: References: <414a9ae5-6602-4cc7-9c04-97fd79c90681@well-typed.com> <20241102172853.d250122548113c86708fb24a@mega-nerd.com> Message-ID: <82a60743-3211-48f8-9e99-db603ac4ee6c@well-typed.com> Hi everyone, This proposal [0] has been lingering for quite some time, unfortunately. So we can make progress, I've tried to summarise our options below; please vote for your preferred option in the next week or two. Once we have decided on our preferred course of action, I'll make any necessary editorial changes to the proposal. To recap, the idea is to extend OverloadedRecordDot such that it permits record selection expressions such as foo.type -> getField @"type" foo even though `type` is a keyword and hence not a valid record field in a traditional datatype declarations. This is primarily motivated by the use of OverloadedRecordDot in libraries such as `persistent` (see [1]), which will generate instances like this: instance HasField "type" SomeRecord SomeField1 where getField = ... instance HasField "bar" SomeRecord SomeField2 where getField = ... Both these instances are accepted, so it is quite surprising and annoying that `foo.type` is a syntax error, even though `foo.bar` will be accepted (and turn into a call to `getField @"bar"`). As a small syntactic change, the proposal has lead to quite some discussion and a few plausible alternatives: A. Accept the proposal as it stands, since it is the smallest change that resolves the issue. B. Extend the proposal to permit still wider syntax, e.g. `foo.Uppercase` or `foo."quoted string"`, motivated by consistency with OverloadedLabels and use cases such as [2]. This seems reasonable to me. C. Extend the proposal to permit keywords such as `type` to be used as field names in traditional record syntax, e.g. `data Foo = Foo { type :: Int }`. In my view this is unnecessary complexity that mistakenly conflates OverloadedRecordDot with traditional record syntax; the motivation for keywords as selector names comes from uses of OverloadedRecordDot that do not involve traditional record syntax. D. Reject the proposal entirely, e.g. due to worries about syntax highlighting. Please reply with your preference order amongst these options. My vote is B > A > C > D. Thanks, Adam [0] https://github.com/ghc-proposals/ghc-proposals/pull/668 [1] https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282397 [2] https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274901 On 05/11/2024 13:58, Arnaud Spiwack wrote: > I have no opinion on this. But I've seen two points in the thread which > make sense: Vlad, our guardian of the parser, says that it's a good > idea, and the comparison with OverloadedLabel (made by Vlad and others) > is apt, and the symmetry is desirable. Ideally the comparison with > OverloadedLabel should be made in the Alternatives section, but I don't > feel like insisting about it :) . > > On Sat, 2 Nov 2024 at 21:21, Simon Peyton Jones > > wrote: > > I'm in support too, but I have made some substantive suggestions on > the GitHub ticket that I'd like to see addressed before we tie a bow > on this. > > Simon > > On Sat, 2 Nov 2024 at 09:25, Sebastian Graf > wrote: > > I'm in support as well, but would like to see a single > clarifying sentence added to the proposal. > https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003 > > Am Sa., 2. Nov. 2024 um 07:29 Uhr schrieb Erik de Castro Lopo > >: > > > > I am in support. > > Erik > > Matthías Páll Gissurarson wrote: > > > I’m in support. No need to keep reservations longer than > necessary. > > > > /Matti Palli > > > > > > On Fri, Nov 1, 2024 at 23:22 Malte Ott > > wrote: > > > > > > > > On 2024-10-29 20:12, Adam Gundry wrote: > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/668 > > > > > > > I’m in support. > > > > > > Best > > > Malte > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee at haskell.org > > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > > > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > _______________________________________________ > 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 > > > > -- > Arnaud Spiwack > Director, Research at https://moduscreate.com > and https://tweag.io . > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- 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 malte.ott at maralorn.de Tue Mar 11 09:04:19 2025 From: malte.ott at maralorn.de (Malte Ott) Date: Tue, 11 Mar 2025 10:04:19 +0100 Subject: [ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept Message-ID: > Please reply with your preference order amongst these options. My vote > is B > A > C > D. > > Thanks, > > Adam I have the same preference. When we allow foo."bar baz" The next question is if we want to go crazy the nix way with foo.${bar}" which is the same as getField @bar foo (instead of getField @"bar" foo). Might become interesting with dependent types.^^ This E-Mail isn’t technically a reply, because I haven’t received anything from the mailinglist since your note about the delivery issues. Best, Malte From sgraf1337 at gmail.com Tue Mar 11 19:23:06 2025 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Tue, 11 Mar 2025 20:23:06 +0100 Subject: [ghc-steering-committee] ghc-steering-committee mailing list deliverability issues In-Reply-To: <4ad505be-29c7-413b-ae97-e6157980cfaa@well-typed.com> References: <4ad505be-29c7-413b-ae97-e6157980cfaa@well-typed.com> Message-ID: Hi, It appears I haven't received any mails from the mailing list either. Cheers, Sebastian Am Fr., 7. März 2025 um 17:44 Uhr schrieb Adam Gundry : > Hi everyone, > > It has come to my attention that there are email deliverability issues > affecting the ghc-steering-committee at haskell.org mailing list (and > probably other haskell.org mailing lists). At least, I have personally > not received most email sent to haskell.org lists since mid-February. > > Has anyone else been affected? You can see what you may have missed in > the online list archives: > > https://mail.haskell.org/pipermail/ghc-steering-committee/ > > I'm trying to get the issues resolved at the haskell.org level, but it > may take some time given limited volunteer administrator bandwidth. > > Cheers, > > Adam > > P.S. Apologies if you receive this twice, as I'm BCCing the whole > committee individually. > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgraf1337 at gmail.com Tue Mar 11 19:30:30 2025 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Tue, 11 Mar 2025 20:30:30 +0100 Subject: [ghc-steering-committee] #686: Amendment to MultilineStrings, recommendation: accept Message-ID: I vote accept. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgraf1337 at gmail.com Tue Mar 11 19:50:35 2025 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Tue, 11 Mar 2025 20:50:35 +0100 Subject: [ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept Message-ID: I vote B > A > C > D as well, barring resolution of a small confusion I raised in the proposal discussion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Thu Mar 13 08:58:20 2025 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 13 Mar 2025 08:58:20 +0000 Subject: [ghc-steering-committee] ghc-steering-committee mailing list deliverability issues In-Reply-To: <4ad505be-29c7-413b-ae97-e6157980cfaa@well-typed.com> References: <4ad505be-29c7-413b-ae97-e6157980cfaa@well-typed.com> Message-ID: I'm also not receiving any emails, I got only the original email from Adam in this thread and none of the other replies that are in the archive. Adam - do we know what the problem is? Cheers Simon On Fri, 7 Mar 2025 at 16:44, Adam Gundry wrote: > Hi everyone, > > It has come to my attention that there are email deliverability issues > affecting the ghc-steering-committee at haskell.org mailing list (and > probably other haskell.org mailing lists). At least, I have personally > not received most email sent to haskell.org lists since mid-February. > > Has anyone else been affected? You can see what you may have missed in > the online list archives: > > https://mail.haskell.org/pipermail/ghc-steering-committee/ > > I'm trying to get the issues resolved at the haskell.org level, but it > may take some time given limited volunteer administrator bandwidth. > > Cheers, > > Adam > > P.S. Apologies if you receive this twice, as I'm BCCing the whole > committee individually. > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Thu Mar 13 17:12:00 2025 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 13 Mar 2025 17:12:00 +0000 Subject: [ghc-steering-committee] GHC Steering committee Message-ID: Colleagues Is email service to the GHC Steering Committee now working again? If not, it's a bit of a problem. If this message gets through, presumably it's working. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Fri Mar 14 08:18:37 2025 From: adam at well-typed.com (Adam Gundry) Date: Fri, 14 Mar 2025 08:18:37 +0000 Subject: [ghc-steering-committee] ghc-steering-committee mailing list deliverability issues In-Reply-To: <4ad505be-29c7-413b-ae97-e6157980cfaa@well-typed.com> References: <4ad505be-29c7-413b-ae97-e6157980cfaa@well-typed.com> Message-ID: Hi everyone, Thanks to those who followed up regarding this. There does appear to be an ongoing issue affecting many list members, although apparently not quite all of them (so far about 6 people have reported being affected, while Arnaud has reported he is mostly unaffected). I believe the haskell.org servers are accepting emails bound for the list and storing them in the archives, but presumably are failing to deliver them to some recipients' mailservers due to some kind of misconfiguration. The issue appears to affect both regular list emails and other emails sent by the list management software (e.g. password reminders). An easy way to test if you are affected is to request a password reminder by entering your address at the bottom of this page: https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee I've been in touch with the haskell.org infrastructure admins about this, and they have now given my colleague Ben access to the box, so he can now investigate more closely. Thus I'm hopeful we will see progress soon. In the meantime, please do keep an eye on the archives (https://mail.haskell.org/pipermail/ghc-steering-committee/) and comment on proposals under review on GitHub (https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Apr+is%3Aopen+label%3A%22Pending+committee+review%22). You may also wish to look back at the Explicit Level Imports proposal (https://github.com/ghc-proposals/ghc-proposals/pull/682) which was accepted while the issue was ongoing. Cheers, Adam On 07/03/2025 16:43, Adam Gundry wrote: > Hi everyone, > > It has come to my attention that there are email deliverability issues > affecting the ghc-steering-committee at haskell.org mailing list (and > probably other haskell.org mailing lists). At least, I have personally > not received most email sent to haskell.org lists since mid-February. > > Has anyone else been affected? You can see what you may have missed in > the online list archives: > > https://mail.haskell.org/pipermail/ghc-steering-committee/ > > I'm trying to get the issues resolved at the haskell.org level, but it > may take some time given limited volunteer administrator bandwidth. > > Cheers, > > Adam > > P.S. Apologies if you receive this twice, as I'm BCCing the whole > committee individually. > > -- 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 Fri Mar 14 08:51:24 2025 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 14 Mar 2025 08:51:24 +0000 Subject: [ghc-steering-committee] ghc-steering-committee mailing list deliverability issues In-Reply-To: References: <4ad505be-29c7-413b-ae97-e6157980cfaa@well-typed.com> Message-ID: Adam, Ben I am definitely affected; e.g. I did not receive this one . Thanks for looking into it. I wonder about other email lists on haskell.org, e.g. ghc-devs? Simon On Fri, 14 Mar 2025 at 08:18, Adam Gundry wrote: > Hi everyone, > > Thanks to those who followed up regarding this. There does appear to be > an ongoing issue affecting many list members, although apparently not > quite all of them (so far about 6 people have reported being affected, > while Arnaud has reported he is mostly unaffected). > > I believe the haskell.org servers are accepting emails bound for the > list and storing them in the archives, but presumably are failing to > deliver them to some recipients' mailservers due to some kind of > misconfiguration. The issue appears to affect both regular list emails > and other emails sent by the list management software (e.g. password > reminders). An easy way to test if you are affected is to request a > password reminder by entering your address at the bottom of this page: > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > I've been in touch with the haskell.org infrastructure admins about > this, and they have now given my colleague Ben access to the box, so he > can now investigate more closely. Thus I'm hopeful we will see progress > soon. In the meantime, please do keep an eye on the archives > (https://mail.haskell.org/pipermail/ghc-steering-committee/) and comment > on proposals under review on GitHub > ( > https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Apr+is%3Aopen+label%3A%22Pending+committee+review%22 > ). > > You may also wish to look back at the Explicit Level Imports proposal > (https://github.com/ghc-proposals/ghc-proposals/pull/682) which was > accepted while the issue was ongoing. > > Cheers, > > Adam > > > On 07/03/2025 16:43, Adam Gundry wrote: > > Hi everyone, > > > > It has come to my attention that there are email deliverability issues > > affecting the ghc-steering-committee at haskell.org mailing list (and > > probably other haskell.org mailing lists). At least, I have personally > > not received most email sent to haskell.org lists since mid-February. > > > > Has anyone else been affected? You can see what you may have missed in > > the online list archives: > > > > https://mail.haskell.org/pipermail/ghc-steering-committee/ > > > > I'm trying to get the issues resolved at the haskell.org level, but it > > may take some time given limited volunteer administrator bandwidth. > > > > Cheers, > > > > Adam > > > > P.S. Apologies if you receive this twice, as I'm BCCing the whole > > committee individually. > > > > > > -- > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Fri Mar 14 09:16:04 2025 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 14 Mar 2025 09:16:04 +0000 Subject: [ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept Message-ID: I'm happy to accept this proposal. B > A > C > D. As you'll see on the GitHub thread , I have convinced myself that (C), allowing keywords in traditional record syntax, is untenable. And I really don't think we should reject (D). I'm favouring (B) over (A) for simple consistency reasons; the fewer exceptions the better. Plus at least one person has said the extra generality would be useful. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob.bruenker at gmail.com Mon Mar 17 00:41:04 2025 From: jakob.bruenker at gmail.com (=?UTF-8?Q?Jakob_Br=C3=BCnker?=) Date: Mon, 17 Mar 2025 01:41:04 +0100 Subject: [ghc-steering-committee] #621: Linear constraints, recommendation: accept In-Reply-To: References: Message-ID: Hi all, There has been some discussion on the github thread since I presented this to the committee, but it has now quieted down, so it would be great to get some more opinions from you all on this proposal. So far I've only heard from Sebastian. Thanks, Jakob On Mon, Feb 17, 2025 at 9:40 AM Sebastian Graf wrote: > After multiple lengthy discussions that brought forth examples that IMO > better motivate the proposal, I retract my earlier vote. > However, since there are multiple points of design disagreement between > Arnaud and me, I cannot vote in favour of acceptance either and will > abstain from voting. > > Cheers, > Sebastian > > Am Mo., 20. Jan. 2025 um 10:22 Uhr schrieb Sebastian Graf < > sgraf1337 at gmail.com>: > >> I vote to return the proposal for revision. I listed my feedback in the >> thread >> , >> but the gist is: >> >> While I am sympathetic to the goal of introducing linearity annotations >>> to constraints, simply because it is a logical extension of >>> -XLinearTypes, I am afraid I do not feel motivated after having >>> considered the examples in the proposal. >>> >> In fact, I think the examples overpromise on the utility of linear >>> constraints and the problems it solves have simpler, more direct solutions. >> >> >> Cheers, >> Sebastian >> >> Am Di., 14. Jan. 2025 um 23:45 Uhr schrieb Jakob Brünker < >> jakob.bruenker at gmail.com>: >> >>> Dear committee, >>> >>> Arnaud Spiwack and Jack Hughes propose to introduce linear constraints. >>> >>> These work analogously to linear functions - as can be seen with the new >>> syntax, which is %1 =>, reflecting the existing %1 ->. The motivation is >>> that these constraints make it possible to design linearly typed APIs that >>> are more convenient to use: Without the linear constraints, tokens would >>> have to be passed manually into each function in these cases. >>> >>> The proposal also introduces dupable classes, which can be used multiple >>> times even when they appear in a linear context, but cannot be passed to an >>> unrestricted function. This is necessary to make some API designs work, see >>> the proposal for details. >>> >>> >>> To me, it seems that this proposal or something like it is necessary to >>> unlock the full potential of linear types. The proposal lays out why >>> monadic API designs don't provide the same benefits, and while there are >>> potential future GHC developments that could make using it even more >>> convenient (existential types, strict let improvements; see proposal), I >>> believe it would already be sufficiently useful with today's GHC to be a >>> valuable addition. Thus, I recommend acceptance. >>> >>> Please read through the proposal and voice your opinions. >>> >>> Best, >>> Jakob >>> _______________________________________________ >>> 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 Mar 19 21:45:18 2025 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 19 Mar 2025 21:45:18 +0000 Subject: [ghc-steering-committee] #686: Amendment to MultilineStrings, recommendation: accept In-Reply-To: <5rffpmymva3ejtbipgivtu5hyd4l6nvkvhlkktmjdnrhi6z7mw@hera.m-0.eu> References: <5rffpmymva3ejtbipgivtu5hyd4l6nvkvhlkktmjdnrhi6z7mw@hera.m-0.eu> Message-ID: I support the proposal; I have asked some technical questions on the Github thread. Simon On Wed, 19 Mar 2025 at 21:44, Malte Ott wrote: > Dear committee, > > in > > https://github.com/ghc-proposals/ghc-proposals/pull/686 > > Brandon Chinn proposes to slightly modify the recently accepted > MultilineStrings > proposal: > > "For the calculation of whitespace prefix removal string gaps (i.e. the / > / > syntax) should be regarded as non-whitespace." > > This is technically a breaking change so we should deliberate on it, but I > don’t see > why anyone would come into this situation in the first place, so I don’t > think > we should dwell on this. > > A motivation for the change is that it is easier to implement. I am torn > whether > it is more or less surprising to users, with maybe a small tendency to less > surprising, so I recommend we go with it. > > The committee could decide to be annoying about this. This is a not > strongly > motivated change which theoretically changes the semantics of a released > extension without warnings or compile errors. > > However, the extension would surely count as experimental if we were > already using the > classification we agreed upon. And this tiny change has already been merged > as part of a bug fix and I think we should let this pass out of respect to > our > implementors. > > Please voice your opinions, I aim to declare this proposal accepted in 7 > days. > > Best > Malte > > _______________________________________________ > 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 Mar 19 21:55:00 2025 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 19 Mar 2025 21:55:00 +0000 Subject: [ghc-steering-committee] ghc-steering-committee mailing list deliverability issues In-Reply-To: References: <4ad505be-29c7-413b-ae97-e6157980cfaa@well-typed.com> Message-ID: I believe that Ben has just fixed it. At least, emails have started arriving again Thanks Ben! S On Wed, 19 Mar 2025 at 21:53, Simon Marlow via ghc-steering-committee < ghc-steering-committee at haskell.org> wrote: > I'm also not receiving any emails, I got only the original email from Adam > in this thread and none of the other replies that are in the archive. Adam > - do we know what the problem is? > > Cheers > Simon > > On Fri, 7 Mar 2025 at 16:44, Adam Gundry wrote: > >> Hi everyone, >> >> It has come to my attention that there are email deliverability issues >> affecting the ghc-steering-committee at haskell.org mailing list (and >> probably other haskell.org mailing lists). At least, I have personally >> not received most email sent to haskell.org lists since mid-February. >> >> Has anyone else been affected? You can see what you may have missed in >> the online list archives: >> >> https://mail.haskell.org/pipermail/ghc-steering-committee/ >> >> I'm trying to get the issues resolved at the haskell.org level, but it >> may take some time given limited volunteer administrator bandwidth. >> >> Cheers, >> >> Adam >> >> P.S. Apologies if you receive this twice, as I'm BCCing the whole >> committee individually. >> >> >> -- >> 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 moritz.angermann at gmail.com Wed Mar 19 21:56:36 2025 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Thu, 20 Mar 2025 06:56:36 +0900 Subject: [ghc-steering-committee] ghc-steering-committee mailing list deliverability issues In-Reply-To: References: <4ad505be-29c7-413b-ae97-e6157980cfaa@well-typed.com> Message-ID: Something must have just resolved. I got a LOT of emails at once. On Thu, Mar 20, 2025 at 6:54 AM Simon Peyton Jones via ghc-steering-committee wrote: > Adam, Ben > > I am definitely affected; e.g. I did not receive this one > . > Thanks for looking into it. > > I wonder about other email lists on haskell.org, e.g. ghc-devs? > > Simon > > On Fri, 14 Mar 2025 at 08:18, Adam Gundry wrote: > >> Hi everyone, >> >> Thanks to those who followed up regarding this. There does appear to be >> an ongoing issue affecting many list members, although apparently not >> quite all of them (so far about 6 people have reported being affected, >> while Arnaud has reported he is mostly unaffected). >> >> I believe the haskell.org servers are accepting emails bound for the >> list and storing them in the archives, but presumably are failing to >> deliver them to some recipients' mailservers due to some kind of >> misconfiguration. The issue appears to affect both regular list emails >> and other emails sent by the list management software (e.g. password >> reminders). An easy way to test if you are affected is to request a >> password reminder by entering your address at the bottom of this page: >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> I've been in touch with the haskell.org infrastructure admins about >> this, and they have now given my colleague Ben access to the box, so he >> can now investigate more closely. Thus I'm hopeful we will see progress >> soon. In the meantime, please do keep an eye on the archives >> (https://mail.haskell.org/pipermail/ghc-steering-committee/) and comment >> on proposals under review on GitHub >> ( >> https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Apr+is%3Aopen+label%3A%22Pending+committee+review%22 >> ). >> >> You may also wish to look back at the Explicit Level Imports proposal >> (https://github.com/ghc-proposals/ghc-proposals/pull/682) which was >> accepted while the issue was ongoing. >> >> Cheers, >> >> Adam >> >> >> On 07/03/2025 16:43, Adam Gundry wrote: >> > Hi everyone, >> > >> > It has come to my attention that there are email deliverability issues >> > affecting the ghc-steering-committee at haskell.org mailing list (and >> > probably other haskell.org mailing lists). At least, I have personally >> > not received most email sent to haskell.org lists since mid-February. >> > >> > Has anyone else been affected? You can see what you may have missed in >> > the online list archives: >> > >> > https://mail.haskell.org/pipermail/ghc-steering-committee/ >> > >> > I'm trying to get the issues resolved at the haskell.org level, but it >> > may take some time given limited volunteer administrator bandwidth. >> > >> > Cheers, >> > >> > Adam >> > >> > P.S. Apologies if you receive this twice, as I'm BCCing the whole >> > committee individually. >> > >> > >> >> -- >> 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 Wed Mar 19 22:16:27 2025 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 19 Mar 2025 22:16:27 +0000 Subject: [ghc-steering-committee] #621: Linear constraints, recommendation: accept In-Reply-To: References: Message-ID: I had a long conversation with Arnaud about it. I think he is planning revisions Simon On Wed, 19 Mar 2025 at 21:57, Jakob Brünker via ghc-steering-committee < ghc-steering-committee at haskell.org> wrote: > Hi all, > > There has been some discussion on the github thread since I presented this > to the committee, but it has now quieted down, so it would be great to get > some more opinions from you all on this proposal. So far I've only heard > from Sebastian. > > Thanks, > Jakob > > On Mon, Feb 17, 2025 at 9:40 AM Sebastian Graf > wrote: > >> After multiple lengthy discussions that brought forth examples that IMO >> better motivate the proposal, I retract my earlier vote. >> However, since there are multiple points of design disagreement between >> Arnaud and me, I cannot vote in favour of acceptance either and will >> abstain from voting. >> >> Cheers, >> Sebastian >> >> Am Mo., 20. Jan. 2025 um 10:22 Uhr schrieb Sebastian Graf < >> sgraf1337 at gmail.com>: >> >>> I vote to return the proposal for revision. I listed my feedback in the >>> thread >>> , >>> but the gist is: >>> >>> While I am sympathetic to the goal of introducing linearity annotations >>>> to constraints, simply because it is a logical extension of >>>> -XLinearTypes, I am afraid I do not feel motivated after having >>>> considered the examples in the proposal. >>>> >>> In fact, I think the examples overpromise on the utility of linear >>>> constraints and the problems it solves have simpler, more direct solutions. >>> >>> >>> Cheers, >>> Sebastian >>> >>> Am Di., 14. Jan. 2025 um 23:45 Uhr schrieb Jakob Brünker < >>> jakob.bruenker at gmail.com>: >>> >>>> Dear committee, >>>> >>>> Arnaud Spiwack and Jack Hughes propose to introduce linear constraints. >>>> >>>> These work analogously to linear functions - as can be seen with the >>>> new syntax, which is %1 =>, reflecting the existing %1 ->. The motivation >>>> is that these constraints make it possible to design linearly typed APIs >>>> that are more convenient to use: Without the linear constraints, tokens >>>> would have to be passed manually into each function in these cases. >>>> >>>> The proposal also introduces dupable classes, which can be used >>>> multiple times even when they appear in a linear context, but cannot be >>>> passed to an unrestricted function. This is necessary to make some API >>>> designs work, see the proposal for details. >>>> >>>> >>>> To me, it seems that this proposal or something like it is necessary to >>>> unlock the full potential of linear types. The proposal lays out why >>>> monadic API designs don't provide the same benefits, and while there are >>>> potential future GHC developments that could make using it even more >>>> convenient (existential types, strict let improvements; see proposal), I >>>> believe it would already be sufficiently useful with today's GHC to be a >>>> valuable addition. Thus, I recommend acceptance. >>>> >>>> Please read through the proposal and voice your opinions. >>>> >>>> Best, >>>> Jakob >>>> _______________________________________________ >>>> 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 moritz.angermann at gmail.com Thu Mar 20 00:08:21 2025 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Thu, 20 Mar 2025 09:08:21 +0900 Subject: [ghc-steering-committee] #686: Amendment to MultilineStrings, recommendation: accept In-Reply-To: References: <5rffpmymva3ejtbipgivtu5hyd4l6nvkvhlkktmjdnrhi6z7mw@hera.m-0.eu> Message-ID: I support this as well! On Thu, 20 Mar 2025 at 07:09, Simon Peyton Jones via ghc-steering-committee wrote: > I support the proposal; I have asked some technical questions on the > Github thread. > > Simon > > On Wed, 19 Mar 2025 at 21:44, Malte Ott wrote: > >> Dear committee, >> >> in >> >> https://github.com/ghc-proposals/ghc-proposals/pull/686 >> >> Brandon Chinn proposes to slightly modify the recently accepted >> MultilineStrings >> proposal: >> >> "For the calculation of whitespace prefix removal string gaps (i.e. the >> / / >> syntax) should be regarded as non-whitespace." >> >> This is technically a breaking change so we should deliberate on it, but >> I don’t see >> why anyone would come into this situation in the first place, so I don’t >> think >> we should dwell on this. >> >> A motivation for the change is that it is easier to implement. I am torn >> whether >> it is more or less surprising to users, with maybe a small tendency to >> less >> surprising, so I recommend we go with it. >> >> The committee could decide to be annoying about this. This is a not >> strongly >> motivated change which theoretically changes the semantics of a released >> extension without warnings or compile errors. >> >> However, the extension would surely count as experimental if we were >> already using the >> classification we agreed upon. And this tiny change has already been >> merged >> as part of a bug fix and I think we should let this pass out of respect >> to our >> implementors. >> >> Please voice your opinions, I aim to declare this proposal accepted in 7 >> days. >> >> Best >> Malte >> >> _______________________________________________ >> 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 moritz.angermann at gmail.com Thu Mar 20 00:52:34 2025 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Thu, 20 Mar 2025 09:52:34 +0900 Subject: [ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept In-Reply-To: <82a60743-3211-48f8-9e99-db603ac4ee6c@well-typed.com> References: <414a9ae5-6602-4cc7-9c04-97fd79c90681@well-typed.com> <20241102172853.d250122548113c86708fb24a@mega-nerd.com> <82a60743-3211-48f8-9e99-db603ac4ee6c@well-typed.com> Message-ID: Hi all, I'm really torn on the syntax in B. #"..." I can get behind, but ."..." feels really odd. I can see the argument for consistency though. Hence there is no clear preference between A and B to me: A = B > C > D Best, Moritz On Thu, 20 Mar 2025 at 06:49, Adam Gundry via ghc-steering-committee < ghc-steering-committee at haskell.org> wrote: > Hi everyone, > > This proposal [0] has been lingering for quite some time, unfortunately. > So we can make progress, I've tried to summarise our options below; > please vote for your preferred option in the next week or two. Once we > have decided on our preferred course of action, I'll make any necessary > editorial changes to the proposal. > > To recap, the idea is to extend OverloadedRecordDot such that it permits > record selection expressions such as > > foo.type -> getField @"type" foo > > even though `type` is a keyword and hence not a valid record field in a > traditional datatype declarations. This is primarily motivated by the > use of OverloadedRecordDot in libraries such as `persistent` (see [1]), > which will generate instances like this: > > instance HasField "type" SomeRecord SomeField1 where > getField = ... > > instance HasField "bar" SomeRecord SomeField2 where > getField = ... > > Both these instances are accepted, so it is quite surprising and > annoying that `foo.type` is a syntax error, even though `foo.bar` will > be accepted (and turn into a call to `getField @"bar"`). > > As a small syntactic change, the proposal has lead to quite some > discussion and a few plausible alternatives: > > A. Accept the proposal as it stands, since it is the smallest change > that resolves the issue. > > B. Extend the proposal to permit still wider syntax, e.g. > `foo.Uppercase` or `foo."quoted string"`, motivated by consistency with > OverloadedLabels and use cases such as [2]. This seems reasonable to me. > > C. Extend the proposal to permit keywords such as `type` to be used as > field names in traditional record syntax, e.g. `data Foo = Foo { type :: > Int }`. In my view this is unnecessary complexity that mistakenly > conflates OverloadedRecordDot with traditional record syntax; the > motivation for keywords as selector names comes from uses of > OverloadedRecordDot that do not involve traditional record syntax. > > D. Reject the proposal entirely, e.g. due to worries about syntax > highlighting. > > Please reply with your preference order amongst these options. My vote > is B > A > C > D. > > Thanks, > > Adam > > > [0] https://github.com/ghc-proposals/ghc-proposals/pull/668 > > [1] > > https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282397 > > [2] > > https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274901 > > > > On 05/11/2024 13:58, Arnaud Spiwack wrote: > > I have no opinion on this. But I've seen two points in the thread which > > make sense: Vlad, our guardian of the parser, says that it's a good > > idea, and the comparison with OverloadedLabel (made by Vlad and others) > > is apt, and the symmetry is desirable. Ideally the comparison with > > OverloadedLabel should be made in the Alternatives section, but I don't > > feel like insisting about it :) . > > > > On Sat, 2 Nov 2024 at 21:21, Simon Peyton Jones > > > > wrote: > > > > I'm in support too, but I have made some substantive suggestions on > > the GitHub ticket that I'd like to see addressed before we tie a bow > > on this. > > > > Simon > > > > On Sat, 2 Nov 2024 at 09:25, Sebastian Graf > > wrote: > > > > I'm in support as well, but would like to see a single > > clarifying sentence added to the proposal. > > > https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003 > < > https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003 > > > > > > Am Sa., 2. Nov. 2024 um 07:29 Uhr schrieb Erik de Castro Lopo > > >: > > > > > > > > I am in support. > > > > Erik > > > > Matthías Páll Gissurarson wrote: > > > > > I’m in support. No need to keep reservations longer than > > necessary. > > > > > > /Matti Palli > > > > > > > > > On Fri, Nov 1, 2024 at 23:22 Malte Ott > > > > wrote: > > > > > > > > > > > On 2024-10-29 20:12, Adam Gundry wrote: > > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/668 > > > > > > > > > > I’m in support. > > > > > > > > Best > > > > Malte > > > > _______________________________________________ > > > > ghc-steering-committee mailing list > > > > ghc-steering-committee at haskell.org > > > > > > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee < > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> > > > > > > > > > > -- > > > ---------------------------------------------------------------------- > > Erik de Castro Lopo > > http://www.mega-nerd.com/ > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee < > 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 < > 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 < > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> > > > > > > > > -- > > Arnaud Spiwack > > Director, Research at https://moduscreate.com > > and https://tweag.io . > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > -- > 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 erikd at mega-nerd.com Thu Mar 20 01:21:23 2025 From: erikd at mega-nerd.com (Erik de Castro Lopo) Date: Thu, 20 Mar 2025 12:21:23 +1100 Subject: [ghc-steering-committee] GHC Steering committee In-Reply-To: References: Message-ID: <20250320122123.d054df04b7b1388c2f925581@mega-nerd.com> Simon Peyton Jones via ghc-steering-committee wrote: > Colleagues > > Is email service to the GHC Steering Committee now working again? If not, > it's a bit of a problem. > > If this message gets through, presumably it's working. Yes, I received about 30 emails from this list overnight. Will not get time to read them until this evening though. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From mpg at mpg.is Thu Mar 20 09:48:25 2025 From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=) Date: Thu, 20 Mar 2025 10:48:25 +0100 Subject: [ghc-steering-committee] GHC Steering committee In-Reply-To: <20250320122123.d054df04b7b1388c2f925581@mega-nerd.com> References: <20250320122123.d054df04b7b1388c2f925581@mega-nerd.com> Message-ID: Yes, finally! /Matti Palli On Thu, Mar 20, 2025 at 02:21 Erik de Castro Lopo via ghc-steering-committee wrote: > Simon Peyton Jones via ghc-steering-committee wrote: > > > Colleagues > > > > Is email service to the GHC Steering Committee now working again? If > not, > > it's a bit of a problem. > > > > If this message gets through, presumably it's working. > > Yes, I received about 30 emails from this list overnight. Will not get > time to read them until this evening though. > > Erik > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > _______________________________________________ > 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 marlowsd at gmail.com Thu Mar 20 10:04:20 2025 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 20 Mar 2025 10:04:20 +0000 Subject: [ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept In-Reply-To: <82a60743-3211-48f8-9e99-db603ac4ee6c@well-typed.com> References: <414a9ae5-6602-4cc7-9c04-97fd79c90681@well-typed.com> <20241102172853.d250122548113c86708fb24a@mega-nerd.com> <82a60743-3211-48f8-9e99-db603ac4ee6c@well-typed.com> Message-ID: I don't feel all that strongly except that C seems like a bad idea. A = B > D > C Cheers Simon On Wed, 19 Mar 2025 at 21:49, Adam Gundry via ghc-steering-committee < ghc-steering-committee at haskell.org> wrote: > Hi everyone, > > This proposal [0] has been lingering for quite some time, unfortunately. > So we can make progress, I've tried to summarise our options below; > please vote for your preferred option in the next week or two. Once we > have decided on our preferred course of action, I'll make any necessary > editorial changes to the proposal. > > To recap, the idea is to extend OverloadedRecordDot such that it permits > record selection expressions such as > > foo.type -> getField @"type" foo > > even though `type` is a keyword and hence not a valid record field in a > traditional datatype declarations. This is primarily motivated by the > use of OverloadedRecordDot in libraries such as `persistent` (see [1]), > which will generate instances like this: > > instance HasField "type" SomeRecord SomeField1 where > getField = ... > > instance HasField "bar" SomeRecord SomeField2 where > getField = ... > > Both these instances are accepted, so it is quite surprising and > annoying that `foo.type` is a syntax error, even though `foo.bar` will > be accepted (and turn into a call to `getField @"bar"`). > > As a small syntactic change, the proposal has lead to quite some > discussion and a few plausible alternatives: > > A. Accept the proposal as it stands, since it is the smallest change > that resolves the issue. > > B. Extend the proposal to permit still wider syntax, e.g. > `foo.Uppercase` or `foo."quoted string"`, motivated by consistency with > OverloadedLabels and use cases such as [2]. This seems reasonable to me. > > C. Extend the proposal to permit keywords such as `type` to be used as > field names in traditional record syntax, e.g. `data Foo = Foo { type :: > Int }`. In my view this is unnecessary complexity that mistakenly > conflates OverloadedRecordDot with traditional record syntax; the > motivation for keywords as selector names comes from uses of > OverloadedRecordDot that do not involve traditional record syntax. > > D. Reject the proposal entirely, e.g. due to worries about syntax > highlighting. > > Please reply with your preference order amongst these options. My vote > is B > A > C > D. > > Thanks, > > Adam > > > [0] https://github.com/ghc-proposals/ghc-proposals/pull/668 > > [1] > > https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282397 > > [2] > > https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274901 > > > > On 05/11/2024 13:58, Arnaud Spiwack wrote: > > I have no opinion on this. But I've seen two points in the thread which > > make sense: Vlad, our guardian of the parser, says that it's a good > > idea, and the comparison with OverloadedLabel (made by Vlad and others) > > is apt, and the symmetry is desirable. Ideally the comparison with > > OverloadedLabel should be made in the Alternatives section, but I don't > > feel like insisting about it :) . > > > > On Sat, 2 Nov 2024 at 21:21, Simon Peyton Jones > > > > wrote: > > > > I'm in support too, but I have made some substantive suggestions on > > the GitHub ticket that I'd like to see addressed before we tie a bow > > on this. > > > > Simon > > > > On Sat, 2 Nov 2024 at 09:25, Sebastian Graf > > wrote: > > > > I'm in support as well, but would like to see a single > > clarifying sentence added to the proposal. > > > https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003 > < > https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003 > > > > > > Am Sa., 2. Nov. 2024 um 07:29 Uhr schrieb Erik de Castro Lopo > > >: > > > > > > > > I am in support. > > > > Erik > > > > Matthías Páll Gissurarson wrote: > > > > > I’m in support. No need to keep reservations longer than > > necessary. > > > > > > /Matti Palli > > > > > > > > > On Fri, Nov 1, 2024 at 23:22 Malte Ott > > > > wrote: > > > > > > > > > > > On 2024-10-29 20:12, Adam Gundry wrote: > > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/668 > > > > > > > > > > I’m in support. > > > > > > > > Best > > > > Malte > > > > _______________________________________________ > > > > ghc-steering-committee mailing list > > > > ghc-steering-committee at haskell.org > > > > > > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee < > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> > > > > > > > > > > -- > > > ---------------------------------------------------------------------- > > Erik de Castro Lopo > > http://www.mega-nerd.com/ > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee < > 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 < > 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 < > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> > > > > > > > > -- > > Arnaud Spiwack > > Director, Research at https://moduscreate.com > > and https://tweag.io . > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > -- > 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 ben at well-typed.com Thu Mar 20 15:54:26 2025 From: ben at well-typed.com (Ben Gamari) Date: Thu, 20 Mar 2025 11:54:26 -0400 Subject: [ghc-steering-committee] Haskell.org mailing list status Message-ID: <878qozsnod.fsf@smart-cactus.org> Hi all, As you may have noticed, yesterday brought an unexpected influx of traffic from haskell.org's mailing lists. This was the result of fixing an interruption in mailing list message delivery which began in late February as a result of on-going infrastructure migration efforts. We are monitoring the situation to ensure that this issue does not recur but if you see anything amiss don't hesitate to contact admin at haskell.org. Thank you for your understanding and help! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 861 bytes Desc: not available URL: From marlowsd at gmail.com Thu Mar 20 16:00:54 2025 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 20 Mar 2025 16:00:54 +0000 Subject: [ghc-steering-committee] Haskell.org mailing list status In-Reply-To: <878qozsnod.fsf@smart-cactus.org> References: <878qozsnod.fsf@smart-cactus.org> Message-ID: Thanks for sorting it out Ben! On Thu, 20 Mar 2025 at 15:54, Ben Gamari via ghc-steering-committee < ghc-steering-committee at haskell.org> wrote: > Hi all, > > As you may have noticed, yesterday brought an unexpected influx of > traffic from haskell.org's mailing lists. This was the result of fixing > an interruption in mailing list message delivery which began in late > February as a result of on-going infrastructure migration efforts. > > We are monitoring the situation to ensure that this issue does not recur > but if you see anything amiss don't hesitate to contact > admin at haskell.org. > > Thank you for your understanding and help! > > Cheers, > > - Ben > _______________________________________________ > 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: