Sam Mohr (Aug 26 2024 at 06:49): Sam Mohr (Aug 26 2024 at 06:49):@Brendan Hansknecht , with respect to your PR comment:
Just curious, why is this named `PlatformTask`?
Could we maybe call this `Primitives`, `Tasks`, or `Effects`....maybe there is a better name? Cause `PlatformTask` really feels like it is defining a new `Task` type specific to the platform.
I think that even PlatformTasks, being plural, conveys the intended "Task defined by the platform, not the std lib" meaning without seeming like a builtin module. I'd also be okay with Tasks for the same reason. Does anyone else have any other suggestions. It's probably the best time to change things
Brendan Hansknecht (Aug 26 2024 at 06:50):Yeah, even just adding the s helps make it clearer
Sam Mohr (Aug 26 2024 at 06:51):I'm okay with that.
Sam Mohr (Aug 26 2024 at 06:51):@Luke Boswell thoughts?
Luke Boswell (Aug 26 2024 at 06:52):I think it is ok like this for now. When we upgrade to Effect Interpreters, I assume we will want to rename it again
Luke Boswell (Aug 26 2024 at 06:52):I don't have a strong opinion either way
Luke Boswell (Aug 26 2024 at 06:53):When we have the effect interpreters... will we still have something similar?
@Brendan Hansknecht your spiked out impl used Op... but I'm guessing we would use something like Effect
Sam Mohr (Aug 26 2024 at 06:53):The plan I saw from Richard was to use module params in the platform module to define them, so this probably won't be a yak shaving issue in the future. Though I'm not sure how exactly that will work
Sam Mohr (Aug 26 2024 at 06:54):I think the singularity combined with a single verb name always implies builtin here with these primitive types, like Effect and Task. I think we need to pluralize to satisfy Brendan's point
Sam Mohr (Aug 26 2024 at 06:56):Renaming to PlatformTasks now to get it over with
Sam Mohr (Aug 26 2024 at 06:56):It won't break the testing efforts AFAIK
Sam Mohr (Aug 26 2024 at 07:02):Done
Last updated: Jul 26 2025 at 12:14 UTC