The day to day work of a developer is, of course, editing and testing code. In the world of ARGON, code is found inside entities. Some of it is stored privately inside the entity, either as handlers for events impinging upon the entity or as modules shared between the handlers; but most code is in modules published from entities.


Most entities share a common behaviour, and just have their own state. In that case, the handlers will be trivial stubs that just run code from a published module somewhere. That module will usually be published from a "template entity" which also provides a pre-packaged template from which people can instantiate new entities, with an initial state and handlers plumbed into the correct behaviour.

But some entities have significant amounts of private code in them, because they are truly intended as one-offs, or to enable them to run independently of published modules.

Either way, ARGON code lives inside entities, and is event-driven: procedures written to handle specific events. One never writes daemon code that sits there blocked waiting for something to happen; one never writes startup and shutdown event handlers that prepare "running state", as all state that persists between handlers is managed by the system. Different handlers for the same entity might be running at once on different nodes, and the system will handle distributed persistence, load balancing, and the like.


So much of a programmer's time will be spent interacting with entities through an administrative interface that lets one edit their contents. That lets you edit source code modules, as well as editing the state of entities to diagnose problems. Debugging will largely consist of creating a test instance of the entity template and attaching to its debug interface. When an entity is in debug mode, all handlers that are invoked on it appear in your debugging interface with an interface that lets you single-step through them, examining their state as you go, or letting it run until it hits a breakpoint, logging chosen kinds of activity (reads or writes of the persistent state, requests to other entities, etc) as it runs.

Persistent State

The persistent state inside entities is represented rather unconventionally; it's a set of tuples making statements about relationships between objects, in a manner familiar to Prolog programmers or people who've used RDF. All access is transactional; if your handler fails with an uncaught error, then all its state updates are rolled back automatically. If it succeeds, its consequences happen atomically from all perspectives. Within a group of connected nodes, all the transactions will seem to commit in the same order, but in the event of a link failure causing a network split, this won't always be the case; however, you always end up with the same eventual state and the set-of-tuples data model encourages a style of programming that makes this work out fine.

The language

ARGON supports using multiple different programming languages for handlers, but the default one is called CHROME. It's a purely functional language, but with uniqueness typing to manage mutation-esque operations in the manner of Concurrent Clean.

Largely, handlers are functions mapping the current state of the system and the details of the event being handled to a new state for the system. Operations on the state of the system would include reading and writing entity state, communicating with other entities (which includes, through gateways, communication with the Outside World of HTTP and such familiar protocols), and sending back a response to the event if one is needed.

Embedded development

There is one exception to the rule that all code lives within entity handlers. It's possible to write code that runs directly "in the kernel", which is useful for extending ARGON itself, or writing device drivers, or real-time tasks that have to respond to events within a bounded time interval too small and strict to allow disk access and competing with other handlers to get involved, or when writing code for minimal ARGON nodes that don't have the infrastructure required to host proper entities.

However, in such cases, your code is still edited inside an entity. But in this case you'll be telling the "node entity" representing the computer that's intended to run it to load it from the published module you're writing it in, and the debugger's a lot more primitive...