Multiple return values mismatch with AstSemantics about spec HOT 7 CLOSED

I think this addition to the spec (as well as the expr/stmt unification) was "aspirational" in nature :) There is an ongoing design/ discussion to add multiple-return values. The result of that discussion would then be reflected here. We should keep this issue open to record this pending work item. Thanks for filing!

from spec.

Could we either make multiple return values an off-by-default feature for now, or add them to the design? I want to make sure we can connect all the pieces together as we get closer to being able to emit code from other languages, so following the design by default becomes pretty important.

from spec.

+1 I think we need to achieve consensus on how to handle them, and post-MVP
is probably the right time frame for that.

We shouldn't let the spec get too far ahead of the design :-)

On Thu, Sep 3, 2015 at 5:57 PM, JF Bastien [email protected] wrote:

Could we either make multiple return values an off-by-default feature for
now, or add them to the design? I want to make sure we can connect all the
pieces together as we get closer to being able to emit code from other
languages, so following the design by default becomes pretty important.

—
Reply to this email directly or view it on GitHub
#15 (comment).

from spec.

I'm happy to bump "Multiple Return Values" from the MVP; clearly the product has been viable so far :)

This is separate, however, from the question of how to define expression types in the spec. As @sunfishcode pointed out for signatures, lists give a nice way to express void (empty list). However, unlike signatures, if we do end up going the route of StrawMan 1 or 2, we'll never have lists of size >1 for expressions, so it'd be better to just have a void type for expressions. None of this is semantically visible (only whether validation succeeds or not), so doing void initially shouldn't prevent a spec refactoring later on if we want real tuple types.

from spec.

I wouldn't introduce void. Instead, isomorphically, just demote expression types from list(value type) to option(value type).

from spec.

sgtm

from spec.

Fixed by #53.

from spec.