It strikes me that the most important design decision is what the underlying paradigm of the golfing language is.
Here are some possible types of language:
- Stack based
- Array based
- Object based
- Functional
- Imperative
- Declarative
Indeed you might even have a mixture of these, or something else entirely like a two dimensional language, automata, regex, machine language or a Turing machine and so on.
This is important because it will greatly affect the syntax of the language and in some ways how concisely code can be written.
Edit: Follow Up
I thought that I would show how the design and implementation phases of creating a language actually work in practice. I realise that's it's more than one tip in this answer and it's lengthy I hope that's ok.
Design Considerations
I wanted the following things out of my new language:
- Quick to implement (or prototype)
- Flexible and concise syntax, perhaps with a view to Golfing
- Can do useful things, not just a toy language
I plumped for some version of Forth, because it would satisfy the first two critera. It would also have to be interpreted at least for prototyping, compiling is out because it would take too much development time.
In terms of it doing useful things, it absolutely had to have the following traits:
- Ability to call functions
- Arithmetic and logic operations
- Manipulation of numbers and strings
- Loops and conditional structures
- Stack manipulation
And because it's Forth I thought the following would be kind of cool:
- Multiple data stacks
- Ability to 'pass in' function literals to be executed inside functions (kind of functional style)
Implementation Details
Firstly, I would leverage my knowledge and use a language I know well for the interpreter: PHP - at least for the prototyping stage.
Next I needed the interpreter to be able to recognise (tokenise) these four things:
- String Literals:
'hello world'
- Numeric Literals:
3.1415
- Labels (for function names)
drop
- symbols (representing atomic actions):
#@$^
The simplest solution for tokensing the program is to use regex. Also because I wanted concise syntax labels would be strictly alphabetic. I would also need some sort of separator to remove ambuiguity in tokenising, I left a space and comma free for that.
So with all that in mind I could create a fat-free Forth syntax. For example:
1.5,2.7,3,4add add add;
would push four numbers on to the stack, and call a function add three times and then return ;.
Once tokenised the interpreter can then consume tokens one by one and act accordingly.
One consequence of using regex, is that it's unable to handle a nested syntax. So I would need to manage nested loops in some way. The way to do this is to look for the start of loops (token) and find the corresponding end and record somehow in the start token where the end is and vice-versa. That way the interpreter could jump around loops and conditionals very easily. A stack would be needed to know which token closes which opening token.
Functions I would just manage as simply labels, or named positions in the token stream. When a function is executed, the position is looked up and interpretation continues from there. I would return from the function using a ; token. This would also require a function call stack to handle nested function calls - and return back to the calling position in the token stream.
For the fancy stuff, such as passing in function literals, the idea would be to push a string literal containing the code fragment on to the data stack e.g:
'2+;'apply;apply:`;
So to break the above down, '2+;' is a string literal containing the code fragment (push 2 and add to top item on data stack). A function called apply is then called. The function definition begins apply: and a backtick actually pops the string literal and executes it in its own brand new context. Once the fragment has been executed and returns, the function then continues.
The interpreter would handle this by separating out the parsing and tokenisation from the actual execution. That way the literal code fragment can be parsed when pulled off the stack, and that new context passed into the Executing function, using PHP's scoping to handle the new context's scope. The only fly in the ointment is that to be able to call a function from the code fragment, it would need to be able to access the parent's context. For example:
'dotproduct;'walkarray;walkarray:...`...;dotproduct:...;
Next for multiple data stacks that would be easy. I would have just one main data stack where all the action happens and provide atomic actions that can push and pull to other named data stacks. That should greatly simplify operations with vectors or arrays of numbers.
I also wanted conditional loops with the condition either at the beginning or end or just infinite loops. So I chose [...] for an if condition, [...) and (...] for conditional loops and (...) for infinite loop.
Lastly, some features that are missing: general mathematical functions, extensive string handling, goto and breaking out of loops and conditions. Although it is possible to break out by returning in a function by using func:(...[;]...).
Anyway, here's the semi-golfed prototype, and hopefully semi readable, enjoy!
Try it online!
1
The community engagement process is a dupe of this.
– None – 2020-01-24T10:45:30.493@a'_', the launching part is, but I also am interested in seeing how to keep a language going after being launched – Lyxal – 2020-01-24T11:19:50.803
3@a'_' Oh wow, that first answer of DJMcMayhem♦ is almost exactly what I wrote in my CW answer below regarding point 3, except much more elaborated. Never seen that meta-answer before, so it's funny how similar it is. :D – Kevin Cruijssen – 2020-01-24T12:56:28.137