I don’t see much uniformity for the reader in letting writers arbitrarily decide the way they want to submit arguments to a function.
(Personally I don’t really care about the reordering abilities of labels. I think the interest labels is that they enforce and suggest descriptive names on the code base, especially due to label punning. But of course that’s useless for the argument of generic traversals like folds for which f: labelling is entirely pointless – if not harmful for lifting functions into other domains. The user of the fold needs to give a good descriptive name to the folding function. But that the creator of the fold function cannot forsee)
Maybe this is a wild idea/question, but I’m going to ask it anyway; what would it take for OCaml to implement this kind of label-relaxation in module unification (not sure that’s the correct technical term but it’s what I’m going to call it) as a language feature instead of a weird compilation flag? It seems pretty generally useful.
The point is that the semantics of a function call is the same (“uniform”) for all orders in which a writer may supply arguments, when supplied using labels.
Making the argument ordering semantically insignificant is a good thing because argument ordering is arbitrary. I don’t like arbitrariness. Do you?
There are of course cases when it is natural for the position of an argument to carry meaning, say for various standard binary operators. In those cases, by all means, use positional arguments.
@dbuenzli By the way, I suspect you may have a blind spot here. After all, you are known to only use your own libraries ( ). So you don’t have to tolerate arbitrary argument orderings imposed by anyone other than yourself, and I am sure you have developed excellent heuristics for deciding what the “canonical” argument ordering for any given function must be.
Making the argument ordering semantically insignificant is a good thing because argument ordering is arbitrary.
In a ML type language this is almost never true due to the possibility of partial application. There is almost always a way to partially apply which is more useful than other ways, and syntactically ordering the arguments in the same way results in the most natural order.
For lack of a more general organising principle I don’t mind arbitrariness to get regularity.
Lots of printed matter conventions are totally arbitrary (e.g. writing orientation, index at the end. etc.), but they are useful because they provide a consistant user interface. This consistency puts less burden on our minds when we need to interact with them.
I would hate a book that randomly switches from left-to-right and right-to-left reading order on every other page.
Totally agreed that such arbitrary conventions are a good thing. The problem is that there is no general convention for how to order function arguments, as far as I am aware, and using a different convention for each function mostly defeats the purpose of a convention, IMO.
And allowing each function application to reorder arguments makes it even worse.
In any case as @nobrowser hinted, you can always try to find orders that are more convenient than other if you think about how your function is going to be used (in a map, in a fold, etc.).
That being said in applications (vs libraries) where you can easily get a dozen of labels (or record fields) I simply tend to fallback on alphabetical order.
