4 ms·
What you are describing is essentially higher-kinded types (HKT). It is known that we want this, but it's probably going to happen post-1.0.
by jmgrosen 12y ago
What you are describing is essentially higher-kinded types (HKT). It is known that we want this, but it's probably going to happen post-1.0.
- Bougainville 12y agoShouldn't this happen before 1.0, so that the standard library can be designed to make use of it before it's frozen?
- dbaupp 12y agoThe standard library is not being frozen as a whole at 1.0, we are only providing strong backwards compatibility guarantees about the language itself. There are precise markers and compiler diagnostics that individual parts of the standard library will use to convey their stability properties (including graceful deprecation warnings).
- Bougainville 12y ago> The standard library is not being frozen as a whole at 1.0, we are only providing strong backwards compatibility guarantees about the language itself. That's unfortunate. :( Which version will have a full backwards compatibility guarantee?
- pcwalton 12y agoI don't think it matters whether the full standard library is marked stable. What matters is whether the portion of the standard library that you're using in your particular app is stable. To that end, we have a lot of tooling to make sure that you can stay within the stable parts of the standard library if you wish. Version 1.0 will have enough of a stable base for most apps. Freezing the entire standard library in one fell swoop would freeze design mistakes, and delaying 1.0 until we're sure about every last symbol in every last library would delay 1.0 for no reason. I'm confident in our approach.
- Bougainville 12y ago> I don't think it matters whether the full standard library is marked stable. For example, unless IO is stable no serious program can be written. But IO would benefit from monads and HKT.
- pcwalton 12y agotry! is good enough for 1.0.