-
Notifications
You must be signed in to change notification settings - Fork 38
Proper handling of local variables capturing inside a loop body #351
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
Conversation
|
Nice! Please first resolve the conflicts and then request my review. |
LPTK
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good work, but let's not claim victory too fast.
| case Label(lbl, loop, bod, rst) => | ||
| scope.allocateName(lbl) | ||
|
|
||
| // [fixme:0] TODO check scope and allocate local variables here (see: https://github.com/hkust-taco/mlscript/pull/293#issuecomment-2792229849) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not actually fixed, as while loops aren't always rewritten yet...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the latest commit I've added this back, but it shouldn't be an issue after loop rewriting. If a loop does not contain any local function, loop local variables can be treated as function locals since there is no capturing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's right, but it's better to keep the doc/tests in sync with what's actually implemented at the moment.
AnsonYeung
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've addressed the comments.
| case Label(lbl, loop, bod, rst) => | ||
| scope.allocateName(lbl) | ||
|
|
||
| // [fixme:0] TODO check scope and allocate local variables here (see: https://github.com/hkust-taco/mlscript/pull/293#issuecomment-2792229849) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the latest commit I've added this back, but it shouldn't be an issue after loop rewriting. If a loop does not contain any local function, loop local variables can be treated as function locals since there is no capturing.
LPTK
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
| //│ lambda$here = runtime.safeCall(lambda2(foo$capture6)); | ||
| //│ return lambda$here | ||
| //│ } else { | ||
| //│ foo$capture6.tmp$capture$1 = runtime.Unit; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just noticed this crazy capture of a temporary variable that just stores the unit value. It's pretty crazy. I wonder why Unit is bound to a temporary variable in the first place.
Previously, variables inside a loop body are treated the same as that of the function body, which leads to bad semantics when a function captures a local variable defined within a loop body.
As mentioned in #293 (comment), this PR lowers while loop into tail recursive function and rely on the scoping of the function for the correct semantics. This is done during lowering as we already know the location of inserting Continue statements and we just need to convert these into tail calls.
runtime.LoopEndis introduced to handle the case when a return statement occur inside the loop body. This value is returned when the loop exits without early return and is tested to determine whether to return from the outer function.