Turning EMU Turing Complete

This article deals with EMU. To try it out follow this link and click “skip” at the login screen.

With EMU I wanted to merge what you can do in spreadsheet with what you can do in an ordinary text editor.

The embedded language in EMU is designed to have a familiar syntax (JavaScript/C-like) and be immediately useful when comes to basic calculations and calling external functions for task such as creating a graph.

Putting something in tuborgs { } in an EMU-document creates a “slot” and inside that you can put a piece of code that looks a lot like a basic piece of JavaScript. If the expression contains any calculation the output is printed right after the slot. Ie.: { 2 + 3 } = 5.

Simply putting JavaScript in the slot would have a number of problems. First the user would be able to break the page (calling alert(...) etc.), secondly JavaScript is a language with side-effects and state making it work quite differently from what one is used to from a spreadsheet. Writing a = a + 1 is perfectly valid and meaningful JavaScript whereas it would make no sense in a spreadsheet.

In the earlier versions of EMU the language allowed just simple mathematical expressions over numbers, list and maps. But in the later versions the language has evolved into a fully-fledged language.

“Fully-fledged” means a number of things. As features such as control structures and recursive functions are introduced the language becomes “Turing complete” meaning that it is able to encode any computational problem, it also may loop forever without any way of detecting that.

It also means that the language has to become “coherent” (I cannot think of a better word). In sense that you as programmer should be able to fully access the structures you are working with. Eg. when you have a map; it should be possible to get the keys of that map and it should access an element of that map with a non-hardcoded index.

It sounds obvious but as soon as you start fiddle about with things you realise that having a map like {a: 2} requires you to have a string type (as strings are the key in the map), a null value (default value of items not present in the structure) and support functions for taking the keys or the values out of the map as lists.

It also gives you a lot of understanding of the various design choices done in languages such as JavaScript; there are languages within the functional space that seem to have simpler and more consistent designs but they often give up programmer usuability and familiarity for a more abstract syntax.

The language in EMU as this time (june 2016) looks as follows:

JavaScript-like syntax with R-like algebra and utilities

You can define a map as you would in JavaScript and call a built-in function to sum its values:

{fruits = { banana: 5, apple: 3, lemon: 6 }}
{sum(fruits)} = 14

Define another containing the weights and mutiply that with fruits:

{weights = { banana: 100, apple: 200, lemon: 75}}
{weights * fruits} = { banana: 500, apple: 600, lemon: 450}}
{sum(_)} = 1,550

Where underscore is a language primitive that gives you the value of the previous slot.

Unlike its JavaScript and R counterparts EMU is strictly without side-effects and is lazy evaluated. Meaning you can write the about in any order.

The EMU editor will show the results of the evaluations (in green) as you type.

Functions, ranges and control structures

EMU has first-order functions defined via the arrow syntax, if/then/else via the JS-style question marks, ranges via ... (as in Swift):

{factorial = n -> n > 1 ? factorial(n-1) * n : 1}
{map(factorial, 1...4)} = [1, 2, 6, 24]

Map along with filter and reduce are functions in the standard library.