o
o copied to clipboard
phase
Ideas for Golfing
This thread is going to be a place where we discuss ideas on making O better suited for codegolf. Right now O can be pretty verbose and is easily beaten by other languages such as Pyth and Seriously (both written in Python). Here are some ideas on how we can solve this issue:
Something needs to be done about implicit input/output.DONE!iandotake up too many bytes. Let's compare it with GolfScript (which is so old it loses pretty much everything). Outputting the string 111 in GS is just111. In O, there are a couple ways to do this. We could output each number by itself,1o1o1o, which is 3 bytes more. We could output it as a string,"111"o, which is still 3 bytes more. A good idea would to have everything on the stack outputted when the code is finished executing. The input could be pushed to the beginning of the stack before the code executes.- We're running out of symbols! I think we should use all 255 characters available to us in a byte, so we can get the most out of each one. I did this with Refract a little bit, but having each character have its own function would allows us to do more complicated things in a smaller amount of bytes.
/cc @kirbyfan64
Idea: create a map of the most-oft-used characters, find the ones that are hardly used, and reserve them into two-byte tokens. (e.g. CJam's e + character).
Idea number 2: All input is initialized on the stack, and the top member(s) of the stack is implicitly outputted?
I like two byte tokens, but if you want to use them they're two bytes instead of one. Seriously doesn't have this issue because (almost) every one byte character does multiple things. I'd seriously choose coding in a hex editor over using two bytes.
@kirbyfan64 How do you feel about the input/output? Do you want to start work on changing it? I think we should keep the inputting the way it is, but take out o and have the stack be outputted when the program finishes. p could become a variable that pushes \n to the stack.
I think O still needs some sort of I/O system like it has now in addition to dumping the stack at the program's end. That way it can work on infinite output challenge.
@kirbyfan64 How about we keep everything we have now, but just output the stack at the end?
@phase That's what I meant. I was just rushing and didn't word it in human English. ;)
@kirbyfan64 How should it be outputted? In reverse or normal? Like:
1234
prints either
1234
or
4321
@kirbyfan64 I was just testing that :P I've got a working version I'll push in a sec.
@kirbyfan64 Here's what it does currently, is this the desired way we want to output?
An operator to push a blank string would also be nice, when using it with #43. There may be ways around this, though.
@kirbyfan64 Do we want to delve into the land of nonasciiia? I set up a text file as a checklist to see what characters we've used, and we're definitely running out. We could just use 0 through 32 codepoints, as they're only one piece one byte a piece.
@phase Well, Pyth uses two-byte sequences (like .{) for less-common operations. That, and intense operator overloading!
It would maybe be neat to try both approaches: non-ASCII and two-byte sequence.
Operator overloading is something we need. We could use ! for some alternative operators, though overloading would probably be better.
We could also use S to push a blank string to the stack.
In normal programming languages, like C, it takes 3 bytes to increment a variable: V++
In O, it's just sad
V):V
):
We could have something like L that increments the next character,
0:V
»V Increment V without putting it on the stack
«V Decrement V without putting it on the stack