hubFS: THE place for F#

In my bachelor thesis I included a short introduction that covered all of the important aspects of the F# programming language and I thought that it may be useful to extend it a little bit to cover also a topics that were not important for my thesis and post it as an article, so there is one and relatively short article that introduces all the interesting F# features. The article got however a bit longer than I expected, so I decided to split it into a three parts that would introduce three different paradigms that are supported by F#. Of course, this series won’t teach you everything about F#, but it tries to cover the main F# design goals and (hopefully) presents all the features that make F# interesting and worth learning. In this first part I will shortly introduce F# and the supported paradigms that will be discussed in the upcoming articles.

Introducing F#

In one of the papers about F#, the F# designers gave the following description: "F# is a multi-paradigm .NET language explicitly designed to be an ML suited to the .NET environment. It is rooted in the Core ML design and in particular has a core language largely compatible with OCaml". In other words this means that the syntax of the F# language is similar to ML or OCaml (don’t worry if you don’t know these languages, we’ll look at some examples shortly), but the F# language targets .NET Framework, which means that it can natively work with other .NET components and also that it contains several language extensions to allow smooth integration with the .NET object system.

Another important aspect mentioned in this description is that F# is multi-paradigm language. This means that it tries to take the best from many programming languages from very different worlds. The first paradigm is functional programming (the languages that largely influenced the design of F# in this area are ML, OCaml and other), which has a very long tradition and is becoming more important lately for some very appealing properties, including the fact that functional code tends to be easier to test and paralellize and is also extensible in a ways where object oriented code makes extending difficult.

The second paradigm is widely adopted object oriented programming, which enables interoperability with other .NET languages. In F# it is often used for implementing elementary data types (meaning that the operations on the type are well known and change very rarely), for grouping a set of elementary functions that are together used to perform some complicated operation (i.e. implementing an interface) and also when working with object oriented user interface frameworks.

Finally, the third paradigm supported by F# is language oriented programming (the design of F# in this area is largely influenced by ML, Haskell and also by LINQ). In general, language oriented programming is focused on developing executors for some code which has a structure of a language (be it a declarative language like XML, or a fully powerful language like some subset of F#). In this overview, I will focus on two techniques provided by F# that allow you to give a different meaning to a blocks of F# code. In a programming language theory, this is often called internal domain specific languages, because the code is written in the host language, but is specifically designed as a way for solving problems from some specific domain. An example of such language (and an associated executor) is a block of code that is written as a linear code, but is executed asynchronously (in F# this can be implemented using computation expressions), or a query that is written in F#, but is executed as a SQL code by some database server (this can be implemented using F# quotations).

F# Overview - Links

In the rest of this article series we will look at all these three paradigms supported by F# starting with functional programming and basic F# types used when writing code in a functional way, continuing with object oriented programming and the support for .NET interoperability which is closely related to the OOP in F#. Lastly, we will look at the language oriented programming paradigm including some of the most important .NET and F# library functions that make it possible. The rest of the articles from the series are available in my other blog:

• F# Overview (I.) - Introduction (at TomasP.Net)
• F# Overview (II.) - Functional Programming (at TomasP.Net)
• F# Overview (III.) - Object Oriented and Imperative Programming (at TomasP.Net)
• F# Overview (IV.) - Language Oriented Programming(at TomasP.Net)

• You can also download the complete article as a single document (PDF).

Other F# Resources

There are many other places where you can find useful information about F#. First of all, there is an official F# web site [1] where you can find the language specification, documentation and other useful resources. There are also two books written about F# (one already published [2], second will be available soon [3]). Lastly, there are also a lot of community resources including an F# community web site with discussion board [4], wiki [5] and several blogs [6,7,8,9]. Finally, there are also some projects developed by the F# community that are available at CodePlex - the first one includes various F# code samples [9, 10] and the second is based on my thesis and tries to solve several web development problems [11].

• [1] F# web site [^] - Official F# homepage
• [2] Expert F# [^] - Book by by Don Syme, Adam Granicz and Antonio Cisternino
• [3] Foundations of F# [^] - Book by Robert Pickering
• [4] hubFS: THE place for F# [^] - The F# community web site with blogs, forums, etc..
• [5] F# Wiki Homepage [^] - F# Wiki started by Robert Pickering
• [6] Don Syme’s WebLog on F# and Other Research Projects [^] - Blog written by the F# language designer Don Syme
• [7] Robert Pickering’s Strange Blog [^] - Blog of the "Foundations of F#" book author
• [8] Granville Barnett [^] - Explorations in programming
• [9] F# News [^] and F#.NET Tutorials [^] by Jon Harrop
• [10] F# Samples [^] - Contains code that demonstrate various F# language features
• [11] F# WebTools [^] - Project that allows writing client/server Ajax web applications entirely in F#

The project that I'm going to introduce in this article has been public for some time already, but I wrote about it only on my personal web site and didn't post the article to the hubFS, which is what I usually do with my other F# articles, so some of the hubFS readers may have missed it.
(Cross-posted from: http://tomasp.net/articles/fswebtools-intro.aspx)

I started thinking about working on "Ajax" framework quite a long time ago - the key thing I really wanted from the beginning was using the same language for writing both client and server side code and the integration between these two sides, so you could write an event handler and specify if it should be executed on the client or on the server side. About a year ago I visited Cambridge (thanks to the MVP program) and I had a chance to talk with Don Syme [^]. Don showed me a few things in F# and suggested using F# for this project, so when I was later selected to do an internship at MSR, this was one of the projects that I wanted to work on.

The original reason for using F# was its support for meta-programming ([8], which makes it extremely easy to translate part of the page code-behind code to JavaScript. During my internship, the F# team was also working on a feature called computational expressions, which proved to be extremely useful for the F# Web Tools as well - I bet you'll hear a lot about this from Don soon, so I'll describe only the aspects that are important for this project. Aside from these two key features that F# has, I also quite enjoyed programming in F# itself - I already used it for a few things during the last year, but I could finally work on a large project in F# (and discuss the solution with the real experts!) and I don't believe I would be able to finish the project of similar complexity during less than three months in any other language (but this is a different topic, which deserves separate blog post).

What makes "Ajax" difficult?

Traditional "Ajax" application consists of the server-side code and the client-side part written in JavaScript (the more dynamicity you want, the larger JS files you have to write), which exchanges some data with the server-side code using XmlHttpRequest, typically in JSON format. I think this approach has 3 main problems, which we tried to solve in F# Web Tools. There are a few projects that try to solve some of them already - the most interesting projects are Volta from Microsoft [1], Links language [3] from the University of Edinburgh and Google Web Toolkit [2], but none of the projects solve all three problems at once.

1. Limited client-side environment

First of the problems with "Ajax" style applications is that significant part of the application runs on the client-side (in a web browser). Currently majority of the web applications use JavaScript to execute code in the browser, so in the F# Web Tools we wanted to use JavaScript as well, however in the future, when installation of Silverlight [4] becomes more common, we would like to allow using Silverlight as an alternative.

F# Web Tools allows you to write client-side code in F# (so if you don't know JavaScript, you don't have to learn it!) and also use your existing knowledge of .NET and F# classes and functions (so you can use some of the .NET and F# types when writing client-side code). The code you write in F# is of course executed in JavaScript, so it runs in any browser that supports JavaScript - the current implementation is tested with IE and Firefox, but it could be easily tested with other browsers.

2. Discontinuity between server and client side

The second major problem with "Ajax" applications is that the web application has to be written as two separate parts - client-side part (when written in JavaScript) consists of several JS files and the server-side part (for example in ASP.NET) is written as a set of ASPX and C# or VB files. Also when using JavaScript, both sides use different formats to store the data, so bridging this gap is difficult. In Silverlight [4] (or in GWT [2]), the gap is still there, even though both parts are written using the same technology - the client-side part is usually even a separate project.

In F# Web Tools we wanted to make this discontinuity as small as possible - You can write both server and client-side code in a same file (as a code-behind code). You can also call server-side functions from the client-side code and you can use certain data-types (including your own) in both sides and you can send them as an arguments from one side to the other. What's also important is that these calls are done without blocking the browser, but without the usual cumbersome programming style (calling a function, setting a callback and writing the rest of the code in the callback).

3. Components in web frameworks are only server-side

The third key problem appears once we tightly integrate client and server side code, because there is one more step that has to be done - most of the web frameworks have some way for composing web site from smaller pieces (in ASP.NET this is done using controls) and by defining the interaction between these pieces, however they allow defining the interaction only for the server-side, which is rather problematic in "Ajax" applications, where most of the interaction between components is done on the client-side.

Since F# Web Tools is built using ASP.NET, we wanted to allow same compositionality as ASP.NET - to achieve this, controls written using F# Web Tools can wrap both server and client side functionality. Controls than expose both server and client side properties and events that can be used by the page to implement server-side, respectively client-side interaction between components.

Example - "Ajax" dictionary

I will demonstrate some of the F# Web Tools features using an "Ajax" dictionary application (see screenshot on the right side) which displays possible matching words as you type the word you want to find. This is one of the typical "Ajax" tasks, so it's a good example to start with. First, we need to define the code-behind file for the ASP.NET page - the page itself is quite simple, it contains just two controls - textbox for entering word that you're looking for (txtInput) and generic element for displaying results (ctlOutput), so let's look at the code-behind:

// F# record type, which will be used for sending lookup 
// results from the server-side to the client-side
type SearchResult = { English:string; Other:string; }

// Code-behind type for the ASP.NET page
[<MixedSide>]
type Suggest = 
  inherit ClientPage as base
  
  // Controls for entering text and displaying result
  val mutable txtInput : TextBox
  val mutable ctlOutput : Element

  (* .. interaction of components will go here .. *)

Aside from the code-behind class, we also defined a type (SearchResult), which will be used for returning loaded results from server to the client side - it is just a F# record containing two strings (word in English and word in the language we're translating to). Now let's look at the methods that define the interaction logic. The first method that we will look at is a method running on the server-side that takes entered text as an argument and returns a collection of results (ResizeArray<SearchResult>) - it is a static method, so it can't modify anything else on the page (I will write about non-static methods in one of the next articles):

// Searches the dictionary for specified prefix
static member LoadSuggestions(prefix) = 
  server
    { let db = DictionaryDb(connectionString)
      let res = 
        SQL <@ { for p in §db.Dictionary
                 when p.English.StartsWith(§prefix) 
                 -> {English=p.English; Other=p.Other} }
                 |> truncate 10 @> 
      return (new ResizeArray<_>(res)) }

The method is all wrapped in server computational expression (this is one of the new F# features - it will be in details described in the Expert F# [6] book, but I'll definitely write a few lines about it as well) - for now you can read it as (almost) ordinary F# code wrapped in a block that specifies how the code should be executed. The server block is executed as ordinary F# code, but wrapping the code in this block allows us to call it from the client side later. The server block also changes the type of the method, so it doesn't return ResizeArray<SearchInfo>, but Server<ResizeArray<SearchInfo>>, where the Server type helps to ensure that the code will be executed only on the correct side.

Now, let's look at the members that define client-side interaction. The entry point on the client-side is a method called Client_Load, which is executed when the page is loaded in the browser:

/// Initialization on the client side - attach event handlers    
[<ReflectedDefinition>]
member this.Client_Load(sender, e) =
  client
    { do this.txtInput.ClientKeyUp.AddClient(this.UpdateSuggestions) }

In this case we just register an event handler that will be called whenever user types something to the txtInput textbox. It is important to note that this code will be executed in JavaScript - even though when writing it, it is easy to forget about this! You can see the method that is used as an event handler in the next code sample (this whole method will be executed in JS as well):

[<ReflectedDefinition>]
member this.UpdateSuggestions(sender, e) =
  client
    { do! asyncExecute
           (client_async 
             { let  sprefix = this.txtInput.Text
               let! sugs = serverExecute(Suggest.LoadSuggestions(sprefix))
               do!  this.DisplayResponse(sugs) }) }            

If you look at the method, you can see that it contains call to the asyncExecute function and the argument given to the function is entire block of F# code marked using client_async computational expression. The asyncExecute function executes the given block asynchronously, which means that it doesn't block the calling function (and it doesn't block browser GUI) - you can look at it as if it created new thread (but it's actually using one trick from functional programming called continuation passing style, because JavaScript doesn't support threads). In the client_async block, we first read the value from the textbox and then call the LoadSuggestions static method to get collection with matching words. The call to the server-side functions is done using serverExecute function (which is a special function, because it bridges the gap between client and the server automatically). Once we get the result we can call the DisplayResponse method to display the results. You can see that we used a let! and do! instead of let and do here - this is because we're calling a methods that are written using F# computational expressions (server or client blocks). In general when you're calling any ordinary code, you can use the operators without the exclamation mark, but when calling a code wrapped in a block you have to use let! or do!.

[<ReflectedDefinition>]
member this.DisplayResponse (sugs:ResizeArray<Result>) =
  client
    { let sb = StringBuilder()
      let array = sugs.ToArray()
      do  Array.iter (fun (res) -> 
            sb.Append("<li><strong>" + r.Source + 
                      "</strong> - " + r.Target + "</li>") |> ignore)
      do   this.ctlOutput.InnerHtml <- "<ul>" + (sb.ToString()) + "<ul>" }

In this last sample code, we just generate HTML code from the data we received from the server and display them. It is interesting to note, that the code is running on the client-side (it's wrapped in the client block), but you can still use some F#/.NET types and functions in the code (we're using ResizeArray, StringBuilder classes and Array.iter function). This is possible because F# Web Tools re-implements subset of the F#/.NET functionality for the client-side code. And that's all - I described slightly simplified version of one of the F# Web Tools demos, but you can get the full source code if you check out our CodePlex project. You can also look at the live Dictionary sample [^].

More information

I think this example gives you a general idea what is the F# Web Tools and why it is interesting. I will definitely write more about it in the future, because I didn't describe all important features in this example. If you're interested in this project, you can also read the Paper we submitted to the ML Workshop or slides from the presentation I did at the end of my internship in MSR Cambridge (see below). This project is also available to the community at CodePlex, so you can look at the source code (including two more samples).

• Rich client/server web applications in F# (Paper, PDF) - Research paper submitted to the ML Workshop
• Ajax-style Client/Server Programming with F# (Slides, PDF) - Final Internship Presentation
• F# Web Tools at CodePlex [^]- Project & Samples source code

Related projects and links

• [ 1 ] Erik Meijer: Volta - Wrapping the Cloud with .NET - Part 1 [^] - Erik Meijer, Microsoft
• [ 2 ] Google Web Toolkit [^] - Google
• [ 3 ] Links: Linking Theory to Practice for the Web [^] - Ezra Cooper, Sam Lindley, Philip Wadler, Jeremy Yallop
• [ 4 ] Microsoft Silverlight [^] - Microsoft
• [ 5 ] Script# [^] - Nikhil Kothari
• [ 6 ] Book: Expert F# [^] - Don Syme, Adam Granicz, Antonio Cisternino
• [ 7 ] Book: Foundations of F# [^] - Robert Pickering
• [ 8 ] Leveraging .NET Meta-programming Components from F# (PDF)

On 2nd of November I did a presentation on F# and functional programming at the Czech .NET User Group meeting. Because I spent quite a lot of time with puting the presentation together I wanted to make it available to wider audience, so I translated the slides and examples to English (anyway, translating the content took me only a few minutes :-)). In case that some of the readers prefer Czech version, I attached the original documents too.

In the presentation I tried to introduce some basic concepts of functional programming (immutable values, lazy evaluation) to the audience with no experience with functional programming, as well as present some of the most interesting features of F# (like strict type system based on type inference, .NET interoperability and metaprogramming). The whole contents of the presentation is following:

• Functional programming in F# - Introduction to the F# type system
• Some useful functional idioms - How to do Foldl/Map/Filter functions and Lazy evaluation in C#
• Interactive scripting - What is important for scripting, mathematical simulation
• Interoperability between F# and other .NET languages - How to use .NET libraries from F# and F# libraries from ohter .NET languages
• F# as a language for ASP.NET - How to use F# as a language for ASP.NET development
• Meta-programming in F# - Meta-programming features in F# and the FLINQ project

Downloads

• Presentation - Czech (889 kB), English (894 kB)
• Demos - Czech (500 kB), English (501 kB)

Some time ago, I wrote an article about useful utility called F# quotations visualizer. This utility can be used to show visual representation of F# quotations, which can represent (subset of) source code written in F#. There are two ways that you can use to get F# quotations - first is using operators <@@ ... @@> (this returns quotation of the code written inside the operator), second method is to get quotation of top level definition from compiled F# assembly (you have to explicitly enable this using command line switch --quotation-data while compiling assembly).

Because I added several new features to the original Quotations visualizer, I decided to publish the latest version - here is the list of main improvements:

• Application is rewritten using active patterns (new F# language feature)
• It is possible to extract quotations from compiled F# assembly (if it contains quotation data)
• Added support for several missing language constructs

Active patterns

Active patterns is a new (experimental) feature in the F# language. You can find some information about this feature in Don Syme's article [1]. In simple words, active patterns allows you to write "switch" consisting of functions (patterns) that return 'a option type. When the code is executed, it finds first pattern whose query returned a value (Some(...)) and the body of selected pattern is executed.

This feature makes it very easy to work with F# quotations because all ef[Something] values that are used for querying quotations have the required signature (the Query function that returns 'a option type), so they can be used with the active patterns feature.

In the quotations visualizer, we need to match the expression (type expr) with all possible expression families (ef[Something]) and choose the first one that matches. To see how active patterns work, you can look at the following part of the function that does this. First, without active patterns:

match efForLoop.Query(expr) with
  | Some(nfrom,nto,body) ->
      // Statement: for i=start to end do body; done;
      // .. create tree node ..
  | _ ->
match efWhileLoop.Query(cond,body) with
      // Statement: while condition do body; done;
      // .. create tree node ..
  | _ ->
match efCond.Query(t,(cond,trbody,flbody)) with
      // if (cond) then trbody; else flbody;
      // .. create tree node ..
  | _ ->
      // unknown expression

And with active patterns the source looks like this:

#light
let EFForLoop = efForLoop
let EFWhileLoop = efWhileLoop
let EFCond = efCond

match expr with
  | EFForLoop(nfrom,nto,body) ->
      // Statement: for i=start to end do body; done;
      // .. create tree node ..
  | EFWhileLoop(cond,body) ->
      // Statement: while condition do body; done;
      // .. create tree node ..
  | EFCond(t,(cond,trbody,flbody)) ->
      // if (cond) then trbody; else flbody;
      // .. create tree node ..
  | _ ->
      // unknown expression

This is very simple example and there are many situations where active patterns are even more helpful. You may have also noticed that the code doesn't contain any semicolons. This is the result of another new feature called lightweight syntax (it is turned on by the #light directive) - if you turn it on the whitespace becomes significant and compiler can understand structure of the code using whitespace instead of semicolons, parentheses and begin/end keywords. This feature is described in the F# manual [2].

Extracting quotations from assembly

When you specify --enable-quotation-data switch to the F# compiler, it stores quotation of every top level definition (functions in modules) in the assembly. This quotation can be later retrieved using resolveTopDef function, however to use the function for loading top-level definitions from another assembly, you first have to load quotation data from the assembly. The following snippet shows how to do this.

let asm = Assembly.LoadFile(name) in
  asm.GetManifestResourceNames() |> Array.to_list 
    |> List.filter (fun rn -> 
        rn.StartsWith(pickledDefinitionsResourceNameBase)) 
    |> List.iter (fun rn -> 
        explicitlyRegisterTopDefs asm rn (readToEnd (asm.GetManifestResourceStream(rn))))

This code first loads the assembly (using LoadFile method which accepts assembly file path). Than it gets all managed resources of the assembly and selects only those resources, whose name starts with pickledDefinitionsResourceNameBase (this is a constant declared in Microsoft.FSharp.Quotations.Raw module). Now we have all resources containing F# quotation data, and we can use explicitlyRegisterTopDefs function to load quoted top level definitions. The explicitlyRegisterTopDefs method takes three parameters - assembly, name of the resource and resource data (byte array). When the top level definitions are registered using this method, it is possible to load quotations of functions declared in loaded assembly - and this is exactly what happens when you click on the "Open F# assembly" link in the application. If you are interested in the complete code, look at the attached source code of quotations visualizer application.

Links

• [1] An upcoming experimental feature: Active Patterns in F# [^] - Don Syme's WebLog on F# and Other Research Projects
• [2] Optional lightweight syntax [^] - F# manual

Downloads

• Download the application (50.3kB)
• Download the application - source code (39.3kB)

CodeDOM and providers

CodeDOM (Code Document Object Model) is set of objects (located in System.CodeDom namespace) that can be used for representing logical structure of .NET source code. For example you can use CodeTypeDeclaration class to represent class declaration or CodeAssignStatement to represent assignment in the body of method. CodeDom is language independent and CodeDOM structure can be translated to source code in specified language using code generator (class that implements ICodeGenerator namespace). The CodeDOM structure can be also compiled to assembly using code compiler (implementation of ICodeCompiler interface). Microsoft provides several code providers with .NET Framework (for C#, VB.Net, JScript and C++), but you can add your own by by implementing previously mentioned interfaces.

In the .NET Framework, CodeDOM is used for automatic code generation. For example when you add web reference to your project, the wrapper class that calls web service is generated using CodeDom. Some more examples are typed dataset (generated from XSD files) and generator for data layer in the upcoming LINQ project, but the most interesting use for CodeDOM for me is in ASP.NET 2.0.

Typical ASP.NET web page consists of several aspx/ascx files and associated code behind files written in one of the .NET languages. When building web page, ASP.NET uses CodeDOM for building aspx/ascx files. It parses these files and generates according CodeDOM structure. For example <asp:Button id="btn" runat="server" /> declaration is translated to declaration of btn member and code that assigns new instance of Button object to this member. This generated structure is compiled to .NET assemblies using code compiler and the web page is ready to use. If you use any in-line code in ASP.NET page, it is included in the CodeDOM structure as literal, which means that if the generated CodeDOM is compiled using C# code compiler, it can contain literals only in C# language (because you can't mix languages in one source file).

ASP.NET and F#

In ASP.NET 1.1 you could compile code behind files using different compiler than the rest of the page (source generated from aspx/ascx). This method is used by ASP.NET in F# demo by Robert Pickering [1]. The more complex approach that is available in ASP.NET 2 is to write CodeDomProvider implementation for F#. This makes it possible to write F# in-line code in web pages and this method allows you to fully benefit of ASP.NET compilation model (for example you can use Publish Web Site command in Visual Studio).

FSharpCodeProvider & AspNetFsharpCodeProvider

I wanted to implement CodeDomProvider for the F# language, for the reasons mentioned above. Currently, I'm presenting version of provider that is able to compile ASP.NET pages quite well, however I implemented only features required by ASP.NET, so the provider is not complete. There are also some problems that has to be handled specially (for example, F# doesn't support partial classes), so apart from standard provider (FsharpCodeProvider), I also implemented AspNetFsharpCodeProvider that contains several 'hacks' for ASP.NET.

How to use it?

Important: For correct functionality of F# CodeDOM compiler, you have to modify your system variable PATH to include 'bin' directory of your F# installation folder. This is because, code compiler uses fsc.exe for compilation and there is no simple way for finding where the F# is installed.

The most simple way to start creating ASP.NET web sites in F# is to use VS.NET project template that you can find in the downloads section. Using this template, you can create web page that is already configured to use F# language. After installation, select File - New - WebSite.. and in the dialog select language 'Visual C#' (it is not possible to add another language AFAIK) and than select 'F# WebSite' template.

If you want to configure ASP.NET web site to use F# code provider manually, you have to do the following steps. First modify the web.config file to include the following elements in the compilation section:

<?xml version="1.0"?>
<configuration>
  <system.web>
    <compilation debug="true">
      <compilers>
        <compiler language="F#;f#;fs;fsharp" extension=".fs" 
          type="EeekSoft.FSharp.CodeDom.AspNetFSharpCodeProvider, fscodeprovider"/>
      </compilers>
    </compilation>
  </system.web>
</configuration>

This adds reference to the assembly that contains the AspNetFShaprCodeProvider class and it configures ASP.NET to use F# code generator for aspx files which Language attribute is set to "F#". When this is done, you can add F# page by adding aspx and code behind fs files. In the Page directive, set the Language attribute to "F#" and define the code behind class in the fs file.

The following example shows code behind class for simple web page (that contains one button with ID set to btnOk):

namespace FSharpWeb

open System;;
open System.Web.UI.WebControls;;

// Code behind class declaration
type Default = class inherit System.Web.UI.Page as base
  // Declaration of button control
  val mutable btnOk : Button;
  // All fields must be initialized in constructor
  new() = { btnOk = null; }
  // Set text of button in onload
  override this.OnLoad (e) =
    btnOk.Text <- "Hello world!";
    base.OnLoad (e);
end;;

There is still one little difference when compared with C#, which is that it is required to manually declare all controls (with ID) that are on the page (btnOk in this example). This is because F# doesn't (currently) support partial classes and so the partial class with control declarations that is generated by ASP.NET is dropped by the CodeDOM provider. The rest is very similar to how you develop ASP.NET pages in other languages; you can see more examples if you download attached example application. More information regarding object oriented programming in F# can be found in F# manual available at F# homepage [3].

Other CodeDom provider notes

As I mentioned earlier, the CodeDOM generator I created is still very limited and it is tested only with ASP.NET. You can find list of not implemented features in the release notes (see downloads). In the future, I'd like to extend it to support generating code for accessing web services too (code is generated using wsdl tool). If you have any interesting idea, how it could be used or if you have any other comments, ideas, bug fixes, etc., please let me know (at tomas@tomasp.net).

Downloads & links

• F# CodeGenerator including sources and sample F# Web application (ZIP, 174kB)
• F# WebSite template for Visual Studio 2005 (VSI, 65.7kB)
• Release notes (known issues and not implemented features) [^]

• [1] F# Resources - Aspf Demo [^] - StrangeLights.Com
• [2] Sample CodeDom Provider [^] - Reference CodeDomProvider implementation
• [3] F# [^] - Microsoft Research

So this is my first post to hubFS :-). First I'd like to give thanks to optionsScalper for creating blog for me. Before writing some more interesting posts on F# I'd like to introduce myself...

I'm student of computer science from Czech Republic (studying at Charles University of Prague). I'm also Microsoft C# MVP and I'm student consultant at our university. As student consultant I'm organizing presentations on several (mostly) Microsoft technologies and I'm also often talking there. Aside from studying I worked on many .NET projects including mostly ASP.NET development.

I started learning F# some time ago (but I'm still very far from knowing it well) and I was impressed with so many interesting possibilities of this language. So far, my favorite F# feature is meta-programming (also known as F# quotations), so my first posts will be focused on this topic. 

My homepage is http://tomasp.net and most of the content that I publish somewhere else is also available at my homepage. You can contact me at tomas@tomasp.net