This is an in-progress PR that moves the Task opaque IO type from platform-specific implementations to the standard library of Roc. The main thrust of the implementation work is done, barring bug fixes and testing. The high level changes are:
Copied the Task module from the basic-cli platform to crates/compiler/builtins/roc/Task.roc
Consolidated Task and Effect into just the Task opaque type with definition Task ok err := {} -> Result ok err, which is the old type for Effect a : {} -> a that Task ok err : Effect (Result ok err) wrapped
Removed the Effect generation code, as everything should use Task directly
This includes the generates Effect with [after, map, ...] clause of the hosted module header, which is a breaking change
FFI definitions on the host side need to return RocResults now, and FFI type declarations on the Roc side need to always have Task return types
Removed generation of the Effect.after, Effect.map, etc. functions as they were needed to glue Effect to Task, but are no longer needed now that those types have been combined
Renamed hosted modules that contain FFI Roc declarations from Effect.roc to PlatformTask.roc to distinguish their behavior from the old approach and to give a name more descriptive of the new behavior
Updated a good deal of the testing, but until basic-cli works, that is on hold
I am running into an issue while testing this with a testing platform where Roc says the inferred types of our generated FFI function bodies don't match their type definitions for the Task return types:
── TYPE MISMATCH in examples/cli/false-interpreter/platform/PlatformTask.roc ───
Something is off with the body of the getLine definition:
This Task.Task opaque wrapping has the type:
Task *
But the type annotation on getLine says it should be:
Task Str
I did not make any real changes to how we generate the FFI calls, and we seem to define the return type based on the definition, but I'm sure I'm missing something. If anyone has any suggestions on how to debug or fix this issue, that would be appreciated.
I have created a twin PR for the basic-cli platform that can be useful for testing this change, as well as basing other platform updates on.
Since most of the cli_run tests depend on current basic-cli, expect the tests to fail on this PR for a bit.
This is an in-progress PR that moves the
Taskopaque IO type from platform-specific implementations to the standard library of Roc. The main thrust of the implementation work is done, barring bug fixes and testing. The high level changes are:Taskmodule from the basic-cli platform tocrates/compiler/builtins/roc/Task.rocTaskandEffectinto just theTaskopaque type with definitionTask ok err := {} -> Result ok err, which is the old type forEffect a : {} -> athatTask ok err : Effect (Result ok err)wrappedEffectgeneration code, as everything should useTaskdirectlygenerates Effect with [after, map, ...]clause of the hosted module header, which is a breaking changeRocResults now, and FFI type declarations on the Roc side need to always haveTaskreturn typesEffect.after,Effect.map, etc. functions as they were needed to glueEffecttoTask, but are no longer needed now that those types have been combinedEffect.roctoPlatformTask.rocto distinguish their behavior from the old approach and to give a name more descriptive of the new behaviorbasic-cliworks, that is on holdI am running into an issue while testing this with a testing platform where Roc says the inferred types of our generated FFI function bodies don't match their type definitions for the
Taskreturn types:I did not make any real changes to how we generate the FFI calls, and we seem to define the return type based on the definition, but I'm sure I'm missing something. If anyone has any suggestions on how to debug or fix this issue, that would be appreciated.
I have created a twin PR for the basic-cli platform that can be useful for testing this change, as well as basing other platform updates on.
Since most of the
cli_runtests depend on currentbasic-cli, expect the tests to fail on this PR for a bit.