I like the wording "compilers would significantly benefit from it" because if only SBCL benefits, then that's only "compiler" not "compilers".

Why are you talking about SBCL here? This is not for the benefit of SBCL, which does not target Web-Assembly, but about implementing multiple return values easily. Yes not many languages have multiple return values today, but Web Assembly should not only focus on implement only the languages that are popular today but the languages of the future.

While I agree wholeheartedly with this point, I have to smile at it being made about one of the oldest programming languages still in use.

In some ways Lisp has always been and continues to be the language of the future.

From what I understand, it really is just Lisp, not any language with multiple return values. The issue here is Lisp semantics for multiple return values being slightly cumbersome (but by no means difficult).

The discussion on github also mentions Lua (https://github.com/WebAssembly/spec/pull/215#issuecomment-17...), though it is true that this is coming from a Common Lisp developer.

From my point of view the feature is useful (efficient implementation without useless memory allocation) and the rebuttal looks slightly uninformed.

There are discussions about coroutines (https://github.com/WebAssembly/design/blob/master/FutureFeat...) and more generally about low-level capabilities (https://extensiblewebmanifesto.org/). Among those, we can see in the design document (https://github.com/WebAssembly/design/blob/4dec2849ad6d79fae...) a "Multiple Return Values" section with a "TODO" placeholder text: it seems that WebAssembly people want to implement MRV.

Go has multiple return values; could this also benefit go? I'd bet that that would garner more calls for MRV support in wasm if so.

This is the (infinite) loop that keeps us with C.

Lets not do X because it would benefit Y which no one uses. No one uses Y because it's slow because no CPU supports X.

Very few people think the future really exists.

You think languages are slow because they aren't 'supported' by the CPU?

A dynamically typed language isn't going to start running at the speed of C with some extra CPU engineering.

Aren't there other Lisp compilers, besides SBCL? What about Lisps besides Common Lisp, like Scheme?