When we have array:build and map:build, then why do we also need array:of and map:of ?

[dnovatchev]

Looking at the current specification of the pairs of functions: (array:build, array:of) and (map:build, map:of), it is impossible not to notice that the second function in each of these pairs is a weak duplicate of the first.

Also, the examples provided for array:build and array:of, seem to have a good deal of common content / duplication / overlap.

Another issue is that array:of requires as input a sequence of value records, whose definition is challenging to understand (and whose meaning seems to be solely to represent a sequence of sequences), and what is also really challenging is how to construct this argument to array:of. If this is unnatural and challenging, one would probably prefer to use just array:build.

Is there an example where it is possible to construct an array (or a map) with array:of (or with map:of) but it is impossible (or significantly more difficult) to construct the same array/map with the function array:build (or with map:build)?

If there are no such significant and convincing examples, then why do we need the xxx:of functions?

Thus the question naturally arises: "Why is the function xxx:of necessary at all?"

[michaelhkay]

Good question. array:of(X) is just array:build(X, function($x){$x?value}), with stronger typing on the type of the first argument. The reason for having it is that it provides an inverse to array:members() - you can decompose an array into "value records", manipulate the value records, and then reconstruct a new array. To do that with array:build you need to understand the internal structure of a "value record"; but perhaps you need to do that anyway.

Similarly, map:of(X) is just map:build(X, function($pair){$pair?key}, function($pair){$pair?value}), again with stronger typing, and the reason for having it is that it provides an inverse to map:pairs().

These are convenience functions, and it's valid to raise the question whether the convenience they offer is sufficient to justify including these functions in the library. Personally I think it probably is -- partly because of the extra type checking, which gives improved diagnostics, and partly because writing out the required callback functions is tedious and error-prone (I got them wrong in my first attempt) -- but it's a value judgement.

[ndw]

We agreed to close this issue with no action at meeting 034, 16 May 2023