4 ms·
> Because sum:int * product:int is a different type from product:int * sum:int, the use of a labeled tuple in this example prevents us from accidentally returni
by munchler 1y ago
> Because sum:int * product:int is a different type from product:int * sum:int, the use of a labeled tuple in this example prevents us from accidentally returning the pair in the wrong order, or mixing up the order of the initial values.
Hmm, I think I like F#'s anonymous records better than this. For example, {| product = 6; sum = 5 |}. The order of the fields doesn't matter, since the value is not a tuple.
- rwmj 1y agoIsn't that just the same as the ordinary OCaml { product = 6; sum = 5 } (with a very slightly different syntax)?
- munchler 1y agoThe difference between { … } and {| … |} is that the latter’s type is anonymous, so it doesn’t have to be declared ahead of time.
- rwmj 1y agoOh I see, good point. I'm wondering how this is represented internally. Fields alphabetically? I've also desired extensible anonymous structs (with defaults) from time to time, but implementing that would involve some kind of global analysis I suppose.
- reycharles 1y agoOne reason why they're not the same is because the memory representation is different (sort of). This will break FFIs if you allow reordering the tuple arbitrarily.
- thedufer 1y agoLabeled tuples are effectively order-independent. Your implementation's order has to match your interface's order, but callers can destruct the labeled tuples in any order and the compiler will do the necessary reordering (just like it does for destructing records, or calling functions with labeled arguments). I don't think this is materially different from what you're describing in F#, except that labeled tuples don't allow labeling a single value (that is, there's no 1-tuple, which is also the case for normal tuples).