This question already has an answer here:
- Introducing a New Golf Language 1 answer
Today I was thinking about brainfuck, there are only 8 instructions (+-,.<>) these could fit in side 3 bits. So in 3 bytes (24 bits) there could fit 8 instructions. But with normal brainfuck each instruction is a byte.
So I wanted to make my own language that compresses brainfuck.
sub question 1: would I be allowed to use that language*? A human can still write code directly in the compressed form (at least if you write it in binary).
But that is not the language I want to create. I was also concerned about some of the other limitations of brainfuck like, for example their is no good way too:
- use arrays/Strings
- set cells to specific values
- do math operations
- use functions
- move the pointer to a far value
so I started expanding it into my own language. I think I will end up with 32 instructions (5 bits, maybe 64,6).
The language will be meant to be written in binary and than compressed to plain text bytes (8 instructions in 5 bytes, maybe 4 in 3). But I would probably add a version that compiles instruction names to binary too for ease of use.
question 1: Would I be allowed to use that language*?
subquestion 2: If so which score would count? The compressed number of bytes? The number of instructions? The binary number of bits? The number of letters in the full text version?
The interpreter will probably be able to handle all 3 versions so I really don't know. Technically the number of compressed bytes should be allowed but the number of instructions feels right. Although I (and any other user) probably should be rewarded because I force a lot of limitations upon myself by limiting the instructions so much. (you would be surprised, I use 0XXXX to select variables so their are only 16 real instructions left!).
I currently have a loophole in my design that allows problems with no input format requirements to be solved in 1 instruction:
- RUN : runs the selected variable as code (sandboxed):
If it is a String run it as an input fileremoved string support they are UTF-8 arrays of bytes now!
- If if is an array run each element (in the same sandbox)
- If it is a byte/Double run it as an instruction
- If the next instruction is a SELECT (selects a variable) use that variable as input for the code AND write the programs output to it.
(It used to be 3 but I changed it so a SELECT 0000 and an INPUT instruction are automatically run at the start of the program)
Maybe I could add a standard loophole so that you are not allowed to execute the input as code unless the questions tells you to. But that doesn't feel right.
For some questions their will also be a problem that you are forced to take all the input at the same time (may be done multiple times, although I don't think I need an INPUT instruction now, you can copy var0000 (9 bits)) but I don't think this is a big problem.
*Assumed fulfilled requirements:
- Having an opensource online/downloadable compiler/interpreter
- Being released before the question
- Has proper documentation so everyone can use it if they want.
- Being turing-complete so it's not question specific.
- Anything else?