Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ideas for Golfing #35

Open
phase opened this issue Nov 12, 2015 · 20 comments
Open

Ideas for Golfing #35

phase opened this issue Nov 12, 2015 · 20 comments

Comments

@phase
Copy link
Owner

phase commented Nov 12, 2015

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
Copy link
Owner Author

phase commented Nov 13, 2015

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

@ConorOBrien-Foxx
Copy link

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
Copy link

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

@refi64
Copy link
Collaborator

refi64 commented Nov 13, 2015

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

@phase
Copy link
Owner Author

phase commented Nov 13, 2015

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
Copy link
Owner Author

phase commented Nov 15, 2015

@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
Copy link
Collaborator

refi64 commented Nov 15, 2015

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
Copy link
Owner Author

phase commented Nov 15, 2015

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

@refi64
Copy link
Collaborator

refi64 commented Nov 15, 2015

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

@phase
Copy link
Owner Author

phase commented Nov 15, 2015

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

1234

prints either
1234

or
4321

@refi64
Copy link
Collaborator

refi64 commented Nov 16, 2015

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

@phase
Copy link
Owner Author

phase commented Nov 16, 2015

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

phase added a commit that referenced this issue Nov 16, 2015
@phase
Copy link
Owner Author

phase commented Nov 16, 2015

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

@refi64
Copy link
Collaborator

refi64 commented Nov 16, 2015

@phase I guess that looks about right!

@phase
Copy link
Owner Author

phase commented Nov 17, 2015

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

@phase
Copy link
Owner Author

phase commented Nov 17, 2015

@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
Copy link
Collaborator

refi64 commented Nov 17, 2015

@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
Copy link
Owner Author

phase commented Nov 17, 2015

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 added a commit that referenced this issue Nov 18, 2015
Related to #35
@phase
Copy link
Owner Author

phase commented Nov 30, 2015

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
Copy link

Are you using the one-byte guillemets?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants