F# Implementation of Scala ZIO

PLEASE NOTE SOURCE CODE IS NO LONGER AVAILABLE AND THE POST IS HERE JUST FOR INFORMATION

This is a prototype implementation of Scala ZIO in F#. It aims to be a skeleton of ZIO features such that additional functions can be easily fleshed out.

Background

I recently went to a talk on Scala ZIO by John De Goes. ZIO is a type-safe, composable library for asynchronous and concurrent programming in Scala.

It takes a different approach to other Scala effects libraries in that it does not require the use of Higher-Kinded Types. Instead it uses a reader monad to provide access to IO effects (called ZIO Environment).

I came away wanting something similar in F#. A useful library that could be used in the outer IO layer to simplify and test IO dependency code. I started to play with some reader code but didn't think it would ultimately work out. In fact, it works really well.

IO

\[IO = Reader + Async + Result\]

The F# equivalent of ZIO type aliases are UIO<'r,'a> which represents effects without errors, and IO<'r,'a,'e> which represents effects with a possible error. IO combines reader, async and result into one unified computation expression.

type UIO<'r,'a> = UIO of ('r * Cancel -> ('a option -> unit) -> unit)

type IO<'r,'a,'e> = IO of ('r * Cancel -> (Result<'a,'e> option -> unit) -> unit)

Reader

The reader part represents all the environment dependencies required in the computation expression. It is fully type-safe with types inferred including any library requirements such as Clock for the timeout. The computation expression can easily be tested by running with a test environment.

Async

At the IO layer thread pool threads need to be used in the most efficient way without any blocking. This usually means Async in F# or async/await in C# need to be used. They both join threads without a thread pool thread having to wait.

    let race (UIO run1) (IO run2) : IO<'r,Choice<'a1,'a2>,'e1> =
        IO (fun env cont ->
            if Cancel.isSet env then cont None
            else
                let envChild = Cancel.add env
                let mutable o = 0
                ThreadPool.QueueUserWorkItem (fun _ ->
                    run1 envChild (fun a ->
                        if Interlocked.Exchange(&o,1) = 0 then
                            Cancel.set envChild
                            if Cancel.isSet env then cont None
                            else Option.map (Choice2Of2 >> Ok) a |> cont
                    )
                ) |> ignore
                ThreadPool.QueueUserWorkItem (fun _ ->
                    run2 envChild (fun a ->
                        if Interlocked.Exchange(&o,1) = 0 then
                            Cancel.set envChild
                            if Cancel.isSet env then cont None
                            else Option.map (Result.map Choice1Of2) a |> cont
                    )
                ) |> ignore
        )

With IO async is implemented directly using the thread pool. There are two main reasons for this. In IO exceptions are not part of control flow. Errors are first class and type-safe. Unrecoverable exceptions output the stack trace and exit the process. Cancellation is fully integrated into IO meaning in race, parallel and upon an error, computations are automatically cancelled, saving resources.

These with the final part dramatically simplify and optimise asynchronous IO code.

Result

The result part of IO represents possible errors in an integrated and type-safe way. The error type is inferred, and different error types are auto lifted into Choice<'a,'b> when combined. IO computations can be timed out and retried based on result using simple functions. Schedule is a powerful construct that can be combined several ways. I've replicated the structure from ZIO but not fully explored its uses.

let programRetry noRetry =
    io {
        do! Logger.log "started"
        do! Console.writeLine "Please enter your name:"
        let! name = Console.readLine()
        do! Logger.log ("got name = " + name)
        let! thread =
            Persistence.persist name
            |> IO.timeout 1000
            |> IO.retry (Schedule.recurs noRetry)
            |> IO.fork
        do! Console.writeLine ("Hi "+name)
        do! thread
        do! Logger.log "finished"
        return 0
    }

Conclusion

When type inference worked for the dependencies I was surprised. When it was also possible to make it work for the errors I was amazed.

Computation expressions do not compose well. At the IO layer a solution is needed for dependencies in a testable way. The IO layer also needs to efficiently use the thread pool. Making errors type-safe and integrated in the IO logic completes this compelling trinity.

References

IO.fs
IOTests.fs
ZIO Overview
ZIO Data Types
The Death Of Final Tagless

Thanks

@jdegoes for ZIO and a great talk that made me want to do this.
@NinoFloris for useful async discussions.
@keithtpinson for the error auto lift idea.