Re: [Caml-list] [ANN] The Missing Library

[Alain.Frisch@ens.fr]

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