`Eval` thread safety

[durban]

If we have an Eval like this:

val e = Eval.defer(Eval.always { println("foo") }).memoize

Accessing e.value concurrently from different threads sometimes prints foo twice. I'm not sure if Eval is supposed to be thread safe, but this seems like a bug.

[johnynek]

Memoize isn't for effects. It should always produce the correct value but in a multithreaded environment it may be evaluated more than once.

Preventing that requires a lock during the eval evalution which would harm performance for those using it for the intended use case: controlling laziness and avoiding stack overflows.

If you care if a race can cause the eval to be run twice probably I'd use a IO or a newtype/opaque type wrapper on IO.

[durban]

Fair enough. I guess then the lazy val could also be removed form Later, right?

[johnynek]

If you mean we don't need the synchronization that lazy val gives then yes. We could reimplement a "evaluate once" semantic without any sychronization and it may be faster. If we had benchmarks to show that it was faster I'd support merging it.

[rossabaker]

Three alternate approaches to laziness, with various tradeoffs, are exemplified in latr.