Unnamed Functions in Code Golf

Question

For many code golf questions, we allow functions as answers. What exactly does it mean for some code to be a valid submission as a function?

This question came up during a discussion on built-ins, but is a separate discussion from that one.

Here are some examples in Python, where I'm not sure which should be allowed.

Cases that seem clearly allowed:

• Defining a wholly new function, where defining means giving the function a name by which it can be later called:

  limit = 10
  def func(a):
      for i in range(limit):
          if a[i % len(a)]:
              return i
  

• An expression which evaluates to a function:

  lambda a:a.count(a[0])/len(a)
  

Cases that seem like they shouldn't be allowed:

• Causing a function to exist and be usable, but without interacting with it directly:

  import math
  

  This causes the function math.gcd to exist, without directly interacting with it.

  This case is particularly problematic, because a golfing language could be defined to cause literally every possible function to become defined when given a 1 (or 0) character command, which defeats the purpose.

• Causing a very large number of functions to be defined, where the function in question is one of them:

  for index, code in enumerate(all_possible_strings):
      eval("func" + str(index) + "=" + code)
  

  Assume that all_possible_strings is a generator which yields all possible strings. Somewhere in that sequence, the string lambda a:a.count(a[0])/len(a) must have occurred, so the function func<very large number> is now defined as that function. This also seems problematic and like a loophole.

Cases I'm not sure about/what the consensus is:

• Submissions that contain an expression that evaluates to the desired function, as well as other code:

  A = [1]
  for i in range(50):
       A.append(sum(A) * i)
  A.count
  

  Supposing A.count solved the challenge, would this be valid?

Given these cases, what should our standard of a valid function submission be?

Answer 1

Here's what I (and the majority of the community) have been going by, which I think works well:

• Named functions/lambdas are acceptable (def foo(n): n+1, foo = lambda n: n+1, int foo(int n) { return n+1; }, auto foo = [](int n){ return n+1; }).
• Unnamed functions/lambdas are acceptable (lambda n: n+1, [](int n){ return n+1; }).
• Any expression which evaluates to a (named or unnamed) function is acceptable (pow).
• Additional "helper" functions may be defined in addition to the primary solution function (f=lambda x:abs(x);lambda n:f(n)+n).
• Any imports/includes/requires/whatever may be imported/included/required/whatever outside of the function (import math;math.gcd).

In general, so long as the code defines at least one function, named or unnamed, and the solution function performs consistently regardless of how many times it has been called previously, the submission is acceptable. The only exception is import-only submissions - though they bring functions into the global scope, they neither define new functions nor evaluate to a function that can be captured and/or called. Thus, from math import* is not valid, but from math import*;gcd is.

(note: that wording seems less than ideal, but I can't think of a way to improve it right now)

As for the code that generates all possible functions, that would be technically valid by these rules, but should be added as a standard loophole.

Answer 2

I would say that you should have to specify how to call it and have the constant part count towards the byte count.

For your example about defining every possible function, you would have to specify the code to create the generator, and the function's number, and everything would count towards the byte count.

For import math, you would also have to count math.gcd (plus () to avoid loopholes?).

Etc.