From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.4 required=5.0 tests=SPF_NEUTRAL autolearn=disabled version=3.1.3 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 7DBADBC6C for ; Tue, 29 Jan 2008 17:49:35 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAI/nnkdA6aq9n2dsb2JhbACQHgEBAQEBBgQGCSCBFJYehyI X-IronPort-AV: E=Sophos;i="4.25,270,1199660400"; d="scan'208";a="21942954" Received: from rn-out-0910.google.com (HELO rn-out-0102.google.com) ([64.233.170.189]) by mail4-smtp-sop.national.inria.fr with ESMTP; 29 Jan 2008 17:49:34 +0100 Received: by rn-out-0102.google.com with SMTP id s46so282543rnb.18 for ; Tue, 29 Jan 2008 08:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=XbL+pszL3wUPUdwzgZPkMGoIEKv9PjyND0auBwi9QV4=; b=VDmBxxkypWqfTXxN/LEDEhAjz9IJGu4pqEQWWwI0xcLvkGKeRatOzSBBHfyKn7IbMosyd1HKP9l16r+XdR/Rao01CQ9Pn4AAi27PbUh3U7bij9QfPRD+asW4wAH0C1lNHU+YvwXDUs+TXXF5tQgWeUFba9vx6BBReEJPQl514yY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=RHwzm5MotliR3NTJvjKfWfB/v97fyL6BmbsacssyFjm/Y5GxyCFBTHQzUaSAiGCTwv+SKJqaRvM9LZAPFhtan5vwr15QNeza/O+sLXe+pbFn57mmNT0qh3QDAsxWmG+D6CGU2oL2Rx1CgPxK73QWINL27WZIPTaTpgqw7a/K0u0= Received: by 10.142.104.9 with SMTP id b9mr3426984wfc.48.1201625372644; Tue, 29 Jan 2008 08:49:32 -0800 (PST) Received: from ?192.168.0.16? ( [70.242.64.39]) by mx.google.com with ESMTPS id h16sm2264539wxd.13.2008.01.29.08.49.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 29 Jan 2008 08:49:28 -0800 (PST) Message-ID: <479F590D.6020706@gmail.com> Date: Tue, 29 Jan 2008 10:49:17 -0600 From: Edgar Friendly User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Jon Harrop Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] [OSR] OCaml Standard Recommandation Process References: <1201440183.6302.27.camel@Blefuscu> <1201541440.6747.68.camel@Blefuscu> <1201554728.19148.53.camel@flake.lan.gerd-stolpmann.de> <200801282139.07894.jon@ffconsultancy.com> In-Reply-To: <200801282139.07894.jon@ffconsultancy.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; ocaml:01 gerd:01 stolpmann:01 ocaml:01 stdlib:01 stdlib:01 distro:01 semantics:01 pitfalls:01 source-code:01 semantics:01 pervasives:01 compiler:01 distro:01 camlp:01 Jon Harrop wrote: > On Monday 28 January 2008 21:12:08 Gerd Stolpmann wrote: >> As it was mentioned, we cannot modify OCaml itself. We can ask here and >> there for changes, e.g. when core APIs could be improved so user add-ons >> have an easier life. But the OCaml language itself is only a matter of >> INRIA. It is still a cathedral, not a bazaar (I don't see any change >> here - except that the cathedral is now completely built). So any >> discussions about changing the language (try finally) or the stdlib are >> off-topic. > > Can we clear up once and for all whether or not we can improve the stdlib? > I wish I could answer your question authoritatively. The best I can tell from the situation comes to this: 1) The community now has some permission to make a distribution out of the OCaml code created at INRIA. 2) This distribution should (Must?) not break backwards compatibility with the currently official, INRIA-blessed distro. The way I interpret these two gives me/us limited ability to improve the stdlib. One question for the community involves both directions of migration. #2 insists that INRIA-OCaml programs have the same semantics (including triggering the same warts of the language) under Community-OCaml. i.e. taking a program compiled under INRIA-OCaml and compiling it under Community-OCaml should "just work". The reverse -- going from Community-OCaml to INRIA-OCaml -- isn't guaranteed to work in the same way, *but* the question comes: how much work must the user spend to translate from Community-OCaml to INRIA-OCaml. Messing with the type system has many pitfalls, but not least of which comes a (likely) very difficult conversion to INRIA-OCaml involving probably complex source-code transformation. Many people seem to put forward improvement ideas for OCaml that stay within the realm of including more libraries in the Community-OCaml distribution, and having efforts to standardize interfaces of these libraries. This kind of change seems to have minimal conversion difficulty to INRIA-OCaml (just install the needed libraries). In between these extremes sits things like changes to the stdlib and extensions to the language. I hope that we can make changes to both of these. stdlib changes should only extend the current library (in my mind this includes changing implementations of existing functions, as long as the semantics stay identical), but to ease compatibility with the INRIA-OCaml system, (some of) these changes could get implemented in such a way that with a small amount of additional work (opening a "Community.Pervasives" module that includes the new changes). Changes to the compiler such as try..finally could get put in to the community distro, but with a "close-enough" camlp4 filter to transform programs using them into programs that would work under the current system. (maybe not as efficiently, maybe with horrible error messages) E.