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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 48EB27F02D for ; Wed, 8 Oct 2014 18:46:19 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yotambarnoy@gmail.com) identity=pra; client-ip=209.85.215.54; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yotambarnoy@gmail.com designates 209.85.215.54 as permitted sender) identity=mailfrom; client-ip=209.85.215.54; receiver=mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-la0-f54.google.com) identity=helo; client-ip=209.85.215.54; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-la0-f54.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncBAJVpNVTRVdc2m2dsb2JhbABfhD2DAM9ZAoECCBYBEQEBAQEBBgsLCRQshAQBAQMBEhEdARsYBQEDAQsGBQQHBzACAiEBAREBBQEODgYTIogHAQMJCKJLboswgXKDEIgdChknDWeGMQERAQUOjgSCMgeCd4FUBZs0ghGBLo4LglWCDRgphTAhL4JKAQEB X-IPAS-Result: AncBAJVpNVTRVdc2m2dsb2JhbABfhD2DAM9ZAoECCBYBEQEBAQEBBgsLCRQshAQBAQMBEhEdARsYBQEDAQsGBQQHBzACAiEBAREBBQEODgYTIogHAQMJCKJLboswgXKDEIgdChknDWeGMQERAQUOjgSCMgeCd4FUBZs0ghGBLo4LglWCDRgphTAhL4JKAQEB X-IronPort-AV: E=Sophos;i="5.04,678,1406584800"; d="scan'208";a="82457083" Received: from mail-la0-f54.google.com ([209.85.215.54]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 08 Oct 2014 18:46:18 +0200 Received: by mail-la0-f54.google.com with SMTP id gm9so8663925lab.41 for ; Wed, 08 Oct 2014 09:46:18 -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=ANXn6sxCsZ/PR807UD73XOpclAT/5zQjGMU8heLeKYU=; b=UWipA/pS8utWXm2tHiNJSXaU4hie2u1h9Zm2AblOpXlrX0saT5D+o4sRoP0h7J96yW 8l5dtDIloWfBuEUvtUusDT456Qn0VO4u4JngSz2rYxAp29plsTzEJ9HkilZ0mvmmXJGL vjBSGzWlNFq92YMCU2dRuEoYEAAzHzlj3BqZVbE2eoXV5cNL7pQWZXHITAGd93Q70IyO o4tlCVRAUssoBqzplUVqwPzYO3R1Px9YYnHvN7/9fV7++ENYZqPxB9AibZC/9+L0G6VE sh3BvAm5RkalG2FHMY9BkuY2jDaisLhbwSoxB4O6J77yz6NxKKBLBq9oOA12cwu5sidk YkoQ== X-Received: by 10.113.10.9 with SMTP id dw9mr12271207lbd.46.1412786778057; Wed, 08 Oct 2014 09:46:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.20.71 with HTTP; Wed, 8 Oct 2014 09:45:58 -0700 (PDT) In-Reply-To: References: From: Yotam Barnoy Date: Wed, 8 Oct 2014 12:45:58 -0400 Message-ID: To: =?UTF-8?Q?Milan_Stanojevi=C4=87?= Cc: Ocaml Mailing List Content-Type: multipart/alternative; boundary=001a113460700cafc80504ec0e87 Subject: Re: [Caml-list] Language feature stability levels --001a113460700cafc80504ec0e87 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=C4=87 = 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 alp= ha > > 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? > --001a113460700cafc80504ec0e87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No, I'm not suggesting turning features on or off as i= n haskell. This requires no actual programmatic changes to the code. It'= ;s just a conceptual labeling of features, indicating their level of stabil= ity. It means that when introducing new features, certain parts of the lang= uage must be seen as static (or close to static) while others are more mall= eable or even very malleable.=C2=A0

The ocaml devs can i= ntroduce features more liberally, without worrying about future implication= s 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 feat= ure is really worth solidifying into the core language. Perhaps there could= even be another level: experimental features, which aren't even guaran= teed to play nice with alpha or other experimental features, but allow expe= rimenting with ideas in the wild.

It also set= s the expectations of the users: if you want to make sure your code will co= mpile 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 be= ta features. If you're not afraid to mess with the latest stuff, you ca= n use alpha level features.


=

On Wed, Oct 8, 20= 14 at 12:35 PM, Milan Stanojevi=C4=87 <milanst@gmail.com> wr= ote:
I'm not sure that current compil= er 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, p= erhaps 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 al= pha
> feature is one that was just introduced, and is still likely to change= in
> future versions. An alpha feature that has survived enough ocaml versi= on
> iterations and seems useful and complete can move into beta level. I f= oresee
> 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?

--001a113460700cafc80504ec0e87--