Challenge Type System

Question

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.

2. 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.
3. 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?

Answer 1

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.

Answer 2

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
> XXX
> XXX
> XXX
> XXX
> XXX
< 10 2
> XXXXXXXXXX
> XXXXXXXXXX

and it would output

Task
====

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:

    XXX
    XXX
    XXX
    XXX
    XXX

Example input 2:

    10 2

Example output 2:

    XXXXXXXXXX
    XXXXXXXXXX

Rules
=====

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

Answer 3

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