[Haskell-cafe] Implicit Multi Threading in Switch Case

Joachim Durchholz 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 mailing list