Monthly Archives: September 2009

F#: Generic Fold

The fold functions in functional languages are very powerful constructs, but how about when you want a different function applied to the first element, or to the last? What about when the sequence is empty? Rather than solving this problem repeatedly, I have written a few functions to cover the range of cases. As I wrote these, I found it interesting that the solutions for Array, Seq and List all look very different.

Continue reading

Advertisements

F#: Pipelined Monads – Solutions From the Community

I was actually quite pleased that I got my state/error monad working (F#: Pipelined Monads), but there was a far more elegant solution staring me in the face. Thanks to other members of the F# community, I have reverted my code back to how it was and added two operators. In doing so the code is now far more elegant. Read on to see more, but thanks again to:

Continue reading

F#: Pipelined Monads

Update (12 September 2009): The community has provided a more elegant solution to this problem. See my more recent post for more details here: F# Pipelined Monads – Solutions From the Community. Thanks go to Keith Battocchi and Felix (felixmar on hubFS) for the revised solution. I have left this post unchanged and I advise you to use the revised solution in your own projects.

I recently completed my own construction of a couple of monads that I am using in a mini-project. I like the way that I am able to compose functions returning monadic values by using let! and do! directly. However, I was frustrated by the need to use multiple let! statements when I needed to chain constructs into a pipeline, for example:

let result = myBuilder {
  let result1 = initialValue
  let! r2 = r1 |> f1
  let! r3 = r2 |> f2
  let! r4 = r3 |> f3
  return r4 }

It is important to use let! because each step in the pipeline is allowed to fail. More generally, the behaviour required is that bind must be incorporated into the pipeline. Additionally, the proliferation of intermediary variables greatly increased the possibility of error in my code because I might have referred to one of the intermediate results, rather than the most recent result. Compare this to a non-computation expression version:

let result = 
     initialValue
  |> f1
  |> f2
  |> f3

The challenge before me was could I do any better?

Continue reading

F#: Delayed, Compositional Maybe Monad (Workflow) – Full Source

There are some good examples of the maybe monad in F# based on the option ‘a type. However, this approach has some shortcomings. This is a short post with code that I am using to provide the semantics of the maybe monad in F#.

Continue reading

F#: Custom Value Types with Controlled Zero Value Semantics

So, you want to create a value type? Easy, just use the [<Struct>] attribute to mark your type. Oh, but you want a non-default constructor. Well that is okay too. Ah, but you want an immutable type that can handle the default constructor? Now that is interesting…

Continue reading

F#: Custom Monad (Workflow) Development

It is my experience that learning how to develop monads is hard. I could follow the theory, and I thought I could even read example code, but when I attempted to actually write my own then I found it hard to marry the implementation and the theory. If that is you experience, then I hope this post will help a little.

Continue reading

F#: Nested Data Structures, Enumeration and Sequence Comprehensions

I have been working on a business data model for my WPF demo application (which I hope to begin describing soon). One of my requirements for this was a nested data structure to model a namespace hierarchy. Doing this in an imperative way was easy but my goal was to use immutable data structures to support a functional-programming approach to the data. Eventually, I settled on a nested Map structure with an F# record data type to represent the underlying data. Structurally, this was similar to how I would have approached it from an imperative perspective, but this was after several other attempts using custom data structures (abstract syntax trees and other approaches) had proven too inflexible to the demands of the application.

A second requirement for this data structure was abstraction. I did not want the internal data structure to be exposed to client code. Therefore, I needed to provide custom enumeration support. This post describes two approaches to this.

Continue reading