Submission formats are always flexible here on PPCG. Named functions, anonymous functions or even full programs that perform IO, are all fine.

Even currying is acceptable, for example, taking arguments as f(4)(5) rather than f(4, 5).

But what about returning a function that returns the result?


Consider the following Python code to find the length of a string:

f = lambda s: s.__len__

I know this is a long way to do it, I'm just trying to give a simple example.

To call this function, one would have to call f with the string parameter, and then call the result, to get the answer - for example, f("String")().

Another example is this pseudo-Java lambda to convert an object to a string:

x -> x.toString

If you assigned this to f, you'd call it with f(object)(). It's very similar to currying, except that the second call takes no parameter.

My question is - should we allow this as an acceptable output format for PPCG code-golf answers?

  • 1
    \$\begingroup\$ Funny, I had this question, too! \$\endgroup\$ Commented Jan 5, 2017 at 20:13
  • \$\begingroup\$ note: I'm not 100% sure you can pass functions like in that java lambda - I'll have a look later. You might have to use :: instead. \$\endgroup\$
    – FlipTack
    Commented Jan 5, 2017 at 22:18
  • \$\begingroup\$ I'm not sure if the f(4)(5) example is the counterpart to returning a function. I believe the counterpart would be f(g(4)), as you are passing in a function, instead of simply calling the return value as a function. \$\endgroup\$ Commented Jan 6, 2017 at 3:03
  • 4
    \$\begingroup\$ This should be trimmed up and left as an answer on Default I/O Methods where it can be incorporated (or not) into the consensus. \$\endgroup\$ Commented Jan 6, 2017 at 23:47
  • 1
    \$\begingroup\$ I would oppose this, I agree with TimmD that this is a good fit for Default I/O Methods. \$\endgroup\$ Commented Jan 8, 2017 at 22:31
  • 1
    \$\begingroup\$ I've voted to close this as a duplicate of Default I/O Methods to push it in that direction. \$\endgroup\$ Commented Jan 10, 2017 at 17:00
  • \$\begingroup\$ "the second call takes no parameter" That's a type of currying (albeit a not-so-useful one) IMO. \$\endgroup\$
    – SE is dead
    Commented Jan 10, 2017 at 20:05
  • 1
    \$\begingroup\$ I've added a post for this on the Default I/O Methods question. Feel free to vote and/or suggest changes. \$\endgroup\$ Commented Jan 20, 2017 at 14:39

1 Answer 1



This is a relatively reasonable way of returning an answer, the way I see it, it is not substantially different from returning a one element (of which the first element must be accessed through a method call). Essentially you are returning the data, in a clear way, which is accessable. (Feel free to edit in additional reasons).


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