[TeMPOraL]

ASTs are, as the name suggests, trees. There are useful concepts you can't express directly in source code of most programming languages. For example, while you can express a function reducing results of other functions directly:

  f(a(), b())

you generally can't do the reverse. Not directly. Best you can do it:

  foo = f()
  a(foo)
  b(foo)

where you create a runtime indirection, or - in a language with reader macros, like Common Lisp:

  (a #1=(f) #1#)

where #1= lets you reference an AST node, and #1# lets you backlink to it. Unfortunately, that code will cause (f) to be called twice.

The article is effectively exploring a way to combine these two methods - to have the code denote a DAG directly (or even cheat a little and denote a graph with cycles), where the runtime representation is also a graph, and not a tree.

Myself, I'm strongly hoping there will be more work done in that direction, because being forced to talk in trees is very limiting. Some problems would be much easier to express as DAGs (or even cyclic graphs), and would even be easier to read them as such.

I worry that what's keeping us working with trees is the nature of plaintext itself. I haven't proven it, or seen it proven, but I strongly suspect that there is no minimal, direct representation of a DAG possible in plaintext - you can't move past a tree without assigning labels for backreferences.

[yvdriess]

SISAL was a language that parsed to a dataflow intermediate representation (IF1). IF1 would then be compiled to native instructions for either a regular (e.g. Cray) or dataflow architecture processor.

IIRC, function composition with multiple return values is sufficient to transform to IF1's 'function with named ports' representation.

https://en.wikipedia.org/wiki/SISAL