Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
JordanMartinez opened this issue Apr 25, 2021 · 1 comment

Comments

@JordanMartinez
Copy link
Contributor

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants