# Tag for challenges with stateful solutions

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?

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

• 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. – Conor O'Brien Dec 21 '16 at 17:26
• 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? – AdmBorkBork Dec 21 '16 at 17:29
• @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]". – Martin Ender Dec 21 '16 at 18:35
• Hmm. In that case, I feel those are still stateful. Else, how would languages like /// contain state? – AdmBorkBork Dec 21 '16 at 18:59
• @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. – Martin Ender Dec 21 '16 at 23:40
• 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. – AdmBorkBork Dec 22 '16 at 13:43
• 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". – Erik the Outgolfer Dec 27 '16 at 17:15
• @EriktheOutgolfer en.wiktionary.org/wiki/stateful. I've never heard of stated being used in this context. – Martin Ender Dec 27 '16 at 17:20
• @MartinEnder Oh gosh, stateful is an actual word. Adding it to my spellchecker. – Erik the Outgolfer Dec 27 '16 at 17:22
• Is this going to be created soon? I'd quite like to do a challenge in this category. – FlipTack Jan 7 '17 at 21:34
• @FlipTack I'll try to take care of it next week. – Martin Ender Jan 7 '17 at 21:49
• 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. – MildlyMilquetoast Sep 18 '17 at 21:32
• This looks like a consensus, and I think it's been long enough, we should put this into action. – FlipTack Nov 26 '17 at 21:37
• @FlipTack Uhhh, yes. More than long enough. I'll try to get onto this. – Martin Ender Nov 26 '17 at 22:01
• @MartinEnder I'll begin slowly retagging challenges, not so rapidly as to flood the front page though. – FlipTack Nov 27 '17 at 21:37

# Tag Name: [persistence]

I prefer over because it feels less ambiguous to me.