Re: [Caml-list] [OSR] Caml Community Code

[Jean-Marc EBER <jeanmarc.eber@lexifi.com>]

Hi all,

Without entering into a dialog on this list, LexiFi, whose name has been cited 
in this mail, wants to make the following clarification(s):

Jon Harrop a écrit :
> One thing I would like to do is try to reconcile existing "OCaml-derived" 
> distributions, taking the best from each of them. I am happy to call 
> these "forks" but perhaps that has bad connurtations.
> 
> For example, Alain Frisch recently said:
> 
>   "In particular, we have our locally-patched version of OCaml and all the 
> third-party libraries (either in source or binary form) in the repository."
> 
> To me, that means LexiFi forked OCaml for their own purposes. Many other 
> industrial users have also forked OCaml. More importantly, these forks are 
> often degenerate: they reimplement the same missing functionality, often in 
> slightly different and incompatible ways.
> 

[I cannot speak for "other industrial users" of course]

1. LexiFi is a member of the Caml Consortium. We think that anybody projecting
serious business with OCaml should try to become such a member.

2. LexiFi is not, in any way, "forking" OCaml. LexiFi is, however, producing and 
selling a "sectorial enhanced" (in our case for the financial sector) OCaml 
compiler. We are very careful in _not_ calling it OCaml, although we publish 
clearly our OCaml compatibility (which our clients are indeed calling for, let 
alone for being able to use the many existing OCaml documentations and libraries).

3. On a regular basis, we upgrade our compiler to the newest OCaml/Inria version.

4. Our "diff" with respect to OCaml that we want, in our own interest, to keep 
as small as possible, can be categorized in 3 kinds:

a. Sectorial enhancements: no interest for the OCaml community, as OCaml is 
supposed to be a general purpose language.

b. Other enhancements that are useful to ourselves or our customers, but that 
are only partially implemented, making any inclusion into OCaml (supposed that 
they would be accepted) impossible. A typical example is an extension of type 
declarations with some annotation mechanism that does not work well with 
objects, polymorphic variants or functors. Clearly a show stopper in OCaml, 
acceptable in a specialized setting like ours.

c. General purpose cleanups, small enhancements etc.: we inform Inria about 
them: Inria may or may not incorporate these patches.


To be clear: LexiFi will not support or participate in any OCaml activity or 
community project that is not clearly managed to go "hand in hand" with Inria.

> 
> . OCaml's top-level runs interpreted bytecode and, consequently, is many times 
> slower than the interactive sessions of "competing" language implementations 
> like SBCL (Lisp) and F#. Alain Frisch has already implemented a native-code 
> top-level for OCaml called "ocamlnat" in his "natdynlink" fork of OCaml. I 
> found this extremely useful and would like it to be easier for other people 
> to benefit from this work.

Jon, please, be careful with your public statements here.
The "natdynlink" branch (repeat after me, branch, _not_ fork) has been 
implemented by Alain Frisch when he was at Inria, with full knowledge of Xavier 
Leroy. The idea was that if this _branch_ worked, it was supposed to become 
mainstream; this is so true that it has been merged into... cvs HEAD !

Best regards,

Jean-Marc Eber
LexiFi