Notes on a new interpreted language

notes.txt

I have been thinking recently about a set of features that might be
interesting for an interpreted language. Largely I am uninterested in the
syntax for now, just the properties of the language and implementation.


1. Actor model similar to erlang with total isolation of actors except
via message passing. Crashing one actor does not affect other actors
unless they want to be affected.

2. Mutability within an actor, but only immutable objects can be passed
between actors. Or mutable objects can be transferred but a runtime
error occurs on accessing a mutable structure after it has been 'moved'.

3. Embrace the unix security model. Actors can be local to the vm or forked actors
with a different pid and user id. Actors could embrace OS level privsep
code, perhaps integrate the language with OS level jails/containers. Make
writing privsepped code a first class citizen of the language...

4. Object/actor capability system. If you do no have an unforgeable
reference to an actor, you cannot message it. See pony for
inspiration. All OS/runtime functionality is controlled by actors, hence
sandboxing code is as simple as not passing references to the relevant
actors to the sandboxed actor.

5. The actors in a different process can be remote or local. spawn an actor over
an ssh link then send it a reference to an open file actor.
Perhaps the runtime needs some smart routing to get messages
to distant actors, especially in the presence of a tree of unix
processes. I think this is slightly different to erlang which has a
notion of 'nodes', and no security isolation or tree structure.

6. Unreachable actors can be garbage collected. This might not be well
thought out or possible.

7. Runtime resource limits can be put on individual actors, or groups
of actors. Be able to say - "This http server actor (tree) cannot use
more than N resources" which is imposed at runtime.

8. Erlang style supervisors should be possible via links.

9. Live code reloading. Code changes are propagated down the process tree.

Some of these are already possible with erlang, but I think some of it
would be a unique combination. Let me know if any of this is new, good,
bad or impossible.

Misc:

Remote messages may need to be unforgeable using cryptography. This can be accomplished by giving each actor
a secret or pub/private, and  messaged recieved must be HMACED/signed. local actors can trust the runtime
that the actor id hasn't been faked for performance, Pony accomplishes this with memory safety.

Examples for the imagination:

Spawning a privsepped remote actor, and getting it to write a file:

write_file(file) {
	// the remote actor can ONLY write to this file, thats all it has a reference to.
	// The chroot and remote message signing add security from runtime exploits.
	file.write("hello from remote actor!")	
	file.close()
}

main(world) {
	// world, remote_world, and file are all references to actors.

	file = world.open("/local/file.txt")
	remote_world = world.spawn_world(host="remote@distant.com", chroot="/jail/")
	remote_actor = remote_world.spawn(write_file, file)
	remote_actor.wait_for_exit()
	// Prints "hello from remote actor!"
	world.print(world.readfile("/local/file.txt""))
}

Perhaps we could send a handle for the current world to the remote world!

Have you seen Monte yet? http://monte.readthedocs.io/en/latest/

I hadn't actually, thanks for pointing it out :)