In compiled non-esoteric languages a solution is essentially always either a full program, a method, or a lambda expression. In a full program submission, the use of comments is clearly allowed. It's not clear to me, however, whether comments should be permitted in lambda submissions, which must be expressions, or method submissions. (This tends to come up in certain challenges.)

Strictly speaking, in Java, comments are a source-level concept and aren't part of the language's grammar, which suggests to me that source code that contains comments cannot represent an expression or even a method definition. I suspect that other similar languages are defined similarly.

It could be said that a submission is acceptable if stripping comments out (as the compiler does) yields a valid expression/method. Yet a trailing line comment can affect the parsing of the program a lambda solution is embedded in if the submission doesn't end with a newline. This too seems a bit suspect to me.

Still, for the most part lambda and method submissions with comments seem intuitively acceptable. This is neither a pressing issue nor a particularly profound one, but it nags at me when I visit many restricted-source challenges. I'm interested to see what others think.

## Examples

Consider this method solution and this lambda solution where the source is restricted to palindromes. And I use the slightly less suspect multiline comment in this lambda solution.

Update: I've added an answer. If you have an opinion on this issue, consider voting on my answer and/or adding an alternative one.

• Can you give an example of where this has come up, so that we're not debating how many angels can dance on the head of a pin? – Peter Taylor Jul 25 '18 at 11:19
• The thing which confuses me in this question is "comments are a source-level concept and aren't part of the language's grammar". While you limit the statement to Java rather than making broad assumptions about comments, I'm not sure what it even means for comments to be "not part of the grammar" or why a "source-level concept" is any more or less relevant to code-golf than other things. – Kamil Drakari Jul 25 '18 at 15:19
• @PeterTaylor Here is one. – Wheat Wizard Jul 25 '18 at 16:53
• @PeterTaylor and I've added a few Java examples – Jakob Jul 25 '18 at 16:56
• @KamilDrakari Yeah, that's where I pick one of several possible definitions for a lambda submission (and a method submission). Since the Java Language Specification defines a formal grammar for lambda expressions (similarly for methods), that provides an unambiguous way to decide whether a submission is valid. Others may not agree that this is a good metric to use. – Jakob Jul 25 '18 at 17:01

# Lambda expressions and anonymous functions in general can require the syntax around them to adapt

TLDR: Expressions can differ a lot in what kind of places in a program they can syntactically fit into, and lambda expressions and especially anonymous functions in general are no different, comments or no comments. As long as there's a reasonable way to adopt the surrounding code, this should not be a reason for disqualification.

Hopefully no one would accuse x+1 of not being a valid arithmetic expression in most mainstream languages. But you still cannot just put it everywhere without adjusting the syntax of what's around it. x+1*y doesn't work, you have to put parentheses: (x+1)*y.

I don't see requiring parentheses as essentially different from requiring a newline, or comments as essentially different from anything else that forces the syntax around to adapt.

In functional languages like Haskell, that commonly use operators on functions, this isn't even theoretical for anonymous functions: Each of the following ways of defining a palindrome test has different ways in which it cannot fit into just any surrounding syntax. First, a lambda:

\s -> s == reverse s


You need parentheses if you want to compose it with operators to its right: (\s -> s == reverse s) . takeWhile (/= ' '). But not to its left: not . \s -> s == reverse s.

Secondly, a golfed palindrome test:

(==)=<<reverse


You need parentheses to compose it with a higher precedence operator: ((==)=<<reverse)<$>["a","hi","bob"], but not with a lower one: (==)=<<reverse$"panama".

Thirdly, one with do notation (admittedly a bit silly for this particular use, but I wanted to show how newlines also matter without comments):

do x <- reverse
(==) x


now you still need something, but you can use a newline and reduced indentation:

do x <- reverse
(==) x
$"madam"  Try them online! In other languages, like Python, using operators to build anonymous functions may not be idiomatic, but it's still possible: class T: def __add__(x,y): return lambda z: y(z) print (T()+(lambda x:x+1))(42)  Try it online! ### If a submission claims to be an anonymous function, it must behave like an anonymous function. In this case the anonymous function is described by a Lambda Expression, but I think the same rules would apply regardless of the mechanism for its definition or the language's terminology for the concept. I'll be using C# syntax for my examples because I'm familiar with it. A trivial anonymous function in C# could be defined by the lambda expression x => x. The way anonymous functions in C# work is that they could be stored under a name (Func<string,string> cat = x => x;), or they can be passed to another function that expects such a parameter (ApplyTransform(x => x)). Thus a submission which wants to be treated as an anonymous function would have to work in those situations. If we take that lambda expression and make it a palindrome using a line comment, x => x//x >= x, then we will find that it no longer works the way an anonymous function should in C#: Func<string,string> cat = x => x//x >= x; and ApplyTransform(x => x//x >= x) will not work because the line comment hides the ; and ) respectively. In this case, I would not accept x => x//x >= x as an anonymous function, and it doesn't work as a program or named function either so it would not be a valid submission. This tends to be highly language-dependent, and isn't particularly exclusive to comments. In a similar way, the leading x => can't be left out, and multiple parameters need to be enclosed in parentheses (x,y) => x+y etc. The problems caused by a trailing line comment in C# are resolved by adding a newline just like they (apparently) are in Java, but trailing line comments are really just one example of a thing where humans can understand the intended meaning ("it's a comment so it shouldn't have any effect") but it doesn't actually work in the language. I don't think there's any need to define a "default" solution for a small subset of the problem, especially since that solution only works for a small subset of languages. TL;DR: There's nothing wrong with comments in general, and comments aren't any more special than other cases of "writing your program wrong so that it doesn't actually work even if it seems like it should". • This answer is a bit hard to reduce to a concise position. Am I correct in summarizing it as follows: a lambda submission must work correctly when embedded in the full program that uses the most reasonable (typical) layout of whitespace? If so, it may be an issue that which whitespace layout is most reasonable not only is subjective but is unlikely to be agreed upon. – Jakob Jul 25 '18 at 20:21 • @Jakob That wasn't really what I was trying to say. In fact, none of my examples rely on whitespace at all. The closest thing to what I was trying to say that involves whitespace is "An answer can't require that the user figure out some extra whitespace to put in before it can be used". – Kamil Drakari Jul 25 '18 at 21:42 • Your main example in paragraphs 2 and 3 concerns whitespace. The comment hides the ; or ) only if the two appear on the same line. Whether they do is a matter of style. If that example doesn't illustrate your point, you should remove it and clarify. – Jakob Jul 25 '18 at 21:53 • I think this thinking is way too Java/C# centric. It seems like this would disallow the following anonymous Haskell function: (==)=<<reverse (which tests for palindromes). No comments and yet it doesn't work just to substitute it anywhere - e.g. you cannot say (==)=<<reverse<$>["test", "a", "bob"] to apply the test to all the words. However you can say (==)<*>reverse<\$>["test", "a", "bob"] - because (==)<*>reverse, a different way of writing the same test, uses an operator with higher precedence. And don't get me started on how this interacts with indentation sensitivity... – Ørjan Johansen Jul 29 '18 at 6:29
• I expanded my comment into an answer. (And now I'm going to be accused of being too Haskell centric. :P) – Ørjan Johansen Jul 29 '18 at 18:15
• Interpreted strictly, this would seem to disallow the very common Python pattern of a lambda with an import (import random;lambda:random.randint(2) as a very contrived example) – Esolanging Fruit Aug 1 '18 at 7:05

# Comment use is restricted

While this may raise unforeseen issues, I suspect the best way to deal with this is to allow comments in a lambda or method submission as long as it's not possible for any comment to affect the parsing of the solution regardless of how it's embedded in a full program.

Essentially this would mean that these submissions cannot have a line comment (//) on their final line—a trailing newline would be required to restore whitespace insensitivity. In other words, golfers may not expect a newline to be placed after their solution in the enclosing class/method/....

• I think the title of this is incorrect, because you propose banning a method of comment use that so far has been accepted (possibly only because nobody realized the problem it causes) – Kamil Drakari Jul 25 '18 at 17:27
• @KamilDrakari Excellent point. I've chosen a different title. – Jakob Jul 25 '18 at 17:28