4 ms·

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 easi

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.

dietrichepp 11y ago
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 11y ago
  The discussion on github also mentions Lua (https://github.com/WebAssembly/spec/pull/215#issuecomment-178309685 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/FutureFeatures.md#coroutines https://github.com/WebAssembly/design/blob/master/FutureFeat...) and more generally about low-level capabilities (https://extensiblewebmanifesto.org/ https://extensiblewebmanifesto.org/). Among those, we can see in the design document (https://github.com/WebAssembly/design/blob/4dec2849ad6d79fae63e7a8529da9358ac8cffe8/Rationale.md 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 11y ago
    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 11y ago
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 11y ago
  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.
nemoniac 11y ago
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 11y ago

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 11y ago
The discussion on github also mentions Lua (https://github.com/WebAssembly/spec/pull/215#issuecomment-178309685 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/FutureFeatures.md#coroutines https://github.com/WebAssembly/design/blob/master/FutureFeat...) and more generally about low-level capabilities (https://extensiblewebmanifesto.org/ https://extensiblewebmanifesto.org/). Among those, we can see in the design document (https://github.com/WebAssembly/design/blob/4dec2849ad6d79fae63e7a8529da9358ac8cffe8/Rationale.md 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 11y ago
  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 11y ago

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 11y ago
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.

nemoniac 11y ago

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.