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

["Daniel Bünzli" <daniel.buenzli@erratique.ch>]

Le mardi, 21 juin 2016 à 16:48, Gabriel Scherer a écrit :
> (3) As Daniel pointed out, we need a better understanding of how to make code written using new stdlib functions compatible with older OCaml versions. So far we've used ad-hoc solutions on each situation, and it was barely manageable despite the small number of instances. (Bytes: in findlib; opaque_identity: clever hack; String ascii functions: no solution).


To sum up the current reality of the situation with respect to per compiler version deprecations and gradual improvements for someone that tries to support more than one version of the compiler is to either:

1. Have to buy into disputable source surgery techniques (preprocessing ifdefs) or isolate differences in module implementations selected according to the compiler version that is targeted. This complexifies your build system, puts a general maintenance burden on everyone and multiplies the paths for bugs.

2. Wait for two or three years to be able to use the new things (I'm personally targeting 4.01 now), possibly having to cope with/silence deprecation warnings during that time (e.g. String.lowercase) which defeats the point of these deprecations.

Given this, I'm wondering how feasible and beneficial, both from a technical and bureaucratic burden point of view, it would be to actually distribute and evolve the standard library separately from the compiler. I didn't give a hard thought about bootstrapping issues since I'm sure there are people on this list that have a clearer answer to that than me.

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.

Of course there are point in times where new versions of this exo-stdlib would introduce lower bounds. But I expect these not to be that widespread. I think they would only happen on significant language/runtime system changes for example because:  

a) A language feature becomes used in the implementation of the stdlib (e.g. GADT for formatters)
b) A language feature becomes used in the interface of the stdlib (e.g. a hypothetical implicits introduction)
c) A language/runtime system feature entails additions of new modules that can't be expressed in earlier version (e.g. a hypothetical introduction of effects).

Note that even in c) it should be possible to backport interfaces, stubbed with failing implementations.

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.

Best,  

Daniel