[Caml-list] Language feature stability levels

[Caml-list] Language feature stability levels

[Yotam Barnoy]

[-- Attachment #1: Type: text/plain, Size: 3493 bytes --]

One thing I've noticed over my time with ocaml and observing its
development, is that there's some confusion and difficulty with regard to
the introduction of new features. Some features are introduced with an
obscure note in the manual stating that they could change in future ocaml
versions. Others are introduced rapidly in one version and then cause
backwards-compatibility problems for future language expansions. Still
others take very long to integrate into the language. I'm wondering if it
makes sense to make levels of integration into the language more official,
and in the process, make it easier to introduce new features while giving
users feedback about feature stability.

The basic problem, as I see it, is that when features are written into the
language, there's no good way for the authors to know how much these
features will be used by programmers, or whether they'll cause
complications in existing or future code. This gap between feature
introduction and feature testing isn't currently accounted for in ocaml's
development cycles.

On the other hand, some features that would benefit from quick introduction
to the users (as well as testing) get stuck in development hell because the
language developers are overly conservative, trying to puzzle out whether
the feature will be useful and consistent many years in the future, without
the advantage of existing long-term user testing.

Haskell has language extensions which, despite some negative effects, such
as language bloat and bad backwards-compatibility, allow haskell to develop
very quickly. A new feature is introduced under a language extension, which
must be activated on a per-file basis. If people like it, the extension
will survive to live in future versions. If not enough people use it or the
feature is shown to be ineffective, the feature can be pruned out in future
versions. The overall result is that haskell is very nimble, developing at
a rapid clip and easily satiating user demands.

While I'm not suggesting playing it fast and loose like haskell, perhaps it
makes sense to have stages of integration into the language. I suggest 3
stages, borrowing the terminology from software release cycles (but
perfectly willing to use other terminology or number of stages). An alpha
feature is one that was just introduced, and is still likely to change in
future versions. An alpha feature that has survived enough ocaml version
iterations and seems useful and complete can move into beta level. I
foresee features spending a long time in the beta state, which also
guarantees the users a further level of stability over alpha features. At
the same time, if ocaml users find little intrerest in maintaining certain
beta features, they may be changed (slowly) or even demoted to alpha level
(with sufficient notification). Graduating beta level means that the
feature is fully incorporated into the language, and cannot change without
serious consideration and *many* notifications to the users. Preferably,
release-level language features will never be changed as is, but instead
require being moved down to beta status first (given sufficient user
notification).

Some examples of possible current alpha features are modular implicits (as
soon as they're ready to integrate into the code, but since they're alpha
they can remain fairly fluid), immutable strings and the Bytes module, as
well as extension types. Possible beta features could be GADTs(?) and
first-class modules.

Thoughts?

-Yotam

[-- Attachment #2: Type: text/html, Size: 3723 bytes --]

Re: [Caml-list] Language feature stability levels

[Milan Stanojević]

I'm not sure that current compiler architecture can easily support
your suggestion.
It does sound nice but I'm afraid it would lead to a combinatorial
explosion in the code, handling different cases where an extension
might be on or off.
A lot of recent ocaml language extension have subtle interactions with
each other that can easily lead to bugs, even unsoundness.


> While I'm not suggesting playing it fast and loose like haskell, perhaps it
> makes sense to have stages of integration into the language. I suggest 3
> stages, borrowing the terminology from software release cycles (but
> perfectly willing to use other terminology or number of stages). An alpha
> feature is one that was just introduced, and is still likely to change in
> future versions. An alpha feature that has survived enough ocaml version
> iterations and seems useful and complete can move into beta level. I foresee
> features spending a long time in the beta state, which also guarantees the
> users a further level of stability over alpha features.

So features then turned on and off by level? E.g. all alpha features
or on or none?

Re: [Caml-list] Language feature stability levels

[Yotam Barnoy]

[-- Attachment #1: Type: text/plain, Size: 2499 bytes --]

No, I'm not suggesting turning features on or off as in haskell. This
requires no actual programmatic changes to the code. It's just a conceptual
labeling of features, indicating their level of stability. It means that
when introducing new features, certain parts of the language must be seen
as static (or close to static) while others are more malleable or even very
malleable.

The ocaml devs can introduce features more liberally, without worrying
about future implications as much. If an alpha feature doesn't survive
alpha, it'll be cut/modified eventually. They can rely on user feedback to
gauge whether a feature is really worth solidifying into the core language.
Perhaps there could even be another level: experimental features, which
aren't even guaranteed to play nice with alpha or other experimental
features, but allow experimenting with ideas in the wild.

It also sets the expectations of the users: if you want to make sure your
code will compile in 5 years' time, use only stable features. If you're ok
with features that have been around for a while but may change a little,
use beta features. If you're not afraid to mess with the latest stuff, you
can use alpha level features.



On Wed, Oct 8, 2014 at 12:35 PM, Milan Stanojević <milanst@gmail.com> wrote:

> I'm not sure that current compiler architecture can easily support
> your suggestion.
> It does sound nice but I'm afraid it would lead to a combinatorial
> explosion in the code, handling different cases where an extension
> might be on or off.
> A lot of recent ocaml language extension have subtle interactions with
> each other that can easily lead to bugs, even unsoundness.
>
>
> > While I'm not suggesting playing it fast and loose like haskell, perhaps
> it
> > makes sense to have stages of integration into the language. I suggest 3
> > stages, borrowing the terminology from software release cycles (but
> > perfectly willing to use other terminology or number of stages). An alpha
> > feature is one that was just introduced, and is still likely to change in
> > future versions. An alpha feature that has survived enough ocaml version
> > iterations and seems useful and complete can move into beta level. I
> foresee
> > features spending a long time in the beta state, which also guarantees
> the
> > users a further level of stability over alpha features.
>
> So features then turned on and off by level? E.g. all alpha features
> or on or none?
>

[-- Attachment #2: Type: text/html, Size: 2981 bytes --]

Re: [Caml-list] Language feature stability levels

[Drup]

[-- Attachment #1: Type: text/plain, Size: 2928 bytes --]

I think you will be quite interested by how Rust handle that.
They have "feature gates" that are annotations (in the source) to enable 
specific features. They also have a notion of stability integrated into 
their documentation.

Le 08/10/2014 18:45, Yotam Barnoy a écrit :
> No, I'm not suggesting turning features on or off as in haskell. This 
> requires no actual programmatic changes to the code. It's just a 
> conceptual labeling of features, indicating their level of stability. 
> It means that when introducing new features, certain parts of the 
> language must be seen as static (or close to static) while others are 
> more malleable or even very malleable.
>
> The ocaml devs can introduce features more liberally, without worrying 
> about future implications as much. If an alpha feature doesn't survive 
> alpha, it'll be cut/modified eventually. They can rely on user 
> feedback to gauge whether a feature is really worth solidifying into 
> the core language. Perhaps there could even be another level: 
> experimental features, which aren't even guaranteed to play nice with 
> alpha or other experimental features, but allow experimenting with 
> ideas in the wild.
>
> It also sets the expectations of the users: if you want to make sure 
> your code will compile in 5 years' time, use only stable features. If 
> you're ok with features that have been around for a while but may 
> change a little, use beta features. If you're not afraid to mess with 
> the latest stuff, you can use alpha level features.
>
>
>
> On Wed, Oct 8, 2014 at 12:35 PM, Milan Stanojević <milanst@gmail.com 
> <mailto:milanst@gmail.com>> wrote:
>
>     I'm not sure that current compiler architecture can easily support
>     your suggestion.
>     It does sound nice but I'm afraid it would lead to a combinatorial
>     explosion in the code, handling different cases where an extension
>     might be on or off.
>     A lot of recent ocaml language extension have subtle interactions with
>     each other that can easily lead to bugs, even unsoundness.
>
>
>     > While I'm not suggesting playing it fast and loose like haskell,
>     perhaps it
>     > makes sense to have stages of integration into the language. I
>     suggest 3
>     > stages, borrowing the terminology from software release cycles (but
>     > perfectly willing to use other terminology or number of stages).
>     An alpha
>     > feature is one that was just introduced, and is still likely to
>     change in
>     > future versions. An alpha feature that has survived enough ocaml
>     version
>     > iterations and seems useful and complete can move into beta
>     level. I foresee
>     > features spending a long time in the beta state, which also
>     guarantees the
>     > users a further level of stability over alpha features.
>
>     So features then turned on and off by level? E.g. all alpha features
>     or on or none?
>
>


[-- Attachment #2: Type: text/html, Size: 4487 bytes --]