You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
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.
The text was updated successfully, but these errors were encountered:
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
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: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:
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.<Module Prefix>.Unstable
. Anything inside this module can change before it gets "stabilized" by moving it from theUnstable
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.DebugWarning
calledUnstableAPI
that notifies someone that the API is unstable. Ideally, this class would be defined inprelude
so it can be used by all other libraries. This has similar benefits of theUnstable
module idea without the module drawbackThe third approach above seems like the best tradeoff.
The text was updated successfully, but these errors were encountered: