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, e.g. 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.)
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 (example: 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.
Programing Language Design
- Ontology of Programing Languages
- A Class of Programing Languages: Math Languages
- Why I Hate Exceptions
- Iterator, Enumerator, Abstraction Went Wrong
- Should Array Index Start at 0 or 1?
- Syntactic Semantic Difference of Map
- Should Map f Specify Order?
- Function Dependency
- Why I Hate C
- Why I Love Golang
- Why I Love Powershell
- PowerShell Complexity
- Why Bash Sucks
- Which Programing Language is Easier to Learn
- The Complexity of Java Access Specifiers