Almost a year ago now, I wrote up a blog post on using FsCheck. I still rate it as an excellent tool, but unfortunately we don't manage to use it that much. The reasons for this basically boil down to the fact that a) we tend to forget it exists and b) a good deal of our code is written in C# or VB.net, and the original API is not very friendly from those languages.

So as part of the 15below developer education sessions we're going to try an exercise to see if we can bring a bit more property based testing into our code base!

In my investigations into type providers, I started digging into a feature of F# called quotations. These blur the boundary between code and data; a representation of an expression tree that you can then evaluate or manipulate.

Why is this useful? Well; it's used in a number of places in various F# libraries. As mentioned above, type providers use them as a mechanism for providing the invocation code for the types that are being provided. The compiler can then take that expression tree and turn in into clr code.

They can also be useful as a way of defining code within your F# that can then be translated into other programming languages. The linq to sql implementation does this (turning your linq into SQL, fairly obviously!) while the FunScript project compiles your F# quotations into JavaScript.

So; linked features, often used in concert: quotations allow you to generate expressions at runtime, manipulate them at run time and evaluate them at run time - where evaluation covers everything from running the code on the clr to outputting it as a different language.

This post follows on directly from Going Functionally SOLID

In our first session looking at SOLID and functional programming, we tried to apply some SOLID principles to an example piece of code.

We ended up with a set of interfaces like those below, and robot classes could then implement the interfaces to define their capabilities and state. I mentioned the example code was for a giant robot game, yes?

Brian McKenna posted an interesting video and gist on implementing a type safe printf in Idris with dependent types.

This led me down a nice little rabbit hole wondering if something similar could be achieved with an F# type provider.

With a bit of help from Tomas the final solution turned out to be surprisingly nice, although not quite so clean as the Idris original.

The one giant robot every programmer should know and love! Meet Big O!

For all your algorithmic complexity needs. And any giant mecha in need of a good pounding.

And now, back to your regularly scheduled blog post…

Inspired both by Mark Seemann's excellent blog post and by my ongoing campaign to introduce functional programming techniques to 15below developers who aren't familiar with them yet, I decided it was time to run a mini-series on applying good principles like SOLID in a functional world.

We run weekly one hour "Developer Education" sessions. For this series I started with a badly written piece of code (it came naturally, given I had limited prep time…) in a style of someone who has kind of heard about SOLID and functional programming:

• SOLID: "So, eh, I need some interfaces and things. Concrete bad, interface good. In wonder what the whole DI thing is?"
• Functional: "And, erm. Chainable functions? Fluent APIs, maybe? That's kind of functional, right?"

This post follows on directly from my previous post Type Providers from the Ground Up. I highly recommend that you read that first, and check out the relevant example code from GitHub.

It's also a bit epic… grab yourself a coffee before you start.

So we have a working type provider now. Unfortunately, we're missing out on at least two major features that your new type provider will almost certainly want to make use of.

The first is that in our example, we're reading the metadata that defines our types from a fixed file location. In almost every real life case, you will want to be able to parametrize your provider to specify where this instance is getting it's metadata from.

The second is that in many cases getting the metadata will be slow, and the number of types available to generate may be very large. In these situations, you really want to be able to only generate the types that are required as they are requested, especially because this will reduce the size of the final compiled output. This is particularly important for type providers that read from large network based data sources like the Freebase provider.

We'll take the second first, because it's easy - and we like easy…

As of a few days ago, the embedded module was merged into Suave master. Enjoy!

I'm a great fan of Suave for simple web development in F#. I highly recommend checking out the site for details, but in the mean time I'd like to share a little trick I've been using for rapid prototyping that I'm finding very useful.

The Suave.Http module contains a few helpers for serving static files from disk. Unfortunately, depending on use case and deployment strategy, relying on the location of a bunch of files on disk can be problematic.

So (open source to the rescue!) I cracked open the code and wrote a small alternative implementation that serves files from the current assembly's embedded resources. I'm finding it especially useful for single page JavaScript apps where you have a small number of resources and then a lot of end points providing api functionality.

Setting up your website looks something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

module Website
open System
open Suave.Http
open Suave.Types
open Embedded

let app =
    choose [
        // serve the embedded index.html for "/"
        GET >>= url "/" >>= resource "index.html"
        // check if the request matches the name of an embedded resource
        // if it does, serve it up with a reasonable cache
        GET >>= browse_embedded
        // If it doesn't, try and trigger your api end points
        GET >>= url "/json" >>== (fun _ -> serveJson <| makeData())
        GET >>= url "/carrier" >>== (fun _ -> getCarrierCodes ())
        // Nothing else has worked - 404
        NOT_FOUND "Sorry, couldn't find your page"
    ]

web_server default_config app

And the embedded module looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

module Embedded

open System
open System.IO
open System.Reflection
open Suave
open Suave.Http
open Suave.Types
open Suave.Socket

let private ass = Assembly.GetExecutingAssembly()

let private resources =
    ass.GetManifestResourceNames()

let private CACHE_CONTROL_MAX_AGE = 600

let private lastModified = DateTime.UtcNow

let private send_embedded resourceName r =
    let write_embedded file (r : HttpRequest) = async {
      use s = ass.GetManifestResourceStream(resourceName)

      if s.Length > 0L then
        do! async_writeln r.connection (sprintf "Content-Length: %d" s.Length) r.line_buffer

      do! async_writeln r.connection "" r.line_buffer

      if s.Length > 0L then
        do! transfer_x r.connection s }

    async { do! response_f 200 "OK" (write_embedded resourceName) r } |> succeed

let resource resourceName =
    if resources |> Array.exists ((=) resourceName) then
      let send_it _ =
        let mimes = mime_type <| IO.Path.GetExtension resourceName
        #if DEBUG
        set_mime_type mimes
        >> send_embedded (resourceName)
        #else
        set_header "Cache-Control" (sprintf "max-age=%d" CACHE_CONTROL_MAX_AGE)
        >> set_header "Last-Modified" (lastModified.ToString("R"))
        >> set_header "Expires" (DateTime.UtcNow.AddSeconds(float(CACHE_CONTROL_MAX_AGE)).ToString("R"))
        >> set_mime_type mimes
        >> send_embedded (resourceName)
        #endif
      warbler ( fun (r:HttpRequest) ->
        let modified_since = (r.headers ? ``if-modified-since`` )
        match modified_since with
        | Some v -> let date = DateTime.Parse v
                    if lastModified > date then send_it ()
                    else NOT_MODIFIED
        | None   -> send_it ())
    else
      never

let browse_embedded : WebPart =
    warbler (fun req -> resource (req.url.TrimStart([| '/' |])))

@ad3mar if you feel like rolling this into Suave, you can consider it licenced under what ever is most convenient. An official licence file would make me much happier using Suave in production, by the way (hint, hint).

Edit: ad3mar has pointed out in the comments that Suave is already Apache2 licensed, I just failed to find the file last time I looked.

While type providers are incredibly powerful, the ProvidedTypes api for creating them is sometimes a bit rough around the edges. And not always as functional as you might hope.

At some point I'd like to do something about that, but for the moment I'm just going to collect a few helpful tips and hints (mostly for own reference).

Tip one is in the case where you have XmlDocs to add to ProvidedTypes, ProvidedMethods and ProvidedProperties; in our case we have an optional description field in our metadata and the boiler plate was getting tiresome.

1
2
3
4
5

let inline addDoc (desc : Descriptor) def =
    match desc.Description with
    | Some d ->
        (^T : (member AddXmlDoc : string -> unit) (def, d))
    | None -> ()

This function takes a Descriptor with a string option Description field and any def with an AddXmlDoc member with the noted signature - and adds description as the xml doc if it exists.

Apparently I should be able to do inline F# code using one of the Octopress plugins, rather than having to use gists every where.

Let's try it:

1

let hello = "world"

Thanks Gustavo

Only issue is that having Python 3.x installed broke Octopress' Pygments support. Which kept me going for a while…

Given I'm not currently doing any Python development, a uninstall and adding 2.7 to the path did the job.

This post is part of a series: part 2 follows on directly from this post.

In the ground tradition of blog posts as both documentation and augmented memory, I've just added our first Type Provider to the code base. Time to write up the details before a) I forget them and b) anyone else needs to modify the code.

So, first things first. Before we get to the actual problem space at hand, let's try and provide a type. Any type…

1) Create yourself a new Visual Studio F# library project (2012 or up should work).

2a) Install the F# TypeProvider Starter Pack or

2b) add ProvidedTypes.fs and ProvidedTypes.fsi to the project as the first couple of files.

In either case, make sure that the .fsi file appears before the .fs file in your project listing, and that both appear before any type provider code - you will probably have to manually re-order them.

These are provided as code files rather than as compiled dlls due to complications with security and AppDomains when referencing dlls in the type provider assembly. For now just add them in - you really don't want to be re-creating the code in there by hand.

3) Replace the contents of Library1.fs with something like this:

1
2
3
4
5
6
7
8
9
10
11

module Mavnn.Blog.TypeProvider

open ProviderImplementation.ProvidedTypes
open Microsoft.FSharp.Core.CompilerServices

[<TypeProvider>]
type MavnnProvider (config : TypeProviderConfig) as this =
    inherit TypeProviderForNamespaces ()

[<assembly:TypeProviderAssembly>]
do ()

So, that's great and it builds. We have a type provider class and an assembly that knows it's a type providing assembly. Unfortunately, it doesn't actually provide any types yet. Let's try it.