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

Try to fix capture flow #371

Merged
merged 1 commit into from
Jan 25, 2024
Merged

Try to fix capture flow #371

merged 1 commit into from
Jan 25, 2024

Conversation

b-studios
Copy link
Collaborator

@b-studios b-studios commented Jan 25, 2024

Fixes #362 and #365 which surprisingly were the result of the same problem.

(bps zip bargs zip captArgs) foreach { case ((tpe, expr), capt) =>
usingCapture(capt)
given Captures = capt
val Result(t, eff) = checkExprAsBlock(expr, Some(tpe))
effs = effs ++ eff
}

Strangely the given instance provided after usingCapture still shadows the previous call.

Introduced new combinator flowingInto to make scoping more explicit.

def flowingInto[T](c: Captures)(prog: Captures ?=> T): T = prog(using c)

Now the above code is

(bps zip bargs zip captArgs) foreach { case ((tpe, expr), capt) =>
flowsInto(capt, callsite)
// capture of block <: ?C
flowingInto(capt) {
val Result(t, eff) = checkExprAsBlock(expr, Some(tpe))
effs = effs ++ eff
}
}

which explicitly scopes the implicit Captures context.

All other changes are clean-up / refactoring changes.

IMO this is a problem with Scala, reproduced here: https://scastie.scala-lang.org/dNPmyHdGSdKJ0atotRofPw

@b-studios b-studios merged commit 5609d49 into master Jan 25, 2024
2 checks passed
@b-studios b-studios deleted the fix/capture-flow branch January 25, 2024 12:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Soundness Bug with Capture
1 participant