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 1B1C47F02D for ; Wed, 8 Oct 2014 17:40:04 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yotambarnoy@gmail.com) identity=pra; client-ip=209.85.215.42; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yotambarnoy@gmail.com designates 209.85.215.42 as permitted sender) identity=mailfrom; client-ip=209.85.215.42; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.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@mail-la0-f42.google.com) identity=helo; client-ip=209.85.215.42; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-la0-f42.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgBAHBZNVTRVdcqm2dsb2JhbABfhDkEgwDQXQgWAREBAQEBAQYLCwkULIQcER0BGxgGAxIQNwIkAREBBQEiNYgHAQMRngODHW6LMIFygxCIHAoZJw1nhkMBBQ6TNIFUBZ1ElBgYKYMbIIF1IS+CSgEBAQ X-IPAS-Result: AsgBAHBZNVTRVdcqm2dsb2JhbABfhDkEgwDQXQgWAREBAQEBAQYLCwkULIQcER0BGxgGAxIQNwIkAREBBQEiNYgHAQMRngODHW6LMIFygxCIHAoZJw1nhkMBBQ6TNIFUBZ1ElBgYKYMbIIF1IS+CSgEBAQ X-IronPort-AV: E=Sophos;i="5.04,678,1406584800"; d="scan'208";a="100050245" Received: from mail-la0-f42.google.com ([209.85.215.42]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 08 Oct 2014 17:40:03 +0200 Received: by mail-la0-f42.google.com with SMTP id mk6so8811003lab.15 for ; Wed, 08 Oct 2014 08:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=GdP26ogtkJpkZlOxP3eS1SytvBHi68cg2IXEILXfK6o=; b=y/YzZSxDrkxG7QfHLgMNbdknu6G3wzrUFlQiQVLwutoYwifIX12IpOF4XdveYKP2aA A6YdkFEwxQm0VuvA+TidKvBOnD7mgnjy5w/go2Zvuha0I9JBKhLlUVVFgvpZPuDm/CAS bajvyLQqXI3cfzd/1tp7+UKrklpTGztWNfbCH7BcZ5JEELcm5ZrIOsAU3Ap8J4YuNQ0L Rs17ZvZhdAIpbG3ay+Xv/4ixUdR7efh+htLc9vyYq+ppRAhc2MaHtSSovVoqkWSdyrIR g1RH6P9tFVbAooXHdI8vJdnlS4pITBewqYWiuQT7i4CkTauqDSGL5n09bcIJ9PigP28c dyHQ== X-Received: by 10.112.5.133 with SMTP id s5mr4109081lbs.102.1412782801871; Wed, 08 Oct 2014 08:40:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.20.71 with HTTP; Wed, 8 Oct 2014 08:39:41 -0700 (PDT) From: Yotam Barnoy Date: Wed, 8 Oct 2014 11:39:41 -0400 Message-ID: To: Ocaml Mailing List Content-Type: multipart/alternative; boundary=14dae94ed8330ce7090504eb2103 Subject: [Caml-list] Language feature stability levels --14dae94ed8330ce7090504eb2103 Content-Type: text/plain; charset=UTF-8 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 --14dae94ed8330ce7090504eb2103 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One thing I've noticed over my time with ocaml and obs= erving its development, is that there's some confusion and difficulty w= ith regard to the introduction of new features. Some features are introduce= d with an obscure note in the manual stating that they could change in futu= re ocaml versions. Others are introduced rapidly in one version and then ca= use 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 officia= l, and in the process, make it easier to introduce new features while givin= g users feedback about feature stability.

The basic prob= lem, as I see it, is that when features are written into the language, ther= e'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 existin= g 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 fro= m quick introduction to the users (as well as testing) get stuck in develop= ment hell because the language developers are overly conservative, trying t= o puzzle out whether the feature will be useful and consistent many years i= n the future, without the advantage of existing long-term user testing.

Haskell has language extensions which, despite some n= egative effects, such as language bloat and bad backwards-compatibility, al= low haskell to develop very quickly. A new feature is introduced under a la= nguage extension, which must be activated on a per-file basis. If people li= ke 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 b= e 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 th= e language. I suggest 3 stages, borrowing the terminology from software rel= ease cycles (but perfectly willing to use other terminology or number of st= ages). An alpha feature is one that was just introduced, and is still likel= y to change in future versions. An alpha feature that has survived enough o= caml version iterations and seems useful and complete can move into beta le= vel. 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 t= he same time, if ocaml users find little intrerest in maintaining certain b= eta 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-l= evel language features will never be changed as is, but instead require bei= ng 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 stri= ngs and the Bytes module, as well as extension types. Possible beta feature= s could be GADTs(?) and first-class modules.

Thoug= hts?

-Yotam
--14dae94ed8330ce7090504eb2103--