Skip to content

Latest commit

 

History

History
80 lines (63 loc) · 5.24 KB

2023-01-23.md

File metadata and controls

80 lines (63 loc) · 5.24 KB

SWG 2023-01-23

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

Previous meeting notes

Agenda & Notes

New items

  • John Ericson's base reform proposal

    • base contains lots of stuff; merit in separating these
      • Basic types like Char
      • I/O library stuff...
      • ...some of which is platform specific
      • Parts of GHC internals (if you are going to depend on these, you should do so consciously; see CLC issue #105.
    • Danger of revolution: high risk of breaking stuff
    • Try to make incremental progress as a way to de-risk
    • e.g. keep base as a wrapper that re-exports a number of smaller, more focused libraries
    • Will incur costs as we design what goes where -- and may change our minds over time.
    • It would help to have a mechanical check that we have not accidentally change the API.
    • Why separate packages rather than just exposed/not-exposed? Answer: because people really do sometimes want to depend on GHC-specific internals.
    • Thought: Enhance cabal check to allow a pvp check as a way to mechanically enforce stability with this change.
    • SPJ asks: any actions here?
      • Explore funding the cabal enhancement?
      • Chris will post a summary of this converation to the thread.
      • HF technical proposals process is the driving force here.

  • The response thread to the GHC medium-term priorities

    • Release cadence /= breakage cadence
    • SPJ wonders: what % of the breakage is due to
      • library changes (addressable by head.hackage mechanism)
      • incompatible language changes, not protected by a language pragma.
      • tools lagging the compiler version We could really do with more specifics, precision, war stories.
    • David: often you transitively depend on something that is somehow closely coupled to GHC internals. [SPJ: it's hard to see how to avoid that.]
    • Key goal: being able to write code that works on old and new (preferably without CPP, but even with CPP is bearable).
    • A serious cost of a faster release cadence is maintaining and applying backports.
      • A "release" means a curated branch, which the GHC team is committed to
        • proactively testing on multiple architectures, and testing against multiple libraries across Hackage.
        • bug-fixing, back-porting bug-fixes from HEAD, and re-releasing
      • GHC team simply cannot do a faster cadence of releases (minor releases come out every 2 months anyway)
      • If you want a fast cadence, use nightly builds.
      • If the nightly builds don't do the job for you, let's talk about would make them better for you.
    • Moritz Angermann explains in detail the problems that breaking changes cause for industrial users:

  • Small breaking changes: are some breaking changes too small to matter?

  • David will talk to Julian about ghcup and nightlies. It should be easy to get a nightly-build GHC onto your machine.

  • GHC.X.Hackage has a role to play here; if a new release of GHC comes with a Hackage overlay for a signficant fraction (by usage) of Hackage, that would make the painful-upgrade problem way way easier.

Updates on in-progress work

Parked for expected absence of token holder

For next week