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=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 9825DBC6C for ; Mon, 28 Jan 2008 22:12:22 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAGzUnUfAXQImh2dsb2JhbACBWI5FAQEBCAopmyAB X-IronPort-AV: E=Sophos;i="4.25,262,1199660400"; d="scan'208";a="8466810" Received: from discorde.inria.fr ([192.93.2.38]) by mail3-smtp-sop.national.inria.fr with ESMTP; 28 Jan 2008 22:12:15 +0100 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0SLCAjC007811 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 28 Jan 2008 22:12:14 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAHzTnUfU436umWdsb2JhbACBWI5FAQEBAQEGBAQLCBibIQE X-IronPort-AV: E=Sophos;i="4.25,262,1199660400"; d="scan'208";a="6673700" Received: from moutng.kundenserver.de ([212.227.126.174]) by mail2-smtp-roc.national.inria.fr with ESMTP; 28 Jan 2008 22:12:10 +0100 Received: from gate.lan.gerd-stolpmann.de (dslb-088-068-212-114.pools.arcor-ip.net [88.68.212.114]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1JJbGw105s-00066X; Mon, 28 Jan 2008 22:12:09 +0100 Received: from [192.168.0.32] (fw.lan.gerd-stolpmann.de [192.168.1.1]) by gate.lan.gerd-stolpmann.de (Postfix) with ESMTP id D669DC110; Mon, 28 Jan 2008 22:12:05 +0100 (CET) Subject: Re: [Caml-list] [OSR] OCaml Standard Recommandation Process From: Gerd Stolpmann To: David Teller Cc: Brian Hurt , caml-list@inria.fr In-Reply-To: <1201541440.6747.68.camel@Blefuscu> References: <1201440183.6302.27.camel@Blefuscu> <200801281204.00689.jon@ffconsultancy.com> <479DE545.9050306@janestcapital.com> <200801281525.12651.jon@ffconsultancy.com> <479E04E6.5000303@janestcapital.com> <1201541440.6747.68.camel@Blefuscu> Content-Type: text/plain Date: Mon, 28 Jan 2008 22:12:08 +0100 Message-Id: <1201554728.19148.53.camel@flake.lan.gerd-stolpmann.de> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/jMK4m0g6SDhHJGY3ZZWCWndzyyi58fRyB8X+ jui1yLtLEn8MAUjqfhyo4nYtKNVqSprDP5bQHurrOtAid95aJL xo4KyrNddf9tr+ySLJeguCqg08dRH+L X-Miltered: at discorde with ID 479E452A.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 gerd:01 stolpmann:01 parsers:01 parsers:01 parser:01 parser:01 ocaml:01 stdlib:01 camomile:01 ocamlnet:01 gerd:01 stolpmann:01 viktoriastr:01 64293:01 Am Montag, den 28.01.2008, 18:30 +0100 schrieb David Teller: > So do we agree on the OSR process as I've described it or does anyone > believe we should first change it ? Well, the discussion has already taken a strange direction, and this might have to do with ... hhmmm ... some missing guidance. We first should make clear what we are talking about, and then there is the question of how to come to an agreement. First of all, I think OSR can only be about giving users more choice. For example, there are several XML parsers, and all use a different representation of XML. I think this is basically good, because every representation has its pros and cons, and the users can choose among several options. But it would be even better if all XML parsers agreed on an _additional_ representation they share, so the user has the additional option to use the common XML representation, which makes it very easy to switch between several parsers (e.g. sometimes the fastest parser is preferred, and sometimes the parser with the best error messages). I think this is the area for a user-driven process, because there are a lot of views on such practical problems, and the result will profit from knowing all of them. 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. What we can do is to improve the infrastructure around the OCaml core. The example of the XML parsers shows that there is a lot to do (although these parsers might not be the most urgent question). I don't like it to talk about things others would have to implement, so I think OSR is mostly addressed at library/tool authors. Of course, it is important to also hear opinions from the users of the libraries, but I think the implementers should finally decide on what they recommend. We should avoid to set standards that are ignored. As an example of OSR, there is the I/O channels effort: http://www.ocaml-programming.de/rec/IO-Classes.html This is basically an agreement between library implementers. As there were only 3 parties involved, it was a good and fruitful debate, and I think the result is convincing. Most importantly, the recommendation was implemented, and the users have finally more options. E.g. they can now transform a Camomile channel by an OCamlnet channel filter. Of course, OSR could also be about new libraries, but I think this is less important. Everybody can create a new library anyway, so there might be no point in discussing that. What I don't like to discuss is everything in the "what is good style" area. This is fruitless, because there are real reasons for preferring different coding styles to solve different problems, and discussing that will only lead to flame wars. Gerd -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------