has anyone ever researched/documented the interaction between encoding a large number of effects/dependent-types and API evolution? I'm concerned "usable" forms require lots of inference, which means lots of potential breaking changes to public APIs.
Conversation
Or even without inference, public APIs have to encode lots of incidental facts you wouldn't normally document that dramatically constrain the implementation.
2
4
Example in Rust: there's arguments for encoding: allocation, nounwind, simd (and which parts), float usage, atomic usage, i/o, purity, constexpr, thread-affinity, and probably others. This is a lot of things to guarantee/care about!
4
8
Not sure if you saw my retweet thread, but as I said there, I would assume changing effects should be a breaking API change anyway, but we're just getting away with it because it's not in our types at the moment:
Quote Tweet
Not sure if there has been any experience with adding and removing them. But then, shouldn't one be worried about that anyway if you are maintaining a library? While not specified by your types (without effects), they might inadvertently break your consumers anyway.
Show this thread
I think there is a UX problem though - I don't necessarily want to see all that information all of the time, depending on my domain. But for some domains it's critical. 🤔 - makes me wish for more powerful code editors that and give you 'perspectives' on APIs, perhaps.
Replying to
Eh, some effects are Very Niche but hoisting them to the type system suddenly makes everyone’s project stop building even if they don’t care about the niche effect
1
I would be interested to see how OCaml are planning to migrate to effects. Perhaps there are some ideas there. Not sure if they are just going to let things fragment though 🙄
2
2
Show replies