From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA13383; Sat, 24 Apr 2004 10:13:14 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA13706; Sat, 24 Apr 2004 10:13:13 +0200 (MET DST) From: Alain.Frisch@ens.fr Received: from nef.ens.fr (nef.ens.fr [129.199.96.32]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i3O8DCjq027252; Sat, 24 Apr 2004 10:13:12 +0200 Received: from clipper.ens.fr (clipper-gw.ens.fr [129.199.1.22]) by nef.ens.fr (8.12.10/1.01.28121999) with ESMTP id i3O8DAKx061379 ; Sat, 24 Apr 2004 10:13:10 +0200 (CEST) Received: from localhost (frisch@localhost) by clipper.ens.fr (8.12.3/jb-1.1) id i3O8D8KX022614 ; Sat, 24 Apr 2004 10:13:08 +0200 (MET DST) X-Authentication-Warning: clipper.ens.fr: frisch owned process doing -bs Date: Sat, 24 Apr 2004 10:13:08 +0200 (MET DST) X-X-Sender: frisch@clipper.ens.fr Reply-To: Alain.Frisch@ens.fr To: John Goerzen cc: Maxence Guesdon , Caml list Subject: Re: [Caml-list] [ANN] The Missing Library In-Reply-To: <20040424042640.GA27972@complete.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; alain:01 frisch:01 caml-list:01 stdlib:01 dependencies:01 ocamlc:01 non-portable:01 stdlib:01 bootstrap:01 dynlink:01 threads:01 forking:01 extlib:01 maintainance:01 monolithic:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, 23 Apr 2004, John Goerzen wrote: > That is interesting to note but, does it actually mean something? (This > is not a rhetorical question; I really don't know.) I always assumed > the libraries listed separately in the docs were just that way because I > had to explicitly list unix.cmxa or str.cmxa to link with them... I guess that one of the reason for not having these libraries inside the stdlib is to avoid useless dependencies to C units for the core system (so that to port ocamlc to a new architecture, you have a minimal amount of non-portable code to consider). Also, some of these libraries are really system specific, or require extra C libraries. Better have a really standard and portable stdlib. > > Maybe the situation would more clear if: > > 1] the standard library was called the bootstrap library; > > 2] other libraries were removed from the standard distribution (ok, maybe > > except dynlink, bigarray, threads which require some cooperaton with > > the compiler, AFAIK). > > Yes. That could make a lot of things easier. As I've pointed out in > some of my other messages, the problem with Unix in particular is that > forking it will result in a painful compatibility choice for developers. Extending libraries that require C support is tricky, because you have to make sure that the OCaml distribution will still compile smoothly on all supported platforms (do you know exactly which functions are specific to your OS, and how to write reliable test code for the configure script ?). Could you elaborate on the compatibility point, since it seems to be at core of your unhapiness ? You can have a module extending Unix and working with the same abstract data types (like UnixExtras in his Shawn's ExtLib), e.g. Unix.file_descr. If there is a problem, it is a maintainance problem for the developer of the extension, but the implementation of Unix.file_descr is not likely to change so often. Also, you can decide to have a complete re-implementation of the functionnalities in Unix. You are free from the burden of keeping compatibility, so you can choose a better organization (Unix is way too monolithic, in my opinion), etc... The same project could use Unix and the new library. If you don't specify the type equality MyNewUnix.fd == Unix.file_descr (and don't give coercion functions between these types), you won't be able to pass your file descriptors to other libraries which expect Unix.file_descr. Are they many libraries with a dependency to Unix.file_descr in there interface out there ? The common situation is that another library use Unix internally; in this case there in no problem. Btw, the compatibility choice already appears with the stdlib, because there are several incompatible ways to do the same thing in OCaml. As an example, take the *printf function. If you write a library with an abstract type t and want to provide a printer, you have to choose between (or give all of): print: (out_channel -> t -> unit) -> t -> unit (* for use with Printf.(f?)printf *) print: (unit -> t -> string) -> t -> string (* for use with (Printf|Format).sprintf *) print: (Buffer.t -> t -> unit) -> t -> unit (* for use with Printf.bprintf *) print: (Format.formatter -> t-> unit) -> t -> unit (* for use with Format.fprintf *) ... > I agree completely. I read that message, and Xavier writes "the > preferred way to contribute to Caml is through independent libraries and > tools, not by aiming at getting your stuff in the core OCaml > distribution." That fine if it adds something that does not already > exist in the core (database APIs, PCRE, configuration parsers to name a > few examples.) But I don't think the suggestion really works for things > like Unix that are already there. You could say that PCRE is an incompatible rewrite of Str. Good example. Many people use it instead of Str even if it is not in the standard distribution. Similarly, LablGTK seems more widely used than LablTk. If a group of people is willing to put some effort into the development of a clean Posix library (well-designed, well-tested under many systems, well-documented, and well-maintained), it might win over Unix. I can see no obstacle to that, neither technical nor political. -- Alain ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners