Announcing ObjoScript

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.

In fact, I called it XHP and it can be downloaded here:

If you run it in the IDE, you’ll see what it can do, I hope.


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:

  1. It’s completely open source 100% native Xojo code
  2. 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.
  3. 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.
  4. Works on iOS (XojoScript does not).
  5. Multi-phase compiler that generates a parse tree as well as bytecode
  6. 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:

  1. 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.
  2. To teach others about how programming languages work.
  3. 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.


Just another update - as of the latest commit I’ve just implemented the compound operators +=, -=, *= and /=.


Are you planning =+, etc? I have found those awfully handy at times in C#.

Dude, literally the post above.

literally the post above.

Is “+=” the same as “=+” ?

I would guess not… and it is because of things like that I developed an allergy to C type languages long ago! :wink:


1 Like

No they are not the same.

+= will increment a value and return it.

=+ 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.

Nope. Please see my response to KarenA.

Ah I see.

Nope, the compound operators listed above are the only ones I’m planning on adding. I’m trying to keep the language simple as it’s for a 10 year old.


You don’t have to tell her about the post-increment versions :wink:

But seriously no I understand. Not a big deal.

Actually I brain-farted on this anyway, I was thinking of this:


… vs this:


Same for --. I haven’t written any C-family code in a couple of months and my brain tends to switch out of that mode if I don’t use it frequently.

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:


Would be identical.

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.

1 Like

True, but were it gets nasty and obtuse is if you were to do this:

newChars[++pos] = s[pos++];

That line is just a mess. I would not be upset to just have:

newChars[pos] = s[i]

A fair point. Not a hill I’m going to die on arguing against :wink:

The trouble with advanced C-family syntax is it tends to allow you to write either very elegant code if you’re judicious, or blow your foot and lower leg clean off if you’re a cowboy.

I do own a copy of Kernighan And Ritchie (2nd edition) bought new … It was not my most useful purchase! :wink:

That was back when I saw everything going that way (I had been coding in BASIC, FORTRAN and Pascal) … C got me to step away from coding for a good while!

It’s not the concepts, I just found that type of syntax hard to read/absorb, and no fun!!!


My experience was originally with Algol style languages: Pascal, Basic, PL1, etc., but I didn’t really mind C syntax. My big complaint with C was/is that the only way you could call by reference is to pass a pointer. I never was able to deal with pointer syntax without having to go to the reference manual every time I needed to use a pointer, or try to follow someone else’s code that used them. I haven’t minded programming in Java and Javascript which are both C syntax.

And I have not minded C#, although it is getting so full of lamdas now that they might be snatching defeat from the jaws of victory when it comes to me. Java, JavaScript, C#, Swift and similar Algol descendants provide the ref syntax you want, get rid of pointers except for code marked unsafe for very particular needs, etc. But these mainstream languages do tend to get a lot of bolted-on obtuseness after awhile, trying to be all things to all people.

I’ve just implemented support for switch statements.

They work as you might expect:

switch someValue {
  case anotherValue {
    // Code...
  case aFunctionCall(), "literal", 3 * 2 {
    // Code...
  else {
    // Executes if none of the cases match `someValue`

They were trickier to implement than I had anticipated. For those interested, the compiler translates a switch statement into a nested if...else statement so there is no performance advantage to using them over if statements but they can be easier to read.



No worries about the chained (not nested) ifs - the times of using static jump tables for better performance are long gone anyway.

1 Like