How are the “labled” modules of the standard library implemented? If I follow the definition of, let’s say, ListLabels.map, vscode points me to the implementation of List.map, ArrayLabels.map points to Array.map and so on. If we look at the ListLabels module implementation on Github , we can see th…

[image] ancolie: I wish they were simply removed from the stdlib… I once tried to suggest this but I gave up. I still think they mostly add more noise to the system but they seem cherished by enough people so that this is unlikely to happen.

Thanks for the feedback Nicolas. – IMO, labeling a parameter when it there is no ambiguity, like f in map, is not very useful. But it’s pretty nice to have labeled arguments when several arguments have the same type. # Array.sub;; - : 'a array -> int -> int -> 'a array = <fun> # ArrayLabels.sub;…

[image] benjamin-thomas: IMO, labeling a parameter when it there is no ambiguity, like f in map, is not very useful. Actually it is, because it allows you to supply the parameters in either order, which is very useful for pipin g with |> and also means you don’t have to remember the order.

What I meant is that map already has its arguments in an order which is pipe-friendly (unlike some other functions I bump into every now and then). There is no ambiguity and it seems to me that the labeled version is verbose for no obvious benefit. # [1;2;3] |> List.map (( * ) 2);; - : int list = …

Not so relevant for maps, but for folds note that using a signature such as: val fold : 'val t -> 'acc -> f:(key -> 'val -> 'acc -> 'acc) -> 'acc yields stronger type-based disambiguation power for the the definition of f if it is written as a lambda, as compared to: val fold : (key -> 'val -> 'a…

Not a huge fan of ~f either but the argument for it in relation to piping is more that you need to put the collection last because of piping, but when not piping it is often clearer if the function is last, which the label lets you do. The point is to write something like this: List.iter my_list ~f…

One can also write my_list |> List.iter @@ fun x -> (* several lines of code here *) You don’t need labels to move arguments around. :slight_smile:

Not sure about n > 2 arguments. You can always move the last argument with |>, and in practice that seems to cover a lot of cases due to how List arranges the arguments. I’m not claiming that there’s a universal way to move arbitrary arguments around. :slight_smile:

Yes, I don’t use the *Labels modules so I sometimes do this. But I find using the piping operator in this way slightly unpleasant, something a bit obfuscating to it I guess, and also it doesn’t work for folds because the initial state argument comes after the function. Anyway all this is very subjec…

How are ListLabels, ArrayLabels, etc. implemented?

Learning

smolkaj November 8, 2023, 3:30am 17

That works for n=2 arguments. How about when you have n > 2 arguments?

Topic		Replies	Views
The ergonomics of labels Learning	18	2099	February 4, 2019
Do you know of `StdLabels` and `MoreLabels` modules? Ecosystem stdlib , survey	7	482	June 20, 2024
String vs StringLabels Learning	8	1360	October 27, 2017
[Real world Ocaml] Put t first Learning real-world-ocaml , module , beginner , design	13	530	January 22, 2026
Why isn't optional use of labels allowed with every argument? Learning	6	1412	January 24, 2018

How are ListLabels, ArrayLabels, etc. implemented?

Related topics