caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
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 --]

      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;
as well as URLs for NNTP newsgroup(s).