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

[aleator]

Just asking, since

foo :: IO (Async ())
foo = forever $ do ...

vs.

bar :: IO (Async ())
bar = async $ forever $ do ...

seems like common error for less attentive guys like me.

[chshersh]

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.

[aleator]

I concede on the point of not causing surprises and this issue may be closed.

However, doesn't the article mentioned justify using the type variable version only with the convenience of not having to say absurdand not needing to import Data.Void? Relude already solves the latter issue and I disagree on the first one. Not having to write absurd is what causes the issue here and in the case mentioned in the article not having absurd is just plain confusing.

But, how would you guys feel about introducing toInfinityAndBeyond :: f a -> f Voidand then adding a hlint hint to use that instead of forever?

[chshersh]

@aleator I agree with you that if you already have Void in scope, then the specific return type Void provides more guarantees. If the return type is polymorphic (e.g. void type variable), you can accidentally pass such IO void action as an IO Int argument, and the code will hang unexpectedly. I now think that always returning Void and expecting Void for actions that run infinitely is a good practice 👍 If you use absurd explicitly in the code to convert Void to Int, something suspsicious is happening, probably.

I don't mind having a different function besides forever that uses Void in the return type. We only need to come up with some name that doesn't have many conflicts on Hackage, but still has meaning.

[aleator]

@chshersh If good name is only thing required before I can make a pull request, then here are some suggestions. Maybe the good name is not on the list, but perhaps it will spark an idea:

• amaranthinely (Quaranteed not to conflict. My favourite)
• ceaselessly
• perpetually
• permanently
• whileTrue

None seem to have obvious word conflicts. Any favourites?

[vrom911]

I agree that this function would be helpful to have!
Another thing to consider is to add it into the Extra module?
In that case we would be able to give it a more "clashing" name, that could probably used for some vars in code (but maybe I am overestimating names in here).

My options are:

• always – there problem that it has the meaning of const in Purescript and Elm
• infinitely
• constantly

[aleator]

Hi @vrom911!

After thinking about these, I'd think infinitelyand perpetually would be good choices, but for me, the name does not matter so much.

Further, I'd vote for not putting it into an Extra module, but to always export it. How would you feel about adding the hlint to move people away from forever?

[vrom911]

@aleator , sounds good to me. I think we can add it in the Relude with the corresponding support HLint warning for forever 👍🏼
I would prefer infinitely personally from the above options 🙂