purescript / governance

22 stars 2 forks source link

Clarify guidelines for when to accept new features into core libraries #12

Open JordanMartinez opened 3 years ago

JordanMartinez commented 3 years ago

In purescript/purescript-arrays#212, we received a PR that added the function, sliding :: Int -> Int -> Array a -> Array (NonEmptyArray a) to the repo. Harry brought up some good points here about how to think through such PRs and whether to merge them. However, the main question that I think worth focusing on is what Harry said here:

as an aside: I think it might be nice to adopt a system like Rust's stability annotations which would make it much easier to iterate on things within the core libraries without introducing too much ecosystem churn, but that's probably quite a big project.

In my understanding, the goal of such annotations is to clearly mark which APIs are stable and won't change and which are unstable and could change drastically. If an API is marked unstable, then we can change it as necessary without needing to make a new breaking change, which typically happens when a breaking-changes compiler release is made. Since we don't currently have annotations in the language, there are a few ways we could implement this idea:

  1. Create an entirely new library outside of core that follows some naming convention (e.g. purescript-arrays-unstable). I don't think I see anything good with this approach because it adds yet another library that has to be maintained and released.
  2. Add a new module to current core libraries called <Module Prefix>.Unstable. Anything inside this module can change before it gets "stabilized" by moving it from the Unstable module to the normal module. Also, any such changes don't count as breaking. Unfortunately, this approach won't work well in some cases if cyclical dependencies arose between modules.
  3. Add another empty type class like DebugWarning called UnstableAPI that notifies someone that the API is unstable. Ideally, this class would be defined in prelude so it can be used by all other libraries. This has similar benefits of the Unstable module idea without the module drawback

The third approach above seems like the best tradeoff.

hdgarrood commented 3 years ago

I think this would really need proper language support, not something bolted on via type classes. We should be able to annotate all kinds of declarations as unstable - data types, type classes, and so on, not just values. I think ideally we’d use something like https://discourse.purescript.org/t/adding-syntax-for-annotations-on-declarations/988