Is Libretto anyhow related to "interaction nets" and / or the Hume language?

[MateuszKowalewski]

I've seen the implementation of "interaction nets" in Libretto.

But would this also work the other way around? Implementing Libretto in terms of "interaction nets"?

This would open up the way to high performance asynchronous runtimes:

https://github.com/inpla/inpla

https://github.com/HigherOrderCO/HVM

Also Libretto reminded me somehow about the Hume language.

In both cases would be nice to learn more about the differences and similarities to Libretto.

I guess this would be also a nice to have in the docs! Some more comparison with similar approaches.

[TomasMikula]

Implementing Libretto in terms of "interaction nets"?

This would open up the way to high performance asynchronous runtimes:

https://github.com/inpla/inpla

https://github.com/HigherOrderCO/HVM

Implementing racing would require the non-deterministic extension of interaction nets. I don't see any mention of non-determinism in either of the linked projects (their front pages, that is).

With non-deterministic extension in place, I tend to say "surely we could do that," because I don't see why not.

Though my intuition is that any translation of Libretto to Interaction Nets will inevitably include elaboration of Libretto to a lower-level intermediate representation, which can then more readily be translated to Interaction Nets.

Why the need for intermediate representation?
Representation of Libretto programs is full of polymorphic constructs like

case class Par[A1, A2, B1, B2](
  f1: A1 -⚬ B1, 
  f2: A2 -⚬ B2,
) extends ((A1 ⊗ A2) -⚬ (B1 ⊗ B2))

This tells you that the Par construct has 4 groups of unconnected wires (A1, A2, B1, B2), but you have no idea what's inside the groups, until you also work out the internals of f1 and f2. In other words, just by seeing the Par constructor, you have no Interaction Net code to output. The Libretto representation is not low-level enough for that. I would even say that Libretto representation is not local enough.

Aside: In the current Libretto implementation, elaborating those abstract ports to concrete ports (like Done or Val[A]) is interleaved with execution (and thus comes with a runtime cost).

Also Libretto reminded me somehow about the Hume language.

In both cases would be nice to learn more about the differences and similarities to Libretto.

I guess this would be also a nice to have in the docs! Some more comparison with similar approaches.

On a high level, Libretto and Interaction Nets are similar:

• rejection of non-local operations (like substitution in λ-calculus, incl. arbitrary copying of values);
• naturally concurrent;
• Libretto ports, just like wires in Interaction Nets, are "one-shot", i.e. they disappear (or morph) after the interaction takes place;
• execution semantics can be given by local rewrite rules.

I would say programming in Libretto is more high-level, and composing Libretto programs is more like composing functions. (YMMV)
Interaction Nets, OTOH, even more faithfully adhere to locality (see the comment above). That is something that can be a source of inspiration for a better Libretto runtime.

I don't really know about the Hume language. I can comment once I educate myself, or you can do that once you get more intuition about Libretto 😉

[MateuszKowalewski]

Great, thanks a lot for the explanations! That was a fruitful question. 😄

Why I asked: I also see that Libretto is a kind of high-level language. It will need some form of a compiler at some point. (Actually the current runtime / interpreter is already half a compiler, as I understand.)

The mentioned runtimes are on the other hand side very low level. They try to build something I would call "machine language for FP programs".

The rest is likely obvious: Bring the high-level language to the low-level runtime…

It seems that interaction nets can be implemented in a maximally efficient way.

The current Libretto runtime is contrary to that more a prove of concept, as I see it. It's good to develop the language, but nothing you would like to use in production, I guess (alone for performance reasons; also it seems a little bit flacky; which isn't a problem for a prove of concept, but would be one in prod).