Utena: A system to fulfil my desire for maximalist computing

Table of Contents

1 Introduction

1.1 Philosophy

Utena is a system that wants to empower an individual developer to achieve as much as possible with as little effort as possible. This is what we mean by `empowerment'. Examples would be program generation, introspection, meta-media, tracing garbage collection, and interactive debugging. This is not the same as dangerous and downright unsafe capabilities that could be considered to be `empowering', such as access to raw memory.

This is because we believe that empowering individual developers to have more leverage and do more things with their system that otherwise would not be possible means that they are able to empower other poeple to do the same who are not necessarily programmers. This is a necessary step to break the hierarchy between producers and consumers of software.

We use the term `Maximalism' because we want to express more with less and distance ourselves from those who seek to express less with less, which to us is the result of minimalist protocols such as Gemini.

1.2 Context

As part of my bachelor's degree I produced a project in order to be assessed on independent learning. In this project I prototyped a virtual machine using Common Lisp, exploring some of the principles I have discussed in this document and developing my ideas. This project was completed before this document and during production of Software & Anarchy.

I recommend that you read the rest of this page, but the report for this project can be read here. Some of the discussion in the report is present for efficient grade scoring and can be skipped.

1.3 A note on the writing

This is a document that is a work in progress, I'm not sure of all of the decisions here and there are some things I do not know about.

As of writing it's more like general notes than anything else. For context and general understanding behind where these ideas came from i recommend you read the bachelor's project report.

2 The Principles

2.1 The Message Send Meta-Medium

At the basis of the environment there is just one single notion, the message send to an object.

The semantics of a message send are controlled by two abstractions, message lookup and message evaluation. These two abstractions can be controlled in the environment by introducing new message reciever objects and slot descriptions.

2.2 Transparent modularity

Utena specifies bytecode should allow for wholly transparent message sends. Byte-code operations should only work to enable the message send, any further semantics must be implemented with messages and objects1. This is to say that the primitives provided with an implementation are wholly transparent, using names that are late bound just like any other client message send2.

2.2.1 Further needs not yet explored

  • There is a need for the concept of a protocol or interface needs to be present to enable automatic protocol inference and efficient proxying (by efficient we mean in terms of labour, not performance).
  • A mechanism to introduce access control and scoping, message selectors are also capabilities. This needs to be considered closely with the protocol work.
  • There should be a distinction between objects that are sealed and mutable, are transportable via serialization or must be proxied.

2.3 Asynchrnous programming

We want all programs to be written in direct style, without adding function colour like async/await. Any solution must also consider interactive condition handling. We're still unsure of how to achieve this, but currently a good solution would be using one shot continuations and green threads, directing all IO through a cooperative scheduler.

2.4 Syntax and language

The environment should be syntax agnostic provided that they follow the same semantics provided by the platform VM but just don't expect to be able to write Rust, Python or your favourite language because they can not operate with the semantics we have discussed. This doesn't mean to say you cannot take what you like about them, provided there are no fundamental incompatibilities, and create a new language. We think JavaScript for instance is a relatively close neighbour that could have an Utena derivative (it would not be JavaScript though).

Footnotes:

1

In the report I say that reset and escape are byte-codes and that was just because I was being lazy, I see no reason why they cannot be implemented via some sort of activation record management messages or mirrors.

2

The reason for this is so we will have a syntax agnostic representation of our programs that can be trustlessly transported between nodes, the dependencies of which are therefor not coupled to the program and there is no ambient authority.