February 2025 - ghc-steering-committee

#668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept
by Adam Gundry 11 Apr '25

11 Apr '25

Dear Committee, In the interests of getting things moving on proposal #668 from Matt Parsons, I'll shepherd it myself, and recommend we accept it. https://github.com/ghc-proposals/ghc-proposals/pull/668 This is a small amendment to the OverloadedRecordDot extension to allow reserved identifiers as field names. For example, this program is currently rejected with a parse error, but would be accepted: import GHC.Records x = foo.type -- parse error, "type" is a reserved identifier data T = MkT Int foo = MkT 42 instance HasField "type" T Int where getField (MkT x) = x While "type" is not a valid field name in a traditional Haskell record data type, there is nothing stopping a user defining their own instance for `HasField "type" r a`, and some users would like to do so (e.g. when using HasField to interface with a database). Attempting to use such an instance with OverloadedRecordDot runs into this parse error. However the presence of the dot syntax means there is no ambiguity in what the user means. Even if a user wrote `x.type` by accident, they are likely to get better diagnostic information if the parser accepts the program. The only issue I see is that some syntax highlighters unaware of this change may incorrectly highlight such record projections as keywords. Please indicate whether you are happy to accept this proposal. 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

10 17

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

19 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

#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