From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p2RIEKGm009625 for ; Sun, 27 Mar 2011 20:14:21 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0DAJF9j03UGyoCkWdsb2JhbACYW40AFAEBAQEJCwsHFAMiiGu3AYVpBIx3g1Qa X-IronPort-AV: E=Sophos;i="4.63,251,1299452400"; d="scan'208";a="79253684" Received: from smtp2-g21.free.fr ([212.27.42.2]) by mail3-smtp-sop.national.inria.fr with ESMTP; 27 Mar 2011 20:14:15 +0200 Received: from [192.168.1.3] (unknown [82.237.71.191]) by smtp2-g21.free.fr (Postfix) with ESMTP id 81CD54B00F2 for ; Sun, 27 Mar 2011 20:14:08 +0200 (CEST) Message-ID: <4D8F7E64.9080403@inria.fr> Date: Sun, 27 Mar 2011 20:13:56 +0200 From: Xavier Leroy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: caml-list@inria.fr References: <20110326011208.GA3915@melkinpaasi.cs.helsinki.fi> In-Reply-To: <20110326011208.GA3915@melkinpaasi.cs.helsinki.fi> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] What are "Language extensions"? On 03/26/2011 02:12 AM, Lauri Alanko wrote: > In the O'Caml reference manual, the actual language specification is > split into two parts, "The Objective Caml language" and "Language > extensions". I'm curious as to what this division indicates about the > status of different features of the language. Don't put too much meaning in this distinction. Basically, the "language extensions" chapter describes most of the features that were added since OCaml 1.00 back in 1995 (!), or that were present in 1.00 but considered a bit experimental then. This said, only one of those extensions went away in the past (stream pattern matching, as Martin Jambon recalled), and I don't see any of the remaining extensions going away in the short to medium term. However, some of those extensions are a little less "future-proof" than the core of the language and are more likely to change in slightly incompatible ways. A prime example is recursive modules, whose type-checking has changed a couple of times in the past (because it walks a fine line between unsoundness and undecidability), breaking some Caml code that uses recursive modules. Perhaps, one day, the most stable "extensions" should be moved from the "language extensions" chapter to the "Objective Caml language" chapter, but this is just a matter of presentation. Hope this clarifies the issue. - Xavier Leroy