An improved version of GolfScript

Question

I am planning to write an improved GolfScript for even shorter programs that can do more things. This is not a challenge; it is a request for feedback and tips on what I should do. (see tags)

^{I'm not sure if this should be Community Wiki. If you think so, just flag for a moderator to convert it :)}

This language will be very similar to GolfScript. It is still written in Ruby. However, it has a few differences:

• Using ` as a string delimiter, because it's an uncommon character, so less escaping will be needed. (Another character can replace its function, like # (more on that later)). \` to escape a backtick, \\ to escape a backslash, and there are no other escape sequences. If you need a newline, just stick an actual literal newline in the string.
• Using Ruby's Rationals for arbitrary precision floating point, one of GolfScript's major flaws.
• The ability to convert types to other types. For example, you can convert a block to a string.
• Regular expressions. Probably created with "...". Operators will be overloaded for them as well. For example, "\W"~{`Invalid: non-word character`}{`OK`}if. Will automatically execute when pushed from a variable, like blocks.
• File and Date objects, to do more stuff that was impossible in GolfScript. These will not have literals, but will have functions for initializing them, such as `file.txt`fl (name of the file-making-function may change).
• Hashes maybe, but I'm not sure on that one. Should I?
• Helper functions to do even more. For example, `http://example.com`net for network access (again, net operator may be renamed). rb to execute a string as Ruby code. There will be many more of these; suggestions welcome.
• No comments, so that # can be used for something else. If you want a comment, `comment here`; will work fine. (Maybe # can replace `'s function)
• It will be completely rewritten in a way that it will be much easier to add functions. Basically, the code will be more readable. (Have you seen the GolfScript source? :/)
• It will be on Github so it can be collaboratively worked on. I'll license it under MIT or something.
• No final newline, so cheaty quines work :P

And I'm setting these apart because I think they're the most drastic and helpful changes (except maybe adding floating point):

• It will have many Ruby functions built-in. For example, shuffle (which may be abbreviated to sf) (previously took 9 characters), tr (previously 14 chars), sample (sm, previously .,rand=), flatten (fl, previously ???), etc.
• It will be mushed, like Rebmu. For example, now you can do ~:a0<{0a-}aIF (using a letter variable name) instead of ~:$0<{0$-}$if (overwriting the sort function). (example from here). Note that this way, it is case-insensitive, and numbers are not allowed in variable names. This is okay in my opinion since it's a golfing language :P
• It will have debugging. I will add the ability to supply a flag specifying array delimiters, element delimiters, etc., number output (rational, float, or int?), stepping through instructions one at a time, tokenizing and outputting each token instead of running the program, etc.

So, my question is: what is there to improve? What do you think I should add?

Any other ideas for this, before I start coding it?

Answer 1

Flexible I/O

Golfscript cannot at present be used for interactive programs. I propose some functions for explicit input be added (i.e. readline, getchar and friends). The interpreter should see if the program uses these before running it.

If the program does not call any input functions, the interpreter should act like Golfscript normally does.

I wouldn't expect the interpreter to detect input functions in eval'ed code generated at runtime, but if it somehow can do that, kudos.

Answer 2

Shorter built-ins

Single-character aliases for all of the built-in commands which don't have them. I would use base a lot more if it were just B.

Answer 3

Combined div-mod

This is a bit more niche than some of the suggestions, but when working on number-theoretic programs I frequently find myself wanting an operation which pops two integers a and b from the stack and pushes a/b and a%b. (At present this is 1$1$/@@%).

Answer 4

Numbers

Change the lexer such that leading 0 is not part of a number:

# current behaviour
01     # -> 1

# new
01     # -> 0 1

Also negative numbers should be written with _ instead:

# current behaviour
1 2-3   # -> -1 3

# new
1 2_3     # -> 1 2 -3

Answer 5

Access to the whole stack

GolfScript is a stack-based language, but access to all but the top three items on the stack is limited to <integer>$ to copy the nth item. It would be useful to have something like PostScript's roll command so that it's easier to work with more than three "live" variables.

Ideally there would be one-arg and two-arg versions, but if there aren't enough names around then the one-arg should get preference for a one-character one.

The one-arg one just takes the number of items to roll. E.g. 1 roll does nothing; 2 roll is equivalent to \; 3 roll is equivalent to @; 4 roll and for higher numbers doesn't have an existing equivalent; the closest that's possible is something like

]-4/()\+\+[]*-1%~

(and that doesn't even handle non-integers at certain positions on the stack, or active [, and almost certainly breaks inside loops too).

The two-arg one also takes an amount to roll; a b roll2 is equivalent to {a roll}b*.

Answer 6

CJam

I have implemented "an improved GolfScript" and it is called CJam - http://sf.net/p/cjam
Now at the second release (version 0.6) it already has many if not most of the features discussed here. I'll try to list them:

• still written in Ruby - nope, java
• using ` as a string delimiter - no, but it uses double-quoted strings with minimal escaping (\ escapes only \ and ")
• floating point - supported, but only standard "double", not arbitrary precision
• convert types to other types - yes
• regular expressions - not yet, but planned; will use regular strings with special operators
• File and Date objects - no, but can get the current date/time
• hashes - assuming those are like python dicts or java maps, then they're not supported (may consider in the future)
• helper functions to do even more - yes, a lot
• `http://example.com`net - "example.com"g
• execute a string as Ruby code - nope
• no comments - exactly, # used for something else, "comments like this";
• easier to add functions - I think so, but I'm also biased :)
• on Github - even better (in my opinion, please don't shoot) - on SourceForge, using hg
• licensed under MIT - yes
• no final newline - right
• shuffle - mr
• tr - er
• sample - not done, _,mr=
• flatten - not done, but probably easier to achieve
• mushed - nope, but identifiers don't need to be separated

• debugging - only stack traces, and ed operator for showing the stack

• flexible I/O - yes, but only explicit input

• shorter built-ins - yes, b = base, z = zip
• separate leading 0 - no, but can use predefined variables
• disambiguate - - yes, but not with _; 1 2-3 -> 1 2 -3; 1 2m3 -> -1 3
• roll/rotate the stack - nope
• array set - t
• divmod - md
• change the lexer (for identifiers) - yes, more below
• cartesian product - not exactly the same, but yes, m*
• unicode operators - no
• single-character identifiers - predefined operators have 1 or 2 characters and variables are single-character uppercase letters; they can all be concatenated without confusing the lexer/parser
• operators on blocks - no
• stable sort - yes
• turn symbols back into code blocks - no, but may add later
• current date/time - et
• command line args - ea
• clearly separating built-ins - yes, but capitals are variables; built-ins are or start with lowercase and special characters
• min and max - yes, currently only for 2 values: e<, e>
• absolute value - z (GolfScript has abs, not lacking)
• sum and product of an array - :+, :*
• Manhattan distance - nope
• chr - c (converts to a character, not a string)
• spill a string onto the stack - CJam strings are made of characters, not numbers; to spill the characters it's still {}/
• a version of : that consumes what is stored - nope
• operators for >=, <= - nope, use <!, >!
• base64 and zlib - nope
• shortcuts for 1$, 2$, 3$, 4$, 5$ - nope
• copy the top two stack items - planned; for now use 1$1$
• local variables - nope
• HQ9+ features - no, thank you

CJam has a lot more features, check out https://sourceforge.net/p/cjam/wiki/Operators/

Answer 7

Change the lexer

GolfScript's lexer treats a Ruby identifier (anything which matches the regex [_a-zA-Z][_a-zA-Z0-9]*) as a single token. If it instead treated [a-zA-Z]+ as a token that would free up _ to be a built-in and would allow an alpha variable to be followed by a literal integer without separating whitespace.

Answer 8

Unicode aliases

Multiple-character commands could have unicode aliases. This would save on the score when the score is counted in characters and not in bytes.

Answer 9

Stable sort

The $ builtin on blocks should perform a stable sort.

Answer 10

Array set operator

["A" "B" "C" "D" "E" "F"] -1 4 S    # -> ["A" "B" "C" "D" -1 "F"]

Any built-in we can make available for that?

Answer 11

Single-character identifiers

It's not like a code golf solution is going to have too many variables. And it would save on spaces.

Answer 12

% as builtin for product

[1 2][1 2 3]%  # -> [[[1 1][1 2][1 3]][[2 1][2 2][2 3]]]

Answer 13

Regex support

The lack of regex support has always struck me as odd in a language designed for golfing. It would be great to have

• <string> <string> <string> y (aka tr, using Perl's one-char alias for it)
• <string> <string> <string> s (substitute)
• <string> <string> <block> s (substitute with callback)
• <string> <string> m (match)

Answer 14

Builtins for current date/time

It is currently very quirky to get date/time using Ruby evals.

D     # -> [2013 12 31]
T     # -> [23 59 59]

Answer 15

Make |, & and ^ built-ins do something useful on blocks

E.g. <array/string> <block> | can be used as index function

[0 -10 -20 30 40 -50 60] {0<} |   # -> [1 2 5]

Any ideas for <array/string> <block> & or <array/string> <block> ^?

Answer 16

A way to turn symbols back into code blocks

Currently, we can bind code blocks to symbols with :, but there's no way to reverse the process: executing a symbol bound to a code block just executes the block.

I can see a couple of ways to implement this:

1. add new syntax, e.g. #foo to push the value of foo to the stack, even if it's a code block, or

2. add an operator to expand every symbol in a code block, so that (using _ as the new operator), e.g. {2*}:dbl; {dbl dbl}_ would produce {2* 2*}.

I can see advantages to both methods. The latter could substitute for the former, at the cost of two extra chars ({foo}_ instead of #foo), but I can see some potential applications for the former syntax where those two chars would be prohibitive (e.g. using array #func % instead of array {func} %).

Meanwhile, the former syntax could be used to replace the latter if there was a convenient way to somehow iterate over the tokens in a code block (which could be useful on its own, anyway).

---

In either case, I'd propose that expanding symbols that are bound to native built-ins (i.e. implemented in Ruby code) should return some kind of stub that could be called to obtain the functionality of the built-in, while being either impossible or just unlikely to be overridden. For example #$ (or {$}_) could return e.g. {builtin_dollar}, where builtin_dollar would contain the actual implementation of the $ built-in (and #builtin_dollar or {builtin_dollar}_ should just return {builtin_dollar} itself).

This would allow built-ins to be redefined without losing access to their functionality (see my earlier suggestion), so that if I, say, for some reason wanted to swap the meanings of $ and @, I could just do #$ #@ :$; :@; (or {$}_ {@}_ :$; :@;).

Answer 17

Variable preset with command line args

Unfortunately, there isn't any char left unassigned, but maybe we can use A for that?

Answer 18

Native Ruby functions that I should implement

This is Community Wiki; feel free to edit and add the functions you think I should implement!

Format: "nativeFunctionName (nameInMyLanguage)"

• shuffle (sf)
• tr (tr)
• sample (sm)

Answer 19

Take features from APL and HQ9+ too!

• Shortcuts, like in APL. EDIT: just saw the answer "unicode aliases". That's what I meant :)
• Other golf-oriented shortcuts, like in H9+, HQ9+, CHIQRSX9+

Answer 20

Clearly separating built-ins

e.g. capitals : built-ins ; making B for base feasable

Answer 21

Local variables / closures

One thing I really miss in GolfScript is the ability to temporarily change the value of a symbol.

In particular, there's currently no way to temporarily override the meaning of a "primitive" built-in: once you, say, redefine $, you're never going to sort anything in that program again. (Well, not without writing your own sort implementation, at least.) It would be really nice to be able to say, for example, that in this code block $ means something else, but still keep the normal meaning elsewhere.

Related to the above, it would be nice to bind symbols in a code block to their current value. Sure, I can write, say, {$-1%}:rsort and be able to use rsort to sort and reverse an array, but that works only as long as the definition of $ (or -1 or %) doesn't change, since my rsort function is still calling the global symbol $. It would be nice to be able to say "let rsort do what $-1% currently does, even if those symbols are later redefined."

In particular, the standard library could use this kind of binding. It's kind of surprising to realize that, say, changing n changes the behavior of puts, or that redefining ! completely messes up xor. (Then again, some caution should be exercised here, since, in particular, the ability to change the behavior of puts turns out to be turns out to be the only way to avoid printing a final newline in the current version of GS.)

Edit: Being able to turn symbols back into code blocks would go a long way towards implementing this functionality. In particular, the {foo}_ syntax suggested in that answer would effectively perform one level of static binding by expanding all symbols in a code block. Combine that with a fixpoint combinator for deep static binding, and Bob's your uncle...

Answer 22

More built-in functions

Make all the single-letter variables a-z and A-Z perform some generic, useful function. Some built-ins that are lacking:

• min and max: all or some of top 2 stack values, top n stack values, over an array
• absolute value
• sum and product of an array. why do {+}* when you can do S? You have 52 functions to work with here!
• Manhattan distance (i.e. x1 y1 x2 y2 --> abs(x2-x1)+abs(y2-y1). Now it'd have to be @-A@@-A+ if A is a built-in absolute value. Granted this only came up caues of my most recent post but I always figured that'd be a good way to expand golfscript: write down what functions would be handy to have, collect them, and add them as built-ins.
• Convert an integer to a one-character string (equivalent of python's chr).
• Spill a string onto the stack (currently {}/)
• A version of : that consumes what is stored. This would have to not get 'stuck' to identifiers to be useful.
• Operators for >=, <=
• As someone suggested, a way to put a variable containing a block onto the stack without executing it. So you could reduce ifs of the form 1{\}{|}if to something like 1?\?|if
• Built-in base64 conversion and zlib support to make embedding data take less characters
• Beyond base64, make a custom base93 encoding (using all printable characters that aren't the string delimiter).
• Shortcuts for 1$, 2$, 3$, 4$, 5$
• An operator to copy the top two stack items as they are, i.e. \.@.@\

Answer 23

It'd be nice if the value written or computed in the last line of a function was automatically returned