CosmicOS version "cosmic.0.8"

(latest version always available at CosmicOS homepage)

Estimate of message entropy in compiled form: 19.1 kB.

There are bugs and rough edges in the message. Please be forgiving. It'll all get fixed in an instant of galactic time...

The easily-human-readable source code for the message is given below. For fun, you can also look at a less readable, alien-esque form of the message, updated periodically from the compiled form of the message.

Message index
(complete message)

0    introduce numbers (in unary notation) (MATH)
1    introduce equality for unary numbers (MATH)
2    now introduce 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    show local assignment (MATH)
12    demonstrate existence of memory (MATH)
13    show mechanisms for branching (MATH)
14    illustrate pairs (MATH)
15    introduce mutable objects, and side-effects (MATH)
16    illustrate lists and some list operators (MATH)
17    describe changes to the implicit interpreter to allow new special forms (HACK)
18    introduce sugar for let (MATH)
19    build up functions of several variables (MATH)
20    show map function for applying a function across the elements of a list (MATH)
21    end of part 1, start of part 2 (NOTE)
22    show an example of recursive evaluation (MATH)
23    some pure lambda calculus definitions - optional (MATH)
24    introduce universal quantifier (MATH)
25    introduce existential quantifier (MATH)
26    introduce logical implication (MATH)
27    introduce sets and set membership (MATH)
28    introduce graph structures (MATH)
29    show how to execute a sequence of instructions (MATH)
30    introduce environment / hashmap structure (MATH)
31    introduce simple mutable structures (OBJECT)
32    introduce method handler wrappers (OBJECT)
33    introduce turing machine model (TURING)
34    introduce simple form of typing, for ease of documentation. (OBJECT)
35    an example object -- a 2D point (OBJECT)
36    an example object -- a container (OBJECT)
37    expressing inheritance (OBJECT)
38    adding a special form for classes (OBJECT)
39    wrapper class for cells (OBJECT)
40    playing around with doors and rooms (MUD)
41    some preparatory work for integrating with Java code (JAVA)
42    class translation 'COS_JavaTest' (JAVA)
43    check that automatic conversion is workable (JAVA)
44    end of part 2, start of part 3 (NOTE)
45    simulating unless gates (GATE)
46    testing alternate primer based on gates: COS_NOT circuit (GATE)
47    testing alternate primer based on gates: COS_AND circuit (GATE)
48    testing alternate primer based on gates: COS_OR circuit (GATE)
49    testing alternate primer based on gates: COS_NOR circuit (GATE)
50    testing alternate primer based on gates: COS_OSC circuit (GATE)
51    testing alternate primer based on gates: COS_SR circuit (GATE)
52    testing alternate primer based on gates: COS_D circuit (GATE)
53    probing networks of unless gates (GATE)
54    end of part 3, start of part 4 (NOTE)
55    a mechanism for referring to parts of the message (SELF)

Message visualization

message parts visualized using icons


To get a sense for how understandable the message is, it can be viewed using a set of fairly arbitrary icons. This visualization is produced for each section above, and is generated from the raw message stripped of any identifiers or comments, so no side-information leaks through (apart from some biases in the visualization itself, e.g. the left-to-right top-to-bottom flow!).

complete message visualized as raw 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.

Version notes

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 message.

Current status: Playing with integrating the Java virtual machine. Looks doable, and Java bytecode can be generated now from many languages (including Scheme). Also trying to make the core functional notation more readable. It is in transition, and some things are broken.

Functions currently introduced through examples, rather than completely defined in terms of other functions:

The generated message currently consists of a sequence of 4 symbols.

  number   symbol   meaning
    0         .     binary digit zero
    1         :     binary digit one
    2         (     marks beginning of an expression
    3         )     marks end of an expression

And two pseudo-symbols coded using the above:

  sequence  symbol   meaning
    ()         /     opens an implicit paren, which will close at next paren
                     (A B / C / D) is another way to write (A B (C (D)))
                     This greatly simplifies complex expressions.
    (())       ;     marks end of sentence

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 concepts.

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.

As a completely separate thread, I have started to integrate a presentation of unless gates.

homepage  -  of  -  Paul  -  Fitzpatrick