ndjango included in mvccontrib wiki

Published
by
alex p
on June 15, 2009
in Uncategorized
. 0 Comments

So the good folks over at mvccontrib have included NDjango in their documentation as a view engine for asp.mvc. After some discussion with Jeff Palermo and Jeremy Skinner, it was decided that rather than including the ASPMVCIntegration project in the MVCContrib libraries, they'll just put up a reference on their documentation page.

I'm really excited about this, as hopefully this will create more visibility for both NDjango and a mainstream use of F#. We'll see where this goes.

This, combined with some good feedback (so far, at least ;)) from the alt.net mailing list on bistro, there's a chance that we're on to something here...

bistro f# extensions go beta! and move to codeplex…

Published
by
alex p
on June 3, 2009
in Uncategorized
. 2 Comments

After some more work on the f# extensions project, we've decided that it's stable enough to start showing to people. To that end, we've moved it to a project on codeplex (here), and put up a beta release of it. It's built with the may ctp (1.9.6.16), so you'll need that installed, but the sample project (which is actually the subject of the post below) is included in the release, as a nice way to provide everything you need to get started, and give you an example app.

happy hunting!

oh, and for the time being (at least), the documentation will still stay on the bistro wiki.

On the heels of Google IO - playing with HTML5 and F# web services

Published
by
alex p
on June 2, 2009
in Uncategorized
. 0 Comments

I went to Google IO this past week, and they had a whole long spiel about the wonders of html5. Well... i've gotta admit - some of the stuff looked kinda cool, so i decided to play with it. I wrote a web serivice in bistro that returned a list of fibonacci numbers, and then a corresponding page that requested that list through jquery, and generated a tiling and then drew a fibonacci spiral over it:

The code for both was remarkably simple. On the service side, all i had to do was define a recursive function for generating fibonacci numbers (yes, it's not tail-recursive, i know, but i was lazy), and a simple controller for binding to the appropriate REST method:

 
let rec fibonacci a b rem =
    if (rem = 0) then [a]
    else [a] @ fibonacci b (a+b) (rem-1)
 
[<ReflectedDefinition>]
[<Bind("get /fib/{numbers}")>]
[<RenderWith(@"Templates\fibResult.django")>]
let fibCt (ctx: IExecutionContext) numbers =
    let fibNbrs = fibonacci 0 1 numbers
    fibNbrs
 

Prest-o change-o, we're done.

Now for the javascript. The majority of the code here is a rather weak attempt to figure out the tiling. My math skillZ are kinda rusty, and i know i should have defined objects for the squares, and dealt with alternating corners that way, but this did the trick:

 
function load() {
    var url = "/fib/" + $("input[name=iterations]").val();
    $.get(url, function(data) { render(data); }, "xml");
}
 
function render(data) {
    var drawFactor = parseInt($("input[name=magnification]").val());
 
    var canvas = $("#golden").get(0);
    var ctx = canvas.getContext("2d");
    ctx.clearRect(0, 0, canvas.width, canvas.height);
    ctx.strokeStyle = "#CCCC99";
    ctx.fillStyle = "#FFFFEE";
 
    var x = canvas.width / 2;
    var y = canvas.height / 2;
    var offsetX = 0;
    var offsetY = 0;
    var arcX = x, arcY = y;
 
    var elems = $(data).find("number");
 
    if (drawFactor == 0)
        drawFactor = Math.min(canvas.width, canvas.height) / (2 * (parseInt($(elems.get(elems.length - 1)).text()) + 1));
 
    for (var i = 1; i < elems.length; i++) {
        ctx.strokeStyle = "#CCCC99";
        ctx.fillStyle = "#FFFFEE";
 
        var last = elems.get(i - 1);
        var current = elems.get(i);
 
        var num = parseInt($(current).text()) * drawFactor;
        var lastNum = parseInt($(last).text()) * drawFactor;
        var idx = i-2;
 
        var startAngle, endAngle = 0;
        switch (idx % 4) {
            case 0:
                x += lastNum;
                y += lastNum - num;
                arcX = x, arcY = y;
                startAngle = Math.PI / 2;
                endAngle = Math.PI * 2;
                break;
            case 1:
                x -= num - lastNum;
                y -= num;
                arcX = x, arcY = y + num;
                startAngle = Math.PI * 2;
                endAngle = Math.PI * 3 / 2;
                break;
            case 2:
                x -= num;
                arcX = x + num, arcY = y + num;
                startAngle = Math.PI * 3 / 2;
                endAngle = Math.PI;
                break;
            case 3:
                y += lastNum;
                arcX = x + num, arcY = y;
                startAngle = Math.PI;
                endAngle = Math.PI / 2;
                break;
        }
 
        ctx.strokeRect(x, y, num, num);
        ctx.fillRect(x, y, num, num);
 
        if (idx < 0)
            continue;
 
        ctx.strokeStyle = "gray";
 
        ctx.beginPath();
        ctx.arc(arcX, arcY, num, startAngle, endAngle, true);
        ctx.stroke();
    }
}
 

Pretty straightforward, really. Notice the lack of work on getting the F# service up and running - just 4 lines of code and you're good.

I'm stoked.

I threw the whole "project" up under bistro samples - you can find the info here under the Examples tree.

first impressions: ndjango updated to the new f# ctp

Published
by
alex p
on May 21, 2009
in Uncategorized
. 1 Comment

so the second i post up the ndjango port, the new f# ctp hits the web... nice timing on my part ;). well, i can take a hint. i spent some time yesterday and branched off a new fork in the svn for a version that works against the new ctp. i still have to spend some time playing with it, but at first glance, the old code worked. There's quite a bit of library name change (moving away from ocaml naming conventions it seems like), but once the renaming was done, all of our unit tests ran just fine. I have to admit that i've grown used to the underscore notation for f# code, and seeing camel case throughout will take some getting used to. Also - I'm starting to see some functions renamed in a way that's less clear than before... hopefully the f# team won't fall into the trap of c# v java where some classes and methods were named differently just for the sake of being different (*cough stringbuilder/stringbuffer cough*). And why do away with the String module?

On another note, we updated the ndjango integrations projects to include a hook for asp.mvc. You should be able to use ndjango with it now, by just declaring a variable in your Global.asax and then instantiating it on app start. That'll load up the right dlls and hook in where necessary.

Putting it all together: F# on the web

Published
by
alex p
on May 20, 2009
in Uncategorized
. 1 Comment

The last few months have certainly been interesting. I was busy building an MVC framework, and decided to use NVelocity as the view. A friend pulled me aside, and (after slapping me for using a 6 year old, poorly-supported java port), said "take a look at the templating language in django". The rest, as they say, was history. Realizing how clean and simple the language was, I set out to build an implementation (of the template piece). As I was just starting to notice F#, i decided - why not? And so my first major project in F# was the core of the NDjango parser , a pure F# (and consequently .NET-friendly) implementation of the django templating language. Now, it's certainly gone through a number of iterations, so most of my early f#-n00b mistakes should have been excised.

The really interesting thing, though, is that as I was building this parser, I started to really get an appreciation for F#, and for it's uses in a more business-oriented environment. This was all coinciding with me building out Bistro, and so concepts merged. Bistro focuses on having multiple controllers, with well-defined inputs and outputs, service a single request. I started seeing parallels to functions - each controller can be viewed as a function with discrete parameters and tupled return values.

In c#, these concepts are relayed to the runtime through class members that are marked with scope and directionality attributes (request-level input parameter, session-level output parameter, etc). Well, with f#, and quotations, you can get away with not having to be that explicit. Whether something is an input parameter or an output parameter becomes easy to tell. The rest, can be handled through discriminated union markers (see earlier post). What that means is that I can write an F# function, and it becomes a controller, almost instantly:

 
[<ReflectedDefinition>]
[<Bind("get /home/index")>]
[<RenderWith("Views/Home/index.django")>]
let home_ct (ctx: IExecutionContext) =
    let Message = "Welcome to Bistro.FS!"
    Message
 

this controller has no input parameters, but has an output parameter called "Message" (yes, the resource name is pulled from the Quotation tree), of type string. We use defaults for most common behaviors - so that one right there is scoped to "request".

A more complex example

 
 
[<ReflectedDefinition>]
[<Bind("get /auth/changepassword")>]
[<RenderWith("Views/Account/register.django")>]
let do_change_pass_ct (ctx: IExecutionContext) (currentPassword: string form) (newPassword: string form)
    (confirmPassword: string form) (errors: Errors) =
    let currentPassword, newPassword, confirmPassword =
        currentPassword.Value, newPassword.Value, confirmPassword.Value
 
    let new_user =
        if validate_change_pass currentPassword newPassword confirmPassword (report_error errors) then
            try
                if membership_svc.ChangePassword(ctx.CurrentUser.Identity.Name, currentPassword, newPassword) then
                    ctx.Response.RenderWith "Views/Account/changePasswordSuccess.django"
                else
                    report_error errors null "The current password is incorrect or the new password is invalid."
            with | _ ->
                report_error errors null "The current password is incorrect or the new password is invalid."
 
    errors
 

This one validates some data that came from the form (currentPassword, newPassword and confirmPassword), and adds to the supplied errors collection, which it then returns as a request parameter.

The semantics of defining controller behavior become incredibly simple. Bistro already strives for smaller controllers with well-defined functions. This just takes advantage of it. Now you can write your controller tier in f#, and it actually makes sense there. If you think about it - the controller tier is effectively small data processing. It's validating and transforming input data, and then relaying it to the model, which can be in c# or whatever other language you chose. With NDjango in the mix, your view is guaranteed to be free of business logic, and your separation of concerns becomes complete!

I'm sure a lot of this makes less sense on this blog than it does in my head - I've been living this for the past few months, so i'm sure some of the connecting dots didn't make it on here, but if you're interested, take a look at some of the writeups that i've put together:

Bistro itself is here, the FSharpExtensions component is here, and NDjango is here

The FSharpExtensions library still has some issues, (like url parameter values can't be option types right now, and a few others), plus the performance piece needs some work, but it's a start, and we'll be working on it. Already it performs within 90% of its c# counterpart, and that's with full-on reflection lookups on every request. Once that stuff is cached up, it'll be on-par if not faster.

As always, I welcome all feedback, on any of these projects.

10 cool things about f# that aren’t functional-specific

Published
by
alex p
on May 10, 2009
in Uncategorized
. 5 Comments

i'm going to be speaking about f# and applicability outside the lab in a few days (see here), so i figured i'd put this up here as part of my prep for the meeting. so - 10 cool things about f# as a .net/oo language

  1. #light syntax. Indentation based syntax, while i'm sure viewed as the bane of our existence, is amazingly easy to deal with, given a proper editor and assistance. Yes, sometimes it's quirky, but not having to look at 40 pages of curly braces is worth it. You simply end up writing less code, seeing more code per screenful, and writing code that's easier to read.
  2. type inference. F# is the ultimate combination - it's a statically typed language, that reads like a dynamic one. That's because the F# compiler infers value and parameter types from their usage. There are mechanisms to specify data types, but unless you're doing funky reflective programming, you don't need them often. Most of the time, the compiler will hit it spot on. That means that this works 
     
let f x y = x + y
// val f : int -> int -> int
 

    but so does this

     
let f2 (x: float) y = x + y
// val f2 : float -> float -> float
 
  3. record types. Or rather how you consume them. Records are compound data structures (kind of like structs). With a record definition of 
     
type SomeRecord = {
    first_name: string
    last_name: string
    dob: DateTime
}
 

    you can get an instance by just writing

     
let alex = { first_name = "alex"; last_name = "p"; dob = (System.DateTime.Parse("01/01/1900")) }
 

    Cool, huh? Notice i didn't have to specify what the type of alex is. It's actually inferred from the record labels i supplied in the expression. What's more, is that i can now create a clone of that record:

     
let alexs_twin = { alex with first_name = "twin" }
 
  4. object expressions. Ever have a piddly little object that you needed to return? Ever wonder why you have to go through the hoopla of defining a class for something that'll never be used outside of where it's declared? Well, in f#, you don't. This example comes from a parser implementation for a markup language. It was broken up into a tag class, and a node class. Tag class did the parsing, node was the AST node representation, and typically did very little work, with most of the functionality being defined in the base clas Node. This specific tag translates words into template syntax: 
     
type TemplateTag() =
    interface ITag with
        member this.Perform token parser tokens =
            let args = List.tl <| smart_split token
            let buf =
                match args with
                    | "openblock"::[] -> "{%"
                    | _ -> raise (TemplateSyntaxError ("invalid format for 'template' tag"))
            [{
                new Node(Block "templatetag")
                with
                    override this.walk walker =
                        {walker with buffer=Some buf}
            }], tokens
 

    What this little code snippet does is rather than explicitly defining a new class TemplateNode that just overrides the "walk" method on Node, it combines the instantiation and definition steps, and returns an anonymous subclass of node, with the "walk" method redefined to do something else. Now, you can take this even further, and use object expressions to define anonymous interface implementations. Say you wanted to make sure that when an operation was done, some resource was released, but that's all you cared about. Simple - use an object expression to implement the IDisposable interface, and you're done:

     
let disp = { new Object() interface IDisposable with member x.Dispose() = (*do stuff*) }
 

    Side note here - object expressions make a lot of sense when coupled with the fact that F# has the concept of closures, but that's more functional so just a quick blurb on this. A closure means that as you define your instance/type combination, you have access to local values of all of your parent scopes. That's why, in the TemplateTag example, my Node class implementation can access the local value "buf" from within it's method definition.

  5. tuples. Ever need to return 2 values from a function? Okay, you do a return value and an output parameter. Annoying to consume, but doable. But what about 3? or 4? At that point it gets to be just unmanageable. In F# this is simple. A tuple is a composition of multiple other types. If i have a function (or method, to stay with our theme) that took my "SomeRecord" from before, and returned the first and last names only, it would look like this 
     
member x.get_names record = record.first_name, record.last_name
 

    That's it! Now, when i consume it, i can either treat it as a single value of type tuple, and then use special accessor functions to read from it:

     
let names = someclass.get_names alex
printf "first name %s\r\n" <| fst names
printf "last name %s\r\n" <| snd names
 

    or using f# syntactical sugar to unfold the value explicitly:

     
let first, last = someclass.get_names alex
printf "first name %s\r\n" <| first
printf "last name %s\r\n" <| last
 

    or ignore one of the values entirely:

     
let _, last = someclass.get_names alex
printf "last name %s\r\n" <| last
 
  6. discriminated unions. When the set of values you care about depend on what you're representing, discriminated unions are awesome. Example here is - if you wanted to have a single data type that represented a vehicle, but wanted to store different attributes for different vehicle types, you could define a discriminated union that stores passenger capacity and Color for passenger cars, and maximum load and number of wheels for trucks:

     
type Vehicle =
| Passenger of int * Color
| Truck of float * int
 
  7. null value handling. F# doesn't really have the concept of a null. I mean it does, but it mostly comes up when interfacing with external libraries that'll slip one in here or there. Outside of that, if you say that method someclass.get_names takes a record of type SomeRecord, you can be sure that you'll never get a null there. Now, if you want to allow for that, you can use the "Option" type. Option is a discriminated union of 
     
type Option<'a> =
| None
| Some of 'a
 

    which means that it either contains "None", or Some value of type 'a (the whole ' thing is to identify a generic type parameter, so the Option type is a generic type). That means that whenever you're dealing with values that may not be supplied, you have to explicitly handle that scenario. That also means that the pesky NullReferenceException goes bye-bye.

  8. lists, list literals and other fun built-in structures. We're starting to get closer to f#'s functional nature, but this is still very much oo-applicable. Lists. F# has awesome support for lists. For starters, you can do stuff like this:

     
// new list, containing 0 through 5
let l = [0..5]
// new list, concatenating l with the list containing 6
let l2 = l @ [6]
// h is the head element in l, t is the remainder
let h::t = l
// pull the first three elements out into h1,2,3 respectively
let h1::h2::h3::t = l2
 

    then you can move on to generating expressions

     
// 10 squares
let l3 = [for i in 0..10 -> i * i]
 

    The other thing is that default lists in F# are immutable structures, so when you modify them, you're actually creating new instances that contain the modified values. But fear not - there's no copying involved. Since each instance is immutable, f# can share elements among instances, allowing the operation some_giant_list @ [0] to not have to copy the contents of some_giant_list. Oh and with arrays, you can also do slicing notation:

     
// generate array of 0 through 5
let a = [|0..5|]
// get the first 4 elements
let a2 = a.[..3]

    .

  9. pattern matching. We're getting closer and closer to functional territory, but with f# that line is somewhat blurred. Pattern matching is effectively a very concise way to write a long if-then-elseif. You can

     
// match over literals
match alex.first_name with
| "alex" -> printf "woo"
| _ as name -> printf "don't know %s" name
 
// and over lists
match l with
| h::t -> printf "the first element is %d, and there are %d in the tail" h <| List.length t
| [] -> printf "the list is empty"
 
// and over Types (there shouldn't be a space between the : and the ?)
match disp with
| : ? System.ICloneable as cloneable -> printf "%A is clonable" cloneable
| : ? System.IDisposable as disposable -> printf "%A is disposable" disposable
| _ as unk -> printf "dunno what %A is" unk
 

    you can also pattern match over discriminated unions (that's actually the main way of working with those), and various other data structures.

  10. access to .net libraries. Okay, i'm cheating a little here, because the remarkable part isn't that there's access to the .net library, but that a functional, statically-typed language has access to the .net library. The fact that I can reach out to components written in c#, with no penalty, is what will make this language more mainstream than most other functional implementations (scala and the like, of course, notwithstanding).

Thoughts on reflective programming with f#

Published
by
alex p
on April 29, 2009
in Code
. 2 Comments

It's been a few days longer than I'd like, but now I have something worth sharing. I bounce back and forth between more framework-oriented work and more application-oriented work, but they do end up being two sides of the same coin. Here I want to talk about framework stuff. Oh and a quick disclaimer - this is more thinking out loud, and less a final solution. Input, as always, is most welcome.

In the oo world, your common unit of function is an object. An object may do more than one thing, but it typically does at least one thing, has at least one "function" (not in the programming sense, but in the "i do something" sense). As such, the problem of storing meta information on your object has long been solved - attributes. If I have an object with data elements on it (fields or properties), then I can encode information for a consuming runtime by applying attributes to it. It is a fairly common design pattern for an object that functions as a component in a larger framework (think any ORM framework as an example) to encode information on its data elements, have the runtime read that information, and populate/read from those elements, and then invoke some method on the object.

In f#, on the other hand, your common unit of function is ... a function. Unlike an object, a function typically does one thing (though a function with side effects most certainly may do more than one). Now, I do still have the concept of attributes in f#, and i can decorate my function with multiple attributes, but there's a slight problem. To implement the design pattern I mentioned before (fields marked by attributes, populated by the runtime), I have to have two things - locally-scoped data elements that are mutable externally. The only way to do that is to implement a class, with mutable properties just like i would in c#. This means that I lose my functional advantage, and now am using f# as a different dialect of an oo language. Feasible, but not pleasant. Or necessary.

Let's take a different approach. I'm going to bring back a piece of functionality i talked about in earlier articles - quotations, and using quotations to determine function signatures. I won't go into those details again, but suppose i have a function like this

 
[<ReflectedDefinition>]
let public sample2 (l_name: string) =
    let f_name = "alex"
    (f_name, l_name)
 

I've shown before that i can use quotations to get at the function signature, and extract the type, name, and position of every parameter to this function. This means that my fictitious runtime, upon learning of this function, can find out that function "sample2" take a parameter "l_name" of type "string". Well that certainly a start. But what happens when I want to pass along more information? For example, what happens when I want to tell the runtime that value l_name will never be the empty string (yay for more contrived examples). Before we answer that question, let's answer a slightly simpler one - how do you handle nulls in f#? Well - we use the Option type, which is effectively a discriminated union, with discriminators None (denoting ... well ... no value), and Some v, denoting that it does contain a value, and the value is v. Option is a generic type, so we could write it as "l_name Option<string>". Or, better yet, we can write it as "l_name string option". Cool. It's succinct, and provides information. Now, since Option is a type, our runtime will see that function sample2 has a single parameter l_name, of type Option<string>, which tells it that it's a string value that may be null.

Okay, back to the original question - how do i inform the runtime of something else - like the string parameter will never be empty? Well, we can use the same thing - we can define our own discriminated union, say... NonEmpty, and change our function signature to be "l_name string NonEmpty". What's even more interesting is that you can compose these values - i can say that the string is optional, but if present, then non empty - "l_name string option NonEmpty" or "l_name string NonEmpty option". So now we have a way of attaching meta information (of sorts) to our parameter values, and it mostly doesn't get in the way.

There are, of course, a few drawbacks and limitations. Two jump to mind - first, these markers aren't parametrizable - meaning that while an actual attribute will let you define parameters that carry the meta information (an attribute for an orm that will denote a field mapping will let you specify the database field name as a string parameter), this approach only allows for marker attributes. Second, while not horribly obtrusive, you do introduce the need to "unwrap" your value. If you do have the example above of l_name string option NonEmpty, you have to do something like l_name.Value.Value to get at the actual l_name.

I don't think either of these are showstoppers. The first one, you can supplement the marker attributes with regular attributes if you must have arbitrary parameters. The second one, you can write a generic decomposition function, something like

 
/// annotates a session-scoped value
type session<'a> =
    | SessionValue of 'a
 
    member x.Value = match x with SessionValue a -> a
 
/// annotates a form-scoped value
type form<'a> =
    | FormValue of 'a
 
    member x.Value = match x with FormValue a -> a
 
/// recursively retrieves values from an arbitrarily-annonated value
let rec get_value (v: obj) =
    match v with
    | : ? session<_> as ssn -> get_value ssn.Value
    | : ? form<_> as frm -> get_value frm.Value
    | : ? Option<_> as opt ->
        match opt with
        | Some v -> get_value v
        | None -> null
    | _ -> v
 

Edit: this actually ends up not working. The type parameters in the type tests get constrained to obj, meaning that you're testing an arbitrary data type against (as an example) session, which will only pass for session, and nothing else. I'm working on ways around this and will update when i found something.

Do note that one drawback of get_value is that it is forced to restrict v to be of type obj, and as a result, restricts the return value to be of type obj as well, forcing casts when consuming. I'm still playing with this, and will post an update if i find a better way.

Finally, on the framework side, reading this information from a function signature is actually not horribly difficult either. (Caveat - this implementation is a simple proof-of-concept, and as such isn't overly extensible. You'll notice that the list of possible parameters is hard-coded a tuple of fixed order and length. That can be replaced with a different data structure, but works for now). This sample takes a function signature and uses discriminated union markers to infer scope and directionality of parameters to a given function. 

 
/// active pattern that is matched when input is a generic type whose definition is pattern_type
let (|MatchGenericType|_|) (pattern_type: Type) (input: Type) =
    if input.IsGenericType && input.GetGenericTypeDefinition() = pattern_type then
        Some <| input.GetGenericTypeDefinition()
    else
        None
 
/// active pattern that is matched when input is an option type
let (|MatchOptionType|_|) (input: Type) =
    if input.IsGenericType && input.GetGenericTypeDefinition() = optiont then
        Some <| input.GetGenericTypeDefinition()
    else
        None
 
/// gets the generic type parameter of this type. note that this function
/// assumes that the supplied type is a specific definition of a generic
/// type, and that it has at least one type parameter
let get_generic (t: Type) = t.GetGenericTypeDefinition().GetGenericArguments().[0]
 
/// recursively peels off outer markers of scope/directionality
let rec decompose state (a: string * Type) =
    let name, parm_type = a
    let form_list, depends, requires, session, request = state
 
    if parm_type.IsGenericType then
        (name, get_generic parm_type) |>
            decompose
                (match parm_type with
                | MatchOptionType opt_type ->
                    form_list, depends @ [name], requires, session, request
                | MatchGenericType sessiont ssn_type ->
                    form_list, depends, requires, session @ [name], request
                | MatchGenericType formt form_type ->
                    form_list, depends, requires, session @ [name], request
                | _ -> raise (new ApplicationException(sprintf "%A is not a known resource marker" parm_type)))
    else
        // if this value has been marked by any of these, then we do nothing
        // otherwise, we assume it to be a requires request value
        if any_have name [session; form_list] then state
        elif any_have name [depends] then
            form_list, depends, requires, session, request @ [name]
        else state
 
/// builds a list of form, depends, requires, session and request fields
/// based on a function signature. signature is a list of string * Type
/// describing the input and output parameters of the function we're dealing with.
let load signature =
    List.fold_left (decompose parameter_fields) ([],[],[],[],[]) signature
 

Note - i hacked this out of a live project, and I'm sure there are some dangling references. I can provide the full (compiling) code to this for those interested.

That's it for now.

Back to basics - F# (and currying) as a time saver for the everyday programmer

Published
by
alex p
on April 16, 2009
in Uncategorized
. 6 Comments

One of the reasons that i've been spending so much time digging around in f# is that i truly believe that once you get past the initial differences, f#'s almost-functional-yet-still-imperative-and-oo approach makes a lot of sense, and not just in the world of academia. my not-so-secret plan is to get my group to start using f# in place of c# for web development, and we're making some significant progress in that direction. But that's all rather abstract. Let me give you a simple example of how functional programming can save time in a scenario that happens in any kind of development.

Tech blogs are always about contrived examples, so let's start there - let's contrive ourselves an example. Suppose i have a class that represents a set of contact info, but does it with some intelligence. We'll give it a set of addresses and phone numbers, and it'll keep for us the first valid of each (i did say contrived, didn't i?) So - here's our class:

 
public class ContactInfo
{
    public string MainNumber { get; private set; }
    public string MainAddress { get; private set; }
 
    public ContactInfo(
        string homeAddress, string workAddress,
        string homeNumber, string workNumber, string cellNumber)
    {
        var address = CleanAddress(homeAddress);
        if (address == null)
            MainAddress = CleanAddress(workAddress);
        else
            MainAddress = address;
 
        var phone = CleanPhone(homeNumber);
        if (phone == null)
        {
            phone = CleanPhone(workNumber);
            if (phone == null)
                MainNumber = CleanPhone(cellNumber);
            else
                MainNumber = phone;
        }
        MainNumber = phone;
    }
}
 

So there's a couple of levels of nastiness here - first the (ironically) second block - the nested ifs that cascade down to find the first non-foobared phone number. The second one is a bit less noticeable - it's the fact that we have a repeting pattern in the code - if (some check that returns a modified value) then return the modified value, otherwise return the second value, modified.

In c# most of us have learned to deal with the repetition - there's no clean way around it when it's that generic. If it were the same check, we could extract it out, but it's not, and we're typically too lazy to declare a delegate for it. In fact, doing so probably wouldn't be the greatest idea - we'd be declaring a type to be consumed by a handful (or more likely 1) method. In f#, however, we're given a few tools that help us deal with it. The ease with which f# lets you build functions that operate on functions, and generic values, is the ticket here. What we're going to do is write out exactly the pseudo-code i just mentioned - if (some check that returns a modified value) then return the modified value, otherwise return the second value, modified.:

 
let choose func v1 v2 =
    match func v1 with
    | Some _ as ex -> ex
    | None -> func v2
 

So what is this? It's a function, choose, that takes three parameters - func, v1 and v2. func is a function that takes some type 'a and returns some other type 'b, which may or may not have a value (an option type), and v1 and v2 are just values of that same type 'a that func takes. This function does exactly what the pseudo code says - it calls func(v1) and if that returns a value, the value is returned, otherwise it returns the value of func(v2). Here's how i'd use it:

 
let mainAddress = choose CleanAddress homeAddress workAddress
 

There's a few keys here. First - notice how nowhere did i need to explicitly declare a variable to hold an intermediate value. Second - no delegate declaration, anonymous or otherwise. Third - my function choose will operate equally well on any other set of parameters, provided that the structure is the same, and yet at the same time i don't have to deal with angle brackets to inform the compiler that choose is a generic function with two Type parameters.

Notice that none of these things are huge, but taken together, i went from four lines of code to 1 (yes, yes, i'm not counting the four lines of the function declaration, but that's a fixed cost).

Okay, that's out of the way, let's talk about the nested ifs. To tackle that, let's spend a second on the concept of currying. The way f# (and other functional languages) is built, it takes parameters one at a time. If you're new to functional programming, that means absolutely nothing to you. Don't worry. Effectively, it means that our function choose is a bit more complex than it looks. It's actually a composition of a few single-parameter functions (lambdas). If I use the same disassembly technique as in my previous article to look at the structure of the definition, i'll see this:

Lambda (func,
        Lambda (v1,
                Lambda (v2,
                        Let (matchValue, Application (func, v1),
                             IfThenElse (UnionCaseTest (matchValue,
                                                        Option`1.None),
                                         Application (func, v2),
                                         Let (ex, matchValue, ex))))))

You can see that it's actually 3 nested functions, with each inner function having access to the values visible in the outer functions. Okay, back to currying. Currying is kind of an extension of this - it's the concept that choose is a function of three parameters (our lambda(func, lambda(v1, lambda(v2,...)))), but if we give it only one parameter, then we've actually invoked just the outer lambda. So - that means that now we're down to lambda(v1, lambda(v2, ...)), which is a function of two parameters. So, by taking a function, and supplying just part of it parameters, we're effectively getting a new function that will behave the same way, but with one (or more) of the parameters bound to the value we already supplied.

So, back to our problem of nested ifs. Let's take a look at the structure of it - we're saying if something, cool, if not then (if something, cool, if not then bring back our failsafe). That looks a lot like our pattern superimposed onto itself. In fact, we can express it like this:

 
let mainNumber = choose (choose CleanNumber homeNumber)  workNumber cellNumber
 

What I'm doing there is i'm currying function choose, to get a new function that has func and v1 "pinned" to CleanNumber and homeNumber, respectively. What will happen is that the outer choose call will call the inner one with workNumber, and then cellNumber.

If we put all of this together, we can see that our 15 lines of c# code turn in to... 2!

 
let mainAddress = choose CleanAddress homeAddress workAddress
let mainNumber = choose (choose CleanNumber homeNumber) workNumber cellNumber
 

What i find significant here isn't that we can use f# to reduce one set of code to a much smaller set of code, but that it's applicable to what is a fairly typical web app problem. And that's using two small aspects of f#.

Dynamic investigation and invocation of f# components

Published
by
alex p
on April 13, 2009
in Code
. 2 Comments

As i'm building out more components of fs bistro, i'm finding more and more interesting tidbits of info. Figure i'll throw some here and hopefully they help someone.

The specific problem i was trying to solve was, given a Type that represents a F# module, pull out all functions marked as ReflectedDefinition, get at their return type (and structure) and be able to invoke them dynamically.

Let's take this step-by-step. Part 1 - Pull out all functions marked as reflected definition. Well, specifically, that means all functions that have their quoted representation stored in the assembly as well. A little-documented method on the Expr class - Expr.TryGetReflectedDefinition will let you do that:

 
let get_module_info (t:System.Type) =
    if not <| FSharpType.IsModule t then []
    else
        t.GetMethods(BindingFlags.Static ||| BindingFlags.Public) |>
        Seq.fold (fun state (m: MethodInfo) ->
                    match Expr.TryGetReflectedDefinition m with
                    | Some ex -> state @ [m, get_parms ex, try_get_return_sig ex]
                    | None -> state) []
 

Specifically, we're taking a class we're assuming to be a Module (side note - modules end up being static classes in the namespace they're marked with, none if not marked. Nested modules are... you guessed it - nested static classes), getting all of its public static methods (that's how functions get represented) and then effectively iterating over all of them, doing some computation when Expr.TryGetReflectedDefinition resolves is Some. TryGetReflectedDefinition will give you an entry point (if there's one to be had) into the expression tree.

The expression tree is actually a very interesting glimpse into how even imperative constructs get realized as functional compositions. Given a function like this

 
[<ReflectedDefinition>]
let public sample3 (ctx: IExecutionContext) (p2: string option) =
    let now_ts = System.DateTime.Now
    let p =
        match p2 with
        | None -> "empty"
        | Some v -> v
 
    ctx.RenderWith ("Test.template")
    (now_ts, p)
 

the expression tree looks like this

Lambda (ctx,
        Lambda (p2,
                Let (now_ts, PropGet (None, System.DateTime Now, []),
                     Let (p,
                          Let (matchValue, p2,
                               IfThenElse (UnionCaseTest (matchValue,Option`1.Some),
                                           Let (v,PropGet (Some (matchValue),
                                                         System.String Item, []),v), Value ("empty"))),
                          Sequential (Call (Some (ctx),
                                            Void RenderWith(System.String),
                                            [Value ("Test.template")]),
                                      NewTuple (now_ts, p))))))

If you take a look at the arguments of Let, you'll see that it's bind site, value and next statement. That type of chaining glues your functions together. But I digress...

So, right now, we have our expression tree and we have a MethodInfo object. That method info is the same type of method handle we would expect from any other static method. That means that we can invoke it much the same way we would - 

 
// mi being our method info object, and parm_list being... well... the parameter list
let ret_val = mi.Invoke(null, parm_list)
 

So that's 2 of three. We got our expression tree, we know how to invoke our method, but what are we actually getting back?

Chances are, that's not a question you'll need to answer often, but it's still a useful piece of info. The Quotations.Patterns (at time of writing, f# ctp 1.9.6.2) namespace contains a list of active patterns that match up to the expression "function calls" that we saw in our expression tree. That means that we can recursively pattern match over our expression tree to get at its structure. We can either use specific cases to look for certain patterns

 
/// returns the first non-None result of invoking func with v1 or v2
let choose func v1 v2 =
    match func v1 with
    | Some _ as ex -> ex
    | None -> func v2
 
/// attempts to locate the return type of the given expression tree
let rec try_get_return_sig = function
| Lambda (_,ex) -> try_get_return_sig ex
| Let (_,_,cont) -> try_get_return_sig cont
| IfThenElse (_,t,e) -> choose try_get_return_sig t e
| NewTuple e -> Some <| List.map (fun (ex: Expr) -> ex.ToString(), ex.Type) e
| Sequential (f,s) -> choose try_get_return_sig f s
| TryFinally (tr,fn) -> choose try_get_return_sig tr fn
| TryWith (tr,_,wt,_,fn) -> choose (choose try_get_return_sig fn) wt tr
| Var var as ex -> Some [(ex.ToString(), ex.Type)]
| _ -> None
 

or we can use the ExprShape patterns to traverse the tree without concerning ourselves with the actual components we're navigating. What the piece of code up above is doing, is it's looking for return values that are explicit Tuple creations. I had a need to analyze functions returning tuples and peek inside their definitions to know the names of the components they're returning. This way, the user can return an arbitrary data structure, but i still get my hands on the names of the individual components i'm getting back. The pattern matches that i have listed out are the tree branches that i care about. Lambda, Let, etc can result in the production of a Tuple, and NewTuple is the actual production. Everything else (there's a significant number of other components) does things that i don't care about (like call out to other functions which may not be marked for quotation, etc), so i just ignore it.

that's it.

More on F# quotations

Published
by
alex p
on April 8, 2009
in Uncategorized
. 5 Comments

Alright, so i threw that blurb out there a few days back, with little more than zOMG! THIS IS COOL!!!ONE!11!. I figured a bit more detail wouldn't hurt.

One of the things that has made F# a bit more difficult to learn for me is that outside of the more basic concepts, everything is explained on a rather theoretical level. It makes sense, really - that's where functional came from, but it does make it more difficult to visualize the feature and understand their applicability. Let's see if i can do any better.

So - f# quotations are simply the full representation of the syntax tree of a fragment of code, available run-time. That means that you have access to anything within <@ @> or marked with a ReflectedDefinition attribute. The common use case that you read everywhere is that you can write code in f# and then execute it elsewhere. And that's certainly cool, but it's only one aspect. One that i've found incredibly useful is the ability to gather more information from dynamically loaded code than previously possible.

With standard reflection you get to see the shell. You get member names, method signatures (as an ordered list of types) and inheritance info (there's more, but these are the core elements). However, with quotations, i can see much more. I can get parameter names, i can get local variables i can get the full source of the block i'm evaluating!

My use for this? In bistro, I used to make the developer decorate his class with member attributes that gave me information about how that member was used. Now, I can pull that information straight from a function signature, and not require any additional markup. Here's how:

Sample target function:

 
#light
open Microsoft.FSharp.Reflection
open System.Reflection
 
module NestedProgram =
    module Program =
        [<ReflectedDefinition>]
        let public sample f_name p2 =
            printf "sample {%A}\r\n" f_name
 

Code:

 
#light
 
open System
open System.Reflection
open DefaultControllers.NestedProgram.Program
 
open Microsoft.FSharp.Quotations.Patterns
open Microsoft.FSharp.Quotations.DerivedPatterns
open Microsoft.FSharp.Quotations
 
open Microsoft.FSharp.Reflection
 
let strip (text: string) = match text.IndexOf "@" with | -1 -> text | _ as i -> text.[..i-1]
 
let rec get_parms exp =
    match exp with
    | Lambda (var,body) ->
        [strip var.Name] @ get_parms body
    | _ -> []
 
let get_info (t:System.Type) =
    if not <| FSharpType.IsModule t then failwith <| sprintf "%A is not a module" t
    else
        let funcs = t.GetMethods(BindingFlags.Static ||| BindingFlags.Public)
 
        Array.iter (fun (m: MethodInfo) ->
            match Expr.TryGetReflectedDefinition m with
            | Some ex ->
                printf "\t%s.%s %s\r\n" t.FullName m.Name (String.concat " " (get_parms ex))
            | None -> ()) funcs
 
let rec searchTypes t =
    if FSharpType.IsModule t then get_info t
 
AppDomain.CurrentDomain.GetAssemblies() |>
Array.iter (fun (asm: Assembly) ->
                printf "asm: %s\r\n" <| asm.GetName().Name
                Array.iter searchTypes (asm.GetTypes())
                )
 
ignore <| System.Console.Read()
 

This code will go through the entire loaded assembly list, find all types and give me the function signatures. How i consume that is now up to me, but it's there for the taking.

As a side note - I'm going to try and blog more about the real-world applicability of f#. I think that the notion of f# or functional programming not being applicable to web development and the like is a misconception, and hopefully i'll be able to illustrate that.