INTRODUCING LA NGUA GE-ORIEN TED PROGRAM MIN G in Font

Encode PDF417 in Font INTRODUCING LA NGUA GE-ORIEN TED PROGRAM MIN G

The following demonstrates that two terms have equivalent NNF normal forms: > let t1 = Not(And(Not(Var("x")),Not(Var("y"))));; val t1 : Prop > fsi.AddPrinter(showProp);; > t1;; val it : Prop = not (not x && not y) > let t2 = Or(Not(Not(Var("x"))),Var("y"));; val t2 : Prop > t2;; val it : Prop = not (not x) || y > (t1 = t2);; val it : bool = false > NNF t1;; val it : Prop = x || y > NNF t2;; val it : Prop = x || y > NNF t1 = NNF t2;; val it : bool = true

In 3 we introduced a useful notation for generating sequences of data, called sequence expressions. For example: > seq { for i in 0 .. 3 -> (i,i*i) };; val it : seq<int * int> = seq [ (0,0); (1,1); (2,4); (3,9) ] Sequence expressions are used extensively throughout this book. For example, in 15 we will use sequence expressions for queries that are executed on a database. It turns out that sequence expressions are just one instance of a more general construct called computation expressions. These are also called workflows, though they bear only a passing similarity to the workflows used to model business processes. The general form of a computation expression is builder { comp-expr }. Table 9-2 shows the primary constructs that can be used within the braces of a computation expression and how these constructs are de-sugared by the F# compiler given a computation expression builder b.

The three most important applications of computation expressions in F# programming are as follows: General-purpose programming with sequences, lists, and arrays Parallel, asynchronous, and concurrent programming using asynchronous workflows, discussed in detail in 13 Database queries, by quoting a workflow and translating it to SQL via the .NET LINQ libraries, a technique we ll show how to use in 15 In this section, we cover briefly how computation expressions work through some simple examples.

let! pat = expr in cexpr let pat = expr in cexpr use pat = expr in cexpr use! pat = expr in cexpr do! expr in cexpr do expr in cexpr for pat in expr do cexpr while expr do cexpr if expr then cexpr1 else cexpr2 if expr then cexpr cexpr1 cexpr2 return expr return! expr

b.Bind(expr,(fun pat -> cexpr )) b.Let(expr,(fun pat -> cexpr )) b.Using(expr,(fun pat -> cexpr )) b.Bind(expr,(fun x -> b.Using(x,fun pat -> cexpr ))) b.Bind(expr,(fun () -> cexpr )) b.Let(expr,(fun () -> cexpr )) b.For(expr,(fun pat -> cexpr )) b.While((fun () -> expr),b.Delay(fun () -> cexpr )) if expr then cexpr1 else cexpr2 if expr then cexpr else b.Zero() v.Combine( cexpr1 , b.Delay(fun () -> cexpr2 )) b.Return(expr) expr

Note If you ve never seen F# workflows or Haskell monads before, then you may find workflows take a

bit of getting used to, since they give you a way to write computations that may behave and execute quite differently than normal programs.

Computation expressions are the F# equivalent of monadic syntax in the programming language Haskell. Monads are a powerful and expressive design pattern and are characterized by a generic type M<'a> combined with at least two operations: bind : M<'a> -> ('a -> M<'b>) -> M<'b> return : 'a -> M<'a> These correspond to the primitives let! and return in the F# computation expression syntax. Several other elements of the computation expression syntax can be implemented in terms of these primitives, though the F# de-sugaring process leaves this up to the implementer of the workflow, since sometimes derived operations can have more efficient implementations. Well-behaved monads should satisfy three important rules called the monad laws. You can find out more about these at http://www.expert-fsharp.com/Topics/ Workflows. F# uses the terms computation expression and workflow for three reasons. First, when the designers of F# talked with the designers of Haskell about this, they agreed that the word monad is a bit obscure and sounds a little daunting and that using other names might be wise. Second, there are some technical differences: for example, some F# workflows can be combined with imperative programming, utilizing the fact that workflows can have side effects not tracked by the F# type system. In Haskell, all side-effecting operations must be lifted into the corresponding monad. The Haskell approach has some important advantages: you can know for sure what side effects a function can have by looking at its type. However, it also makes it more difficult to use external libraries from within a computation expression. Third, F# workflows can be reified using F# quotations, giving a way to execute the workflow by alternative means, for example, by translation to SQL. This gives them a different role in practice, since they can be used to model both concrete languages and computational languages.