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.1 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr 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 C4D8EBC6C for ; Sun, 27 Jan 2008 20:07:02 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAF5lnEfAXQImh2dsb2JhbACQKAEBAQgKKYEUmE4 X-IronPort-AV: E=Sophos;i="4.25,257,1199660400"; d="scan'208";a="21858478" Received: from discorde.inria.fr ([192.93.2.38]) by mail4-smtp-sop.national.inria.fr with ESMTP; 27 Jan 2008 20:07:02 +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 m0RJ72HH021990 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Sun, 27 Jan 2008 20:07:02 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAOpknEfBMVMPh2dsb2JhbACQKAEBAQgKKYEUmE8 X-IronPort-AV: E=Sophos;i="4.25,257,1199660400"; d="scan'208";a="6630305" Received: from kabis.univ-orleans.fr (HELO ka.univ-orleans.fr) ([193.49.83.15]) by mail2-smtp-roc.national.inria.fr with ESMTP; 27 Jan 2008 20:07:01 +0100 Received: from smtps.univ-orleans.fr (localhost [127.0.0.1]) by ka.univ-orleans.fr (Postfix) with ESMTP id 38E0B12AD69; Sun, 27 Jan 2008 20:07:01 +0100 (CET) Received: from [192.168.0.12] (ras75-4-82-235-58-110.fbx.proxad.net [82.235.58.110]) by smtps.univ-orleans.fr (Postfix) with ESMTP id 9FEE636E5B; Sun, 27 Jan 2008 20:07:04 +0100 (CET) Subject: Re: [Caml-list] [OSR] OCaml Standard Recommandation Process From: David Teller To: yminsky@gmail.com Cc: OCaml In-Reply-To: <891bd3390801270624h4df6cdadn9d5e888dae615280@mail.gmail.com> References: <1201440183.6302.27.camel@Blefuscu> <891bd3390801270624h4df6cdadn9d5e888dae615280@mail.gmail.com> Content-Type: text/plain; charset=utf-8 Date: Sun, 27 Jan 2008 20:07:01 +0100 Message-Id: <1201460821.19472.31.camel@Blefuscu> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 8bit X-Miltered: at discorde with ID 479CD656.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 univ-orleans:01 camlp:01 camlp:01 camomile:01 lablgtk:01 ocamllex:01 ocamlduce:01 pervasives:01 patching:01 ocaml:01 interacts:01 mutable:01 mutable:01 syntax:01 You are correct, I should have been more specific. The idea is to discuss * libraries * Camlp4 extensions * language features that may be implemented as a combination of libraires and Camlp4 extensions * actual code. Let me summarise a few good candidates for discussion. Please don't start the actual debate in this thread, they will be posted again in their own e-mail. ** The Unicode situation ** At the moment, at least four libraries (Camomile, ExtLib, ULex, LablGtk) contain their own, incompatible, Unicode management modules, none of which is compatible with OCamllex, or (I believe) OCamlDuce, Camlp4, OCaml-Java, Spidercaml, the Str module, wxOCaml, Expat... We need to * decide on APIs we will consider "standard" for Unicode management -- preferably in the form of one already-existing library, possibly with minor modifications, otherwise as things-that-need-to-be-implemented * decide on whether/how to include these APIs in end-user distributions (e.g. GODI, Debian packages, Fedora packages) * add new implementations of Pervasives / standard library functions for Unicode strings instead of the string type * document the use of these APIs for the most common situations, both for newbies and seasoned developers * start patching our own applications to make use of these APIs, both as a way to test them and as a way to have bring the OCaml world one step further towards something that interacts more easily * from the moment the debate is concluded, make it clear for new users of OCaml that, unless they have very specific needs, this is the One True Way of using Unicode. ** The mutable string situation ** Since the first version, OCaml has mutable strings. With time and the hindsight provided by numerous languages with immutable strings, this design decision has begun to be seen by many developers as wrong. As pointed out by Xavier Leroy, however, it is now impossible to come back on that decision and fully root out mutable strings from the language. However, new data structures may be added, made comfortable for general use and documented as being the new standard. We need to * decide if we actually want this to happen * decide on the necessary APIs and performance requirements for these new data structures (e.g. ropes) * discuss and implement a nice Camlp4 syntax for these revised strings * decide on whether/how to include these APIs in end-user distributions (e.g. GODI, Debian packages, Fedora packages) * add new implementations of Pervasives / standard library functions for text strings instead of the string type * document the use of these APIs for the most common situations, both for newbies and seasoned developers * start patching our own applications to make use of these APIs, both as a way to test them and as a way to have bring the OCaml world one step further towards something that interacts more easily * from the moment the debate is concluded, make it clear for new users of OCaml that, unless they have very specific needs, this is the One True Way of using text. --- Of course, these two debates will probably be closely linked, as they both deal with the representation of text. Other subjects would include ExtLib (anything we need to add ?), Lazy lists, lazy pattern-matching (yes, this can be implemented in Camlp4), pattern views, simple equation solving in patterns à la Haskell (match x with y+1 -> ...), ... Does this answer your questions ? Cheers, David On Sun, 2008-01-27 at 09:24 -0500, Yaron Minsky wrote: > > What is it that is meant to be standardized by this process? Is this > meant to be parallel to the Java Community Process or Python's PEPs > (Python Enhancement Proposals)? Those are not just about "best > practices", but are actually about code, language features, APIs, etc. > I don't at first glance see any real use in agreeing on best practices > for OCaml. Can you give some examples of what would make a reasonable > OSR? That might clarify the purpose of them considerably. > > y