Returns the list that results from applying the function f to each element of the list l, and concatenating the results in order. The closure f should take one argument and may return a value of any type. If f has the wrong signature or if any evaluation of f returns ERR, then _map returns ERR. However, f will be applied to every element of the list, even if one of its evaluations produces ERR.
plus3(x: int): int { return x + 3; } _map(plus3, <1, 2, 3>) == <4, 5, 6> strip_extension(file: text): text { pos: int = _findr(file, "."); return if (pos >= 0) then _sub(file, 0, pos) else file; } _map(strip_extension, <"hello.c", "index.html", "build.ves">) == <"hello", "index", "build">
Note that the value of the implicit final parameter "." (aka dot) of the function f is always taken form the value of the variable "." at the point of the _map call. Unlike a normal function call, there is no way to override it's value by passing an additional argument.
Also, remember that Vesta SDL is a pure functional language. There is no sharing of variables between the differen functions called by _map. Just as with any other function call, each call to the function f has no side effects.
Returns the binding that results from applying the function f to each <name, value> pair of the binding b, and appending the resulting bindings together. The function f should take the name (of type text) and value (of type any) as arguments, and return a value of type binding. If f has the wrong signature or if any evaluation of f returns ERR, then _map returns ERR. However, f will be applied to every pair of the binding, even if one of its evaluations produces ERR.
text_only(n: text, v: any): binding { return if _is_text(v) then _bind1(n, v) else []; } _map(text_only, [ foo = 1, bar = TRUE, msg = "Vesta evaluator, version 2.21" ]) == [ msg = "Vesta evaluator, version 2.21" ]
As with the list version of _map, the value of dot (the variable ".") is always taken from the context calling _map, and the calls to the function f have no side effects (just like all other function calls).
Equivalent to _map, but the implementation may perform each application of f in a separate parallel thread. External tools invoked by _run_tool in different threads may be run simultaneously on different machines.
Using _par_map can significantly increase the parallelism of your builds. If you have a large number of hosts available for tool invocations (i.e. running the RunToolServer daemon), this can make your builds complete more quickly. However, the operations performed by the parallel threads are interleaved in an arbitrary order, which can make the evaluator's output harder to follow.