tl;dr: Make invalid regular expression strings and attempts to access non-existent capture groups a compile-time error, thanks to the Regex type provider.
Either type, also called
Choice in F# parlance, is a way of representing a value that can be either one of two types. This can be extremely useful. For example, retrieving a date of birth from a textbox could be expressed as
Either<ParseException, DateTime>. In other words, the result is a value that is either a valid
DateTime, or is a
Being a hasty introduction this post is not going to do justice to how useful this type is, but hopefully some of its goodness will shine through despite my rambling prose. :)
Most of the time .NET GC just works. Occasionally when dealing with things like interop with unmanaged code, things go wrong. Things I learned today from this aforementioned going wrong include:
- Variable scope can be greater than the lifetime of the object it points to
- Mark-and-sweep GC marks objects for survival, not for collection
GC.KeepAlive(object)is a no-op
- Finalisers from collected objects can break active objects
- Use a release configuration build for reproducing GC issues, running without the debugger attached
- Non-deterministic finalisation makes me confused
One thing I’ve battled with in my OO, TDD adventures is useless abstractions. I find it very easy to churn out class like the
PaddedSingleWidgetList described below in an attempt to follow the Single Responsibility Principle and write testable code, but in doing so I end up with lots of classes that don’t really make much sense in isolation, and that are not inherently reusable. (Just me?)
Instead of my usual approach of splitting a problem in terms of somewhat arbitrarily chosen responsibilities, what if we divided it into the parts that need knowledge of specific types, and the parts that can have the specific types abstracted away?
Last post we looked at using a less general form of the Free monad to purely represent side-effects in F#. Because Haskell supports higher-order polymorphism it makes using this approach much easier. Here is the complete example from that post, rewritten in Haskell:
Previously we looked at using IO without side-effects in C# by deferring the execution of side-effects. Rather than immediately performing IO, we wrapped up side-effecting operations in an
IO type and used combinators like
SelectMany to work within that type, so we could use
IO values without having to give up the benefits of pure functions by executing the side-effect.
This is a useful technique, but it has the drawback that the
IO instances assembled with these combinators are opaque – there is no way for us to inspect them and work out what the represent. We know an
IO<String> is some IO operation that will result in a string, but is it
In this post we’ll look at another way of representing side-effecting (and other) operations that addresses this drawback.
"I hope that one day, the business needs a string calculator. Then I can say "This is the moment I trained for my whole life!"" – Michael Stum (@mstum), tweet
An effective string calculator is obviously indispensable to any software project. I have attempted this before, but one can never be too prepared, and so I thought I’d revisit it. But this time I thought I’d try it using Parsec, a parser combinator library for Haskell.
filter and it’s monadic cousin
This is my attempt to understand the relevance of the differences between these two functions. Please leave a comment to let me know about anything I’ve misunderstood. :)
I have avoided seriously trying F# for years now, mainly because:
- F# was described as a "functional programming language", and I didn’t know FP. I was keen to learn FP, but prioritised learning more about OO design and patterns that seemed more immediately applicable to my everyday work.
- The syntax looked really confusing.
- Whenever I heard F# mentioned it was in the same breath as "financial data processing" or some other niche area that seemed to have little to do with the types of applications I wrote.
I carried these hastily-acquired preconceptions around for years, until this year I needed to do a small application for work, and decided to try it in F#. To my surprise I found that none of these preconceptions were valid! What’s more, I actually quite enjoyed it. F# seemed to let me do everything I would normally do in C#, only with less code, and with more powerful features waiting in the wings should I want to dabble with them.
So in this post I wanted to go through why these assumptions were false, just in case they are holding you back too. I think F# is well worth trying out for every developer that does anything with .NET, but rather than trying to sell you on why you should try F#, I’m going to focus on the reasons you may think that you shouldn’t, and trust your natural developer curiosity to do the rest. ;)