Oct 10, 2026, 2:09 AM…and if I could go COMPLETELY off the deep end…
- Add the special syntax : where symbol:symbol is implicitly (symbol symbol). This would allow the clearer:
10:i32 40:i32 i32.add
- Have mild type inference on the instructions. Why not? Allow either of
10:i32 40:i32 add
or
10 40 i32.add
There's only one instruction that fits the constants in the former example, and only one interpretation of the literals that fits the instruction in the latter example.
Oct 10, 2026, 2:09 AM…I could implement all of this if I wanted. Maybe I will, if I wind up in a situation I'm ever writing textual wasm in the future. Which may not actually be likely come to think of it.
Oct 10, 2026, 2:40 AMEssentially the goal above is that I view the "forward, then backward, then forward again, then also sometimes forward within the backward" structure of wast fundamentally confusing ( https://mastodon.social/@mcc/117386721892679996 ) and I don't think it adds anything. When I saw it described I was like "oh that's SMART" but when I tried to use it it was just frustrating. I'm trying to recover the spirit of what they were *trying* to do without actively fighting the spirit of a stack language.
Oct 10, 2026, 4:16 AM@mcc Yeah it's very odd. FORTH is a thing that has existed for a long time, and brains take maybe 10 minutes to get used to reading it fluently. And as you say - unambiguous. This just seems like a mess.
Oct 10, 2026, 4:21 AM@TomF i find forth hard to adjust to, but— in order to write WAST, you have to adjust to it? so once you've adjusted to it, why go back and forth? maybe the person on the standards committee who got the LISP mode in actually does write WAST code where all stackiness is done via "unrolling". but, i found myself writing code like
global.get $var ;; return value
local.tee $v2
global.get $var
i32.mul
local.get $v2
i32.add
global.set $var
;; end of function
you can't LISP that!!