Change the ordering of invocations in Defer#fix

[TimWSpence]

What we want is to evaluate fn and pass the recursive value lazily in case fn doesn't need to evaluate it ie fn(defer(res)).

defer(fn(res)) also works but it suspends the initial fn invocation, which is pointless as we must always evaluate fn at least once to produce a result

[armanbilge]

After being befuddled, here's an attempt to put it in my own words: the idea is we want to pass the lazily-evaluated defer(res) to the fn, rather than res itself.

A trivial example of where this obviously makes a difference:

Defer[F].fix[Unit] { _ => // discard it!
  F.unit
}

Under the old implementation, res would be strictly evaluated, before being passed to fn (which is discarding it anyway). Under the new implementation, instead defer(res) is passed to fn. Since defer(res) is lazy and is discarded, res is not evaluated. This eliminates a level of recursion.

[armanbilge]

Heh, forgot I can approve stuff here 😜

[johnynek]

This arose from cats-parse where I had written a function this way (but not, strangely, the fix override).

The motivation there was that for parser you would always need to call the function. So if you know you must call it, lift it out and don't bury it in a level of recursion.

I'm not 100% sure there couldn't be F instances where this is worse but it seems like a better default to me, and if some F likes the other way better I think they can override.

[TimWSpence]

This arose from cats-parse where I had written a function this way (but not, strangely, the fix override).

The motivation there was that for parser you would always need to call the function. So if you know you must call it, lift it out and don't bury it in a level of recursion.

I'm not 100% sure there couldn't be F instances where this is worse but it seems like a better default to me, and if some F likes the other way better I think they can override.

Sorry I meant to include this context in the description