On the default allowed I/O methods, we have come to a consensus that programs may not take input from a predefined variable.
However, we have decided that anonymous functions are allowed. In the answer, the poster, arguing that it doesn't make sense to ban anonymous functions, says, "it wastes bytes on something rather arbitrary.
Assume that this was a Javascript solution:
s=x=>x+1
By that argument, we could remove the s=
from the beginning, leaving this:
x=>x+1
This means that it can't just be used as a full program by itself, but it is still allowed.
Here's the problem: By our current rules, this would be disallowed:
x+1
This is taking input from a predefined variable. Arguably, however, the anonymous function header x=>
is also wasting bytes on something arbitrary. The new snippet can't be used on its own, but that's true for the anonymous function as well. It's just a matter of whether you declare the input variable in the program or not.
I understand that this is a slippery slope, but I still think this problem lacks a justified solution.
Why should taking input from a predefined variable be disallowed?
(x=>x+1)(1)
and[1,2,3].map(x=>x+1)
works just fine on their own. In fact, it's not even the intended use case. If you're going to name your function, might might as well use a function expression. \$\endgroup\$x=1,x+1
\$\endgroup\$x=>
defines an anonymous function with an input that will be referenced asx
inside it. Then,x
does not refer to the variablex
, but to the function's inputx
. You can't do(x+1)(1)
, sincex+1
is a snippet that returns the sum of the variablex
and the literal1
. As that is an integer literal and not a function literal, it is not callable as a function. On the contrary,(x=>x+1)(1)
works becausex=>x+1
is a function literal that, when you call it, will calculate the sum ofx
(its input) and1
. \$\endgroup\$