Skip to content

Latest commit

 

History

History
62 lines (50 loc) · 4.53 KB

2022-10-03.md

File metadata and controls

62 lines (50 loc) · 4.53 KB

SWG 2022-10-03

Meeting URL: https://meet.jit.si/StableHaskellMeetBiWeekly

Previous meeting notes

Agenda

  • Left from last time
  • New items
    • Organizing impact as discussed in this thread
  • Updates on in-progress work
  • GHC API: following the Haskell Implementors Workshop and Haskell Symposium, David C offered to convene a working group to work out what kind of more stable GHC API would be most useful -- GHC as a library.
    • At the moment it is not clear what the GHC API is (except for "every module in GHC" which is unhelpful).
    • Having a clear API would make it much easier to use, much easier for GHC devs to know what APIs are public (and hence with a high stablity threshold) and which are entirely internal to GHC (and hence can be changed at will).
    • We hope that this group's product will be a useful resource to GHC development going forward, and that the group can serve as a source of feedback

Notes of meeting

  • CLC proposal to warn on head/tail would break users of -Werror.

    • How concerned should be we about breaking libraries that use -Werrror?
    • GHC proposal about user-defined-warnings
    • GHC proposal about Warning pragmas with categories This would allow users to disable specific warnings (eg. those for head and tail).
    • Our role: we could (say) identify a GHC Proposal that would really help to smooth the path for otherwise-sensible CLC proposals.

  • Organizing impact as discussed in this thread

    • Can we provide a framework for considering impact to the community?
    • Outcome: a markdown file in our repo.
    • Include: a list of implied priorities for each "slice" of users.
    • David will create the file; Trevis will make the "list of implied priorities"

  • GHC.X.Hackage second draft.

    • No new developments; awaiting Ben.
    • But a putative consensus that Something Should Be Done, and roughly what.
    • David will talk to Ben about what to do next

  • GHC tick-tock releases.

    • No consensus of "user voice" has emerged here. So let's just park this (unless Ben wants to pursue it).

  • GHC API

    • Have a separate ghc-api package? Or a subset of modules in the ghc package that are advertised as stable.
      • An issue driving this is that ghc the library and ghc the application share versions.
    • Could we collect from the community which parts of ghc are used?
    • How does this group interact with the new working group?

  • Update on Language/compiler features to help stability

  • Exposing package internals

    • Neither Simon nor Richard has enough cycles to actively push this.
    • There have been surprisingly mixed reactions
    • Several people have said "just use a convention" e.g. "it's unstable if it has Internal in the module name"
    • SPJ's suggestion: park this pending more user pressure. Encourage the GHC folk articulate a policy about what is public API for ghc-prim and base libraries.
    • Trevis has ideas, but is unsure how to amend the proposal to fit or if we should open new proposal(s).

  • GHC warning policy document as discussed previously