[asibahi]

I dont really disagree with the main premise of the article, which is that WASM is not really a stack language, but this part just gave me pause:

> In textual Wasm, for example, they are instead represented in a LISP-like notation – not any less or more efficient

The Text format, at least when it comes to instructions, it 1 to 1 with the binary format. The LISP-like syntax is mainly just syntax sugar[1].

    ‘(’ plaininstr  instrs ‘)’ ≡  instrs plaininstr

So (in theory, as far as I understand it) you can just do `(local.get 2 local.get 0 local.get 1)` to mean `local.get 0 local.get 1 local.get 2`, and it works for (almost) any instruction.

Unfortunately, in my limited testing, tools like `wat2wasm` and Binaryen's `wasm-as` don't seem to adhere to (my perhaps faulty understanding of) the spec, and demand all instructions in a folded block be folded and have the "correct" amount of arguments, which makes Binaryen do weird things like

    (return
      (tuple.make     ;; Binaryen only pseudoinstruction
        (local.get 0) ;; or w/e expression
        (local.get 1) ;; or w/e expression
      )
    )

when this is perfectly valid

    local.get 0
    local.get 1
    return

tl;dr: the LISP syntax is just syntax sugar. The textual format is as "stack-like" as the binary format.

Edit: An example that is easily done with the stack syntax and not with lisp syntax is the following:

    call function_that_returns_multivalue
    local.set 2 ;; last return
    local.set 1 ;;
    local.set 0 ;; first return

In LISP syntax this would be

    (local.set 0
      (local.set 1
        (local.set 2
          (call function_that_returns_multivalue
            ( ;; whatever input paramters 
            )))))

I have not yet tried this with Binaryen but I doubt it flies.

[1]: https://webassembly.github.io/spec/core/text/instructions.ht...

[soegaard]

FWIW if you are looking for examples of WebAssembly written in the textual format, take a look at:

https://raw.githubusercontent.com/soegaard/webracket/refs/he...

As a small example, here is a definition of `$car` which extracts the first value from a pair.

    (func $car (type $Prim1) 
               (param $v (ref eq)) 
               (result (ref eq))
      (if (result (ref eq)) 
          (ref.test (ref $Pair) (local.get $v))
          (then (struct.get $Pair $a (ref.cast (ref $Pair) (local.get $v))))
          (else (call $raise-pair-expected (local.get $v))
                (unreachable))))

[keithwinstein]

I can't speak to Binaryen, but afaik WABT's wat2wasm and wasm-tools's wat2wasm (aka wasm-tools parse) are both 100% spec-correct in this respect. Parsing the Wasm text format doesn't require any knowledge of the type of each instruction. If you have a counterexample would love to see it!

There are some cool edge cases if you want to print a mismatched multi-value instruction sequence in the folded form (which WABT and wasm-tools again handle "correctly," but not identically to each other, and not particularly meaningfully).

[asibahi]

This is the wat2wasm tool I have been playing with: https://webassembly.github.io/wabt/demo/wat2wasm/

It refuses to accept the following

    (module
      (func (export "addTwo") (param i32 i32) (result i32)
        (i32.add 
          local.get 0
          local.get 1
        )
      )
    )

which based on my reading should be accepted.

I will try the tools you mentioned but I personally settled on generating the unfolded ones for my experiments as they just seem easier.

[soegaard]

Don't you need parens here?

    (local.get 0)
    (local.get 1)

[asibahi]

I do, but where does it say so in the spec?

[purplesyringa]

> tl;dr: the LISP syntax is just syntax sugar. The textual format is as "stack-like" as the binary format.

Not that you're technically wrong, but I think you're begging the question.

Stack-based languages/encodings, in a colloquial sense, are equated to postfix notation, e.g. `a b +` instead of the infix `a + b`. Both LISP and textual Wasm use prefix notation, e.g. `(+ a b)`. Neither of the three is any more foundational than the other -- all notations can encode all expression trees, and postfix and prefix notations in particular have the same coding efficiency.

So sure, the LISP syntax is sugar, but for what? It's not sugar for a stack program, because prefix notation in general can't represent an arbitrary stack program; it's sugar for a mathematical expression. Which is encoded in postfix notation in binary, sure, but that's just an implementation detail, and prefix notation could've been selected when Wasm was born with little adversarial consequences.

[asibahi]

I am saying that textual wasm uses `a b +` (justl ike binary wasm) and `(+ a b)` is just a nicety.

It is explicity sugar for the stack operations, per my reading of the spec.

[purplesyringa]

My brain does not understand how one can see `(+ a b)` in text and read it as `a b +`. I suppose you can argue that moving operators to the right and removing all parentheses converts `(+ a b)` to `a b +`, sure, but that applies to pretty much any language -- next thing you'll tell me is the JavaScript expression `f(1, g(2), h(3))` actually uses stack and is just syntactic sugar for `1 2 g 3 h f`.

> It is explicity sugar for the stack operations, per my reading of the spec.

The entire Wasm text format is syntax sugar for binary Wasm, so this is kind of a vacuous truth -- if Wasm's spec says it's a stack machine, of course everything is sugar for a stack machine. But if you weren't aware of Wasm and just saw a program in textual Wasm for the first time, I don't think the idea that it's stack-based would cross your mind.

[pjjpo]

I have reread this several times but might be missing so I am begging the question, what exactly makes the LISP syntax sugar for something that isn't a stack machine? Or did I misread that?

If not, I think the OP is making the same point we all are, any program can be translated for execution on any machine - so bringing it up in the blog seems weak, which I agree with.