GolfScript Syntax

Source is split into tokens. These tokens are words (letters or underscore followed by letters, numbers, and underscore), numbers, strings (either "...", or '...'), comments (# until newline), everything else is a single character token. The regular expression used is:

/[a-zA-Z_][a-zA-Z0-9_]*|'(?:\\.|[^'])*'?|"(?:\\.|[^"])*"?|-?[0-9]+|#[^\n\r]*|./m

{} denote inner block creation

: is a special assignment operator

Every other token is treated as a variable. Numbers and strings are variables too, just that they have a logical initial value (which you could change if you really wanted to).

' Strings and " strings are parsed using ruby's string parse, via eval. Therefore it is possible to run ruby code in GolfScript by doing something like this:

"The time is #{Time.now}" -> "The time is Tue Dec 11 12:59:27 -0500 2007"

This will probably be of little use, except for doing things that GolfScript does not have built-in, such as floating point arithmetic, etc.

All variables when loaded are pushed on the stack except if that variable is a block it will be evaluated instead. So essentially interpreting GolfScript is just pushing or evaluating variables. This is why an interpreter is about 25 lines of ruby code.

However this language will not be able to do anything without some variables already initialized to some blocks that execute primitive functions. Most of the complexity in a GolfScript interpreter comes from defining this set of primitive functions. At the bare minimum functions such as integer add, divide, array concat, array to string, block execute, etc would be needed. From these the rest of the standard operators could be defined. However, the current implementation implements most everything in ruby for simplicity's sake.

It might be interesting to try and write an implementation using as few as built-in's as possible and defining everything else in GolfScript itself. However this would make little difference except making code run even slower. Also local variables should be added to the language to make defining your own functions easier.

Ruby is slow to start with so GolfScript is even slower. There is nothing innately slow about GolfScript. Except for the string evaluate method, everything could be statically compiled into C, and analysis could be done to remove most if not all stack use. I do not plan on making a more efficient interpreter, as the purpose of language is not numerical analysis, however if any feels like creating one, I would be delighted to use it.


Home Tutorial Syntax Built-ins Quick ref Examples Download	GolfScript Syntax Source is split into tokens. These tokens are words (letters or underscore followed by letters, numbers, and underscore), numbers, strings (either "...", or '...'), comments (# until newline), everything else is a single character token. The regular expression used is: /[a-zA-Z_][a-zA-Z0-9_]\|'(?:\\.\|[^'])'?\|"(?:\\.\|[^"])"?\|-?[0-9]+\|#[^\n\r]\|./m {} denote inner block creation : is a special assignment operator Every other token is treated as a variable. Numbers and strings are variables too, just that they have a logical initial value (which you could change if you really wanted to). ' Strings and " strings are parsed using ruby's string parse, via eval. Therefore it is possible to run ruby code in GolfScript by doing something like this: "The time is #{Time.now}" -> "The time is Tue Dec 11 12:59:27 -0500 2007" This will probably be of little use, except for doing things that GolfScript does not have built-in, such as floating point arithmetic, etc. All variables when loaded are pushed on the stack except if that variable is a block it will be evaluated instead. So essentially interpreting GolfScript is just pushing or evaluating variables. This is why an interpreter is about 25 lines of ruby code. However this language will not be able to do anything without some variables already initialized to some blocks that execute primitive functions. Most of the complexity in a GolfScript interpreter comes from defining this set of primitive functions. At the bare minimum functions such as integer add, divide, array concat, array to string, block execute, etc would be needed. From these the rest of the standard operators could be defined. However, the current implementation implements most everything in ruby for simplicity's sake. It might be interesting to try and write an implementation using as few as built-in's as possible and defining everything else in GolfScript itself. However this would make little difference except making code run even slower. Also local variables should be added to the language to make defining your own functions easier. Ruby is slow to start with so GolfScript is even slower. There is nothing innately slow about GolfScript. Except for the string evaluate method, everything could be statically compiled into C, and analysis could be done to remove most if not all stack use. I do not plan on making a more efficient interpreter, as the purpose of language is not numerical analysis, however if any feels like creating one, I would be delighted to use it.