Adds missing functions to *Labels modules

[little-arhat]

This fix make it possible to use labeled modules as drop-in replacement with
open StdLabels.

Added signatures:

(* arrayLabels.mli *)
val iter2 : f:('a -> 'b -> unit) -> 'a array -> 'b array -> unit
val map2 : f:('a -> 'b -> 'c) -> 'a array -> 'b array -> 'c array

(* bytesLabels.mli *)
val extend : bytes -> left:int -> right:int -> bytes
val blit_string :
val cat : bytes -> bytes -> bytes
val uppercase_ascii : bytes -> bytes
val lowercase_ascii : bytes -> bytes
val capitalize_ascii : bytes -> bytes
val uncapitalize_ascii : bytes -> bytes
val equal: t -> t -> bool

(* listLabels.mli *)
val compare_lengths : 'a list -> 'b list -> int
val compare_length_with : 'a list -> len:int -> int
val cons : 'a -> 'a list -> 'a list

(* moreLabels.Hashtbl *)
val is_randomized : unit -> bool

(* stringLabels.mli *)
val uppercase_ascii : string -> string
val lowercase_ascii : string -> string
val capitalize_ascii : string -> string
val uncapitalize_ascii : string -> string
val equal: t -> t -> bool
val split_on_char: sep:char -> string -> string list

[gasche]

In principle I agree that keeping the *Labels module on par is a good thing.

Now the nitpicking details. Would we want to have labels on some of the several-arguments function? Here are some potential ideas (but I'm not saying they should absolutely be applied):

val compare_length_with : 'a list -> len:int -> bool
val split_on_char: sep:char -> string -> string list

[garrigue]

Thank you very much for these additions.
Keeping the *Labels modules on par is not just a good thing, it is actually a requirement: open StdLabels and open MoreLabels should add labels to some functions, without hiding anything.

I agree with @gasche on the labelling of compare_length_with and split_on_char, which is coherent with the rest of StdLabels.

[little-arhat]

@gasche, @garrigue I've added labels to these two functions.

By the way, I couldn't find any tests checking compatibility of labeled and non-labeled modules. We could miss to add new functions again in the future without them. Should we add tests for that? The easiest way I could think of would be comparing .mli files, but maybe there is some clever way to check this with type-checker and include module type?

[damiendoligez]

It should be easy with a sed script that creates a .ml file, but is there a more elegant way?

[Drup]

module L : module type of List = ListLabels

for each module, compiled with -nolabels ?

[little-arhat]

@Drup great! used your idea to add simple tests.

[Drup]

module type of struct include Hashtbl end if you want to preserve type equalities. Not sure if that's going to be enough since the fields are not re-exported in MoreLabels.Hashtbl ... but they probably should be.

[little-arhat]

Tried this, same error ...Their kinds differ..

[gasche]

@damiendoligez do we want this in 4.04? I'm ready to release a new version of Batteries with 4.04 compatibility, but if we decide to take this one in I would wait for it first.

[alainfrisch]

I'm against changing the stdlib a few hours/days before a release. People are supposed to start adapting their libraries when we issue release candidates, and if we start changing things (which can break code in the wild) after release candidates and just before the release, it will reduce people's incentive to play with release candidates in the future. (Of course, this is a bit rhetorical here, since you are also a maintainer of Batteries.)

Not being able to use the most recent additions of stdlib in the *Labels versions is certainly not a critical bug that cannot wait until the next release (which should be out in about 3 months, right?).

[gasche]

I think that's a fair argument.

[damiendoligez]

which should be out in about 3 months, right?

What?

[alainfrisch]

I thought 4.05 should be frozen in January 2017. So it would be a bit more than 3 months for the release, but hopefully not much more (I know, I'm dreaming...).

[damiendoligez]

I thought 4.05 should be frozen in January 2017.

February, so it'll be frozen, not out, in 3 months.

[alainfrisch]

Please Damien let me dream a bit about the delay between freeze and release going down at some point...

[alainfrisch]

Coming back to the topic of this PR. Would it be a good opportunity to change the doc strings in *Labels modules to refer to the real module names? (e.g. refer to ArrayLabels.iter2 as ArrayLabels.iter2, not Labels.iter2)

[EDIT] I see that these modules are supposed to be used through open StdLabels. If we stick to this style, the "deprecated" messages in this PR should refer to Array.foo, not ArrayLabels.foo; and also the doc for split_on_char. I've no strong opinion on which is best, but let's be consistent.

[little-arhat]

As per @alainfrisch suggestions, fixed all docs and deprecation warnings in *Labels.

[little-arhat]

Is everything OK with this patch now, or there are some other suggestions to improve it?
Thanks.

[alainfrisch]

Thanks for the reminder and the nice contribution.