Interaction nets are an alternate model of computation (along the lines of the lambda calculus or Turing machines). It has several interesting properties, one of the most notable being that it is fundamentally parallel.
https://en.wikipedia.org/wiki/Interaction_netshttps://t6.fyi/guides/inets
The inverse operator is one of the most unusual and powerful language features. It’s not the main pitch or anything though – the main goal of the language is to explore the design space of interaction-net-based programming languages. I think there are many potential applications for interaction nets in parallel & distributed computing, among other fields; and such applications will need a language.
That is a mind-bending idea. Worth a read. My kneejerk is response is “wow that’ll be hard to reason about” but it’d be unfair to write the idea off with such little consideration.
Would there be any performance advantage to the “substract min from list” example when written with the inverse operator?
Looks like it avoids writing another loop explicitly, but it will still go through the list twice in practice. Kind of like a defer operator, but more powerful in its semantics?
The version with the inverse operator takes 948 interactions, whilst a version without it takes 1069 interactions, so there is a performance advantage.
For a list with 10000 elements the difference in the number of reduction between the two examples very closely matches 3/2, which is exactly the theoretical limit, if I analyzed the algorithm correctly.
Note that this just counts interactions, and there is a difference of parallelism between the two examples, the more optimal is actually less parallel, so the difference in time is not 3/2.
I guess the second iteration can be made parallel, as you mention in another comment. But at the cost of O(n) space to keep references to all values needing substraction?
I’ve been fascinated by interactions nets.
HVM is a massively parallel runtime, based on interaction combinators, and Bend is a language built upon HVM.
Adding Vine to my short list of projects to follow.
Can’t wait for the LKML drama in 20 years: “We won’t force you to maintain this Vine code, we will do it for you, you just have to accept it because it’s what’s trendy now”.
On a more serious note, are the languages themselves the limitation to good design and proper improvements in innovation and development? I feel that these days we see way too many programmers blame the tools instead of making the most out of them.
Programming language design is kind of just the unbelievably difficult task of tricking programmers into using formal methods tools, by presenting them in an ergonomic way that doesn’t obstruct how people are used to writing software in a given era. Necessarily each push forward rules out more and more common sources of bugs.
Couldn’t find out what interaction nets are from the docs but this seems to be the banner language feature: https://vine.dev/docs/features/inverse
Interaction nets are an alternate model of computation (along the lines of the lambda calculus or Turing machines). It has several interesting properties, one of the most notable being that it is fundamentally parallel. https://en.wikipedia.org/wiki/Interaction_nets https://t6.fyi/guides/inets
The inverse operator is one of the most unusual and powerful language features. It’s not the main pitch or anything though – the main goal of the language is to explore the design space of interaction-net-based programming languages. I think there are many potential applications for interaction nets in parallel & distributed computing, among other fields; and such applications will need a language.
For me that “inverse operator” looks like a way for having lazy evaluation in mostly eager language, as it is similar to Tardis monad.
This sounds faintly reminiscent of X, which I found fascinating as an undergraduate (a couple of decades ago!)
That is a mind-bending idea. Worth a read. My kneejerk is response is “wow that’ll be hard to reason about” but it’d be unfair to write the idea off with such little consideration.
I could be misunderstanding, but I think they’re just promises and futures, but used in a single-threaded instead of a multithreaded context.
Author here, happy to answer any questions.
Would there be any performance advantage to the “substract min from list” example when written with the inverse operator?
Looks like it avoids writing another loop explicitly, but it will still go through the list twice in practice. Kind of like a
deferoperator, but more powerful in its semantics?The version with the inverse operator takes
948interactions, whilst a version without it takes1069interactions, so there is a performance advantage.For a list with 10000 elements the difference in the number of reduction between the two examples very closely matches 3/2, which is exactly the theoretical limit, if I analyzed the algorithm correctly.
Note that this just counts interactions, and there is a difference of parallelism between the two examples, the more optimal is actually less parallel, so the difference in time is not 3/2.
I guess the second iteration can be made parallel, as you mention in another comment. But at the cost of O(n) space to keep references to all values needing substraction?
I’ve been fascinated by interactions nets. HVM is a massively parallel runtime, based on interaction combinators, and Bend is a language built upon HVM.
Adding Vine to my short list of projects to follow.
Can’t wait for the LKML drama in 20 years: “We won’t force you to maintain this Vine code, we will do it for you, you just have to accept it because it’s what’s trendy now”.
On a more serious note, are the languages themselves the limitation to good design and proper improvements in innovation and development? I feel that these days we see way too many programmers blame the tools instead of making the most out of them.
Programming language design is kind of just the unbelievably difficult task of tricking programmers into using formal methods tools, by presenting them in an ergonomic way that doesn’t obstruct how people are used to writing software in a given era. Necessarily each push forward rules out more and more common sources of bugs.
The tools are all bad and the most we can make out of them is less bad tools. It will go on like this indefinitely. This is good not bad.
Partially… Yes.
But it is not only the languages. It is the compilers and build systems. Which cannot really be separated from the language.