# Should point-free function expressions be allowed when a function is asked for?

Should an expression evaluating to a function count as a function for the purpose of providing a solution when a function is asked for? An earlier question on meta seems to indicate a consensus that it is fine to provide a function literal when "a function" is asked for.

Many languages treat functions as first-class citizen, and allow operations on functions such as composition or binding variables. What I wonder is if such expressions that evaluate to a function should be acceptable as an answer.

To illustrate the difference, below is an example of an explicit and a point-free function in Haskell, both yielding the same result.

\xs -> map succ xs            -- explicit ("function literal")
map succ                      -- point-free (partial application due to currying)

-- both behave the same
(\xs -> map succ xs) [1,2,3]  -- evaluates to [2,3,4]
(map succ) [1,2,3]            -- evaluates to [2,3,4]


This seems sufficiently different than the linked question to deserve one on its own. So, what do you think?

• Why can them be not allowed? It is trivial to turn it into an actual named function (like with linked "function literals"). – Vi. Oct 31 '14 at 23:17
• Sure, so that's one argument in favour of allowing them. The reason I ask is because I remember some opposition on this before (but I can't remember when, and considering how infrequently I post here it might've been long ago so it might not be relevant anymore). – FireFly Oct 31 '14 at 23:25
• Oppositioners may specify explicitly what they do accept as a function. – Vi. Oct 31 '14 at 23:29
• I would say that the point-free counts as a function so long as the surrounding brackets are included. Hence (map succ) would be considered a function, while map succ is an expression. – COTO Nov 1 '14 at 3:49
• @COTO you can just as well do f=map succ and have a named function at the same cost in most languages (a notable exception being J, where it's one character more expensive) – John Dvorak Nov 1 '14 at 6:39
• @JanDvorak Agreed. f=map succ works too. – COTO Nov 1 '14 at 10:56
• @COTO what is the rationale for requiring the parentheses (or a name)? It is a function-value expression in either case. – FireFly Nov 1 '14 at 11:48
• @FireFly: The reason I'd be reluctant to accept simply map succ is that it's a function that is only ever used once, for one input, to produce one output. Fundamentally, an expression is just a function that is only ever used once, for one input, to produce one output. Hence a point-free/anonymous function is semantically equivalent to an expression, and expressions aren't allowed in code golf challenges that ask for functions. That's just my take on it. – COTO Nov 1 '14 at 13:12

I can't see a consistent way that works cross-language to ban functions defined in a point-free style, and in many esoteric languages (e.g. Underload), the point-free style is the only one that exists anyway. Even in more normal languages, surrounding a function with \x->()x is just boilerplate, and we normally don't count boilerplate if it's inherent in the way the language works. (See also this newer question which covers the ground of whether parentheses or the equivalent are required around this sort of expression; at the time of writing, we're leaning towards no.)
Note that this differs from an expression that evaluates the answer directly (as opposed to evaluating to a function that evaluates the answer); most (but not) all languages draw a distinction, and in this case the expression is just a snippet. For example, in the OP's example, map succ is a valid function (it has function type, and doesn't do anything unless you call it), but map succ xs is a snippet (because it doesn't evaluate to a function, but rather a value of the base type Enum b => [b]). So valid function submissions would include map succ, (map succ), \x->map succ x, let f=map succ, and let f x=map succ x, because all of these return a function, and don't actually read any input, produce any output, or the like.