A very common task in writing a challenge is to define the allowed input/output types. These descriptions have a couple of problems as I see them:

  1. They can get really verbose. If I want somebody to output an ascii art image, describing the allowable outputs can get really complicated:

If you write a full program, your answer must be printed to STDOUT as a string, optionally followed by a trailing newline. If your answer is a function, you may print to STDOUT, or return a string, or return an array/list of strings (rows), or return a two-dimensional array or nested list of characters.

  1. There are lots of "gotcha's" in types. For example, defining the precision needed for a double, or the minimum image size for image output.
  2. These type descriptions are repeated a lot from challenge to challenge

It'd be great if we could come up with some sort of "type description" (e.g. Integer -> 2D string), that allows users to quickly understand the input/output types, while covering edge cases and other problems.

Do you like this idea? If so:

  1. What should the syntax look like?
  2. How should the types be defined?
  3. Should types simply be a shorthand (and a full description is still required)? If the full description isn't required, how should new users figure out what the types mean?
  • \$\begingroup\$ One interesting argument I could see is that there is (often) no reason to specify a specifin i/o format. generally any "convenient and reasonable" format is acceptable, but I do support this question as there are certain questions where certain i/o formats may be overly cheating. \$\endgroup\$ Commented Aug 8, 2016 at 17:54
  • \$\begingroup\$ "Convenient and reasonable" often works with simple data types (integer, or list of integers), but beyond that, it gets really complicated. \$\endgroup\$ Commented Aug 8, 2016 at 18:03
  • \$\begingroup\$ makes sense, I have seen too much abuse of i/o rules \$\endgroup\$ Commented Aug 8, 2016 at 18:05
  • \$\begingroup\$ (and abused it myself) \$\endgroup\$ Commented Aug 8, 2016 at 18:05

3 Answers 3


Don't golf your specs

We already have a lot of defaults: program or function, I/O methods, STDERR, submission must halt, functions must be reusable, standard loopholes, things to avoid when writing challenges, etc.

It makes sense to come up with defaults that apply to pretty much all code golf challenges, but for a newcomer, they're a lot to take in. Adding even more defaults for all specific sub-types of code golf challenges is only going to make this worse. And providing a large number of links one would have to follow before answering a question, topped with some obscure syntax that specifies which ones apply, will even be a strain for regular users.

Specifications of challenges should be as long as needed to make the challenge understandable by someone who is not familiar with our site. Even though it is a default, I mention in all of my code golf challenges that a full program or a function is required. Sure, there will always be corner cases that are covered by some consensus on meta, but 9 times out of 10, a reasonable person should be able to post a valid submission to the challenge without being familiar with those defaults.

Finally, having defaults for every single aspect of a challenge will create backlash for challenge writers that do not adhere to those defaults. Ever since we had the programs of functions default, regular users came to expect it in all challenges (see arbitrarily overriding the defaults), regardless of the author's wishes. While it makes sense to have a default like this (or it would have to be specified in literally every single code golf challenge, which many newcomers do not do), it will create a mess if we attempt to cover all code golf sub-types and corner cases.

  • 2
    \$\begingroup\$ I'm really not sure if this really would make it less friendly to challenge readers (in fact, it would make it easier to read and understand IMO). The majority of users understand what Integer -> String means (even if we have a specific meaning on both of those terms). I'm also not sure how much backlash there would be to users, as this is more of a linguistic change than an actual challenge criterion change. \$\endgroup\$ Commented Aug 9, 2016 at 5:14

Use challenge types to compile a stripped-down "challenge format" to full-blown explanations

My original idea, which spurred Nathan to make this post, was a tool that converts such a type signature -- along with some metadata -- into a lengthy specification. The output would follows a clear template, explain all our default rules, include a leaderboard snippet, etc. Something like a "templating language" for PPCG challenges, that compiles to Markdown. I'd feed it something like

Int, Int -> AsciiArt

Given two positive integers **w** and **h**, print a **w** by **h** rectangle of `X`s.

< 3 5
< 10 2

and it would output


Given two positive integers **w** and **h**, print a **w** by **h** rectangle of `X`s.

Test cases

Example input 1:

    3 5

Example output 1:


Example input 2:

    10 2

Example output 2:



* Your solution must be either a function/subroutine definition, or a full program.

* Your solution may receive input in the following ways:

  * Two integer function arguments.
  * Two command line arguments.
  * Two integers, in any reasonable string format, read from STDIN.
  * ...

* Your solution may produce output in the following ways:

  * Return/print an ASCII-art string, with newlines separating the rows.
  * Return/print a list of strings, each representing a row.
  * ...

* This is [tag:code-golf], so the shortest solution (in bytes) wins.

Yes, lets do this!

  1. The syntax should look like InputType[Param] -> OutputType[Param]. This seems intuitive to me, and it matches type hinting of Python (and likely other languages)
  2. A meta question is asked, and for each type, a different answer is given (and can be voted on)
  3. Shorthand is sufficient as long as the above meta post is linked to immediately above/below or on the types themselves

You must log in to answer this question.

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