shajra/try_task_and_rt.md

## try_task_and_rt.md

      
    Raw
  

              try_task_and_rt.md
            
          
    When scala.util.Try first came out, there was a lot of discussions about the
validity of it's implementation.  Some discussions got distracted with issues
beyond the facts.  Ultimately, the issue came down to the following:


Is Try a monad?


Does referential transparency (RT) apply in the presence of possible
non-terminating or errant functions -- those returning ⊥?


Not requiring Try to be a monad is an easy solution to the whole problem.  If
it's not a monad, there's no laws restricting it's implementation.  It does
what it does, and we hope it's useful.
However, if it's a monad, it needs to obey certain laws.  One law that breaks
is the left identity monad law:
return a >>= f ≡ f a

but it only breaks when f throws an exception or fails to terminate (returns
⊥):
scala> def f[A, B](a: A): Try[B] = throw new RuntimeException("fail")
f: [A, B](a: A)scala.util.Try[B]

scala> f(1)
java.lang.RuntimeException: fail

scala> Try(1) flatMap f
res0: scala.util.Try[Nothing] = Failure(java.lang.RuntimeException: fail)

Though the two calls should be the same, the first one throws returns ⊥ (by
throwing an exception), but the second call returns an instance of Failure,
which is a value and not ⊥.
We know we want RT for total functions.  But in the Turing complete languages
we use, it's too difficult to exclude the introduction of partial functions.
The benefits of equational reasoning that we derive from RT are so great we'd
like not to sacrifice it all, just because we occaisionally get an exceptional
condition.
Typesafe has shown strong resistance to changing the implementation of Try, but
this problem surfaces in another monad implementation -- ScalaZ's Task, which
is a variant of their Future implementation that catches exceptions.
Here's what ScalaZ's Task does in version 7.0.2 of the library:
scala> def f[A, B](a: A): Task[B] = throw new RuntimeException("fail")
f: [A, B](a: A)scalaz.concurrent.Task[B]

scala> f(1) attemptRun
java.lang.RuntimeException: fail

scala> Task(1) flatMap f attemptRun
res1: scalaz.\/[Throwable,Nothing] = -\/(java.lang.RuntimeException: fail)

This is the same problem as scala.util.Try.  The first call throws an exception
(⊥), while the other returns an instance of Scala's / type (not ⊥).
This problem was addressed for ScalaZ's Task in versions 7.0.3 and 7.0.1-M2:
scala> def f[A, B](a: A): Task[B] = throw new RuntimeException("fail")
f: [A, B](a: A)scalaz.concurrent.Task[B]

scala> f(1) attemptRun
java.lang.RuntimeException: fail

scala> Task(1) flatMap f attemptRun
^C

Now, rather than returning /, the thread hangs (because the exception has been
thrown unhandled in a dependent thread that the first is blocking on).
Operationally, this is a different failure, but logically, the non-terminating
computation is the same ⊥ type as the exception.  Thus we have referential
transparency, but the possible added inconvenience of non-termination.
However, is this really a fix?  I've suffixed attemptRun in this expression for
one particular illustration of the monad law, but the expressions should be the
same even without this ancillary call.  But this is not the case:
scala> f(1)
java.lang.RuntimeException: fail

scala> Task(1) flatMap f
res1: scalaz.concurrent.Task[Nothing] = scalaz.concurrent.Task@3248b991

As we'd expect the first call returns ⊥ again.  But the second one still
doesn't return ⊥, returning an instance of a Task instead.
In a language like Scala's this expression could be easily computed, but not
used.  Because Scala is strictly evaluated, this first version would make the
whole program return ⊥.  But the second version would allow the program to
continue on unaffected.
In this regard, the fix for Task seems:


incomplete, and therefore not much better from a correctness perspective


now more inconvenient to use operationally.


Does this mean that Task is better off the way it was?  I'm not sure I feel
that way.  But it does not feel right the way it is.  The dilemma feels in our
face.  f(1) is going to throw an exception regardless of the implementation
of Task.  This seems to imply that Task(1) flatMap f must return ⊥ as well.
But how can we do that without evaluating the Task?  This wouldn't be a problem
if the Task had no side-effects, but ScalaZ's Task and Future implementations
were designed with side-effects in mind.  They are supposed to be asynchronous
effect tracking types.