Random / State workflow in F#

Question

I'm trying to wrap my head around mon-, err, workflows in F# and while I think that I have a pretty solid understanding of the basic "Maybe" workflow, trying to implement a state workflow to generate random numbers has really got me stumped.

My non-completed attempt can be seen here:

let randomInt state =
    let random = System.Random(state)
    // Generate random number and a new state as well
    random.Next(0,1000), random.Next() 

type RandomWF (initState) =
    member this.Bind(rnd,rest) =
        let value, newState = rnd initState
        // How to feed "newState" into "rest"??
        value |> rest
    member this.Return a = a // Should I maybe feed "initState" into the computation here?

RandomWF(0) {
    let! a = randomInt
    let! b = randomInt
    let! c = randomInt
    return [a; b; c]
} |> printfn "%A"

Edit: Actually got it to work! Not exactly sure how it works though, so if anyone wants to lay it out in a good answer, it's still up for grabs. Here's my working code:

type RandomWF (initState) =
    member this.Bind(rnd,rest) =
        fun state ->
            let value, nextState = rnd state
            rest value nextState

    member this.Return a = fun _ -> a 

    member this.Run x = x initState

How to fix it? Or generally how such a monad/workflow should be constructed. — monoceres, Jul 10 '15 at 19:34
Here is a good description how state monad works. It's kind of lengthy (3 parts) but it worth reading. Maybe it would help http://fsharpforfunandprofit.com/posts/monadster/ — Petr, Jul 10 '15 at 21:11
Aah, I love fsharpforfunandprofit! Actually, while working on this code I have been studying this series: http://fsharpforfunandprofit.com/posts/computation-expressions-intro/. Thanks for the link! — monoceres, Jul 10 '15 at 21:27
By seeding the next random using a generated number you could end up in a loop. I.e. Random(123).Next(0,1000).Next() == 123. It would be nice to get the seed from Random, but it is not exposed. Best alternatives are either roll your own Random class, or use the fact that Random is serializable and serialize it and pass that string out and in. — Martin Capodici, Nov 18 '15 at 22:24

scrwtp · Accepted Answer · 2015-07-14T19:41:33.533

There are two things that make it harder to see what your workflow is doing:

You're using a function type for the type of your monad,
Your workflow not only builds up the computation, it also runs it.

I think it's clearer to follow once you see how it would look without those two impediments. Here's the workflow defined using a DU wrapper type:

type Random<'a> = 
    Comp of (int -> 'a * int)

let run init (Comp f) = f init

type Random<'a> with 
    member this.Run(state) = fst <| run state this 

type RandomBuilder() =
    member this.Bind(Comp m, f: 'a -> Random<_>) =
        Comp <| fun state ->
            let value, nextState = m state
            let comp = f value
            run nextState comp             

    member this.Return(a) = Comp (fun s -> a, s)

let random = RandomBuilder()

And here is how you use it:

let randomInt =
    Comp <| fun state ->
        let rnd = System.Random(state)
        rnd.Next(0,1000), rnd.Next()

let rand =
    random {
        let! a = randomInt
        let! b = randomInt
        let! c = randomInt
        return [a; b; c ]
    }

rand.Run(0)
|> printfn "%A"

In this version you separately build up the computation (and store it inside the Random type), and then you run it passing in the initial state. Look at how types on the builder methods are inferred and compare them to what MSDN documentation describes.

Edit: Constructing a builder object once and using the binding as an alias of sorts is mostly convention, but it's well justified in that it makes sense for the builders to be stateless. I can see why having parameterized builders seems like a useful feature, but I can't honestly imagine a convincing use case for it.

The key selling point of monads is the separation of definition and execution of a computation.

In your case - what you want to be able to do is to take a representation of your computation and be able to run it with some state - perhaps 0, perhaps 42. You don't need to know the initial state to define a computation that will use it. By passing in the state to the builder, you end up blurring the line between definition and execution, and this simply makes the workflow less useful.

Compare that with async workflow - when you write an async block, you don't make the code run asynchronously. You only create an Async<'a> object representing a computation that will produce an object of 'a when you run it - but how you do it, is up to you. The builder doesn't need to know.

Late reply, but many thanks for this! I'm finally beginning to understand this stuff, writing out the bind call nesting really helps. The machinery around the workflow to get a nice interface to it is also very useful. One question though, there seem to be a convention to not use the builder type directly, but rather make an object and use that. Any specific reason for that? I would think that using the type directly gives you a useful opportunity to provide for example initial state (like I did). — monoceres, Jul 14 '15 at 16:50
@monoceres: I gave you a reply in the edit (since it grew to be quite long). — scrwtp, Jul 14 '15 at 19:42

Random / State workflow in F#

1 Answers1