Comments in lambda submissions

Question

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 restricted-source 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.

Answer 1

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!

Answer 2

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".

Answer 3

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/....