CosmicOS version "cosmic.0.5"
(latest version always available at CosmicOS homepage)
The high-level structure of the message is as follows. There are some
basic preliminaries (enumerating numbers etc) to introduce the
low-level syntax and semantics of the message. This is followed by
many examples of relational operators and basic functional notation.
Once a sufficient set of operators is avalailable, most new concepts
are introduced both by examples and a definition in terms of what is
The message consists of a sequence of statements that can be
evaluated, and each statement evaluates to true. The message can
refer to its own syntax, and a statement can change that syntax. Thus
the form of the message changes over its course, with the introduction
of shorthand forms, object-oriented notation, etc.
The goal of current work on the message is to bring it to a point
where it is easy to write statements about a MUD (a simulated world
consisting of (things that act like) locations, movable objects, and
people). This MUD will be used to communicate Freudenthal-style
The advantage of using a programming-code-like language is that
the reader can play with hypothethicals at any time, and
experiment to evaluate alternative statements that are not in the
Current status: just reached the MUD -- keep needing to go back and
put in new infrastructure. Lots of rough spots in the message to
smooth over. An automatic checker is now in place, to make sure the
message is consistent, when interpreted as code. This flushes out a
lot of bugs.
(more version notes at bottom of this page)
Estimate of message entropy in final form: 9.6 kB.
|0 || || introduce numbers (in unary notation) || (MATH) |
|1 || || now show equality || (MATH) |
|2 || || now show other relational operators || (MATH) |
|3 || || introduce the NOT logical operator || (MATH) |
|4 || || introduce the AND logical operator || (MATH) |
|5 || || introduce the OR logical operator || (MATH) |
|6 || || use equality for truth values || (MATH) |
|7 || || introduce addition || (MATH) |
|8 || || introduce subtraction || (MATH) |
|9 || || introduce multiplication || (MATH) |
|10 || || introduce a simple form of binary notation || (MATH) |
|11 || || demonstrate idea of leaving gaps in an expression || (MATH) |
|12 || || show some simple function calls || (MATH) |
|13 || || show mechanisms for branching || (MATH) |
|14 || || some pure lambda calculus definitions - optional || (MATH) |
|15 || || show an example of recursive evaluation || (MATH) |
|16 || || introduce universal quantifier || (MATH) |
|17 || || introduce existential quantifier || (MATH) |
|18 || || introduce logical implication || (MATH) |
|19 || || illustrate lists and some list operators || (MATH) |
|20 || || - intro to cons, car, cdr || (MISSING) |
|21 || || describe changes to the implicit interpreter to allow new special forms || (HACK) |
|22 || || introduce sugar for let || (MATH) |
|23 || || build up functions of several variables || (MATH) |
|24 || || show map function for applying a function across the elements of a list || (MATH) |
|25 || || introduce mutable objects, and side-effects || (MATH) |
|26 || || show how to execute a sequence of instructions || (MATH) |
|27 || || introduce environment/hashmap structure || (MATH) |
|28 || || introduce simple mutable structures || (OBJECT) |
|29 || || introduce method handler wrappers || (OBJECT) |
|30 || || introduce turing machine model || (TURING) |
|31 || || introduce sets and set membership || (MATH) |
|32 || || introduce graph structures || (MATH) |
|33 || || introduce simple form of typing, for ease of documentation. || (OBJECT) |
|34 || || an example object -- a 2D point || (OBJECT) |
|35 || || an example object -- a container || (OBJECT) |
|36 || || expressing inheritance || (OBJECT) |
|37 || || adding a special form for classes || (OBJECT) |
|38 || || wrapper class for cells || (OBJECT) |
|39 || || playing around with doors and rooms || (MUD) |
message visualized as image|
The image reads diagonally, starting at the top left. It is handy for
spotting phase changes in the message (e.g. the transition from using
unary to binary, or - more importantly - bugs). Breaks
between statements are white dots, zeros are greenish, ones are
reddish, parentheses are different shades of blue.
The generated message currently consists of a sequence of 5 symbols.
number symbol meaning
0 . binary digit zero
1 : binary digit one
2 ( marks beginning of an expression
3 ) marks end of an expression
4 ; marks end of sentence
There are constraints in the possible transitions between these
symbols that would allow a simple and shorter encoding if desired.
Numbers are encoded as binary digits between parentheses, e.g. (:::.)
is 1110 base 2 which is 14 in decimal. A set of numbers between
parentheses constitutes an expression. Expressions can be nested.
Expressions followed by a semicolon should evaluate to be true, once
the rules for evaluation have been introduced.
In the human-readable form of the message, decimal numbers can be
used. There are converted to the above form. Identifiers can also be
used. Identifiers are mapped onto arbitrarily assigned numbers.
In the message, there is nothing to distinguish identifiers from
numbers. The actual language is carefully constructed so that
this distinction is never necessary.
The first number in an expression is treated as an index
into an environment that returns a function. When
the lambda notation is introduced, it works by modifying
that (nested) environment. Expressions are evaluated
from the outermost inwards, from left to right, and
the "if" form is introduced as lazy.
This "functional style" of expression is not always particularly easy
to follow, even for a human, but it is certainly very expressive.
Currently functional definitions are given alongside numerous examples
that are in many cases sufficient by themselves to communicate the
definition, at least for working purposes. It is probably important
to maintain this duality and perhaps extend it with other forms
of expression. There are so many models of computation, why not
use all of them? Perhaps one will be easier for the reader to follow
than the others.
While it is tempting to try to make the message airtight from a
formal point of view, defining everything in terms of axioms,
this is just one didactic approach - and may be counter-productive
or impossible for a a large-scale message that includes AI-complete
Currently there is a conflict between using definitions of functions
that are easy to communicate, and definitions that are efficient (or
external). This will require some more thought. For example, it
would be nice to introduce "if" in its pure lambda calculus form, but
to do so would slow checking down right now. The "if" function is
instead built in, and (to add insult to injury) introduced with lazy
evaluation. It would be more consistent to keep everything eager to
begin with, and then show the evaluator being rewritten to facilitate
laziness -- easy using the standard trick of wrapping conditional
expressions in single-argument functions.
There are going to be bugs in the message -- it is being cobbled
together quite hastily. Please be forgiving. It'll all get fixed in
an instant of galactic time...