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

Fixed issue where translate after translateSync should restore any UnconsAsync steps #948

merged 2 commits into from Oct 12, 2017


None yet
1 participant

mpilquist commented Oct 11, 2017

This came up in a discussion with @tpolecat on Gitter today. Example use case is translating from IO to some free algebra that doesn't have an Effect instance via translateSync and then at the end of the program, translating back to IO via translate.

Prior to this PR, any UnconsAsync steps in the program (e.g., those arising from unconsAsync, merge) were replaced with an Eval(F.raiseError(new IllegalStateException(...))). In this PR, I introduced a new UnconsAsyncDeferred constructor which acts as a sort of higher kinded Coyoneda. When calling translate later, any UnconsAsyncDeferred steps are rewritten to UnconsAsync steps using the captured Effect instance.

I have a more drastic idea on how to fix this, where we no longer capture the Effect instance on unconsAsync, merge, etc. and instead, the instance is provided at the edge of the program on calls to run, runFold, etc. This will mean changing these functions to take an Effect[F] instead of Sync[F] but I plan to add alternatives like runSync, runFoldSync, and so on which require only a Sync instance. I'll do this as a separate PR if it works out.

@mpilquist mpilquist merged commit 4bed569 into functional-streams-for-scala:series/0.10 Oct 12, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed

@mpilquist mpilquist deleted the mpilquist:topic/translateSync branch Nov 27, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment