Announcing ObjoScript

[Garry]

I’m super happy to announce the open source release of ObjoScript. I also posted this over on the official Xojo forum but wanted to share it here too.

What is ObjoScript?

ObjoScript is an object-oriented, dynamic, embeddable and debuggable scripting language for use in Xojo applications. It utilises a stack-based VM and is about 20x faster than my previous open source language Roo.

The syntax is heavily inspired by Wren. It’s a curly brackets language but semicolons are not needed.

Major features

1. Integrated debugger - step through code line-by-line and inspect local and global variable names and values.
2. Familiar syntax. It’s C-like but semicolon free.
3. Implemented via a stack-based virtual machine. This makes it much faster than tree-walk interpreter languages.
4. Object-oriented. All code executes either within a function or the method of a class. Class fields are private by default and are accessed through method calls.
5. Lovingly crafted. Almost every line of code is commented and there is rich documentation within the source code.
6. Comprehensive test suite. Several hundred tests have been implemented testing every facet of the language and the core library.
7. Cross platform. The desktop dev harness compiles and runs on macOS, Windows and Linux. The ObjoScript VM compiles without issue on iOS.
8. 100% native API 2.0 Xojo code. The only plugins required are for the demo app / bundled code editor. The actual VM is entirely Xojo code.

Why create it?

I needed an embeddable scripting language for an app I’m working on that’s written in Xojo. Obviously Xojo provides its own scripting engine (XojoScript) and there are several other scripting languages available via plugins (e.g. Wren and Python) however none of them provide any way to debug code written in the scripting language.

For my app, it’s crucial that the end user is able to step through code written in the scripting language and inspect variables to help them debug. This is simply impossible in the currently available engines so I decided to implement my own.

What’s in the GitHub repo?

1. The ObjoScript compiler and virtual machine.
2. A basic IDE including a syntax-highlighting code editor, interactive debugger, bytecode disassembler and AST viewer.
3. Comprehensive automated test suite.
4. A command line tool (CLI) to run scripts from the Terminal.

About the IDE and debugger

The IDE contains a cut-down version of my XUICodeEditor control. I debated a lot about whether or not to include this in the repo (since I sell the editor as part of a larger suite of controls) but decided in the end that this project is much better with its inclusion. If you like the project, please consider purchasing a license for the full XUI suite.

As you can see from the screenshot, the IDE has most basic functionality.

Code editing

Bytecode disassembly

AST viewer

Debugger

Test suite

Requirements

Development has been done with the latest version of Xojo (currently Xojo 2022 Release 3.2). The code is API 2.0 so you’ll need a modern version of Xojo to run it.

Whilst ObjoScript is 100% Xojo code and itself doesn’t depend on any plugins, the development harness uses Einhugur’s TreeView plugin and the code editor uses Einhugur’s open source TextInputCanvas. Demo versions are included in the repo.

Documentation

There is extensive documentation in the repository’s wiki. I still need to document the core library (string, number functions, etc) but the code is extensively commented.

Where to get it

As usual, it’s hosted on GitHub.

Pull requests and constructive feedback are welcome.

[rgb]

Hi,
Nice project!
I like like wren, gravity interpreters.
I’m working on a graphics IDE. for theirs interpreters.

Looking your code this week.

[bgrommes]

My dude, you are nothing if not prolific! The Xojo community is fortunate to have your contributions. Even though this particular one is not something I need ATM I expect to learn a lot just from studying the code.

[Garry]

Wren is a cool language. I had planned on using it instead of rolling my own language but there is no good way to debug Wren code. @einhugur has written a Xojo plugin for the official Wren language but the debugger branch for Wren is pretty poor.

[rgb]

If you time look gravity interpreter, it’s also nice
https://marcobambini.github.io/gravity/#/

[Garry]

Very cool. Again though it lacks any ability to step through code. In ObjoScript you can step line-by-line through the script code.

[JuliaTruchsess]

Pardon my ignorance, but what exactly do you do with it? Any real-world examples?

[Garry]

I’m building a game-maker app for my daughter. It uses the Box2D port I did and the entities are programmed using ObjoScript.

[JuliaTruchsess]

So it generates code? Xojo code?

[bgrommes]

It’s its own scripting language with the twist that it is debuggable. It is used for user scripting of the Box2D lib in this case. I have to say, Garry’s daughter is a lucky one! How many kids have their own custom game development system courtesy of a parent?

[tempelorg]

It’s being interpreted, I believe (whereas XojoScript compiles into machine code, and even plugins for JS and Lua can optional get compiled into machine code, or execute in an interpreter).

[npalardy]

I believe you are correct based on Garry’s description of

1. Implemented via a stack-based virtual machine. This makes it much faster than tree-walk interpreter languages.

I’ve made use of XojoScript + the option to save compiled code and its pretty dang fast once compiled. Plus access to the Context object make it easy to have XojoScript that can interact with Xojo code

Some of my scripts are 8 - 10K lines long !

[bgrommes]

This prompted me to look at XojoScript for the first time, though I don’t have any immediate need for it.

I guess 8 to 10K lines in a script is not necessarily a bad thing since one can define methods, functions, classes, etc in the script. I would hate to have to debug subtle problems, though. On the other hand … Garry’s objective is to tutor his daughter in coding in a controlled environment, including using a debugger to step through code and see what is going on. If I wanted to make something scriptable about an app, the potential audience likely wouldn’t know what to do with a debugger.

I’m an old-school Code Complete kinda guy who believes in stepping through all new code to make sure it works as intended, rather than just appearing to, but I would guess your typical scripting user would not be writing thousands of lines of code or doing anything very complicated. You would feed them a context object to support a particular purpose and give them some very defined things to do.

And it’s nice that XojoScript is compiled.

[npalardy]

@bgrommes

I would hate to have to debug subtle problems, though

Why I created a way to debug them too
https://www.great-white-software.com/blog/2022/11/23/xojoscript-debugging/

@bgrommes

I’m an old-school Code Complete kinda guy who believes in stepping through all new code to make sure it works as intended, rather than just appearing to

Absolutely
I think everything in this client project has 100% test case coverage for functionality
Makes it easy to figure out if I break something like this morning

@bgrommes

You would feed them a context object to support a particular purpose and give them some very defined things to do.

welllllll …

[bgrommes]

Thanks for pointing out the debugger, I had seen that at some point and had forgotten about it. I hope it can be made public and make you and your client a bit of $.

To the point of a typical scripting user having modest ambitions and probably abilities – of course you can provide a constrained context object to code against and not document all the possibilities of what the script could do but that wouldn’t prevent someone from doing something very ambitious, it’s true.

It does sound like your use case is not “typical”, lol

[npalardy]

@bgrommes

Thanks for pointing out the debugger, I had seen that at some point and had forgotten about it. I hope it can be made public and make you and your client a bit of $.

that would be nice
there are some technical issues I still need to sort out - like being able to use multiple contexts or a way to chain them or something

@bgrommes

It does sound like your use case is not “typical”, lol

Not at all
Its very ambitious

[bgrommes]

@npalardy

there are some technical issues I still need to sort out - like being able to use multiple contexts or a way to chain them or something

I don’t see anything in the Xojo docs to prevent a context object from just holding pointers to other objects, such as, say, the main window, the app, etc.

[npalardy]

Oh I have NO issue doing that
But the context object basically adds new language to whatever script you write
So, in order for anyone to use this debugger thing they’d literally have to modify ITS context object every time for every unique script they run because there is no way to expose more than one context object to a script

THAT makes it painful to use and a limitation I cant figure out how to overcome - yet

[bgrommes]

@npalardy

I cant figure out how to overcome - yet

That’s the spirit!

[prodman]

@npalardy

there are some technical issues I still need to sort out - like being able to use multiple contexts or a way to chain them or something

I think I submitted a request for this years ago, to no avail. Meantime, my scripts have a 20k+ lines of code prefix and a context class that has more methods than you can shake a stick at.