Remove required laziness in Prod, fixes #615

[adelbertc]

No description provided.

[codecov-io]

Current coverage is 89.61%

Merging #877 into master will increase coverage by +0.27% as of ed296d5

@@            master    #877   diff @@
======================================
  Files          169     181    +12
  Stmts         2337    2417    +80
  Branches        75      76     +1
  Methods          0       0       
======================================
+ Hit           2088    2166    +78
  Partial          0       0       
- Missed         249     251     +2

Review entire Coverage Diff as of ed296d5

Powered by Codecov. Updated on successful CI builds.

[ceedubs]

Thanks for bringing this out of the archives, @adelbertc! :)

👍 for this change in general. Is there anything in particular about Prod that makes it useful to create the Always helpers? This isn't something that we've generally done for other data types.

[adelbertc]

I mostly just added it since I figured if we would have convenience for later might as well have it for always. Say the word and it's gone :-)

[ceedubs]

@adelbertc I guess I really meant having Eval helpers at all (both always and later). I have never used Prod, so I'm not familiar with its common usage.

[adelbertc]

Ah I see. I've never found myself wanting them - @eed3si9n do you know of the motivation behind this?

[eed3si9n]

@eed3si9n do you know of the motivation behind this?

If I understand it correctly, the usefulness of Prod, described in EIP, is that it's an automatically derived return type of an applicative function composition product.
This represents a split in the calculation graph. An example of this might be calculating rows and columns of sudoku "in parallel" - http://eed3si9n.com/sudoku-using-func.
I'm putting the scare quotes because the parallelism is only in semantics, but the calculation is actually not done concurrently. The motivation behind putting lazy evaluation here is to delay the calculation of a branch so we can avoid them, when not needed.

[ceedubs]

Thanks for the explanation @eed3si9n. There are quite a few places where it could be helpful to have a lazy argument (Semigroup.combine, etc) but that we have chosen to let people handle this via Eval if they choose to instead of baking the laziness into things. I'm inclined to say that people could do the same here and that we don't really need helpers for Lazy etc. I guess they don't really cause any harm, but it seems inconsistent with other places. For example we have Applicative.pureEval but we don't provide helpers for Lazy, Always, etc. I guess I'm inclined to take the same approach here unless we have a compelling reason to do otherwise.

[ceedubs]

👍

[non]

👍