Extended computation expressions without for..in..do

Question

What I mean by extended computation expressions is computation expressions with custom keywords defined via CustomOperation attribute.

When reading about extended computation expressions, I come across very cool IL DSL by @kvb:

let il = ILBuilder()

// will return 42 when called
// val fortyTwoFn : (unit -> int)
let fortyTwoFn = 
    il {
        ldc_i4 6
        ldc_i4_0
        ldc_i4 7
        add
        mul
        ret
    }

I wonder how the operations compose without using for..in..do construct. My gut feeling is that it starts with x.Zero member, but I haven't found any reference to verify that.

If the example above is too technical, here is a similar DSL where components of a slide are listed without for..in..do:

page {
      title "Happy New Year F# community"
      item "May F# continue to shine as it did in 2012"
      code @"…"
      button (…)
} |> SlideShow.show

I have a few closely related questions:

• How does one define or use extended computation expressions without For member (i.e. provide a small complete example)? I don't worry much if they aren't monads any longer, I'm interested in them in developing DSLs.
• Can we use extended computation expressions with let! and return!? If yes, is there any reason of not doing so? I ask these questions because I haven't encountered any example using let! and return!.

Answer 1

I'm glad you liked the IL example. The best way to understand how expressions are desugared is probably to look at the spec (though it's a bit dense...).

There we can see that something like

C {
    op1
    op2
}

gets desugared as follows:

T([<CustomOperator>]op1; [<CustomOperator>]op2, [], fun v -> v, true) ⇒
CL([<CustomOperator>]op1; [<CustomOperator>]op2, [], C.Yield(), false) ⇒
CL([<CustomOperator>]op2, [], 〚 [<CustomOperator>]op1, C.Yield() |][], false) ⇒
CL([<CustomOperator>]op2, [], C.Op1(C.Yield()), false) ⇒
〚 [<CustomOperator>]op2, C.Op1(C.Yield()) 〛[] ⇒
C.Op2(C.Op1(C.Yield()))

As to why Yield() is used rather than Zero, it's because if there were variables in scope (e.g. because you used some lets, or were in a for loop, etc.), then you would get Yield (v1,v2,...) but Zero clearly can't be used this way. Note that this means adding a superfluous let x = 1 into Tomas's lr example will fail to compile, because Yield will be called with an argument of type int rather than unit.

There's another trick which can help understand the compiled form of computation expressions, which is to (ab)use the auto-quotation support for computation expressions in F# 3. Just define a do-nothing Quote member and make Run just return its argument:

member __.Quote() = ()
member __.Run(q) = q

Now your computation expression will evaluate to the quotation of its desugared form. This can be pretty handy when debugging things.

Answer 2

I have to admit I do not fully understand how computation expressions work when you use query expression features like the CustomOperation attribute. But here are some remarks from some my experiments that might help....

Firstly, I think it is not possible to freely combine standard computation expression features (return! etc.) with custom operations. Some combinations are apparently allowed, but not all. For example, if I define custom operation left and return! then I can only use the custom operation before return!:

// Does not compile              // Compiles and works
moves { return! lr               moves { left 
        left }                           return! lr }

As for the computations that use only custom operations, most common cusotom operations (orderBy, reverse and this kind) have a type M<'T> -> M<'T> where M<'T> is some (possibly generic) type that represent the thing we're building (e.g. a list).

For example, if we want to build a value that represents a sequence of left/right moves, we can use the following Commands type:

type Command = Left | Right 
type Commands = Commands of Command list

Custom operations like left and right can then transform Commands into Commands and append the new step to the end of the list. Something like:

type MovesBuilder() =
  [<CustomOperation("left")>]
  member x.Left(Commands c) = Commands(c @ [Left])
  [<CustomOperation("right")>]
  member x.Right(Commands c) = Commands(c @ [Right])

Note this is different from yield which returns just a single operation - or command - and so yield needs Combine to combine multiple individual steps if you use custom operations, then you never need to combine anything because the custom operations gradually build the Commands value as a whole. It only needs some initial empty Commands value that is used at the beginning...

Now, I would expect to see Zero there, but it actually calls Yield with unit as an argument, so you need:

member x.Yield( () ) = 
  Commands[]

I'm not sure why this is the case, but Zero is quite often defined as Yield (), so perhaps the goal is to use the default definition (but as I said, I'd also expect to use Zero here...)

I think combining custom operations with computation expressions makes sense. While I have strong opinions on how standard computation expressions should be used, I do not really have any good intuition about computations with custom operations - I think the community still needs to figure this out :-). But for example, you can extend the above computation like this:

member x.Bind(Commands c1, f) = 
  let (Commands c2) = f () in Commands(c1 @ c2)
member x.For(c, f) = x.Bind(c, f)
member x.Return(a) = x.Yield(a)

(At some point, the translation will start requiring For and Return, but here they can be defined just like Bind and Yield - and I do not fully understand when is which alternative used).

Then you can write something like:

let moves = MovesBuilder()

let lr = 
  moves { left
          right }    
let res =
  moves { left
          do! lr
          left 
          do! lr }