phase / o

Esoteric stack-oriented programming language for code golf
https://jadon.io/o
MIT License
56 stars 7 forks source link

Ideas for Golfing #35

Open phase opened 8 years ago

phase commented 8 years ago

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:

/cc @kirbyfan64

phase commented 8 years ago

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

ConorOBrien-Foxx commented 8 years ago

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 commented 8 years ago

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

refi64 commented 8 years ago

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

phase commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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

refi64 commented 8 years ago

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

phase commented 8 years ago

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

1234

prints either
1234

or
4321
refi64 commented 8 years ago

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

phase commented 8 years ago

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

phase commented 8 years ago

@kirbyfan64 Here's what it does currently, is this the desired way we want to output? ide

refi64 commented 8 years ago

@phase I guess that looks about right!

phase commented 8 years ago

An operator to push a blank string would also be nice, when using it with #43. There may be ways around this, though.

phase commented 8 years ago

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

refi64 commented 8 years ago

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

phase commented 8 years ago

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.

phase commented 8 years ago

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
ConorOBrien-Foxx commented 8 years ago

Are you using the one-byte guillemets?