[Caml-list] About contributions to the Standard Library

[Caml-list] About contributions to the Standard Library

[Damien Doligez]

Dear Ocaml contributors and users,

I would like to call to your attention the section below,
which was recently added to the CONTRIBUTING.md file in the
OCaml source repository.

Have a nice day,

-- Damien


## Contributing to the standard library

Contributions to the standard library are very welcome.  There is some
widespread belief in the community than the stdlib is somehow "frozen"
and that its evolutions are mostly driven by the need of the OCaml
compiler itself.  Let's be clear: this is just plain wrong. The
compiler is happy with its own local utility functions, and many
recent additions to the stdlib are not used by the compiler.

Another common and wrong idea is that core OCaml maintainers don't
really care about the standard library.  This is not true, and won't
be unless one of the "alternative standard" libraries really gains
enough "market share" in the community.

So: please contribute!

Obviously, the proposals to evolve the standard library will be
evaluated with very high standards, similar to those applied to the
evolution of the surface langage, and much higher than those for
internal compiler changes (optimizations, etc).

A key property of the standard library is its stability.  Backward
compatibility is not an absolute technical requirement (any addition
to/of a module can break existing code, formally), but breakage should
be limited as much as possible (and assessed, when relevant).  A
corollary is that any addition creates a long-term support commitment.
For instance, once a concrete type or function is made public,
changing the exposed definition cannot be done easily.

There is no plan to extend dramatically the functional domain covered
by the standard library.  For instance, proposals to include support
for XML, JSON, or network protocols are very likely to be rejected.  Such
domains are better treated by external libraries.  Small additions to
existing modules are much simpler to get in, even more so (but not
necessarily) when:

  - they cannot easily be implemented externally, or when
  - they facilitate communication between independent external
    libraries, or when
  - they fill obvious gaps.

Of course, standard guidelines apply as well: proper documentation,
proper tests, portability (yes, also Windows!), good justification for
why the change is desirable and why it should go into stdlib.

So: be prepared for some serious review process!  But yes, yes,
contributions are welcome and appreciated.  Promised.

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

[Gabriel Scherer]

[-- Attachment #1: Type: text/plain, Size: 5995 bytes --]

In my experience, reviewing propositions for new functions to the standard
library is very delicate and a rather stressful process. I think that
guidelines on how to discuss, review and validate these proposals would
help making it easier. Do we have some, or do we intend to have some in the
short-term future?

What makes standard library additions hard to review is that the review is,
*in essence*, a session in bike-shedding. We can all recognize
bike-shedding and it makes nobody happy, but when doing API design
bike-shedding is very much the point. So standard library addition
discussions, by design, tend to make people frustrated. I think policies on
how to contribute to these discussions, and how decisions will be made,
could help alleviate some of that frustratoin.

For the 4.03 deadline we had a very simple policy: we would only accept
functions whose name and function were completely obvious and
non-objectionable ("map2" for example). If anyone in the discussion had a
reservation about a function, we did not include it. In retrospect, I think
that having agreed on that was an excellent choice, it made it easy to
discuss those proposals.

Now of course this specific policy was only intended short-term, and is
probably too conservative to handle future stdlib changes. Is there a
reasonable relaxation of that policy that people would be willing to agree
on? Or maybe it would be possible to explicit the fact that there are
several kind of contributions, some that fit certain well-defined criteria
(such as the one above: being obvious and completely uncontroversial) and
are expected to be processed/review/decided in due diligence, and some that
are outside these bounds and should be *expected* to devolve into long and
possibly-frustrating discussions?


## Notes

(1) Discussing function names or seemingly-minor API details is not
necessarily an exercise in subjectivity. There are precise (formal) things
that can be said about properties of certain interfaces compared to others,
as we discussed with Daniel Bünzli in a memorable past discussion in
GPR#10. Taking time to make decisions can result in measurably better
designs, and the importance of unit testsuits *and* property testing to
help and structure API design cannot be under-estimated.)


(2) I think part of the stress comes not from the specific status of
standard library (it exists with other libraries), but because of
backward-compatibility requirements: one cannot get it wrong on the first
time. I think this strong requirement is a good choice for the standard
library, despite its costs.


(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).

On Tue, Jun 21, 2016 at 7:56 AM, Damien Doligez <damien.doligez@inria.fr>
wrote:

> Dear Ocaml contributors and users,
>
> I would like to call to your attention the section below,
> which was recently added to the CONTRIBUTING.md file in the
> OCaml source repository.
>
> Have a nice day,
>
> -- Damien
>
>
> ## Contributing to the standard library
>
> Contributions to the standard library are very welcome.  There is some
> widespread belief in the community than the stdlib is somehow "frozen"
> and that its evolutions are mostly driven by the need of the OCaml
> compiler itself.  Let's be clear: this is just plain wrong. The
> compiler is happy with its own local utility functions, and many
> recent additions to the stdlib are not used by the compiler.
>
> Another common and wrong idea is that core OCaml maintainers don't
> really care about the standard library.  This is not true, and won't
> be unless one of the "alternative standard" libraries really gains
> enough "market share" in the community.
>
> So: please contribute!
>
> Obviously, the proposals to evolve the standard library will be
> evaluated with very high standards, similar to those applied to the
> evolution of the surface langage, and much higher than those for
> internal compiler changes (optimizations, etc).
>
> A key property of the standard library is its stability.  Backward
> compatibility is not an absolute technical requirement (any addition
> to/of a module can break existing code, formally), but breakage should
> be limited as much as possible (and assessed, when relevant).  A
> corollary is that any addition creates a long-term support commitment.
> For instance, once a concrete type or function is made public,
> changing the exposed definition cannot be done easily.
>
> There is no plan to extend dramatically the functional domain covered
> by the standard library.  For instance, proposals to include support
> for XML, JSON, or network protocols are very likely to be rejected.  Such
> domains are better treated by external libraries.  Small additions to
> existing modules are much simpler to get in, even more so (but not
> necessarily) when:
>
>   - they cannot easily be implemented externally, or when
>   - they facilitate communication between independent external
>     libraries, or when
>   - they fill obvious gaps.
>
> Of course, standard guidelines apply as well: proper documentation,
> proper tests, portability (yes, also Windows!), good justification for
> why the change is desirable and why it should go into stdlib.
>
> So: be prepared for some serious review process!  But yes, yes,
> contributions are welcome and appreciated.  Promised.
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 6940 bytes --]

[Caml-list] About "precise (formal) things that can be said about properties of certain interfaces"

[David MENTRE]

Hello,

Le 21/06/2016 à 17:48, Gabriel Scherer a écrit :
> (1) Discussing function names or seemingly-minor API details is not
> necessarily an exercise in subjectivity. There are precise (formal)
> things that can be said about properties of certain interfaces compared
> to others, as we discussed with Daniel Bünzli in a memorable past
> discussion in GPR#10. Taking time to make decisions can result in
> measurably better designs, and the importance of unit testsuits *and*
> property testing to help and structure API design cannot be under-estimated.

Could you elaborate a bit that point? Could you give example of such
"precise (formal) things that can be said about properties of certain
interfaces"?

I am especially interested in such formal properties that could much
improve the design.

Sincerely yours,
D. Mentré

Re: [Caml-list] About "precise (formal) things that can be said about properties of certain interfaces"

[Gabriel Scherer]

[-- Attachment #1: Type: text/plain, Size: 4918 bytes --]

TL;DR: there is no *generic* technique to improve any design, it's a
methodology that consists in finding invariants that your functions
respect, and tweaking their behavior so that they respect nicer, simpler
invariants. The trick, in my experience, is that this practice naturally
arises when you are careful about testing and have a random-testing library
easily available.

Long version:

Quickcheck-style property testing ("generate randoms x, y, z and check that
they verify this property") encourage users to formulate the
invariants/properties of the function(s) they are testing as first-order
formulas (usually forall-only). In my experience, this is an excellent
mindset in which to put code authors at the moment they are designing and
implementing the function (so these tests should come simultaneously, not
after the implementation effort), because it makes you think about the
properties the function should have, and this is a very effective way to
make the right choices on corner cases: most choices will *not* respect
nice properties, and those that do are the right ones.

In Batteries we use the qtest library (
https://github.com/vincent-hugot/iTeML ) to write inline random tests, but
they are less common than unit tests (they take more effort to write). I
just looked (git grep -A2 "\$Q") and they seem to fit in three big
categories:
1. Round-trip tests
    ((decode (encode s) = s)
    (eq li (li |> enum |> of_enum)).
2. Equivalence of the function implementation with a naive/simpler
implementation,
    (eq (filter p v) = (to_list v |> List.filter p |> of_list))
    (popcount x = popcount_sparse x)
    (to_list (List.fold_left insert empty l) = List.sort Pervasives.compare
l)
3. A bunch of more diverse and less easy/generic to formulate tests.

The most benefits come from (3) of course, but (2) can also be a way to
solve corner cases -- although usually you don't have to think this way to
"know" what the right behavior is.

Some examples of (3) are the following
  val edit_distance : string -> string -> int
    (edit_distance s1 s2 = edit_distance s2 s1)

  val nsplit : ('a -> bool) -> 'a list -> 'a list list
    (xs = join sep (nsplit ((=) sep) xs))
    (nsplit ((=) sep) la @ nsplit ((=) sep) lb = nsplit ((=) eq) (la @
[sep] @ lb)

In the case discussed in GPR#10,
  val split : ~sep:string -> string -> string list

I found it rather hard to get a good design for the corner cases, for
example what the value of (split ~sep sep) should be, or (split ~sep ""),
or (split ~sep:"" s), or (split ~sep:"" ""). My solution to get a
meaningful behavior on all those cases was to ask: what is a function
(concat_splits) such that

  split ~sep (sa ^ sb) = concat_splits (split ~sep sa) (split ~sep sb)

?

In more formal terms that corresponds to asking for split to transport the
monoid structure of strings. Formally one would also need to specify (split
~sep "") separately, but in fact finding any reasonable concat_splits
function also answers this question.

Daniel Bünzli independently designed this function on his end, thinking
about different invariants, and we got the exact same behavior on both
ends. That's anecdotal evidence that this approach can lead to more
objective design choices.

(In fact I would say that property-testing is *more* useful for API
guidance than actual testing -- at implementation-time or against
regression; in my experience you always also write small unit tests to
specifically exercise the corner cases you think about, and those tend to
suffice to catch the implementation bugs or regressions that are easily
found by testing.)



On Tue, Jun 21, 2016 at 11:54 AM, David MENTRE <dmentre@linux-france.org>
wrote:

> Hello,
>
> Le 21/06/2016 à 17:48, Gabriel Scherer a écrit :
> > (1) Discussing function names or seemingly-minor API details is not
> > necessarily an exercise in subjectivity. There are precise (formal)
> > things that can be said about properties of certain interfaces compared
> > to others, as we discussed with Daniel Bünzli in a memorable past
> > discussion in GPR#10. Taking time to make decisions can result in
> > measurably better designs, and the importance of unit testsuits *and*
> > property testing to help and structure API design cannot be
> under-estimated.
>
> Could you elaborate a bit that point? Could you give example of such
> "precise (formal) things that can be said about properties of certain
> interfaces"?
>
> I am especially interested in such formal properties that could much
> improve the design.
>
> Sincerely yours,
> D. Mentré
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 6177 bytes --]

Re: [Caml-list] About "precise (formal) things that can be said about properties of certain interfaces"

[Jesper Louis Andersen]

[-- Attachment #1: Type: text/plain, Size: 2168 bytes --]

On Tue, Jun 21, 2016 at 9:11 PM, Gabriel Scherer <gabriel.scherer@gmail.com>
wrote:

> In my experience, this is an excellent mindset in which to put code
> authors at the moment they are designing and implementing the function (so
> these tests should come simultaneously, not after the implementation
> effort), because it makes you think about the properties the function
> should have, and this is a very effective way to make the right choices on
> corner cases: most choices will *not* respect nice properties, and those
> that do are the right ones.


Elaborating with an insight I once learned from John Hughes.

When a QuickCheck test case fails, one out of three things are wrong. They
are wrong with about the same frequency:

1. The system-under-test has a failure
2. The property/test specification has a failure
3. The generator, producing random inputs has a failure.

If the 1st happens, it is a genuine bug which can be fixed. If the 2nd
happens, it forces you to think about and strengthen the property, which
after a couple of rounds of strenghtening often results in the 1st case.
The 3rd case is peculiar since it tells you something about the (input)
domain, which often is as important as the property themselves.

A war story was a circuit breaker system I wrote for Erlang. In this
system, there was a specific configuration parameter which could be any
natural number (including 0). But it turned out there were lots of failures
when the configuration parameter was 0. This forced me to think, and I soon
realized that a parameter of 0 did not make any sense, so I changed the
validity domain to be 1 or greater, and added a test which made sure that 0
or less would return an error on system setup.

But then, the code coverage showed a lot of dead code. It turned out my
code had two code paths through it: the 0 case, and everything else. And
the 0 case didn't work. I ended up deleting about half of that module as a
result. QuickCheck systems are really good at testing your boundary and
edge cases for correctness. A really good QC implementation could perhaps
even find that OCaml's default List.map is not tail recursive :)



-- 
J.

[-- Attachment #2: Type: text/html, Size: 2948 bytes --]

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

[Junsong Li]

[-- Attachment #1: Type: text/plain, Size: 6610 bytes --]

Thanks for calling it out.

Well, this actually confuses me a bit. Is the ultimate goal for evolving
the builtin library another "Batteries"? I ask this because it does not
sound like you're actually calling for a battery-included stdlib.

If not, here is my second question: Why now? What's the problem for current
stdlib?

Thanks.


On Tue, Jun 21, 2016 at 11:48 PM, Gabriel Scherer <gabriel.scherer@gmail.com
> wrote:

> In my experience, reviewing propositions for new functions to the standard
> library is very delicate and a rather stressful process. I think that
> guidelines on how to discuss, review and validate these proposals would
> help making it easier. Do we have some, or do we intend to have some in the
> short-term future?
>
> What makes standard library additions hard to review is that the review
> is, *in essence*, a session in bike-shedding. We can all recognize
> bike-shedding and it makes nobody happy, but when doing API design
> bike-shedding is very much the point. So standard library addition
> discussions, by design, tend to make people frustrated. I think policies on
> how to contribute to these discussions, and how decisions will be made,
> could help alleviate some of that frustratoin.
>
> For the 4.03 deadline we had a very simple policy: we would only accept
> functions whose name and function were completely obvious and
> non-objectionable ("map2" for example). If anyone in the discussion had a
> reservation about a function, we did not include it. In retrospect, I think
> that having agreed on that was an excellent choice, it made it easy to
> discuss those proposals.
>
> Now of course this specific policy was only intended short-term, and is
> probably too conservative to handle future stdlib changes. Is there a
> reasonable relaxation of that policy that people would be willing to agree
> on? Or maybe it would be possible to explicit the fact that there are
> several kind of contributions, some that fit certain well-defined criteria
> (such as the one above: being obvious and completely uncontroversial) and
> are expected to be processed/review/decided in due diligence, and some that
> are outside these bounds and should be *expected* to devolve into long and
> possibly-frustrating discussions?
>
>
> ## Notes
>
> (1) Discussing function names or seemingly-minor API details is not
> necessarily an exercise in subjectivity. There are precise (formal) things
> that can be said about properties of certain interfaces compared to others,
> as we discussed with Daniel Bünzli in a memorable past discussion in
> GPR#10. Taking time to make decisions can result in measurably better
> designs, and the importance of unit testsuits *and* property testing to
> help and structure API design cannot be under-estimated.)
>
>
> (2) I think part of the stress comes not from the specific status of
> standard library (it exists with other libraries), but because of
> backward-compatibility requirements: one cannot get it wrong on the first
> time. I think this strong requirement is a good choice for the standard
> library, despite its costs.
>
>
> (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).
>
> On Tue, Jun 21, 2016 at 7:56 AM, Damien Doligez <damien.doligez@inria.fr>
> wrote:
>
>> Dear Ocaml contributors and users,
>>
>> I would like to call to your attention the section below,
>> which was recently added to the CONTRIBUTING.md file in the
>> OCaml source repository.
>>
>> Have a nice day,
>>
>> -- Damien
>>
>>
>> ## Contributing to the standard library
>>
>> Contributions to the standard library are very welcome.  There is some
>> widespread belief in the community than the stdlib is somehow "frozen"
>> and that its evolutions are mostly driven by the need of the OCaml
>> compiler itself.  Let's be clear: this is just plain wrong. The
>> compiler is happy with its own local utility functions, and many
>> recent additions to the stdlib are not used by the compiler.
>>
>> Another common and wrong idea is that core OCaml maintainers don't
>> really care about the standard library.  This is not true, and won't
>> be unless one of the "alternative standard" libraries really gains
>> enough "market share" in the community.
>>
>> So: please contribute!
>>
>> Obviously, the proposals to evolve the standard library will be
>> evaluated with very high standards, similar to those applied to the
>> evolution of the surface langage, and much higher than those for
>> internal compiler changes (optimizations, etc).
>>
>> A key property of the standard library is its stability.  Backward
>> compatibility is not an absolute technical requirement (any addition
>> to/of a module can break existing code, formally), but breakage should
>> be limited as much as possible (and assessed, when relevant).  A
>> corollary is that any addition creates a long-term support commitment.
>> For instance, once a concrete type or function is made public,
>> changing the exposed definition cannot be done easily.
>>
>> There is no plan to extend dramatically the functional domain covered
>> by the standard library.  For instance, proposals to include support
>> for XML, JSON, or network protocols are very likely to be rejected.  Such
>> domains are better treated by external libraries.  Small additions to
>> existing modules are much simpler to get in, even more so (but not
>> necessarily) when:
>>
>>   - they cannot easily be implemented externally, or when
>>   - they facilitate communication between independent external
>>     libraries, or when
>>   - they fill obvious gaps.
>>
>> Of course, standard guidelines apply as well: proper documentation,
>> proper tests, portability (yes, also Windows!), good justification for
>> why the change is desirable and why it should go into stdlib.
>>
>> So: be prepared for some serious review process!  But yes, yes,
>> contributions are welcome and appreciated.  Promised.
>>
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa.inria.fr/sympa/arc/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
>
>

[-- Attachment #2: Type: text/html, Size: 7798 bytes --]

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

[Alain Frisch]

On 21/06/2016 17:48, Gabriel Scherer wrote:
> In my experience, reviewing propositions for new functions to the
> standard library is very delicate and a rather stressful process. I
> think that guidelines on how to discuss, review and validate these
> proposals would help making it easier. Do we have some, or do we intend
> to have some in the short-term future?

I don't think we have such review guidelines, but we don't have them 
either for non stdlib-related proposals (and the proportion of open 
Github PRs related to the stdlib is only a tiny fraction; contrary to 
you, I don't feel the stdlib discussions to be more painful than most 
other PR discussions).  Perhaps with some more experience with reviewing 
stdlib PRs, some process and guidelines (for contributing and reviewing) 
could emerge.

Something else that should also be clarified is that the input from the 
community on PRs (stdlib-related or not) is very much appreciated.  It's 
not about crowdsourced design, but judging the usefulness of proposals 
is not something where the technical expertise of core developers is of 
a big help.  (Of course, the original contributor should also take the 
time to explain why they believe their proposal is useful: it's usually 
not obvious)


Alain

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

[Daniel Bünzli]

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

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

[Alain Frisch]

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

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

[Daniel Bünzli]

[snip]

Ok generally agreed that the proposal doesn't feel like a good idea.

> 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.

Well bug fixes… You can start branching for these users but it is a maintenance burden.
  
> Could you share the reasons for you to target 4.01 (and not, say 3.04)
> today?

Note, if it were only me I'd only target the smallest version that has everything that I used in the implementation of the package…

However I have in the past published some libraries using 4.02 only features and I was asked if this could be backported to 4.01 (since it was only changing an open variant into a universal type, I did). In general I now choose 4.01 because:

1) I think that supporting at least the current major OCaml release and the previous one is reasonable both for me and users of my software. (Well 4.03 is out now but adoption seems to have been slow… Also if the pace of major releases accelerates this rule of thumb may have to change).

2) 4.01 has GADTs, fixes for them and a few convenient combinators added to pervasives. It seems a reasonable version to code in.

3) IIUC it is what is distributed by current debian stable.

Note that I'm not sure whether 3) is relevant or not. In my opinion system package managers should be used to install applications written in OCaml. If you want to develop in OCaml you should install OPAM and the OCaml version you end up using is no longer really relevant.

Best,  

Daniel

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

[Goswin von Brederlow]

On Fri, Jul 08, 2016 at 03:37:27PM +0100, Daniel Bünzli wrote:
> [snip]
> 
> Ok generally agreed that the proposal doesn't feel like a good idea.
> 
> > 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.

When people can't be bothered or aren't allowed to update the ocaml compiler
what makes you think there would be any difference with updating stdlib? I
think the time is better spend of releasing ocaml more frequently than making
more work by splitting compiler and stdlib.
 
> Well bug fixes… You can start branching for these users but it is a maintenance burden.
>   
> > Could you share the reasons for you to target 4.01 (and not, say 3.04)
> > today?
> 
> Note, if it were only me I'd only target the smallest version that has everything that I used in the implementation of the package…
> 
> However I have in the past published some libraries using 4.02 only features and I was asked if this could be backported to 4.01 (since it was only changing an open variant into a universal type, I did). In general I now choose 4.01 because:
> 
> 1) I think that supporting at least the current major OCaml release and the previous one is reasonable both for me and users of my software. (Well 4.03 is out now but adoption seems to have been slow… Also if the pace of major releases accelerates this rule of thumb may have to change).
> 
> 2) 4.01 has GADTs, fixes for them and a few convenient combinators added to pervasives. It seems a reasonable version to code in.
> 
> 3) IIUC it is what is distributed by current debian stable.
> 
> Note that I'm not sure whether 3) is relevant or not. In my opinion system package managers should be used to install applications written in OCaml. If you want to develop in OCaml you should install OPAM and the OCaml version you end up using is no longer really relevant.
> 
> Best,  
> 
> Daniel

3) is a big reason for me. Or if not stable then at least testing.
There is also Ubuntu and others with long term releases where versions
can remain lower than would be good.

But then again there is opam. If you can't update the system but need
newer ocaml it's easy enough to build it locally. Half the time you
need opam just because the distribution doesn't even have everything
you use packaged.

MfG
	Goswin

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

[Daniel Bünzli]

Le lundi, 11 juillet 2016 à 09:55, Goswin von Brederlow a écrit :
> I think the time is better spend of releasing ocaml more frequently than making
> more work by splitting compiler and stdlib.

[…]

> 3) is a big reason for me. Or if not stable then at least testing.
> There is also Ubuntu and others with long term releases where versions
> can remain lower than would be good.

[…]  

If 3) is important to you then releasing ocaml more frequently won't change anything to the problem.  

One of the big problem and reason I have not been able to simply always targeting the latest I naturally need to implement a package is *precisely* because of distributions lagging far behind from the current released version — 4.01 was released almost three years ago and that's what we have in debian stable.  

Best,  

Daniel

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

[Adrien Nader]

On Mon, Jul 11, 2016, Daniel Bünzli wrote:
> Le lundi, 11 juillet 2016 à 09:55, Goswin von Brederlow a écrit :
> > I think the time is better spend of releasing ocaml more frequently than making
> > more work by splitting compiler and stdlib.
> 
> […]
> 
> > 3) is a big reason for me. Or if not stable then at least testing.
> > There is also Ubuntu and others with long term releases where versions
> > can remain lower than would be good.
> 
> […]  
> 
> If 3) is important to you then releasing ocaml more frequently won't change anything to the problem.  
> 
> One of the big problem and reason I have not been able to simply always targeting the latest I naturally need to implement a package is *precisely* because of distributions lagging far behind from the current released version — 4.01 was released almost three years ago and that's what we have in debian stable.  

And this is why there are time-based releases of software projects which
moreover try to align with the schedule of distributions for their
stable versions. For debian oldstable, the OCaml release arrived only a
few weeks, at most months, late; I wouldn't blame Debian for not going
with something that was known to not be very stable.

-- 
Adrien Nader

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

[Daniel Bünzli]

Le lundi, 11 juillet 2016 à 10:48, Adrien Nader a écrit :
> For debian oldstable, the OCaml release arrived only a
> few weeks, at most months, late; I wouldn't blame Debian for not going
> with something that was known to not be very stable.

Sure, but what strikes me is that people feel that supporting the OCaml version distributed by mainstream system packagers is important.  

I see the later as being a medium to distribute end-user application that are installable by the same package system not as a medium that is useful to support the working OCaml programmer.

Best,  

Daniel

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

[Adrien Nader]

On Mon, Jul 11, 2016, Daniel Bünzli wrote:
> Le lundi, 11 juillet 2016 à 10:48, Adrien Nader a écrit :
> > For debian oldstable, the OCaml release arrived only a
> > few weeks, at most months, late; I wouldn't blame Debian for not going
> > with something that was known to not be very stable.
> 
> Sure, but what strikes me is that people feel that supporting the OCaml version distributed by mainstream system packagers is important.  
> 
> I see the later as being a medium to distribute end-user application that are installable by the same package system not as a medium that is useful to support the working OCaml programmer.

I see it as important because things get a bit sad if your code never
reaches end-users.
If you look around, you'll see that many large-ish projects have shifted
to time-based releases. That said, I don't like calling them
"time-based" because the approach is more to limit the scope and avoid
schedule slips by having a clear and simple measurement (time left
before the given day) that is also known in advance.

Of course, with time-based releases, it is also possible to synchronize
in order to always release right after distros freeze. The idea is
rather to take them into account because getting stable and
reasonably-recent software to users is really. Releasing stable versions
is a time-consuming work not matter the topic and I don't find it sane
to not take them into account.

-- 
Adrien Nader

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

[Daniel Bünzli]

Le lundi, 11 juillet 2016 à 19:34, Adrien Nader a écrit :
> I see it as important because things get a bit sad if your code never
> reaches end-users.

[...]
> If you look around, you'll see that many large-ish projects have shifted
> to time-based releases.

[...]  
> Releasing stable versions
> is a time-consuming work not matter the topic and I don't find it sane
> to not take them into account.

I'm not sure we are understanding each other here.  

1. I think it's precisely the purpose of a system package manager to cut consistent releases of OCaml and OPAM packages in order to deliver end-user *applications* (e.g. unison). Once this is done you get to install these applications using this consistent system.  

2. The fact that people are doing time-based releases is irrelevant to this discussion. What is relevant is how long these releases are supported, the constraints they impose and for which purpose they are used.

3. I don't know where you got the idea that I was somehow against stable versions or that I didn't want to take them into account.

So to sum up while 1. is fine. It seems dubious to me to use these system packages in order to do application *development*, and hence to require current developments to remain compatible with these versions, especially if they are long-lasting without the possibility of bumping their version number beyond bug fixes.

Best,  

Daniel

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

[Goswin von Brederlow]

On Mon, Jul 11, 2016 at 10:43:10AM +0100, Daniel Bünzli wrote:
> Le lundi, 11 juillet 2016 à 09:55, Goswin von Brederlow a écrit :
> > I think the time is better spend of releasing ocaml more frequently than making
> > more work by splitting compiler and stdlib.
> 
> […]
> 
> > 3) is a big reason for me. Or if not stable then at least testing.
> > There is also Ubuntu and others with long term releases where versions
> > can remain lower than would be good.
> 
> […]  
> 
> If 3) is important to you then releasing ocaml more frequently won't change anything to the problem.  
> 
> One of the big problem and reason I have not been able to simply always targeting the latest I naturally need to implement a package is *precisely* because of distributions lagging far behind from the current released version — 4.01 was released almost three years ago and that's what we have in debian stable.  
> 
> Best,  
> 
> Daniel

But at least ocaml will only be as old as the distribution and not an
extra 2 years because the next ocaml releast was a year after the
distribution froze.

Anyway. My point (did I have a point?) was that a stdlib release won't
change anything. Old compiler or old stdlib, same problem. If you like
my prefer a stable distribution then you have to live with older
versions (or use opam). I don't think this proposal would change
anything there.

MfG
	Goswin

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

[Ian Zimmerman]

On 2016-07-11 10:55 +0200, Goswin von Brederlow wrote:

> But then again there is opam. If you can't update the system but need
> newer ocaml it's easy enough to build it locally. Half the time you
> need opam just because the distribution doesn't even have everything
> you use packaged.

OTOH installing opam itself can be difficult because of its
dependencies, mostly aspcud.

I just switched to gentoo, and there it is pretty much impossible unless
one's content with the internal solver.

-- 
Please *no* private copies of mailing list or newsgroup messages.
Why does the arrow on Hillary signs point to the right?

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

[Gabriel Scherer]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

Did you consider packaging aspcud for gentoo? Are there gentoo-specific
issues with that route?

On Tue, Jul 12, 2016 at 2:32 PM, Ian Zimmerman <itz@buug.org> wrote:

> On 2016-07-11 10:55 +0200, Goswin von Brederlow wrote:
>
> > But then again there is opam. If you can't update the system but need
> > newer ocaml it's easy enough to build it locally. Half the time you
> > need opam just because the distribution doesn't even have everything
> > you use packaged.
>
> OTOH installing opam itself can be difficult because of its
> dependencies, mostly aspcud.
>
> I just switched to gentoo, and there it is pretty much impossible unless
> one's content with the internal solver.
>
> --
> Please *no* private copies of mailing list or newsgroup messages.
> Why does the arrow on Hillary signs point to the right?
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 1833 bytes --]

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

[Ian Zimmerman]

On 2016-07-12 15:01 -0400, Gabriel Scherer wrote:

> > OTOH installing opam itself can be difficult because of its
> > dependencies, mostly aspcud.
> >
> > I just switched to gentoo, and there it is pretty much impossible unless
> > one's content with the internal solver.

> Did you consider packaging aspcud for gentoo? Are there gentoo-specific
> issues with that route?

An aspcud package exists - that is not the problem.  The problem is its
horribly long and tangled list of dependencies.  Which, unlike most
distros, includes build-only dependencies, of course.  And which is
almost guaranteed to conflict with some other package you need for an
unrelated purpose.

-- 
Please *no* private copies of mailing list or newsgroup messages.
Why does the arrow on Hillary signs point to the right?

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

[Gabriel Scherer]

[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]

Note that opam in theory supports other solvers as listed at


https://opam.ocaml.org/doc/Specifying_Solver_Preferences.html#Yestherearedifferentversionsoftheuserpreferencelanguage

for example "packup" also gives good results and may be easier to build.

In practice, however, I think that most opam users choose aspcud (maybe
simply because the documentation recommends it) and I would not be
surprised if opam lost compatibility with other solvers at some point, for
example by making ascpud-specific assumption on the solver preference
language. But more people using other solvers can only improve the problem
-- and it may work already.

On Tue, Jul 12, 2016 at 5:26 PM, Ian Zimmerman <itz@buug.org> wrote:

> On 2016-07-12 15:01 -0400, Gabriel Scherer wrote:
>
> > > OTOH installing opam itself can be difficult because of its
> > > dependencies, mostly aspcud.
> > >
> > > I just switched to gentoo, and there it is pretty much impossible
> unless
> > > one's content with the internal solver.
>
> > Did you consider packaging aspcud for gentoo? Are there gentoo-specific
> > issues with that route?
>
> An aspcud package exists - that is not the problem.  The problem is its
> horribly long and tangled list of dependencies.  Which, unlike most
> distros, includes build-only dependencies, of course.  And which is
> almost guaranteed to conflict with some other package you need for an
> unrelated purpose.
>
> --
> Please *no* private copies of mailing list or newsgroup messages.
> Why does the arrow on Hillary signs point to the right?
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 2743 bytes --]

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

[Ian Zimmerman]

On 2016-07-12 18:35 -0400, Gabriel Scherer wrote:

> In practice, however, I think that most opam users choose aspcud
> (maybe simply because the documentation recommends it) and I would not
> be surprised if opam lost compatibility with other solvers at some
> point, for example by making ascpud-specific assumption on the solver
> preference language.

Indeed, this has already happened with the Java-based solver which I
also tried.

Btw, do you see the top line of my sig?

-- 
Please *no* private copies of mailing list or newsgroup messages.
Why does the arrow on Hillary signs point to the right?

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

[Goswin von Brederlow]

On Tue, Jun 21, 2016 at 01:56:43PM +0200, Damien Doligez wrote:
> Dear Ocaml contributors and users,
> 
> I would like to call to your attention the section below,
> which was recently added to the CONTRIBUTING.md file in the
> OCaml source repository.
> 
> Have a nice day,
> 
> -- Damien
> 
> 
> ## Contributing to the standard library
> 
> Contributions to the standard library are very welcome.  There is some
> widespread belief in the community than the stdlib is somehow "frozen"
> and that its evolutions are mostly driven by the need of the OCaml
> compiler itself.  Let's be clear: this is just plain wrong. The
> compiler is happy with its own local utility functions, and many
> recent additions to the stdlib are not used by the compiler.
> 
> Another common and wrong idea is that core OCaml maintainers don't
> really care about the standard library.  This is not true, and won't
> be unless one of the "alternative standard" libraries really gains
> enough "market share" in the community.
> 
> So: please contribute!
>...

Why should we contribute when contibutions are just left to bitrot?

Like: http://caml.inria.fr/mantis/view.php?id=4909 which has had a
patch for 6 1/2 year that's just left rotting.

MfG
	Goswin

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

[Gerd Stolpmann]

[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]

Am Montag, den 27.06.2016, 11:09 +0200 schrieb Goswin von Brederlow:
> Why should we contribute when contibutions are just left to bitrot?
> 
> Like: http://caml.inria.fr/mantis/view.php?id=4909 which has had a
> patch for 6 1/2 year that's just left rotting.

I guess you hit one of the pain points of the current library design,
namely the various integer types (and the issue of combinatorial
increase of possible variants). In my most recent code (a data science
lib) I solved that radically - no support for 32 bit architectures
anymore. The truth is that with current OCaml you cannot support both 32
bit and 64 bit equally well. Either you get a performance loss from
boxed ints, or you get macros in central places of your code.

Of course, that's no excuse for not responding at all.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Gabriel Scherer]

[-- Attachment #1: Type: text/plain, Size: 1651 bytes --]

Well there are more tickets on the bugtracker (and github PRs) than human
time to review and make decisions on all of them. I'm very sorry if some
contributions are left to bitrot. Anyone can help by reviewing and giving
informed opinions on suggestions, and it's most helpful if contributors are
ready to ping from time to time to ask for an opinion on their contribution.

On Mon, Jun 27, 2016 at 7:19 AM, Gerd Stolpmann <info@gerd-stolpmann.de>
wrote:

> Am Montag, den 27.06.2016, 11:09 +0200 schrieb Goswin von Brederlow:
> > Why should we contribute when contibutions are just left to bitrot?
> >
> > Like: http://caml.inria.fr/mantis/view.php?id=4909 which has had a
> > patch for 6 1/2 year that's just left rotting.
>
> I guess you hit one of the pain points of the current library design,
> namely the various integer types (and the issue of combinatorial
> increase of possible variants). In my most recent code (a data science
> lib) I solved that radically - no support for 32 bit architectures
> anymore. The truth is that with current OCaml you cannot support both 32
> bit and 64 bit equally well. Either you get a performance loss from
> boxed ints, or you get macros in central places of your code.
>
> Of course, that's no excuse for not responding at all.
>
> Gerd
> --
> ------------------------------------------------------------
> Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
> My OCaml site:          http://www.camlcity.org
> Contact details:        http://www.camlcity.org/contact.html
> Company homepage:       http://www.gerd-stolpmann.de
> ------------------------------------------------------------
>
>

[-- Attachment #2: Type: text/html, Size: 2518 bytes --]

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

[Goswin von Brederlow]

On Mon, Jun 27, 2016 at 09:21:11AM -0400, Gabriel Scherer wrote:
> Well there are more tickets on the bugtracker (and github PRs) than human
> time to review and make decisions on all of them. I'm very sorry if some
> contributions are left to bitrot. Anyone can help by reviewing and giving
> informed opinions on suggestions, and it's most helpful if contributors are
> ready to ping from time to time to ask for an opinion on their contribution.
> 
> On Mon, Jun 27, 2016 at 7:19 AM, Gerd Stolpmann <info@gerd-stolpmann.de>
> wrote:
> 
> > Am Montag, den 27.06.2016, 11:09 +0200 schrieb Goswin von Brederlow:
> > > Why should we contribute when contibutions are just left to bitrot?
> > >
> > > Like: http://caml.inria.fr/mantis/view.php?id=4909 which has had a
> > > patch for 6 1/2 year that's just left rotting.
> >
> > I guess you hit one of the pain points of the current library design,
> > namely the various integer types (and the issue of combinatorial
> > increase of possible variants). In my most recent code (a data science
> > lib) I solved that radically - no support for 32 bit architectures
> > anymore. The truth is that with current OCaml you cannot support both 32
> > bit and 64 bit equally well. Either you get a performance loss from
> > boxed ints, or you get macros in central places of your code.
> >
> > Of course, that's no excuse for not responding at all.
> >
> > Gerd

But then you should ask for more workers, not for more work.

If you already can't keep up with the existing rate of contributions
then more contributions will only mean more are left to bitrot. Worse,
it means less contribution do get added because you spend more time
just checking new contributions and deciding to not handle them right
now.

But anyway, consider this a ping for my patch. Hopefully it will be
looked at again now.

MfG
	Goswin

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

[Gabriel Scherer]

[-- Attachment #1: Type: text/plain, Size: 3990 bytes --]

On Thu, Jun 30, 2016 at 7:08 AM, Goswin von Brederlow <goswin-v-b@web.de>
wrote:

> But then you should ask for more workers, not for more work.
>

Very true, and we do!

We've always repeatedly claimed that reviewing proposed patches/changes
would be a big help. Some external contributors frequently do it and it is
very useful. (It is particularly useful when they're ready to go to the
level of a code review, but feedback on the design is already useful.)

For a concrete example, the email I sent to announce that we would accept
pull-requests on Github, in addition to patches on Mantis (
https://sympa.inria.fr/sympa/arc/caml-list/2014-01/msg00254.html ), starts
as follows:

I think we need more people ready to review patches proposed for
> inclusion in the OCaml compiler/distribution; lack of reviews is
> currently one of the bottleneck in the development process -- among
> others, such as the sheer difficulty to reach consensus on any change
> to the language itself. Doing patch reviews is helpful, extremely
> interesting, and an excellent way to get to know more about small
> parts of the compiler.
>

To repeat again: any help reviewing proposed patches, on *both* Mantis and
Github, is warmly welcome. It's an excellent way to get to know diverse
parts of the compiler distribution codebase, it's informative, low-risk,
interesting, very helpful. Do it!

That should, of course, not prevent us from un-blocking a situation with
the compiler stdlib, where people interested in also improving its state
(such as you) were prevented from contributing by lack of clear upstream
guidance on the range of accepted changes and the decision process. We want
more reviews *and* more good stuff, and we should have both.

On Thu, Jun 30, 2016 at 7:08 AM, Goswin von Brederlow <goswin-v-b@web.de>
wrote:

> On Mon, Jun 27, 2016 at 09:21:11AM -0400, Gabriel Scherer wrote:
> > Well there are more tickets on the bugtracker (and github PRs) than human
> > time to review and make decisions on all of them. I'm very sorry if some
> > contributions are left to bitrot. Anyone can help by reviewing and giving
> > informed opinions on suggestions, and it's most helpful if contributors
> are
> > ready to ping from time to time to ask for an opinion on their
> contribution.
> >
> > On Mon, Jun 27, 2016 at 7:19 AM, Gerd Stolpmann <info@gerd-stolpmann.de>
> > wrote:
> >
> > > Am Montag, den 27.06.2016, 11:09 +0200 schrieb Goswin von Brederlow:
> > > > Why should we contribute when contibutions are just left to bitrot?
> > > >
> > > > Like: http://caml.inria.fr/mantis/view.php?id=4909 which has had a
> > > > patch for 6 1/2 year that's just left rotting.
> > >
> > > I guess you hit one of the pain points of the current library design,
> > > namely the various integer types (and the issue of combinatorial
> > > increase of possible variants). In my most recent code (a data science
> > > lib) I solved that radically - no support for 32 bit architectures
> > > anymore. The truth is that with current OCaml you cannot support both
> 32
> > > bit and 64 bit equally well. Either you get a performance loss from
> > > boxed ints, or you get macros in central places of your code.
> > >
> > > Of course, that's no excuse for not responding at all.
> > >
> > > Gerd
>
> But then you should ask for more workers, not for more work.
>
> If you already can't keep up with the existing rate of contributions
> then more contributions will only mean more are left to bitrot. Worse,
> it means less contribution do get added because you spend more time
> just checking new contributions and deciding to not handle them right
> now.
>
> But anyway, consider this a ping for my patch. Hopefully it will be
> looked at again now.
>
> MfG
>         Goswin
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 5744 bytes --]

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

[Goswin von Brederlow]

On Mon, Jun 27, 2016 at 01:19:10PM +0200, Gerd Stolpmann wrote:
> Am Montag, den 27.06.2016, 11:09 +0200 schrieb Goswin von Brederlow:
> > Why should we contribute when contibutions are just left to bitrot?
> > 
> > Like: http://caml.inria.fr/mantis/view.php?id=4909 which has had a
> > patch for 6 1/2 year that's just left rotting.
> 
> I guess you hit one of the pain points of the current library design,
> namely the various integer types (and the issue of combinatorial
> increase of possible variants). In my most recent code (a data science
> lib) I solved that radically - no support for 32 bit architectures
> anymore. The truth is that with current OCaml you cannot support both 32
> bit and 64 bit equally well. Either you get a performance loss from
> boxed ints, or you get macros in central places of your code.
> 
> Of course, that's no excuse for not responding at all.
> 
> Gerd

But that patch addresses exactly that problem by introducing a new
Bigarray type that is fast (uses int, not a boxed type) and also uses
the same size on 32bit and 64bit. There are many cases where 31bit
integers are sufficient but in ocaml one can not use them consistently
on 32bit and 64bit.

MfG
	Goswin