Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Semantics of closure return #55

Open
ltratt opened this issue Aug 28, 2020 · 4 comments
Open

Semantics of closure return #55

ltratt opened this issue Aug 28, 2020 · 4 comments
Labels
spec Needs specification, or is specification related.

Comments

@ltratt
Copy link

ltratt commented Aug 28, 2020

If I have a method along the lines of:

m = (
    [ ^nil ] value.
)

the closure, when invoked, will return from the method. It's already defined that such closures aren't allowed to call "return" if they've escaped from the method. Are there any other restrictions e.g. if you have a multiply nested closure such as:

m = (
    [ [ ^nil] value ] value.
)

must it be at least 2 frames deep for the return to be valid?

@smarr
Copy link
Member

smarr commented Aug 28, 2020

Hmmm, I am not sure I understand. Could you elaborate?
What does the it refer to, the block?

This here should print 42:

Hello = (
  | field |

  aMethod = (
    [ field := [ ^ 42 ] ] value.
    field value.
  )

  run = (
    self aMethod println.
  )
)

I think, there are no further restrictions, and, there's no "lexical" binding or similar going on.
The semantics of the return are dynamic, and for instance for recursive versions of m, you'd need to return from the correct m.

@smarr smarr added the spec Needs specification, or is specification related. label Aug 28, 2020
@ltratt
Copy link
Author

ltratt commented Aug 28, 2020

OK, that example (aMethod) pretty much answers my question. I wondered if the fact that the "outer" block had completed before the "inner" block did a closure return was against the spec, but it seems not :)

@smarr
Copy link
Member

smarr commented Aug 28, 2020

Ah ok, so, within the method, the blocks can freely flow between scopes, as normal objects, and they are still normal objects.

The only requirement is that the outer method, in my example aMethod, is on the stack. No further requirements where it is on the stack when the return is triggered.

So, any assumptions you may want to make, for instance, to optimize stack unrolling, would not necessarily hold in the most general case.

@ltratt
Copy link
Author

ltratt commented Aug 28, 2020

Got it, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spec Needs specification, or is specification related.
Projects
None yet
Development

No branches or pull requests

2 participants