Live data from Hacker News

Vine: A programming language based on Interaction Nets

vine.dev

31–40 of 51 posts

Re: Vine: A programming language based on Interaction Nets

#31
post #3

"This function calculates the minimum of a list of numbers, and subtracts every number in the list by that minimum. This function currently iterates over the list twice; once to calculate the minimum, and once to do the subtraction. At a first glance, it looks like there is no way to merge these two loops, because you need to calculate the minimum of all the numbers before you can subtract from any of them. As it tur…

Reading this page made me feel same way when was watching Tenet.

Re: Vine: A programming language based on Interaction Nets

#33
post #13

It starts off looking like a slightly modified Rust until about half way through where it gets real weird. It’s burying the lede… why not open with what interaction nets are and why you’re building them into a programming language? Made my head hurt a bit, it’s odd that it doesn’t really attempt to contextualise if the weirdness is for its own sake or some greater practical purpose. Always fun to find a novel way to…

Yeah I don't know enough rust to know what's special here. Presumably the inverse backwards part. I retain that every project (language, application, etc) should start with what it is, what it looks like (code or screenshot as appropriate), and why it matters. This felt very implicit in that.

And, I'm still not sure how that wacky stuff gets compiled down. It looks like syntax sugar as a language.

Re: Vine: A programming language based on Interaction Nets

#37
post #12
post #8

Earlier quoted context omitted.

What are the differences with HVM?

There are many. One major difference is that HVM/Bend focus entirely on functional programming, whereas Vine supports both imperative and functional patterns, in a cohesive manner.

But that's just about how things look in the higher level language, right? Implementation wise, it's still interaction nets, so...?

I'm interested in a wider comparison, and understanding why you didn't go with HVM, especially as the low-level runtime.

Re: Vine: A programming language based on Interaction Nets

#38
post #34
post #5

Author here, happy to answer any questions.

I would love a better explanation for `~~x = x`. I first understood `~x` as an equivalent of an unresolved future. Would one be able to model `~x` with, say, Rust channels?

In interaction nets, one of the core primitives is the 'wire', which form the edges in the graph. One can think of a wire as like a one-shot channel; it has a 'producer' side, which sends some value across, and a 'consumer' side, which does something with that value.

In that context, then, the inverse operator switches which side of the wire you're talking about. If you have a parameter of type `N32`, you're on the 'consumer side'. But if you have a parameter of type `~N32`, that can be viewed as being the 'producer side' of an `N32` channel. Since `~` just swaps the sides, `~~T` is the same as `T`.

Re: Vine: A programming language based on Interaction Nets

#39
post #12

Earlier quoted context omitted.

There are many. One major difference is that HVM/Bend focus entirely on functional programming, whereas Vine supports both imperative and functional patterns, in a cohesive manner.

But that's just about how things look in the higher level language, right? Implementation wise, it's still interaction nets, so...? I'm interested in a wider comparison, and understanding why you didn't go with HVM, especially as the low-level runtime.

Well, there have been several iterations of HVM, each extremely different from the last.

IVM is architecturally similar to HVM-64 (which I was the lead developer of). The most major difference is how they handle IO. IVM uses its extrinsic system, where all side effects are mediated through an IO handle, which provides a number of useful properties, and is greatly simpler to implement / use. Interactions with side effects are small and low-cost, and can happen in parallel with the rest of the program.

HVM-64 had built-in net definitions that had side-effects when expanded, which was very messy to use in practice. HVM2 has a monadic IO interface, which requires stopping the whole program on every single IO call. (And also requires writing things monadically.)

Using extrinsics for IO handles in IVM creates a very nice API for IO in Vine; side-effect-ful functions simply take a mutable reference to the IO handle. It's also very easy to support multiple 'threads' of parallel IO effects – simply duplicate the IO handles.

Post reply on HN