The use case for me is that I needed a scripting language that fully supported step-by-step debugging with variable inspection. This is something that is impossible with XojoScript and any other embedded plugin scripting language.
I designed ObjoScript to be debuggable and really easy to embed into an Xojo app and to extend it as needed.
I’m currently planning on completing the Advent of Code competition with ObjoScript to show what it can do (I have done day 1 so far).
I’m a little time pressured right now as I’ve had a sudden family bereavement and am acutely unwell myself so hopefully I can get back to working on it in a couple of days.
The interaction with Xojo is explained in the Wiki. Basically, you have to write Xojo functions and then call a “Bind” function to link them to the Objo runtime. Getting and setting parameters requires calling special functions, similar to how you’d work with Database records.
I’m sure this could also be extended with support for a “Context” class, just like it works with XojoScript, through Introspection. Either Garry may find the time for it in the future or someone else writes that - it’s all open, after all.
The Wiki does have examples, though they’re only showing small details, like the Binding.
Overall, it’s like XojoScript: You can let a user write code, and then run it in your program, and you can have the script access functions that you provide in your program to the script. Just like the IDE provides your Xojo programs with functions such as “Length()” and “InStr()”, which are not build-in compiler features, you can provide similar functions to the script via Binding (ObjoScript) or a Context class (XojoScript).
And where is this useful?
I use scripts in many places in my own apps. For instance, one app, my FindAnyFile, has hard-coded rules to look for specific properties of files, such as name, size, etc. But there are users who want special tests that I have not hard-coded yet. So they’re now able to write scripts that in turn can access the file properties on their own, or even run Shell commands, and then return to my program whether they consider a file “found” or not.
Another case is where I want to give the user more flexibility to format printed (HTML, PDF) output from templates. Basically, they can embed XojoScript code into a template file just like you write PHP code inside a server-based HTML file. This is quite easy to accomplish with XojoScript. I am happy to share the code, though I’m sure I’ve shared that years before here in the forum already.
Thanks to @Thomas_Tempelmann for taking the time to explain some of the usage of ObjoScript.
Essentially, it’s a replacement for XojoScript or any other scripting engine available to Xojo (for example Wren or Python provided by Einhugur). Some of the unique advantages that ObjoScript has over other engines are:
It’s completely open source 100% native Xojo code
Debuggable. This is probably the single biggest differentiator from the other engines. There is no way to line-by-line step through code written in XojoScript (for example) without adding a lot of boilerplate code mixed in with script code. With ObjoScript, you can debug it in a similar manner to how you debug Xojo code.
Provides a rich (and growing) core library that is more expansive than XojoScript. For example, it has a native dictionary class that is directly accessible from the host Xojo app.
Works on iOS (XojoScript does not).
Multi-phase compiler that generates a parse tree as well as bytecode
Stack-based VM.
As for what are its use cases, well it can be used in any app that you want to make extensible. Perhaps you want a plugin architecture for your Xojo app and you want your users to be able to write code that interacts with your Xojo app - ObjoScript can do this.
I created the language for several reasons:
To show what is capable with Xojo. I think it is fair to say that if you can write a compiler and performant runtime for a new language in Xojo, you can do anything with Xojo.
To teach others about how programming languages work.
To use in my own application because the alternatives (such as XojoScript) were not adequate for my needs.
As for a working example, just download the main project and run the demo app. It is lovingly commented throughout and I think it’s pretty self-explanatory as to how I embed the VM and compiler into it. Also, as Thomas has mentioned, there is a comprehensive wiki on GitHub. I’m also (very slowly) going through this year’s Advent of Code competition using ObjoScript. You can see what the language looks like in my repo.
=+ will read the unincremented value and increment it afterwards. It’s very handy when you want to pull something out of a collection and bump the counter without adding another line of code just to do that.
Actually the difference between x++ and ++x only matters when you are using them inline within another code line. such as “a = ++x”. Basic languages would forbid such an operation. as the ++ would be a statement of its own. so:
This is true, inherently it’s stuffing 2 statements into 1. Some people hate that. I kind of like it in those infrequent cases where it’s succinct. Your example of a= ++x would not be such a situation. Where I have used it is with stuff like this:
newChars[++pos] = s[i];
… where newChars is a char buffer and s[i] is a character from a string and pos is the integer position in the buffer. That statement increments pos and THEN assigns s[i] to the new position pos in the buffer. The alternative / more verbose (arguably clearer, depending on what you’re used to) way would be:
newChars[pos] = s[i];
pos++; // or pos += 1 or pos = pos + 1, etc.
… which I would argue adds verbosity but not really clarity. My guess is that either there’s no real performance difference or compilers would optimize whichever is slower into the faster one, so it comes down to personal preference.
You would never of course use this if pos were already controlling a loop, assuming the compiler would even let you.
Amusingly, the +=, -=, =+ and =- operations were all implemented to take advantage of a peculiarity of ancient magnetic core memory which hasn’t existed for decades. At the time it produced faster code (on DEC computers) because it compiled to a single machine instruction. Nowadays, it’s just syntactic sugar.
