12
\$\begingroup\$

I will mainly speak about the programming language Lua, because that's where this question comes from.

In Lua, everything but nil and false evaluates to true, it means that even 0 or an empty string are true. In the first case, there's no doubt about it: it's a truthy value as of PPCG's definition.

The empty string is a little bit problematic. If I have to output a truthy value in some cases, writing os.write"" can be my best option to do the stuff, but it has no feedback to the user testing the program, not even a newline or a space.

You couldn't say if it outputted or not, unless you redirect its output to a truth machine.

On the other side, it technically outputs to stdin the representation of an object of type string, which always evaluates to true.

As commented by @MartinEnder, this is only a particular case of a bigger question: What's our stance on outputting to stdin/printing a truthy/falsy value when its string representation is an empty string.

\$\endgroup\$
  • \$\begingroup\$ Do nil and false have natural string representations? Are they just "nil" and "false"? I think your problem is similar to other languages though where 0 is falsy and "0" is truthy... when you print 0 to STDOUT have you printed the number or the string? We usually assume good faith and you can use whichever makes more sense in your context as long as you do it consistently. If in doubt, go by the definition you linked and print its natural representation (so empty output would indeed be truthy). \$\endgroup\$ – Martin Ender Jun 23 '16 at 14:55
  • \$\begingroup\$ @MartinEnder That's the guideline I personnaly prefer, but as seen in the chat and in the answer below, objections can be made for this edge-case. That's why I think a clear consensu of the community would be better \$\endgroup\$ – Katenkyo Jun 23 '16 at 15:02
  • \$\begingroup\$ I'd also like to note that printing nothing as a falsy result is also fairly common practice in some languages where empty strings/lists are considered falsy, so I don't see why it should be different for languages which consider it truthy. Maybe frame the question more generally whether printing empty strings (as in, nothing) is valid as truthy/falsy in general, since the only answer so far also treats both of those cases the same. \$\endgroup\$ – Martin Ender Jun 23 '16 at 15:32
  • \$\begingroup\$ Here is where Lua specifies everything except nil and false is true. Love Lua by the way. \$\endgroup\$ – Insane Jun 27 '16 at 9:04
  • \$\begingroup\$ In C, the empty string literal, "", is also truthy. ideone.com/zomVN0 \$\endgroup\$ – SoniEx2 Jul 2 '16 at 13:07
11
\$\begingroup\$

I'm not going to distinguish empty strings as truthy or falsy outputs here - just because some popular languages consider them falsy is no reason to bias this discussion one way or the other. So...

Yes, this is fine, provided that...

...two conditions are met:

  1. The interpretation must be consistent with your language's interpretation of the truthiness/falsiness of the empty string (or empty list, if that also prints nothing). If your language considers the empty string to be truthy, you don't get to use it as a falsy output and vice versa.
  2. Your output format must be unambiguous. This is a very important rule that we always apply implicitly, regardless of what we're actually outputting. Pretty much all of the issues that could arise from using empty strings for output are covered by this.

I'll elaborate a bit on that second part. When the challenge asks you to output a list of integers in any convienient format, you're not allowed to just print those integers back to back. There's no way to reconstruct where one numbers ends and the next begins. We require unambiguous separators (which also means you can't separate them with other digits).

The same applies here. As long as you choose an output format that a) complies with the challenge spec and b) allows a user to infer the result of the computation unambiguously, you can use empty strings as output. Some examples:

  • A challenge asks you to print a single truthy/falsy value. If the empty string is falsy and every non-empty string is truthy, there is no potential for confusion of the output.
  • A challenge asks you to print a single truthy/falsy value for valid input and nothing at all for invalid input. In this case you cannot use the empty string as a truthy/falsy value, because it's indistinguishable from printing nothing at all (which is something your program should be able to do for different inputs).
  • A challenge asks you to print a list of truthy/falsy values. You may use an empty string for one of them (depending on your language), but you have to print a separator between every pair of values so that one can infer the empty strings from adjacent separators. Having a trailing separator after each value (analogous to 1\n2\n3\n) is still fine as long as its used consistently (because then you know that the empty string after the last separator does not ever represent a value).

Of course all of those things equally apply to challenges that ask you to print a string which might potentially be empty. We'd be handling those cases exactly the same way.

One last thing: when you do output an empty string, you are allowed not to print anything. Your code doesn't need to contain print '' if omitting it gives the exact same output. I believe this has been used occasionally in programs that handle certain inputs by terminating with an error (which doesn't print to STDOUT). Only the observable behaviour is relevant.

\$\endgroup\$
  • \$\begingroup\$ In case someone is looking for an example of what was mentioned in the last paragraph, I did that here among other places, as I had assumed this was an acceptable interpretation of the exiting on error discussion. \$\endgroup\$ – FryAmTheEggman Jun 23 '16 at 18:34
  • \$\begingroup\$ Your rationale has won me over. I've upvoted this answer, and I'm going to delete mine. \$\endgroup\$ – Mego Jun 24 '16 at 20:28

You must log in to answer this question.

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