There was a wasm predecessor (by, well, me) with a bit more of the Forth flavor: https://github.com/darius/idel

From >20 years ago and my main regret is a failure to carry it through to be more than a demo.

They wanted to make it low friction to learn for their audience who are largely javascript programmers. I think it's a reasonable tradeoff even if I personally would prefer a more combinator style syntax.

Was that really the intent? I made a longer rant elsewhere in this thread but I sure got the impression it was really for compiler implementers and not for anyone really writing in it at all. It’s sort of a false Lisp and a false Forth when I really should have not been afraid of the ARM vs x86 split and brushed up on a real assembly. :)

WASM grew out of the earlier asm.js, which was explicitly designed as a subset of javascript: http://asmjs.org/spec/latest/ The core idea there was to identify a subset of JS that was high performance on browsers and could be used as a compile target. WASM appeared because once asm.js got some momentum, people naturally asked "hey if browsers could implement just a couple extra things how much better could we make this?"

wasm isn't compatible with asm.js or with js tho

they could have totally made it forthier if they thought that was a good idea, but their objective was rapid generation of efficient, secure code

Except that would be strongly against the familiarity of the community momentum already built.

what they actually came up with was just as strongly against the familiarity of the community momentum already built, wasn't it?

what features do you have in mind of the current wasm spec that are (1) in common with asm.js and (2) not in common with a hypothetical more-forth-like spec for efficient secure execution in browsers?

Is the pool of JS programmers who are just going to casually learn in assembly language - and are totally cool with s-expressions - really that large?

Seems like a waste of time to make your text format 3 times longer than it should be to cater to these unicorns.

I think the target audience probably has no choice. They need performance, but their background might be web.

I guess my point is there minds are going to be melted anyway by 1. low level details 2. a stack machine and 3. s-expressions. might as well use a text format that at least fits the domain.