Re: [Caml-list] [OSR] OCaml Standard Recommandation Process

[Edgar Friendly <thelema314@gmail.com>]

Jon Harrop wrote:
> On Monday 28 January 2008 21:12:08 Gerd Stolpmann wrote:
>> 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.
> 
> Can we clear up once and for all whether or not we can improve the stdlib?
> 

I wish I could answer your question authoritatively.  The best I can
tell from the situation comes to this:

1) The community now has some permission to make a distribution out of
the OCaml code created at INRIA.

2) This distribution should (Must?) not break backwards compatibility
with the currently official, INRIA-blessed distro.

The way I interpret these two gives me/us limited ability to improve the
stdlib.  One question for the community involves both directions of
migration.  #2 insists that INRIA-OCaml programs have the same semantics
(including triggering the same warts of the language) under
Community-OCaml.  i.e. taking a program compiled under INRIA-OCaml and
compiling it under Community-OCaml should "just work".  The reverse --
going from Community-OCaml to INRIA-OCaml -- isn't guaranteed to work in
the same way, *but* the question comes: how much work must the user
spend to translate from Community-OCaml to INRIA-OCaml.

Messing with the type system has many pitfalls, but not least of which
comes a (likely) very difficult conversion to INRIA-OCaml involving
probably complex source-code transformation.

Many people seem to put forward improvement ideas for OCaml that stay
within the realm of including more libraries in the Community-OCaml
distribution, and having efforts to standardize interfaces of these
libraries.  This kind of change seems to have minimal conversion
difficulty to INRIA-OCaml (just install the needed libraries).

In between these extremes sits things like changes to the stdlib and
extensions to the language.  I hope that we can make changes to both of
these.  stdlib changes should only extend the current library (in my
mind this includes changing implementations of existing functions, as
long as the semantics stay identical), but to ease compatibility with
the INRIA-OCaml system, (some of) these changes could get implemented in
such a way that with a small amount of additional work (opening a
"Community.Pervasives" module that includes the new changes).

Changes to the compiler such as try..finally could get put in to the
community distro, but with a "close-enough" camlp4 filter to transform
programs using them into programs that would work under the current
system.  (maybe not as efficiently, maybe with horrible error messages)

E.