Ideas re: IO and Future

gistfile1.scala

// Some thoughts on IO and Futures
 
object Future {
 
  // A future must have the option of performing IO during its computation; this
  // is one of the primary uses of Futures. So we construct with an IO[A]. Construction
  // is itself an effect because it forks execution of `a`.
  def ioFuture[A](a: IO[A]): IO[Future[A]] 
 
  // Unit, but it has to be eager, so not super useful. What if it's not really a monad at all?
  def apply[A](a: A): Future[A]
 
}
 
 
trait Future[A] {

  // Monad ops are pure
  def map[B](g: A => B): Future[B] 
  def flatMap[B](g: A => Future[B]): Future[B]

  // Observers may wish to do something with the result. This must be an effect, otherwise
  // why bother? Registration changes the future's completion behavior, so it has to be in IO.
  // TODO: dibblego notes that this is ContinuationT[IO, A, Unit] ... investigate.
  def onComplete(a: A => IO[Unit]): IO[Unit] 
 
  // Summoning the answer is pure, but may block forever. Sound but not safe. 
  def get: A
 
  // Summoning the answer given a timeout is somewhat more sensible, and is an effect.
  def await(ms:Long): IO[Option[A]]
 
  // We can check to see if it is complete.
  def isComplete: IO[Boolean] 
 
}

I'm a little worried about the future[A](a: => A): Future[A] constructor; in Scala, this can be used to break referential transparency because the by-name parameter can be effectful. Maybe make the parameter eager?

I think you're right. I'm not convinced by-name is a cromulent unit anyway.