From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 3B3D97F057 for ; Wed, 8 Oct 2014 20:27:06 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of drupyog+caml@zoho.com) identity=pra; client-ip=74.201.84.156; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="drupyog+caml@zoho.com"; x-sender="drupyog+caml@zoho.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of drupyog+caml@zoho.com designates 74.201.84.156 as permitted sender) identity=mailfrom; client-ip=74.201.84.156; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="drupyog+caml@zoho.com"; x-sender="drupyog+caml@zoho.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@sender1.zohomail.com) identity=helo; client-ip=74.201.84.156; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="drupyog+caml@zoho.com"; x-sender="postmaster@sender1.zohomail.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoBALqBNVRKyVScm2dsb2JhbABfhz2FW8l+AoEKFgERAQEBAQEGCwsJFCyEAwEBAQMBIyABMAQBAgMLCxIGCRYIAwICCQMCAQIBDyUDDgYBDAEFAgEBiCUBAwEEBAgEsBF4hQgCiBAiKA0YhlMBEAeOEoIyB4J3gVSTAog3ghGBLoEXhR+HVYJVh2RqgkoBAQE X-IPAS-Result: AnoBALqBNVRKyVScm2dsb2JhbABfhz2FW8l+AoEKFgERAQEBAQEGCwsJFCyEAwEBAQMBIyABMAQBAgMLCxIGCRYIAwICCQMCAQIBDyUDDgYBDAEFAgEBiCUBAwEEBAgEsBF4hQgCiBAiKA0YhlMBEAeOEoIyB4J3gVSTAog3ghGBLoEXhR+HVYJVh2RqgkoBAQE X-IronPort-AV: E=Sophos;i="5.04,679,1406584800"; d="scan'208,217";a="100074366" Received: from sender1.zohomail.com ([74.201.84.156]) by mail2-smtp-roc.national.inria.fr with ESMTP; 08 Oct 2014 20:26:42 +0200 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type; b=JFPBEclODGNsEqY6RnZ8UVFLf7Gt11xkITRik7UXAY09fn/RUezORpM1cG9VA/Awvns9E44WekU7 F2qXbvEkOllDu5/F/JDvTkADwLVfUiaVXBD9UnlJ2UDsd47f8iVy Received: from [192.168.1.49] (ivr94-8-88-162-25-213.fbx.proxad.net [88.162.25.213]) by mx.zohomail.com with SMTPS id 1412792797764642.1062703037751; Wed, 8 Oct 2014 11:26:37 -0700 (PDT) Message-ID: <543581DA.1080707@zoho.com> Date: Wed, 08 Oct 2014 20:26:34 +0200 From: Drup User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Yotam Barnoy , =?UTF-8?B?TWlsYW4gU3Rhbm9qZXZpxIc=?= CC: Ocaml Mailing List References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040701000507010409020501" X-ZohoMailClient: External X-Zoho-Virus-Status: 2 Subject: Re: [Caml-list] Language feature stability levels This is a multi-part message in MIME format. --------------040701000507010409020501 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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ć > 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? > > --------------040701000507010409020501 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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> 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?


--------------040701000507010409020501--