Hi @aleator! We reexport forever from base and not much can be done with its type signature. One of relude goals is to keep the number of custom things as small as possible, we really would like to avoid introducing more surprises and differences for the library users.

However, I totally understand your concern. It would be really nice to prevent such situations from happening. I will refer to the following blog post that explains best-practices around specifying types for infinite loops:

https://www.fpcomplete.com/blog/2017/07/to-void-or-to-void/

Main idea, is that if your function returns infinite loop, its type should be something like IO void (polymorphic variable), and if an action expects an infinite loop, argument type should be something like IO Void (monomorphic type Void). Applying this suggestion to forever, we can see that its type should be:

forever :: Applicative f => f a -> f void

You can notice, that this is the same as the original type signature, just with a slightly different variable name:

forever :: Applicative f => f a -> f b

Thus being said, it is probably a good idea to replace b with void in type signature for forever directly in base to give a hint in the type signature. Or even to change the type to to forever :: Applicative f => f a -> f Void to avoid such problems completely. But this should be raised to the core library committee and it is up to them to decide how to change the type signature. Introducing a custom version of forever just with renamed type variables is not worth it in relude.

But what you can do to solve this problem, is to introduce a custom helper function that expects an infinite action:

asyncInfinite :: IO Void -> IO (Async Void)
asyncInfinite = async

And this would probably be a good function to be added to async as well 🙂 This won't prevent your original error from happening, but will be a hint and a compile-time guarantee on the input action.

Uh oh!

Could forever be Applicative f => f a -> Void instead? #327

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Could `forever` be `Applicative f => f a -> Void` instead? #327