questioning FP

On Mon, Oct 10, 2011 at 3:11 AM, Ittay Dror <ittay [dot] dror [at] gmail [dot] com> wrote:

I'd love to see a code example where the introduction of IO[_] makes more errors detectable. In the code example I used in the first message, I couldn't find where it helps.

Consider the following code outline, and assume a purely functional implementation of Scala (even if strict!)
object A {   def foo(String):Int = ...  def bar(String):Int = ...} Then the program:
object B {  def run(f:String,b:String):Int =     A.foo(f)+A.bar(b) }
At the very least, in our purely functional version of Scala we know that the evaluation of A#foo and A#bar cannot possibly affect one-another, we are guaranteed referential transparency.
Now, drop back into *real* Scala.  Without actually knowing what are inside foo and bar we cannot be assured that evaluating foo will not alter the results of bar.  If there is referential transparency between foo and bar, to quote Adrian Moors elsewhere in this thread, it is implicit.
OK, let's switch back to the purely functional version of Scala for a moment and rewrite things like this:
object A {  def foo(String):Int = ...   def bar(String):IO[Int] = ... }
then:
object B {  def run(f:String,b:String):IO[Int] = {    val x = A.foo(f)    A.bar(b)  }}
Since we are back in purely functional land we can observe two things:

1. The evaluation of A.foo(f) cannot possibly effect the results of A.bar(b) and therefore can trivially be eliminated (optimization!) as dead code
2. The evaluation of A.bar(b) cannot possibly alter the result returned bu A.foo(f) otherwise A#foo type signature would indicate that

Unless I'm grossly mistaken we are already in a better world given the above.
Finally, let's write(still in a purely functional Scala universe):
object A {  def foo(String):IO[Int] = ...  def bar(String):IO[Int] = ...   def baz(String):Option[Int] = ...}
then:
object B {  def run(f:String,b:String,z.String):IO[Option[Int]] =     for {       a <- A.foo(f)      b <- A.bar(b)    } yield A.baz.map(_+a+b)}
We know a bunch of information merely from the types alone to help us track down a possible bug in the above program.  We know, from the types that A#baz is a pure function and we can test it's behavior with deterministic outcomes.  On the other hand A#foo and A#bar may interact in strange ways.  In the case of an error in the above program the search space to look for the bug is easily partitioned on types alone.
Extend this to a "real-world" example as necessary.
This doesn't come across as progress?  Using the IO monad can guide us as to where to look for "action at a distance" kinds of bugs.
--
Jim Powers

Thank you for this excellent example.

All your points are valid, and very true. The question is not whether we gain something by using the IO monad. It is whether we gain enough. Since using it comes with its own price of trickier code, and mental hoops to jump through, spending brain CPU on how to deal with the monad, rather than the business problem.

Normally, one does not work with functions without knowing what they do. When I know what a function is supposed to do, I usually know what side effects it is doing, or, I don't care because they are an implementation detail. If they were not, then all I know is that something is going on under there, but can't do anything about it.

Ittay

CAMjNOCNEC5ndUNSFOhe5BuqqQgJWEsGS41CESxFYLyTcOUTJ+w [at] mail [dot] gmail [dot] com" type="cite"> On Mon, Oct 10, 2011 at 3:11 AM, Ittay Dror <ittay [dot] dror [at] gmail [dot] com" rel="nofollow">ittay [dot] dror [at] gmail [dot] com> wrote:

I'd love to see a code example where the introduction of IO[_] makes more errors detectable. In the code example I used in the first message, I couldn't find where it helps.

Consider the following code outline, and assume a purely functional implementation of Scala (even if strict!)
object A {   def foo(String):Int = ...   def bar(String):Int = ... }   Then the program:
object B {   def run(f:String,b:String):Int =      A.foo(f)+A.bar(b) }
At the very least, in our purely functional version of Scala we know that the evaluation of A#foo and A#bar cannot possibly affect one-another, we are guaranteed referential transparency.
Now, drop back into *real* Scala.  Without actually knowing what are inside foo and bar we cannot be assured that evaluating foo will not alter the results of bar.  If there is referential transparency between foo and bar, to quote Adrian Moors elsewhere in this thread, it is implicit.
OK, let's switch back to the purely functional version of Scala for a moment and rewrite things like this:
object A {   def foo(String):Int = ...   def bar(String):IO[Int] = ... }
then:
object B {   def run(f:String,b:String):IO[Int] = {     val x = A.foo(f)     A.bar(b)   } }
Since we are back in purely functional land we can observe two things:

1. The evaluation of A.foo(f) cannot possibly effect the results of A.bar(b) and therefore can trivially be eliminated (optimization!) as dead code
2. The evaluation of A.bar(b) cannot possibly alter the result returned bu A.foo(f) otherwise A#foo type signature would indicate that

Unless I'm grossly mistaken we are already in a better world given the above.
Finally, let's write(still in a purely functional Scala universe):
object A {   def foo(String):IO[Int] = ...   def bar(String):IO[Int] = ...   def baz(String):Option[Int] = ... }
then:
object B {   def run(f:String,b:String,z.String):IO[Option[Int]] =      for {       a <- A.foo(f)       b <- A.bar(b)     } yield A.baz.map(_+a+b) }
We know a bunch of information merely from the types alone to help us track down a possible bug in the above program.  We know, from the types that A#baz is a pure function and we can test it's behavior with deterministic outcomes.  On the other hand A#foo and A#bar may interact in strange ways.  In the case of an error in the above program the search space to look for the bug is easily partitioned on types alone.
Extend this to a "real-world" example as necessary.
This doesn't come across as progress?  Using the IO monad can guide us as to where to look for "action at a distance" kinds of bugs.
--
Jim Powers