Why are you talking about SBCL here? This is not for the benefit of SBCL, which ...

nemoniac · on March 12, 2016

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.

dietrichepp · on March 12, 2016

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

junke · on March 12, 2016

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.

thinkpad20 · on March 12, 2016

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.

_3u10 · on March 12, 2016

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.

CyberDildonics · on March 12, 2016

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.