You have to get a bit creative to make it ergonomic, like integrate support for timelines to schedule effects a bit more easily than with "Sequence" nodes, but it's pretty nice to only have to deal with one kind of wire.

You can represent execution order algebraically using an "Effects" data type. Nodes that would normally have control flow inputs and outputs produce a value of type "Effects" instead. You can combine effects coming from different nodes into one by using a "Sequence" node.

I really like this article about how the dichotomy between data flow and control flow can make visual scripting systems less composable johnaustin.io/articles/202...

I got your book the other day btw, really excited to get into it, love your work :)

So when breaking into a c function that invokes lua you'd be able to step through the lua call stack instead of the interpreter internals

I've been wondering... Is there a way to make a dwarf file that's capable of running arbitrary code in the target process to synthesize stack frames for a scripting language called from c e.g. lua? Something that would work in stock gdb, even if it relies on horrible hacks ^^"

I want to add match statements, for loops, and iterators next, and re-work some internal details. I'll share more once Rukt feels as cohesive and productive as regular Rust :)

ps: loving the recent podcasts with James btw, it's actually inspiring me to make Rukt applicable for a bunch of use cases

I'm still iterating but there's a couple interesting features already in place, most notably the ability to work with arbitrary token trees as first-class language items, export them across crate boundaries, and splice them anywhere in regular rust code!

the way I've worked around this problem is by using a sort of continuation passing style, and I'm currently building a minimal token-based scripting language backed by macro_rules to make this pattern easier to work with. still wip but you might find it interesting docs.rs/rukt/latest/...