Ideas for Golfing

[phase]

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. i and o take 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 just 111. 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. DONE!
• 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

[phase]

Looking through CJam's docs, I found these interesting operators that would work nicely in O.

[ConorOBrien-Foxx]

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

[ConorOBrien-Foxx]

Idea number 2: All input is initialized on the stack, and the top member(s) of the stack is implicitly outputted?

[refi64]

@ConorOBrien-Foxx You just said what @phase mentioned at the very top... :)

[phase]

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.

[phase]

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

[refi64]

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.

[phase]

@kirbyfan64 How about we keep everything we have now, but just output the stack at the end?

[refi64]

@phase That's what I meant. I was just rushing and didn't word it in human English. ;)

[phase]

@kirbyfan64 How should it be outputted? In reverse or normal? Like:

1234

prints either
1234

or
4321

[refi64]

@phase Hmmm...well CJam prints them like 1234...

[phase]

@kirbyfan64 I was just testing that :P
I've got a working version I'll push in a sec.