Lutz wrote:Both map and apply also take arrays in the next version, but will do array -> list conversion internally to keep code changes / additions to a minimum leveraging existing code.
This sounds good!
There are some functions for which there are different performance characteristics for lists and arrays: e.g. an
assoc for arrays should be slower for large arrays compared to lists. In such cases there is a trade-off, because there are two possibilities for making such a function applicable for the other data type:
- Use the same name: comfortable to use (unification), but may create performance surprises, if list arg gets an array or vice-versa;
- use another name: less comfortable to use, but you have it explicit, that a list or an array is expected, and exclude the other data type.
My point has been - under the assumption, that arrays are specially made just for performance reasons -, that this kind of trade-off needn't be applied for
apply, if it will be implemented accordingly. So far I had seen
array-list as a result of the will to make computation effort visible (you explicitely have to convert), and not as something, which has to be there.