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

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
      )
    )

    local.get 0
    local.get 1
    return

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

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

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

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).

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))))

> 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.