FAQ update ideas

Question

I'm trying to solicit ideas on a couple of items where I think a FAQ update is appropriate:

• Amend FAQ to state that language-agnostic is the default
• Is using external decompression legitimate golfing

My personal opinion is that the first one should be implemented, and for the second one, we should disallow eval and external program execution by default. This is where I'm seeking opinions the most:

1. Is it watertight enough to discourage compression-based solutions?
2. Would it make things unnecessarily difficult, especially for languages like GolfScript where a lot of its mechanics are very eval-based?
3. Disabling external program execution basically disallows shell-based solutions. Are we okay with this?

Answer 1

IMHO, there's a clear line between eval, which is a metaprogramming facility that operates on code, and general-purpose compression, which is a representation tool that operates on byte streams. I see only one of them as a "code golfing" activity.

Unfortunately, it's hard to give rules on the activity when what we're given to judge is that activity's result.

In my dream world, the rules would say "anything goes," and the questions that lead to 80% of zipped contributions would be downvoted to hell as much as the answers. Populist eternal September tells me that'll never happen. Unless the FAQ makes it clear and the mods are quick to react.

In my real world, here's a debatable proposal:

1. general-purpose compression is banned
2. code golf character count is the number of Unicode code points; the code has to work as UTF-8.
3. eval is encouraged. That is, allowed.
4. language-agnostic is the default. There must be a good (and explicit) reason to waive it.
5. External program invocation is allowed, but should be declared for languages other than shell. Within reason, e.g. available to all to check, sufficiently well-known, existed prior to question...
6. [Redacted] when two submissions are tied, mine wins

PS: the eval ban would also kill J as far as parsing goes. (the silver lining being that nobody notices J's eval anyway)

Answer 2

No, disallowing eval and external programs would not stop the use of compression. Many scripting languages, including Perl, PHP and Python, come with zlib decompression routines that don't involve calling external programs, and if the task is to produce a fixed (or only slightly varying) output string, one can just print the decompressed text (possibly after modification) without bothering with eval.

If external compression tools are to be disallowed here, I'd prefer that we say so directly, instead of trying to come up with seemingly unrelated restrictions that we hope will achieve it as a side effect. My proposed wording would be something like:

Unless otherwise specified in the challenge, the use of pre-existing decompression tools or libraries such as zlib is not allowed in code-golf challenges. This applies even if such decompression features are built into the language.

Answer 3

1. I think so, but I think J B's point that the problem is the questions is a good one, and we should instead be discouraging such questions.

2. It would make things quite painful for GolfScript. An awful lot of GolfScript programs evaluate either the entire input or parts of it, because it's the easiest way to convert a string to an integer. To take my answer on polynomial extrapolation, where the input format allowed me to get all the numbers on the stack with just one evaluation, removing eval would require replacing the initial ~ with something along the lines of

   ' '/{{48-}%10base}/
   

3. It doesn't entirely disallow shell-based solutions, because bash, tcsh, and zsh all have some fairly powerful built-ins. E.g. my bash answer to Shamir secret sharing doesn't use any external programs. But it would be a significant disadvantage for some problems.

Overall I don't think that banning eval by default is a proportionate response to a handful of questions which naturally have uninteresting answers. If we're going to address that via a policy on answers, I think it should be restricted to disallowing eval for questions tagged as kolmogorov-complexity.