When consistent and distinct values are asked as input, you cannot input complete or partial functions
When I create a challenge and ask for a
boolean or two 'consistent and distinct values' I mean it in the sense of a truthy and falsey value. Usually I leave the choice to the ones doing the challenge, since I don't care whether it's
I know just asking for a truthy/falsey value specifically in the challenges is also an option, but since
1/0 isn't considered truthy/falsey in for example Java or .NET C# and I still don't mind if they are used, this default loop hole would be relevant.
'/\n|-DI>-/---< ' for left,
'/\n|-DI<-\\---> ' for right. In the challenge description it states:
the other being one of two distinct, consistent values of your choice (
1 / 0,
l / r,
left / right, etc.)
Standard loopholes are forbidden.
Although original, and it does comply with the challenge description above, I think it would be wise to prevent these kind of partial or complete functions as input in the future. What would prevent someone from having the fictional program
run param where the
param is a complete program when a truthy value is asked, or a different complete program when a falsey value is asked? Also sharply mentioned by @darrylyeo as comment on that same challenge:
eval - Input a program that generates a left-facing plane for left, and a program that generates a right-facing plane for right.
Related: Using the program name to store data without counting those bytes
In this related loophole the file-name is counted towards the byte-count. But I don't think adding the two values to the byte-count is a good idea either, otherwise the
true/false should also be counted. Where do we draw the line of which inputs should be counted towards the byte-count, and which shouldn't? So just preventing these kind of inputs as standard loophole would be better in my opinion.