In my mind I already had a concept of simple scripting language. Every line will contain one command and, like in Assembler, there will be a keyword first, then arguments separated by space. I didn't care about spaces in text, because only language keywords would be allowed and they won't contain spaces anyway.
I call this language "Cue", because in English it has the same pronunciation as "Q" and it's meaning is similar to purpose of the language - to trigger an action.
From general perspective it's a bad language, because it has wildly disputed "goto" command. And even worse - "goto" here is the only command for structure, as there are no blocks (like curly braces in C) and all functions has to be coded in advance in platform's source code. From Cue you can only call them with arguments and retrieve their return value.
There are no variables in Cue, the result of each command is stored under a number of the line, where the command is. When you need the value, you can simply recall it by using hash and number of the line, e.g. #5 to get a value from the fifth line.
There are a major catch for editing the code, when number of lines changes due to add/remove lines in the middle of the code. For this reason there is a smart code editor "out of the box", which also draws a diagram of the source code (little help to manage all those gotos) and provides inline help for each command and it's arguments. It also allows to run the code and display a step trace.
Now let me show you how to code (gray comments are not part of the code):
- add 5 4 // calculates 5 + 4 and stores the result (9) into line number
- sqrt #1 // calculates square root of the result from line 1 (=9)
The only thing I don't like (but I don't see any other option, so I dealt with it) are conditions; IF statements, so to speak. Because it technically consists of two parts - condition and then/else branches, I had to split it onto two lines. In the first one I eval the condition (and store true/false result), the second one is if-goto statement. There is no else branch, because if the condition is false, the parser goes to the next line (which is, in fact, the else branch).
I thought about more complex "if" statement, but only this way you can use multiple conditions clearly. The only hack is, that "if" is always if-goto, it's NOT an if-command, because it would violate the single-line-single-command concept.
![]() |
| QetriX Cue Code Editor |
The best usage though is to define actions between two states in a work flow. In QetriX you can define events, as a starting point for launching Cue script. Events are fired in specific occasion, but I'll write about it next time. For more info about Cue please visit our wiki.

No comments:
Post a Comment