This recent quine challenge made me realise that we have a certain class of challenges that require answers to do something different each time they are run (at least for a finite amount of runs). This isn't too common but it's a recurring challenge feature, so I thought it might be nice to have a tag for these, so people can seek them out if they like them, and also to make it immediately clear to people if a challenge has this property or not (which is likely impossible in many esoteric languages).

My first idea was but these challenges don't necessarily require self-modification. Function answers will usually keep track of some global state between invocations and even programs have other means to fulfil the goal, e.g. by keeping track of state in files, using localStorage for browser languages, etc.

Some examples:

So, the questions are: Should we introduce a tag for these? What should it be called? What should the tag's scope be?


2 Answers 2


Let's create a [stateful] tag

I propose a tag which should be generic enough that it isn't limited to self-modification but should encompass the general idea that running the program multiple times will result in different behaviour.

The most important thing that this doesn't include is randomness and time-based behaviour. The behaviour should really depend on previous invocations of the solution (either how often it's been executed or which parameters it was executed with). One way to put it would be that given the same input (in the generalised sense, where the current time and a random number seed are considered inputs), the program will yield different results on multiple runs.

One thing that I don't have a strong opinion about is whether challenges should solution outputs a new solution (instead of quietly changing its own state). I'm leaning towards not including these though. I'd be happy about some discussion on this in the comments.

  • \$\begingroup\$ As for the last point, I think the default should be quietly changing its own state, though the author can specify whether or not outputting is also acceptable. \$\endgroup\$ Dec 21, 2016 at 17:26
  • \$\begingroup\$ I don't think I understand the last paragraph. Are you trying to distinguish between like a chaining-quine (running A outputs B, running B outputs C, etc.) challenge and a challenge where some file in the same directory is modified? \$\endgroup\$ Dec 21, 2016 at 17:29
  • \$\begingroup\$ @TimmyD pretty much, yes. There are also some challenges like "output result X and a the source of a new program that does [the next step]". \$\endgroup\$ Dec 21, 2016 at 18:35
  • \$\begingroup\$ Hmm. In that case, I feel those are still stateful. Else, how would languages like /// contain state? \$\endgroup\$ Dec 21, 2016 at 18:59
  • \$\begingroup\$ @TimmyD a) I think these are usually disjoint challenges. Either the challenge requires keeping state internally, or it requires outputting the next program. b) not every language has to be able to participate in every challenge, e.g. many challenges can't manipulate the file system, and that's completely fine. \$\endgroup\$ Dec 21, 2016 at 23:40
  • \$\begingroup\$ It's true that not every language need participate. I think I'm arguing for a broader definition of [stateful] than you, in that challenges like outputting the next program should classify as well. Since you're still maintaining some semblance of "I've run the program X times and now expect that Y will happen on this execution," it seems like you're still keep state. \$\endgroup\$ Dec 22, 2016 at 13:43
  • \$\begingroup\$ Why shouldn't the tag be stated instead? I define "stateful" as "being full of states", which is unclear to me, while "stated" for me means "having states". \$\endgroup\$ Dec 27, 2016 at 17:15
  • 1
    \$\begingroup\$ @EriktheOutgolfer en.wiktionary.org/wiki/stateful. I've never heard of stated being used in this context. \$\endgroup\$ Dec 27, 2016 at 17:20
  • \$\begingroup\$ @MartinEnder Oh gosh, stateful is an actual word. Adding it to my spellchecker. \$\endgroup\$ Dec 27, 2016 at 17:22
  • \$\begingroup\$ Is this going to be created soon? I'd quite like to do a challenge in this category. \$\endgroup\$
    – FlipTack
    Jan 7, 2017 at 21:34
  • \$\begingroup\$ @FlipTack I'll try to take care of it next week. \$\endgroup\$ Jan 7, 2017 at 21:49
  • 1
    \$\begingroup\$ I see no reason to exclude challenges that have to do with internal state or things like run time complexity from this tag. I know there are relatively few of these types of challenges, even without having to do with changing state every time it's run, but it seems like an arbitrary distinction to make. \$\endgroup\$ Sep 18, 2017 at 21:32
  • \$\begingroup\$ This looks like a consensus, and I think it's been long enough, we should put this into action. \$\endgroup\$
    – FlipTack
    Nov 26, 2017 at 21:37
  • \$\begingroup\$ @FlipTack Uhhh, yes. More than long enough. I'll try to get onto this. \$\endgroup\$ Nov 26, 2017 at 22:01
  • \$\begingroup\$ @MartinEnder I'll begin slowly retagging challenges, not so rapidly as to flood the front page though. \$\endgroup\$
    – FlipTack
    Nov 27, 2017 at 21:37

Tag Name: [persistence]

I prefer over because it feels less ambiguous to me.


You must log in to answer this question.

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