String vs StringLabels

Learning
1

What’s the difference between “String” and “StringLabels” in the standard library?

Apologies for a dumb question, but the reference manual doesn’t really explain this. (BTW, it would be nice if it did.)

2

The two modules have the same functions, but in the second one some arguments are labeled. Example with the sub function :

 String.sub;;
- : string -> int -> int -> string = <fun>

StringLabels.sub;;
- : string -> pos:int -> len:int -> string = <fun>

In the labeled module, the signature gives the meaning (using a label) of the int arguments : the first one gives the start index of the substring and the second one its length. BTW, the illustrations given in the labeled version of the documentation are wrong (it seems to only be a copy/paste from the non-labeled one). You should use the functions like this :

String.sub "hello" 1 2;;
- : string = "el"

StringLabels.sub "hello" ~pos:1 ~len:2;;
- : string = "el"

You can also pass the labeled arguments in the order you want :

 StringLabels.sub "hello" ~len:2 ~pos:1;;
- : string = "el"
3

@perry feel free to open an issue about this documentation oversight (or even open a PR!).

4

Not a dumb question. I was similarly confused with this perceived dichotomy myself. I think the error lies in the design of ocaml stdlib itself.

My thinking is if labelling of functions is a good practice - which I believe it is - why not deprecate the old api (to maintain backwards compatibility) and expose the new labelled api into the forefront.

Or perhpas have one main module that contains all labelled api in one place so that it is easily discoverable.

As things stands now, this api design is probably confusing a lot of ocaml newcomers and adds to redundancy IMHO.

In case you are interested, there are labelled, alternative api for other modules in ocaml stdlib, for eg.
https://caml.inria.fr/pub/docs/manual-ocaml/libref/MoreLabels.html
https://caml.inria.fr/pub/docs/manual-ocaml/libref/ArrayLabels.html

B.

5

I think similarly, they are also a burden for people trying to enhance the stdlib. I once opened an issue to deprecate it, but it seems other people like @gasche disagree.

Judicious use of labels is a good practice (e.g. the various int arguments of string processing functions).

However I’m not so fond of gratuitous use of labels like the various f in map-like functions. They make it harder to use combinator based libraries where you need to lift functions in another domain (e.g. react) and frankly I don’t see much value in having these f labelled except verbosity. The function name you use should make it clear which argument is the function in the expression.

2 Likes
6

Another stupid question: where does one open issues or PRs about the base OCaml implementation and documentation?

7

Here.

8

Nice. The rationale is clearly expressed and I agree 100%. Do you need help? Perhaps to test a pull request?

9

I have no plan to work on this for now. So feel free to champion the process, however I think we’d need a little bit more consensus than just @alainfrisch and me (I was recently surprised to see it being used in more recent code bases).