Multiple return values mismatch with AstSemantics

[naturaltransformation]

AstSemantics suggests that multiple return value calls are possibly pushed to post-MVP but they are present in the spec implementation (complete with test case). Is spec supposed to represent MVP or something more than that?

[lukewagner]

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!

[jfbastien]

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.

[titzer]

+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 notifications@github.com 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).

[lukewagner]

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.

[rossberg]

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

[lukewagner]

sgtm

[lukewagner]

Fixed by #53.