Skip to content

Latest commit

 

History

History
89 lines (71 loc) · 5.24 KB

2023-02-20.md

File metadata and controls

89 lines (71 loc) · 5.24 KB

SWG 2023-02-20

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

Previous meeting notes

Agenda & Notes

Action Items From Previous

  • David will talk to Julian about ghcup and nightlies.

    • Need update from David.

  • Trevis: Create a CLC issue for a stability field package

    • Each module in base has a "stability" field, but it is free-form text, and no one knows quite what it means, and how to use it.

      • Step 1: grep the "stability" field for every module in Hackage. Here is a preliminary list

      • Seek patterns/consensus.

      • Step 2: discuss (in this group) what a good proposal for an enumeration of values for th stability field.

      • Step 3: make a proposal to CLC

      • Question: is "stability" the main point here? Our goal is to distinguish three kinds of module:

        • Non-exposed; no one can import this module
        • Exposed and external: this API is intended to be stable; specifically, it is subject to the PVP (major bump)
        • Exposed and internal: this API can be imported by client, but should be regarded as part of the package's implementation; not subject to the PVP (i.e. only minor bump)

        A module could be exposed-and-external, but nevertheless under development (not very stable), and the author might perhaps want to signal that via the stablity field.

      • Instead of proposing a hackage-wide change, let's start with a specific case:

        • Categorise each module in base. Here is Ben's draft. (Necessarily a compromise; since we expose everything right now, making any module "exposed-but-internal" is potentially a breaking change.)
        • Invite the CLC and others to suggest how we might encode this classification in a machine-readable manner (e.g. use stablity field, split into two packages, invent a new field)
        • Draft text here https://edit.smart-cactus.org/EjfMUGhOSzCnGpEsGLR4iA?edit#
        • Include columns for "Eventual goal" and "Proposed first step"
        • Need to think about deprecations cycles: we'd like to be able to mark a module in such a way that you get a warning if you import it (unless perhaps you suppress the warning at the import site); and the warning should suggest what other module you should import instead.

  • Ben: Carry base stability proposal to CLC

New items to discuss

  • Stablizing Template Haskell
    • Constructing syntax trees:
      • Encourage using quotations instead
      • When not possible, perhap use smart constructors
      • But when, specifically, is it not possible to use quotations?
    • Pattern matching on syntax trees:
      • What proportion of TH clients actually analyse (patttern-match on) TH syntax and why?
      • We think perhaps many analyse data type decls; and few analyse expressions.
      • Maybe an API to TH data decls would do the job.
      • Pattern synonyms could play a role, but they don't have to constitue the whole API.
      • John Ericson has a GHC proposal to allow TH quotes in patterns
    • We believe there is a relatively stable api to cover ~95% of use cases
    • Representative TH users:
      • vector-th-unbox
      • aeson
      • lens
      • optics
      • QuickCheck
      • mustache
      • tasty-discover?
    • Task (Trevis):
      • Examine representive TH users for how much effort is it to use th-abstraction
    • Task (Ben):
      • Engage with Eric Mertens and ask whether he agrees with our goal (we want to discourage direct use of the TH syntax data type; prefer quotes and abstractions); perhaps he wants to join a meeting

In progress projects

Updates

Parked for expected absence of token holder

For next week

Action Items

Discussion items