Howdy.

Been quiet for a while but have been getting back into my scripting language compiler/virtual machine. No particular reason, just has grabbed my attention for the last few weeks.

Today I started adding support for range-syntax on strings and lists:
var s = "hello";var m = [ "one", 2, 3.0 ]; out s[1...3];out m[...func { return 2; }() ];

The ellipse syntax in a subscrpt means you can have two optional expressions to mark the low and high indices to slice at. If omitted, they are 0 and count - 1 implicitly. You can even do s[...] as shorthand for s if you want :)

I realised though that I now have two systems, one for single subscript s[20]; and one for ranged, where these could be combined into a single system, where a single subscript is represented by a range with the low and high set to the same value under the hood. Since I'm aiming for small and clean implementation over high performance, I've now ripped out all of the subscript handling code and going to start again with this in mind.

However, something I also want to do is switch Om over to work with UNICODE so I'm wondering if now would be a good time to tackle this, while I have a load of code ripped out that won't therefore need to be rewritten. I'm not quite sure what is going to be involved in UNICODE support but I presume the less code I have to worry about, the better.

Ho hum. Regarding Om, I'll just briefly recap its main purposes.

Om is a duck-typed scripting language that draws on JavaScript but provides an entirely deterministic approach to object lifetimes via careful reference tracking. There is no (and no need for) garbage collection since objects are released in a completely deterministic way.

One of the types, Om::Object, which works like a string-value map, has a couple of special properties. You can assign a parameterless function to a property called destructor which will then be called when the Om::Object is released.

Om::Objects also support prototype-based inheritance. If the prototype property of an Om::Object points to another Om::Object, that forms a prototype chain. When properties are being read from, the VM searches up the prototype chain for the value, checking to ensure no infinite prototype look has been accidentally created. When writing, the property is always set on the local object. This is how I believe JavaScript inheritance works. It is actually very clean and simple to implement.

Unlike JS, Om::List is a separate type to Om::Object. Lists are declared like [ 1, 2, 3 ]; and so on.

This is the full list of types:
namespace Om {enum class Type { Null, Int, Float, Bool, String, Function, List, Object, Error };

The first four are value-types and the rest are reference types, so the value that is stored is a unsigned int id that points to an Entity inside the machine.

Wish me luck on my UNICODE experiments. wctombs or something isn't it?