caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Yotam Barnoy <yotambarnoy@gmail.com>
To: "Milan Stanojević" <milanst@gmail.com>
Cc: Ocaml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] Language feature stability levels
Date: Wed, 8 Oct 2014 12:45:58 -0400	[thread overview]
Message-ID: <CAN6ygOk=yn2VPyGXN7b6sDELeXPZsM-2TizVVWpCTRsAR+JE2g@mail.gmail.com> (raw)
In-Reply-To: <CAKR7PS8nPFoC_bcnynYJfqNkV9i9+njc1oUFg7UhAf5sgjMb8A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2499 bytes --]

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?
>

[-- Attachment #2: Type: text/html, Size: 2981 bytes --]

  reply	other threads:[~2014-10-08 16:46 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 [this message]
2014-10-08 18:26     ` Drup

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='CAN6ygOk=yn2VPyGXN7b6sDELeXPZsM-2TizVVWpCTRsAR+JE2g@mail.gmail.com' \
    --to=yotambarnoy@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=milanst@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).