Awelon Virtual Machine

An ‘Awelon Virtual Machine’ (AVM) is a description of an RDP-based programming environment.

This description includes types, partitions, and behavior primitives. It is a complete description, repeating even the ‘standard’ primitives like first and compose. Unlike a traditional VM, an AVM can be heterogeneous – i.e. different partitions types often have different primitives and asymmetric communication. Depending on the AVM’s developer, some partitions may operate at a very high level (i.e. HTML/DOM) while others operate at a very low level (FPGAs, GPUs).

Beyond primitives, an AVM may additionally include: equational laws, proposed rewrite rules, application models. An application model would describe behavior types for applications or pluggable applets, along with some English text about how it is used.

An AVM is essentially a machine processed standards document, to support evolution of the language.

In practice, there will not be many AVMs – slowly evolving standards, experimental extensions, and so on. I imagine compilers will often be specialized against an AVM (or even specific application models). But I think the AVM will be a useful concept to handle these changes over time.

The machine might or might not supply an ambient authority to resources. Personally, I’d prefer that it does not, but either way can make sense.

Representing the AVM

I plan to represent the AVM using a simple, static, standard subset of Awelon to construct a structured representation of the AVM – i.e. as a structure of static strings and numbers. I might pass in an argument, what to do with each definition after it is represented. The AVM will be an Awelon module (without imports), which should make it trivial for an Awelon programmer to work with.

When I developed the idea for an AVM, I was dreading the thought of including another parser (even if it’s for XML or JSON). I believe the approach I’m planning will prove both simpler and cleaner, especially since Awelon requires almost no parsing and has only four static types.

This isn’t a new idea. I have read that people use FORTH in a similar manner, even installing tiny FORTH interpreters in their applications to support configuration. But it is not well known, and I still find it clever.

This entry was posted in Grammars, Language Design, Modularity, Reactive Demand Programming, Types. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s