UnCompetition
UnCompetition is an esolang created by User:Yayimhere, with the focus of trying to have an undecidable question, instead of actually being a programming language, however there is no proof that it has any so far.
Description
UnCompetition consists of a tree, where each node is a program IN UnCompetition. these programs, are all "solutions" to another program. Every UnCompetition program is a set of conditions, for which all programs branching from it in the tree must follow. as such, it becomes similar for finding the variable X within a set of conditions. on every iteration, this process is done for every node in the current "level" of the tree, and then the tree is saved for the next iteration(as such, the tree is the closest to memory in UnCompetition).
There is a limit on how many node's each level of the tree can have. if it is of the first level of the tree(so the user program), then it will be allowed to generate 10000000 programs on the next level(all programs generated from the user program). if more than 10000000 are possible, then generation must stop on the 10000000'th. this limit increases on every level of the tree by squaring the current limit number. The order of program generation here matters, so different programs arent uncut by the limit in different interpreters. This is solved by having the order of nodes created being equal to the ASCII order, with the first one being the one with the least.
these are all the commands(each is on its own line). P1 represents the current program(which would in the start be the actual user written program), and P2 represents all the generated programs branching from it, within the tree:
| Command | Meaning |
|---|---|
! |
P1 and P2 will be different. |
[x] |
P2 will have x number of lines(1-9).
|
:x |
If there's x many node's in the current level of the tree, then include the below indented code will be ran, else, it will not(1-1000).
|
# |
P2 will not create any more node's. |
{x} |
the command x is excluded from P2.
|
(x) |
oppesite of {x}.
|
~x |
logical negation of each command's condition(for example ~! will make P1 and P2 be equal). when applied to :x, it negates the condition instead of the logic.
|
All numbers must be positive integers.
P2 solutions are not allowed to have repeating commands, and order doesn't matter. this includes having both a [x] and a [y], no matter the number(this only counts for [x]). They must also not have any errors.
If there is a [x] and a [y] in P1, the larger will always be chosen.
in {x} and (x), if multiple commands are wanted, then the same indentation as in :x can be used.
` can be used to represent a generic number for operations like :x and [x] when referenced in the {} and () operations (ex. {:`} ).
no programs may have contradictions, like a program having both {!} and (!).
Computational class
Currently, UnCompetition's computational class is unknown, and would be quite the challenge to prove or disprove it Turing complete. however, there are a few things that we can go of off that may be useful:
- UnCompetition is basically just a large function, where inputs are passed in, and then out, only to be passed in again. this is in some ways highly similar to Lambda-calculus, however only with one function, and an infinite amount of inputs, which is quite similar to Preface.
- Another way to look at it, is that each program is a function of its own, that when interpreted, (nearly) always returns another function. this is interesting, as it means each function has a sort of "inertia", where they even without input(which is just another wording for a single universal input), give an output.
- Both of the above, and the language, at its core, is functionally pure.
The reason I, the creator of UnCompetition, believe UnCompetition is TC, is because of its massive difference in tree sizes, even though there isnt much difference between programs.
Computability
Originally, UnCompetition was uncomputable, as an infinite number of infinite programs could pop up within the tree. as such UnCompetition would have been uncomputable. That makes it seem quite apparent that UnCompetition is turing complete, as this restriction still allows for infinite data, however only finite data at a single moment in time(which all computable algorithms must have). Though this is still no proof, it is quite obvious that UnCompetition is turing complete.
(Surprisingly enough) a short list of examples
here is a non limit reaching, one line generating program:
[1]
{{{`}}}
{((`))}
{{(`)}}
{({`})}
now all generated programs are listed here(all on an individual line).
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
#
!
([1])
([2])
([3])
([4])
([5])
([6])
([7])
([8])
([9])
(#)
(!)
{[1]}
{[2]}
{[3]}
{[4]}
{[5]}
{[6]}
{[7]}
{[8]}
{[9]}
{#}
{!}
~[1]
~[2]
~[3]
~[4]
~[5]
~[6]
~[7]
~[8]
~[9]
~#
~!
~([1])
~([2])
~([3])
~([4])
~([5])
~([6])
~([7])
~([8])
~([9])
~(#)
~(!)
~{[1]}
~{[2]}
~{[3]}
~{[4]}
~{[5]}
~{[6]}
~{[7]}
~{[8]}
~{[9]}
~{#}
~{!}
if the {{`}} and the {(`)} weren't there, the limit would be hit, as an infinite amount of programs could have been created.
and here is an infinite unchanging loop, as its children must be itself:
~!
and here's a program that, after making the initial amount of programs, stops making any new ones!:
(~!) [2] !
generated programs(separated by two newlines):
~! [2] ~! ~[1] ~! ~[3] ~! ~[4] ~! ~[5] ~! ~[6] ~! ~[7] ~! ~[8] ~! ~[9] (INCOMPLETE)
One token per line
Although one might think something different, UnCompetition only has one token per line... kinda. see ~! could be CONSIDERED two tokens, however it only states one thing. same with (~!). they both only state one thing about the programs being generated. (~!) doesnt force just ~ and !, it forces ~! specifically.