Re: [Caml-list] About contributions to the Standard Library

[Alain Frisch <alain.frisch@lexifi.com>]

On 07/07/2016 12:26, Daniel Bünzli wrote:
> The goal behind this move would not be to change the stdlib conservativeness and minimalistic approach but make it possible to use improvement made to stdlib in older OCaml versions.

The stdlib is somehow mechanically tied to the evolution of the runtime 
system (new primitives being exposed) and the compiler (in particular 
for the camlinternalXXX modules).   There would necessarily be a new 
version of the stdlib to be shipped together with a new version of the 
system.  If we stick to our new plan of making much more frequent 
releases, there would probably be no need for intermediate releases of 
the stdlib between versions of OCaml.  So the question is really whether 
"the" stdlib shipped with OCaml version N should work with OCaml version 
M < N.

Supporting in a single stdlib code base the current version of OCaml 
(compiler+runtime system) and older ones would be as difficult as what 
you describe in your point 1.  And we would have the same dilemma about 
waiting to use new features or not.  (Even with the core team 
conservatism, the stdlib is not so slow at adopting new language 
features.  E.g. GADTS for formatters, which is exposed in the interface, 
or the internal use of inline records for performance reasons.)  It 
would be somehow a shame if the stdlib were the last one to benefit from 
language improvements (at least in its implementation, but also in its 
interface for new features).

Considering that progressing on the stdlib is already quite hard, adding 
such extra constraints and work seems a good way to ensure it remains 
completely stalled.  And who would decide until which version one should 
maintain support?

Now, nothing prevent people from backporting some chosen parts and 
distribute e.g. a "stdlib 4.04 for OCaml 4.01", indeed outside the core 
distribution.  This might not be a complete coverage, but it could 
provides some new goodies (e.g. String.split?) to people stuck with 
older versions of OCaml.  This could certainly be done by motivated 
contributors outside the core team.  In this context, I'm not so sure 
about stubbing recent runtime features with failing implementations (if 
a project depends on Ephemerons, it's unlikely to work with a failing 
version of their API).


 > Finally I would just like to say that the current situation also has 
its pluses as it encourages people to upgrade and hence follow the 
general evolution the system.

Good point.  I've to say that I'm always a bit puzzled by the amount of 
energy hobbyists put into supporting old versions of OCaml (compared to 
e.g. ensuring continuously that their packages are ready for the next 
one).  Some industrial (or big academic) users being stuck with older 
versions of OCaml (but many aren't) for good or bad reasons, but the 
same ones are not likely to require the latest versions of third-party 
libraries anyway, so this should not even be an incentive for library 
authors to maintain such compatibility.

Could you share the reasons for you to target 4.01 (and not, say 3.04) 
today?


Alain