• Designed a mathematically pure, graph-based intermediate representation for abstract computation.
• Designed and implemented a text-based front-end targeting the graph-based representation.
• Created a matrix-vector based graph runtime enabling parallel execution.
• Built a visually rendered, non-textual programming interface.
• Testing an NDFSM optimizer that uses reinforcement learning to navigate an incomputable search space.

Philosophy

The design of Molten is summarized in axioms:

• All theoretical computation consists of transitions between graphs.
• All optimization is about leveraging time, data, and dependency symmetries between function map spaces.
• All contractual behavior should be visible and extendable.
• Hardware, software, and data are unified.
• Machines will overtake humans as program generators.

The validity of these axioms is predicated on the results of the development of the Molten Rust compiler and subsequent Molten Molten compiler.

Motivation

While my personal motivation is less about "how to make languages better," Molten does address specific problems. Existing languages have the following theoretically undesirable features:

• Do not separate platform details and compute details.
• Target basic mathematical operators or hardware intrinsics instead of computing with pure transitions.
• Assume serialized execution ordering by default.
• Have a memory model.
• Have implicit computational contracts.
• Have metaprogramming as a second class feature; often expressed differently than the core language.
• Human opinion cannot be unified.

With that in mind, consider this Turing Machine implemented in Molten, capable of simulating all computable functions.

                      [False] (Boolean),
                      [True] (Boolean),
                      [Not.Boolean] (
                          [True] (False),
                          [False] (True),
                      ),
                      [And.Boolean.Boolean] (
                          [True.True] (True),
                          [False.Boolean] (False),
                      ),
                      [Or.Boolean.Boolean] (
                          [True.Boolean] (True),
                          [False.False] (False),
                      ),
                  

The expression, in this case has only 5 semantic features.

• [] []: indicates a bi-directional transition. You are free to translate back and forth, these are isomorphisms.
• [] (): indicates a forward directional transition from [] to (). You can only move forward using this rule, these are relations.
• ,: indicates a partion. These separate statements which are independent from one another in the program. These can be executed in parallel, or speculated on, sometimes called orthogonality. They also prevent relation constructions between defined to be unrelated features, though program analysis is allowed to disprove these assumptions and optimize.
• .: indicates a conceptual partion. These separate statements which are independent from one another, but are grouped together into a graph. These are stacked to define constraints, seldom used in file systems, but we prefer to call it attributes.
• All other characters. These are either styling information, or depending on context, execution labels. For example, And is a label defined, and when grouped with Boolean.Boolean maps to an operator scope, as seen in the program.

A key idea is that there is no order for program control flow. It is only explicitly ordered based upon the relations in the program, which are user defined. Further, if a program has some constraints grouped with . or , there is no contract defined about the order in which the evaluation may take place. We will expand on this later.

With this, we have defined a non-deterministic finite state machine; and provided a framework for abstraction layer communication which allows for contracts to be built on top of one another. In addition, we've unified human and computer program interpretability. We can now design other ways to express these semantics, like in a graphical programming language (the next desire.).

As it's developed, I encourage those who are interested to checkout the project at Vantle. It's still unreleased, so links may be broken and a playground isn't available yet, but send me an email if you want to setup a time to talk!