doxyer Liu's List: F# Computation Expression

• • While for repetition.
   
  • TryWith and TryFinally for handling exceptions.
   
  • Use for managing disposables
• all the methods discussed here rely on delays being used.
• this is the key to understanding a "while" loop -- it can be expanded in the same way
• One question that is immediately apparent is: what should be returned when the while loop test fails?
• Finally, the pseudo-code can be simplified by collapsing it into a recursive function
• And indeed, this is the standard "boiler-plate" implementation for While in almost all builder classes
• In other words, the use! keyword triggers both a Bind and a Using.
• Similar to the other methods, we have a body, or continuation part, of the "using" expression, which is evaluated once.

6 more annotations...

• What happens if we want to delay the whole workflow itself until needed
• If we analyze this using the terminology of the earlier post, we can see that the types used are
• • Wrapper type: 'a option
   
  • Internal type: 'a option
   
  • Delayed type: unit -> 'a option
• But what happens if we refactor the code into a child workflow
• The output shows that the child workflow was evaluated even though it wasn't needed in the end.
• you can create a new Maybe type by using a maybe expression!
• With Zero and the builder instance, you can create new instances of the type even if they don't do anything.

• If we analyze this new builder using the terminology of the earlier post, we can see that the types used are:

    
   
  • Wrapper type: Maybe<'a>
   
  • Internal type: 'a option
   
  • Delayed type: unit -> 'a option
• An alternative design might use Maybe<'a> as the internal type as well, which would make things more consistent, but makes the code harder to read
• The delayed implementation above does ensure that the child workflow is only be evaluated on demand, but it does not stop it being run twice
• Summary: Immediate vs. Delayed vs. Lazy
• Is the code in the expression cheap to execute, and without important side-effects? If so, stick with the first, immediate version.
• Is the code in the expression expensive to execute, might the result vary with each call (e.g. non-deterministic), or are there important side-effects? If so, use the second, delayed version
• F# does not attempt to be a purely functional language, so almost all F# code will fall into one of these two categories.
• Whatever your choice, do make it clear in the documentation

13 more annotations...

• Ultimately, this detour will lead to a dead end, but I hope the journey might provide some more insight into good practices for designing your own computation expressions
• But as a consequence of the generics, the Return method can't be overloaded any more!

• the extra features needed to make the workflow more efficient, by controlling when expressions get evaluated
• return and yield do not generate an early return from a computation expression. The entire computation expression, all the way to the last curly brace, is always evaluated and results in a single value.
• This is a problem, because you might get unwanted side effects (such as printing a message in this case)
• wrap part 2 of the expression in a function and only call this function when needed
• And this is exactly what the Delay method is for. Any result from Return or Yield is immediately wrapped in a "delay" function like this, and then you can choose whether to run it or not.
• The Run method exists for exactly this reason. It is called as the final step in the process of evaluating a computation expression, and can be used to undo the delay
• • The bottom (or innermost) expression is delayed.
   
  • If this is combined with a prior expression, the output of Combine is also delayed.
   
  • And so on, until the final delay is fed into Run.
• Delay and Combine can use internal types that are not exposed to clients of the computation expression

6 more annotations...

• returning multiple values from a computation expression using the Combine method
• In other words, we now have two values in our computation expression. And then the obvious question is, how should these two values be combined to give a single result for the computation expression as a whole?
• Let me repeat that. Every part of the computation expression is always evaluated -- there is no short circuiting going on
• yield is naturally used as part of sequence generation
• The Combine method is just list concatenation.
• I would strongly encourage you to play around with this a bit until you are clear on what is going on behind the scenes.
• A subtle but important point is that they are combined "backwards", starting from the last value.
• There are a number of common ways of doing this, depending on the concepts that the workflow supports
• this technique is very convenient when doing parsing or evaluating a sequence of (possibly unsuccessful) operations
• If the workflow has the concept of sequential steps, then the overall result is just the value of the last step, and all the previous steps are evaluated only for their side effects.
• The difference from a normal bind is that the continuation has a unit parameter, and evaluates to b. This in turn forces a to be of type WrapperType<unit> in general
• First, note that Combine does not have to give the same result if the parameters are swapped. That is, Combine(a,b) need not be the same as Combine(b,a)
• So for a workflow that is strongly sequential, you could easily create a builder class with Combine, Zero, and Yield, say, without having to implement Bind and Return at all.
• And the "left-biased" combination (that is, only do the second expression if the first one fails)
• A symmetric combination operation is often written as ++ or <+>
• Combine can be exposed as a standalone function

14 more annotations...

• we'll work from the bottom up, starting with a simple workflow and adding methods only as needed to solve a problem or an error.
• the MSDN documentation for computation expressions is meagre at best, and although not inaccurate, can be misleading
• For an detailed overview of the concepts behind computation expressions, a great resource is the paper by Tomas Petricek and Don Syme. And for the most accurate up-to-date technical documentation, you should read the F# language specification
• The MSDN documentation uses this more precise approach. It uses "pattern" and "expression" in the definitions, such as let! pattern = expr in cexpr
• There is not always a one-to-one correspondence, but generally, to support the syntax for a special operation, you must implement a corresponding method in the builder clas
• the operations without a "!" always have unwrapped types on the right hand side, while the ones with a "!" always have wrapped types.
• In normal F#, do is just like let, except that the expression doesn't return anything useful (namely, a unit value)
• • 例如, Option type 带来的各种 try 操作.
    函数组合带来的各种函数快捷写法

  • F#概念太多, 需要一个 mindmap 来整理
• What is the smallest computation expression you can get away with?
• that in this particular case we haven't returned anything explicitly, yet the computation expression as a whole must return a wrapped value.
• Does the workflow have a concept of "success" or "failure"? If so, use the "failure" value for Zero
• In normal F# code, an expression that did return anything explicitly would evaluate to unit. So to parallel this case, your Zero should be the wrapped version of unit.
• Is the workflow primarily concerned with manipulating data structures? If so, Zero should be the "empty" data structure.
• Remember, you not required to have a Zero, but only if it makes sense in the context of the workflow.
• if return and yield are basically the same thing, why are there two different keywords? The answer is mainly so that you can enforce appropriate syntax by implementing one but not the other. For example, the seq expression does allow yield but doesn't allow return, while the async does allow return, but does not allow yield
• yield should be used for sequence/enumeration semantics, while return is normally used once per expression.
• Things with bangs have wrapped types on the right hand side.

15 more annotations...

• Any type with a generic parameter can be used as a wrapper type
• This rule and the next are about not losing information as you wrap and unwrap the values
• This rule is required for composition to behave properly
• There is no one-to-one correspondence between the wrapper type and the unwrapped type!
• This is where the "wrapper type" analogy becomes a bit misleading.
• If we treat lists and sequences as a special case, we can add some nice syntactic sugar to replace let! with something a bit more natural.
• every computation expression must have an associated wrapper type
• The short answer to this is that you can treat any type as its own "wrapper". But there is another, deeper way to understand this.
• One way to think about List<T> is that it is a function, not a type.
• the input values are types (say int or string) and the output values are other types (List<int> and List<string>)
• The "identity" function for types fits our definition and can be used as a wrapper type
• You can easily compose computation expressions, because the output of a Return can be fed to the input of a Bind

10 more annotations...

• The let! has "unwrapped" the option before binding it to the value
• the return has "wrapped" the raw value back into an option.
• one of the major uses of computation expressions: namely, to implicitly unwrap and rewrap values that are stored in some sort of wrapper type.
• These are not just special cases. In fact, every computation expression must have an associated wrapper type
• The DbResult type we created is more than just a simple type for return values; it actually has a critical role in the workflow by "storing" the current state of the workflow
• In other words, for some type T, the Return method just wraps it in the wrapper type.
• Even if the function is not applied, Bind must still return a wrapped U.
• there is nothing stopping the maybe binding function from taking an int and returning a Option<string>, or taking a string and then returning an Option<bool>. The only requirement is that it always return an Option<something>.

• a key benefit:

    
   
  • the output of a Return can be fed to the input of a Bind
• you can put a "child" workflow on the right hand side of a let! expression.
• The solution is a variant on return called return!, which takes a wrapped type as input and returns it.
• The corresponding method in the "builder" class is called ReturnFrom
• This post introduced wrapper types and how they related to Bind, Return and ReturnFrom, the core methods of any builder class.

11 more annotations...

• computation expressions are just a way to create nice syntax for something that we could do ourselves.
• In fact, you can turn it into an infix operation like this
• this symbol ">>=" is the standard way of writing bind as an infix operator.
• There is a moral in this -- don't be too hasty to write your own functions. There may well be library functions that you can reuse.

2 more annotations...

• the called function always decides what to do
• A continuation is simply a function that you pass into another function to tell it what to do next
• With the power of continuations at our disposal, we can use the same divide function in three completely different ways, depending on what the caller wants
• the caller never has to catch an exception from divide anywhere. The caller decides whether an exception will be thrown, not the callee.
• by passing functions around like this, we can use all our favorite functional techniques such as composition, partial application, and so on
• In the contination passing style, though, there is no "master controller". Instead there is a sort of "pipeline", not of data but of control flow, where the "function in charge" changes as the execution logic flows through the pipe.
• If you have ever attached a event handler to a button click in a GUI, or used a callback with BeginInvoke, then you have used this style without being aware of it.

• Why bother to wrap the pipe into a function?

    

  The answer is that we can add extra code in the pipeInto function to do stuff "behine the scenes", just as in a computation expression
• we can think of let as a nice syntax for doing continuations behind scenes

7 more annotations...

• I will try to avoid using the forbidden m-word
• Once you are on the other side, it is all obvious, but to someone on this side, it is baffling.
• let's look at a few trivial examples that show the same code before and after using computation expressions.
• But using a mutable value is bad practice, as we know. The appropriate functional way to do this is to pass the state between each function, rather than having a globally scoped value.
• This code is much better from a functional design point of view, but passing the counter value around makes the code seem more complicated that it should be
• What all the cases have in common is that the computation expression is "doing something behind the scenes" between each expression
• like a post-commit hook for SVN or git, or a database trigger that gets called on every update
• Not all computation expression implementations are workflows.
• I would say that maybe is the workflow we are using, and the particular chunk of code { let! a = .... return c } is the computation expression

7 more annotations...

• Once you are on the other side, it is all obvious, but to someone on this side, it is baffling