FP: Capturing the characteristics of a process which blocks, causes side-effects, and may fail

Question

I have a driver function modifyFile that interacts with many sources in the outside world (e.g. HTTP, filesystem). Let's say the code is as such:

def downloadFile(from: String, to: String): Try[Unit]

def runUnixProcess(cmd: String): Boolean

def modifyFile = {
    downloadFile(from = "http://.../some/file.dat", to = "/tmp/file.dat") // 
    val status = runUnixProcess("/usr/bin/somebinaries /tmp/file.dat")
    if (status == Status.OK) deleteFile("/tmp/file.dat")
}

For the sake of the argument, let's consider that these functions abide to the Single Responsibility Principle rule, and that modifyFile is only a driver that "integrates" and facilitates communication between separate entities such as OS, File system and web service.

While this function will most likely sit in the higher level of the application logic, some other application function might be built on top of it. Hence, I want to have some kind of proper abstraction (e.g. by wrapping it with a monadic construct) so that we can still compose an even higher abstraction over it.

Now my question: What is the best language construct to abstract this kind of computation? Namely a computation that:

• calls to many entities in the external world
• may fail, either partially or completely at some steps due to various conditions. To name a few, we might be dealing with filesystem permission issue, network connection issue, unix binaries missing issue, etc.
• might need to be ran asynchronously, considering that there are several blocking calls in it.

Is Scalaz's Task up for it?

Or should I simply wrap it as a Future[Try[T]], which basically captures most of the characteristics it exhibits?

Answer 1

I'm not sure how easy this would be to implement in Scala, but here's how I'd look to structure it in Haskell:

To begin I'm going to review a couple of the monads which Haskell and F# provide -- You're probably familiar with them, but I'll review them just to set the stage.

In Haskell there is the IO monad which is used for doing IO operations (e.g. web calls, file-system access) and which keeps side-effects out of pure code.

There are also the Maybe and Either monads; these monads will short-circuit a chain of monadic functions when there's an error/failure in one of the functions, bypassing the remaining functions in the chain.

In F# there's the Async monad (aka workflow/computation expression) -- I'm sure there's some equivalent in Haskell, but I've not worked with one yet -- which lets you run asynchronous operations with code that looks like regular sequential calls. (Here's an intro tutorial on async programming in F#, and there's another tutorial on that site which goes more into the development of the workflow and how bind for it naturally arises from callbacks, but I can't find it at the moment.)

Now, what you're asking about is some way to use all of these at once. There is a way to do this, and it's a little more complex, but it's definitely a nice thing to have in your toolbox.

Beyond monads, there are monad transformers; these allow you to compose monads together, creating a kind of super monad that allows you to use the all capabilities of the monads composing it -- think of it as kind of a monad stack where you can access the individual monads at different levels (using the lift function).

Some example (return) type-signatures:

IO (Either String a) -- Either & IO
IO (Async (Maybe a)) -- Maybe, Async, IO

If, for example, you have a bunch of IO operations you want to run sequentially, any of which might fail, then you'd probably create a transformer stack using the IO and Either monads.

I won't go into the details of them here, but the paper Monad Transformers Step-by-Step is a pretty good introductory resource.

Monad transformers have, IMO, a steep learning curve, so if you're in a hurry to get something implemented then this probably isn't the way to go, but maybe it'll give you some ideas. If you're looking for a long-lasting general abstraction then you probably should consider monad transformers, despite the large up-front investment.