All functions are automatically broadcasting on lists and pair values:

square number = number*number
square [1 2 3] == [1 4 9]

square [a:1 b:2 c:3] == [a:1 b:4 c:9]

square.([1 2 3]) // julia style

The library words of one number broadcast the same way: cos([0, 1]) is [1 0.5403…], abs([-1, 2]) is [1 2], round [1.4 2.6] is [1 3].

# a sketch, not run
delete file = run `rm $file.name`
delete all files in ls /   # 🧐

Even though the map functor is part of angle, in 99% situations it should be superfluous via all/iteration as seen above.

Broadcasting reduces the amount of cases where function pointers are necessary.

Just use square [1 2 3] == [1 4 9] instead of map &square [1 2 3] == [1 4 9]

folding multiple arguments

An interesting special case might be if functions take more than one argument: int sum(int a, int b) { return a + b; } sum [ 1 , 2 , 3 ] MIGHT be treated as sum(1,sum(2,3)) // depending on the associativity or the operator left or right folding or it doesn't matter

Interesting or bad idea ?

ambivalence

how to apply broadcasting on maps?

# open question: what should these give?
square [1:a 2:b 3:c] == ?
square [1:1 2:2 3:3] == ?

Broadcasting applies to functions but not to basic operators:

# sketch: list + item is an ambiguity error now
[1,2,3]+4 == [1,2,3,4]
[1,2,3]>>1 == [2, 3] (maybe)
[1,2,3]++ == [2, 3]

In these cases one does have to use the keywords map or each or wrap the operator into it a closure:

map [1,2,3] {it+1}         // [2 3 4]
for x in [1,2,3] { print x+1 }

[1,2,3] {++} is refused: an operator without operands is no function.

MAYBE we adopt ruby style symbols for function pointers too: map [1,2,3] :++