From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <milanst@gmail.com>
X-Original-To: caml-list@sympa.inria.fr
Delivered-To: caml-list@sympa.inria.fr
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	by sympa.inria.fr (Postfix) with ESMTPS id 2F1357F02D
	for <caml-list@sympa.inria.fr>; Wed,  8 Oct 2014 18:36:02 +0200 (CEST)
Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  milanst@gmail.com) identity=pra; client-ip=209.85.213.181;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="milanst@gmail.com";
  x-sender="milanst@gmail.com"; x-conformance=sidf_compatible
Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of
  milanst@gmail.com designates 209.85.213.181 as permitted
  sender) identity=mailfrom; client-ip=209.85.213.181;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="milanst@gmail.com";
  x-sender="milanst@gmail.com"; x-conformance=sidf_compatible;
  x-record-type="v=spf1"
Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@mail-ig0-f181.google.com) identity=helo;
  client-ip=209.85.213.181;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="milanst@gmail.com";
  x-sender="postmaster@mail-ig0-f181.google.com";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AncBAAtnNVTRVdW1m2dsb2JhbABfhD2DAM9ZAoECCBYBEQEBAQEBBgsLCRQshAQBAQMBEhEdARsYBQEDAQsGBQsHCAImAgIiAREBBQEODgY1iAcBAwkIoiduizCBcoMQiBwKGScNZ4YxAREBBQ6BHo8YB4J3gVQFnUWBLpBggg0YKYUwIS+CSgEBAQ
X-IPAS-Result: AncBAAtnNVTRVdW1m2dsb2JhbABfhD2DAM9ZAoECCBYBEQEBAQEBBgsLCRQshAQBAQMBEhEdARsYBQEDAQsGBQsHCAImAgIiAREBBQEODgY1iAcBAwkIoiduizCBcoMQiBwKGScNZ4YxAREBBQ6BHo8YB4J3gVQFnUWBLpBggg0YKYUwIS+CSgEBAQ
X-IronPort-AV: E=Sophos;i="5.04,678,1406584800"; 
   d="scan'208";a="82455816"
Received: from mail-ig0-f181.google.com ([209.85.213.181])
  by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 08 Oct 2014 18:36:01 +0200
Received: by mail-ig0-f181.google.com with SMTP id r10so9333087igi.2
        for <caml-list@inria.fr>; Wed, 08 Oct 2014 09:36:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type;
        bh=+kXL0wZxw8ClMm3SMKIFv5f86UoMY5/vRcv3kEeUGGs=;
        b=P4aU6louhZO31Ta4d85VVpkyLZL4RHANsOPV2DRAguHo9C5qNFYz1tZml20HG60gNd
         zU9cLosZ/xdxvNkmkz9cNJSgKZPXLFpPlOfTr+GomSe4GHvVpPJVU0UJWf03g0Cuaqic
         XSEof70c+9fpLqjo7lH0YyYUBb3GfMgJDQfFGISrS5yZL/BbzoIwwgFE1zs0UkRCZrqR
         44I8bhtWybQzkE/+wD3/LsLhYfrpb9OP6o/Cw8mjI+3W9dM2Z7zH6w0bf6YegFWfQJ37
         6RAm/Q8EuedEBp0xOibLbnBI93eN/LJZv7AmaZ0JNeZpqb9pRCu7usFeDYXqMUGKFk6S
         /3Pg==
X-Received: by 10.50.152.35 with SMTP id uv3mr17942015igb.46.1412786159937;
 Wed, 08 Oct 2014 09:35:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.114.38 with HTTP; Wed, 8 Oct 2014 09:35:19 -0700 (PDT)
In-Reply-To: <CAN6ygO==ZepF-NpE-CyrbevU+2Xvjs0PaJWBVBMkvK6KgGEOZQ@mail.gmail.com>
References: <CAN6ygO==ZepF-NpE-CyrbevU+2Xvjs0PaJWBVBMkvK6KgGEOZQ@mail.gmail.com>
From: =?UTF-8?Q?Milan_Stanojevi=C4=87?= <milanst@gmail.com>
Date: Wed, 8 Oct 2014 12:35:19 -0400
Message-ID: <CAKR7PS8nPFoC_bcnynYJfqNkV9i9+njc1oUFg7UhAf5sgjMb8A@mail.gmail.com>
To: Yotam Barnoy <yotambarnoy@gmail.com>
Cc: Ocaml Mailing List <caml-list@inria.fr>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Caml-list] Language feature stability levels

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?