[Haskell-cafe] Implicit Multi Threading in Switch Case
jo at durchholz.org
Tue Jun 20 23:28:49 UTC 2017
Am 21.06.2017 um 00:23 schrieb Richard A. O'Keefe:
> As I understand it, the original poster wanted the arguments
> to be evaluated *concurrently* and to catch whichever of them
> finished first. (OK, define "finished" to be "evaluated to
> WHNF".) Years ago people used to discuss the question of
> whether it was possible to define
> or True _ = True
> or _ True = True
> or False x = x
> or x False = x
> symmetrically, so that if *either* argument returned True,
> the result True would be delivered, even if the other
> argument diverged. As I recall it, the answer was "NO",
> but I don't recall the proof.
It depends on evaluation strategy I'd say.
If evaluation is sequential ("depth-first"), if the first argument
diverges, then the whole expression diverges and you never get to
inspect the second argument to see whether it evaluates to True.
If evaluation alternates ("breadth-first", "concurrently"), then
infinities-caused divergence does not matter.
Divergence due to invalid operations (division by zero, taking the head
of an empty list etc.) will still cause failure.
Of course this means evaluating both parameters, which is less efficient
than just evaluating one of them and touch the second one only if needed.
To capture invalidity divergence, you'll need to modify evaluation
strategy further by allowing "known to diverge" as if it were an
ordinary result (similar to NaN values in IEEE arithmetic).
Actually SQL defines such a strategy, it assumes that divergence is
equivalent to "this might be any value", which gives us counterintuitive
answers like NULL == NULL evaluating to False, which is a well-known and
rich source of bugs in any but the most trivial SQL statements.
So this approach isn't a good idea at all.
More information about the Haskell-Cafe