Should the Map Function Specify Order?

most lang's map function is basically alt syntax for loop. That is, it does a loop in order.

it'd be nice to have map that is not. Example: unspecified order. So that, when function is applied over a list, parallel execution can be done. (this will also force programers to write functions such that they don't have side effects.)

But there's a issue here, is that if we don't specify an eval order, it adds a non-deterministic behavior, when function has side effect or does computations where order matters.

if the lang has builtin mechanism for function to not have side-effect, such as haskell, then this issue does not come up. But most langs for one reason or another, is not like that, and sometimes for practical reasons don't want to be like that, such as ocaml fsharp clojure.

so, the dilemma is: should “map” specify order?

in scheme lisp, when i first learned that eval order of function args is not specified, around 1999, i thought, how idiotic that is. Because, specifying the order seems so simple, and freely adds a deterministic property. Now i understand why.

A similar issue is the short-circuit of logical function “or” and “and”. It basically also relies on a specified order. When you have short-circuit of “or”, the lang's “or” becomes also a branching construct, which most programers abuse, in fact, recommend it as idiom. e.g. var x = y || 4 as a construct to set default value. So, here the problem is, the code is no longer boolean logic, but rather, sequential instructions. (it matters when the functions or expressions in “or” have side effects.) (the problem of using “or” with short-circuit is that, your code is now less able to be statically analyized.)

If a new lang's map does not specify apply order (and does not have mechanism as in haskell to check side-effect), the problem is, it's hard to enforce this. For a given popular language such as JavaScript or perl or python, you can't just add this no-order spec and expect things to work well. Most people will use them as if they are just eval by order. Only when they have bugs they learn a lesson. And this is may create a social problem. That is, you got a lang where you get lots warnings in books and tutorials and community about this “tricky” order issue, telling and explaning about how the function used with map should not have side-effect, and you'll have coding styles/conventions baggage and FAQ about it. (a lang that necessitates lots of idioms or hack tricks or Frequently Asked Questions is a bad thing. Things should be automatically enforced by syntax, semantics, compiler, as much as possible.)

but then, maybe that's not a problem. Because, if you consider all the pitfalls of languages, there are tons of them in any language. Such as, max number allowed, max lengeth of list, max number of parameters, what happens if you combine arbitrary function/operator/statement/catch/throw/directives in weird unexpected ways (e.g. you see these things in obscurity contests, or, write a program to generate valid syntax, but most will not make sense.). And these pitfalls or holes for abuse, cannot be avoided, unless perhaps in some math proof lang with math foundation such as cog or such. That is, basically all practical languages in use have almost infinite number of pitfalls, vast majority of which we actually never thought of. Only a handful that become issues and get discussed in books or forums. So, maybe, a lang with map that specifies no appy order, isn't practically a problem, because most functions used naturally with map will have be no-side-effect functions.