From: Drup <drupyog+caml@zoho.com>
To: "Yotam Barnoy" <yotambarnoy@gmail.com>,
"Milan Stanojević" <milanst@gmail.com>
Cc: Ocaml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] Language feature stability levels
Date: Wed, 08 Oct 2014 20:26:34 +0200 [thread overview]
Message-ID: <543581DA.1080707@zoho.com> (raw)
In-Reply-To: <CAN6ygOk=yn2VPyGXN7b6sDELeXPZsM-2TizVVWpCTRsAR+JE2g@mail.gmail.com>
[-- 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 --]
prev parent reply other threads:[~2014-10-08 18:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-08 15:39 Yotam Barnoy
2014-10-08 16:35 ` Milan Stanojević
2014-10-08 16:45 ` Yotam Barnoy
2014-10-08 18:26 ` Drup [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=543581DA.1080707@zoho.com \
--to=drupyog+caml@zoho.com \
--cc=caml-list@inria.fr \
--cc=milanst@gmail.com \
--cc=yotambarnoy@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox