- ghc-steering-committee

Re: [ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept
by Sebastian Graf 14 Apr '25

14 Apr '25

I vote B > A > C > D as well, barring resolution of a small confusion I raised in the proposal discussion.

2 1

Haskell.org mailing list status
by Ben Gamari 20 Mar '25

20 Mar '25

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(a)haskell.org. Thank you for your understanding and help! Cheers, - Ben

2 1

GHC Steering committee
by Simon Peyton Jones 20 Mar '25

20 Mar '25

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

3 2

#686: Amendment to MultilineStrings, recommendation: accept
by Malte Ott 20 Mar '25

20 Mar '25

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

3 2

#621: Linear constraints, recommendation: accept
by Jakob Brünker 20 Mar '25

20 Mar '25

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

3 4

ghc-steering-committee mailing list deliverability issues
by Adam Gundry 20 Mar '25

20 Mar '25

Hi everyone, It has come to my attention that there are email deliverability issues affecting the ghc-steering-committee(a)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

8 9

#668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept
by Simon Peyton Jones 14 Mar '25

14 Mar '25

I'm happy to accept this proposal. B > A > C > D. As you'll see on the GitHub thread <https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-272406…>, 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

1 0

Re: [ghc-steering-committee] #686: Amendment to MultilineStrings, recommendation: accept
by Sebastian Graf 12 Mar '25

12 Mar '25

I vote accept.

1 0

Re: [ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept
by Malte Ott 11 Mar '25

11 Mar '25

> 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

1 0

#682: Explicit Level Imports, recommendation: accept
by Arnaud Spiwack 07 Mar '25

07 Mar '25

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.

9 38