Archive for the ‘F#’ Category

FAKE impressions

August 8th, 2011

Weird post title, I know. But I refer to FAKE – F# Make.

It’s a nice and simple library to perform usual build related tasks. The fact that it’s pure F# makes it quite powerful – have you tried doing complex stuff with NAnt or MSBuild? If so, you know what I mean. Xml is *not* a programming language.

FAKE is simply organized as a collection of modules, each exposing related functions and|or operator overloads. So it’s not exposed in an OOP fashion, rather in a very flat public surface. That *may* make up for the lack of documentation. It’s somewhat easy to understand how things work by browsing the source – for those who are comfortable with that.

That said, in my first experience I couldn’t get the FileSet to generate any result. I also couldn’t find a way to turn on a more verbose logging. I went on a trial-and-error and realized the fileset was missing a BaseDir setting.

Since I’m a big fan of F# Project Extender, which adds metadata to define the order of the build items that are not recognized by MSBuild. So I managed to create a FscTask that takes that in consideration. In the process I noticed how FAKE lacks a few common NAnt features, such as resolving reference assemblies. I guess the author didn’t need them, which is fair in the OSS world. That said, a simple Fsc.exe invocation turned into a sizable task.

My fsc task is dirty and ugly, so beware. You can find it here. For now I’m sticking to Fake for MR builds and see how it goes.

Categories: .NET, F# | Top Of Page | 2 Comments » |

MR 3 update / Castle Blade

July 18th, 2011

Fun times! Since I’ve left MS I’ve been working on a real web site/backend/frontend – you know, doing actual work instead of long meaningless meetings, doc writing and one-on-ones with managers setting you up for failure (I wonder if I should make one of my ‘reviews’ public, so you’ll see the amount of BS I had to put up with).

WebSockets

Anyway, the first work was to create a websockets server. That was fun especially since F# offers its async workflow support and MailboxProcessor. It’s fun to think about it. While at MS, one of my friends there wouldn’t stop bitching about how F# is incredibly superior to C#. Gosh, he was right..

The company I’m doing the work for and I are discussing whether we will make the websocket server available commercially. It’s a PITA to implement the protocols, to test them and keep up, since the spec is in progress. So, sorry, won’t be doing all this work for free.

Ideas playground

On the MonoRail end, we’ve been using it extensively and coding up functionality as needed – by we I mean Henry and I. It’s been quite a journey to reassess all the design decisions in MR1/2, and also evaluate what’s out there. I’m sure we learn more from our mistakes than anything else. Mauricio is pushing some interesting ideas on web frameworks that are making me reevaluate our proposed API over and over again. Now that I’m quite familiar with FParsec, the idea of using combinators to compose forms (formlets) is enticing. It’s just strike me as something hard to expose in C#, we would need a different API and I’m sure it would be awfully verbose.

Castle.Blade = ++Razor

I love Razor’s simplicity and tooling support. Achieving simplicity is a major accomplishment, and the guys at the ASP.NET team did it. I remember when Scott Hunter gave us a preview of what at the time was code named Plan9. Awesome work!

I’ve then decided to make Razor the main view engine for MR3. However, when I started to experiment with a better API for our helpers library I bumped into some not-so-nice limitations from Razor. For example, I wanted to be able to express something like:

 Rails |  copy code |? 
1
2
@Form.For(..., {
3
	// this is a block
4
        @builder.EditorFor(m => m.Name)
5
})
6

Well, Razor does support translating a mix of content and code block into a delegate – which is neat. The limitation is that they cannot be nested, and the parameter name is restricted to “item”

 Rails |  copy code |? 
1
2
@Form.For(..., @{
3
        @item.EditorFor(m => m.Name)
4
})
5

The issue is that “item” is not very expression. I’ve spent many hours digging into Razor’s code trying for find a way to work-around this limitation (by using its extension points, not changing their code). At some point it was clear that coding up my own parser and translator would be easier. Castle Blade then came to fruition.

Blade intends to be 100% backward compatible with Razor, and introduces a few (one?) different transition marks to overcome Razor’s limitations. For the example above, we would use:

 Rails |  copy code |? 
1
2
@Form.For(..., @=> builder {
3
        @builder.EditorFor(m => m.Name)
4
})
5

The @=> transition signals that a delegate will be created for the block, and the parameter name is the one that follows. In theory more than a single parameter is supported.

We also support nested blocks, which allows for the something like the following:

 Rails |  copy code |? 
01
02
@Form.For(..., @=> builder {
03
        builder.FormTemplate(@=> t {
04
                <div>
05
                    @t.Label(): @t.Field()
06
                </div>                                                      
07
            });
08
 
09
        <fieldset id="contactForm">    
10
 
11
        @builder.TemplateFor( m => m.Name )
12
        @builder.TemplateFor( m => m.Email )
13
 
14
        </fieldset>
15
})
16

Feel free to give it a try.

MonoRail+++

MonoRail’s 3 goal is based on our my experience and perception of the “state of the union” and trends. If I could put them in three simple statements:

I’m mentally tired of crafting web sites despite huge functionality overlaps (combine/compose). I’m tired of REST being an afterthought to existing websites (rest support from the beginning). I’m tired of frameworks created by people without *actual* website building experience (frictionless).

The goals/roadmap/value-proposition were discussed in the past in our development list.

  • Since our underlying runtime (CLR) is keen on static typing then fully embrace it
  • Move forward: embrace HTML 5
  • Simplify special render for different form factors
  • Strive for simplicity, but no simpler

I’ll dive into what’s been done in practice to address each of the above bullets in upcoming blog posts.

Exposing extension methods in F#

April 13th, 2011

Thanks for Quora + Reflector + MSDN, I’ve figured out how to expose extension methods from F#

  1. Create a public module within a namespace
  2. Add the extension method as a function
  3. Decorate both the module and the function(s) with the ExtensionMethodAttribute

 C# |  copy code |? 
01
02
namespace Castle.MonoRail
03
 
04
[<System.Runtime.CompilerServices.ExtensionAttribute>]
05
module public ExtensionMethods = 
06
 
07
    open Castle.MonoRail.Routing
08
    open Castle.MonoRail.Hosting.Mvc
09
 
10
    [<System.Runtime.CompilerServices.ExtensionAttribute>]
11
    let Match(router:Router, path:string) = 
12
        router.Match(path, MonoRailHandlerMediator())
13

Categories: .NET, F# | Top Of Page | 2 Comments » |