4
\$\begingroup\$

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?

\$\endgroup\$
8
  • \$\begingroup\$ Why can them be not allowed? It is trivial to turn it into an actual named function (like with linked "function literals"). \$\endgroup\$
    – Vi.
    Commented Oct 31, 2014 at 23:17
  • \$\begingroup\$ 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). \$\endgroup\$
    – FireFly
    Commented Oct 31, 2014 at 23:25
  • \$\begingroup\$ Oppositioners may specify explicitly what they do accept as a function. \$\endgroup\$
    – Vi.
    Commented Oct 31, 2014 at 23:29
  • \$\begingroup\$ 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. \$\endgroup\$
    – COTO
    Commented Nov 1, 2014 at 3:49
  • \$\begingroup\$ @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) \$\endgroup\$ Commented Nov 1, 2014 at 6:39
  • \$\begingroup\$ @JanDvorak Agreed. f=map succ works too. \$\endgroup\$
    – COTO
    Commented Nov 1, 2014 at 10:56
  • 2
    \$\begingroup\$ @COTO what is the rationale for requiring the parentheses (or a name)? It is a function-value expression in either case. \$\endgroup\$
    – FireFly
    Commented Nov 1, 2014 at 11:48
  • 2
    \$\begingroup\$ @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. \$\endgroup\$
    – COTO
    Commented Nov 1, 2014 at 13:12

1 Answer 1

8
\$\begingroup\$

Any expression that evaluates to a value of function type can be submitted as a function

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.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .