I was hoping to catch this on Jitsi but got called away

There wouldn't happen to be a recording of your livecoding, by any chance?

@neauoire @alderwick
And as they say in cooking shows: "here is a version of the language that I prepared earlier"

https://blindedcyclops.neocities.org/cat22/cat22

(mind you, it's still full of typos and probably bugs too, and the interface is currently very weird)

I will probably keep tinkering with the language, despite starting it mainly as a personal challenge, because it turned out to be too much fun to play with!

@neauoire Oh thank you so much for the links!

I love the “[something] ?heads; tails;” representation of branching!

In early Uxn development we had a conditional flag “?”, but we could only apply it to primitives. It saw a lot of use with what was our RETURN and JUMP opcodes, but it was hard to see the use of something like “ADD?” or “MUL?” since the stack depth might have changed but execution carried on in the same place.

So it's really nice to see it work well!

@alderwick @neauoire Well, honestly, cat-22 also mainly uses it in the equivalent of JUMP and RETURN instructions - it's just that the wide opcodes make jumps implicit (any value larger than built-in primitive opcode is a jump address), and the use of an encoded return flag removes the separate opcode for it.

> it was hard to see the use of something like “ADD?” or “MUL?”

Wouldn't that have been the equivalent of a single-instruction jump though? Or was the conditional flag non-consuming?

@neauoire This is much more like assembly than FORTH, so with the conditional flag it would either execute the opcode or not. After a “MUL?” instruction we would have the following stack changes:

2 7 1 → 14
2 7 0 → 2 7

I analysed our assembly code and “[address] [true/false] JUMP? POP” came up everywhere, because we didn't need the jump address after an unsuccessful test and it wasn't automatically popped. So we switched to a new opcode for conditional jump and repurposed the flag.

@alderwick @neauoire aaaah, I forgot that uxn uses the *the stack* to determine the address to jump to! That was the missing bit of context. Yes, I see your point now.

I assume that consuming the address regardless of true/false condition introduced other issues?