Introduction

sUTL stands for the sUTL Universal Transform Language. It's one of those annoying recursive acronyms.

sUTL is a language for transforming JSON from one shape to another. In mathematical terms, it looks like this:

where source, transform and result are JSON data structures.

A transform is a lot like a function in other languages. 

Say I want to reverse the order of an array. In javascript I could write it like this:

The same thing in sUTL, written the same way, is this:

That's pretty long. It uses an "if" transform, and recursion.

A better way to write reverse in sUTL is to use "reduce":

The takeaway here is that when you see discussion of transforms, you can think "function" and that's about the right idea.

So why not call them functions? Because they're a bit different. Functions in a language like javascript use imperative code to build up a result to return. With a sUTL transform you specify the result you want in a declarative single step (where that step can be arbitrarily complex). A sUTL transform is much more like a powerful relative of a mustache template than it is like a javascript function. You could call mustache templates "functions", because technically they are, but it's not a good practical way to talk about them. Similarly with sUTL transforms.

Domain Specific Language

A domain specific language (DSL) is not supposed to be general purpose; it is for one specific type of job. Regular expressions, templating languages, and SQL are examples of DSLs, and so is sUTL. Regexes are for operating on text, templating languages transform a JSON data structure to a string (often html), SQL is for querying databases, and sUTL transforms a JSON data structure to another JSON data structure.

Guest Language

sUTL's reason for being is to allow declarative transformation of JSON data structures in other languages.

JSON data structures are fairly universally available in general purpose languages, and are particularly native in dynamic languages. Transforming this sort of data is a job that needs doing in all these languages.

sUTL is designed to live inside other languages, and to be used for data transformation jobs. It saves you from writing nasty imperative code, which has to pick through incoming data and building something out of it.

The idea is that you include the sUTL interpreter (written in the host language), and your sUTL declarations (these are sUTL transforms with some enclosing declaration info), and use sUTL to transform JSON data structures rather than the host language. This is just like you might use regexes (including a host language regex interpreter) when you need to parse text. 

As part of being a guest language, sUTL is a small language by design. It only has a small set of primitives, and so is easy to build an interpreter for, and the resulting interpreter sits lightly inside host language programs. 

Turing Complete

Unlike many DSLs, sUTL is turing complete. That is, it has the same theoretical power as all the general purpose programming languages. It is a fairly remote dialect of LISP.

Not imperative, immutable data

sUTL is not an imperative language. If it had functions, you might call it a pure functional language with immutable data structures. As it is made of transforms rather than functions, we could call it a pure transform language, which would be a useless thing to say!

You could squint and call sUTL a declaration language. A transform is a declaration of the result you want. It's not imperative, so you could call it declarative. However, that's a bit of a cheat. You really are programming when you write sUTL in a way that you are not when you write SQL. 

No Side Effects

sUTL is side-effect free. 

A sUTL transform is like a function (as discussed above); you pass in input (the "source") and get back output (the "result"). More general purpose languages like C or Javascript allow side-effects; things could happen inside a function like mutating globally scoped data, updating a database, or fetching a url.  sUTL is only for transforming JSON data structures, and cannot create side-effects. If you need side-effects, do them in the calling code.

This makes sUTL transforms very testable because they are deterministic; if you pass the same input you will get the same output.

Next: Simple Transforms