A Software Engineering Blog

by Nick Holmes

  Home  |   Contact  |   Syndication    |   Login
  11 Posts | 0 Stories | 6 Comments | 0 Trackbacks

News

Archives

Post Categories

May 2009 Entries

When we use LINQ To SQL in C#, the compiler doesn't generate IL to implement our query - we want Sql Server to execute the query, and so IL would not be much good. Instead the compiler creates data that describes our query, in the form of a System.Linq.Expressions.Exp... When the query needs to be executed, LINQ To SQL examines the expression and converts it to the equivalent T-SQL, and sends that to the database for execution. It follows, then, that if we want to use LINQ To SQL in F#, we'd...
  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati

To use LINQ To SQL, we need a Data Context object to provide our point of entry. It might be possible to use a System.Data.Linq.DataContext object directly, but its more usual to derive from this class to make a database specific version. Additionally, we need classes to represent our "entities". These define the mapping to the tables (or views) and columns. We could code all this up by hand, but Visual Studio 2008 comes with the grandly named Object Relational Designer that makes short work of this....
  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati

[Update: This blog post was orignally posted in early 2008, in another blog. Things have changed a little in F#, and Ted Nedward has provided updated information related to this, showing how to create data contracts in F#] On the road to a really interesting Web Service, I increased the complexity of my "could-not-be-simpler" web service one notch, and added a class-typed argument to the operation. This requires constructing of a Data Contract, so that WCF can build the correct WSDL, and also know...
  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati

I had half an hour to fill while I waited for a large download, on my slow connection. I'd thought about re-implementing my C# WCF test host in F#. It didn't look too complex, and indeed it wasn't: #light #I @"C:\Program Files\Reference Assemblies\Microsoft\Framew... #r "System.ServiceModel.dll" #r "Server.dll" open System open System.ServiceModel open System.Diagnostics open Coyote.FSWCFTest let services = [ (typeof<TestWebService>, "http://localhost:8080/Test... ] let...
  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati

I tidied up the F# web service, mainly by factoring out an interface for the web service. Without the attributes it looks like this: type ITestWebService = abstract TestMethod: Param:string -> string type TestWebService() = interface ITestWebService with member x.TestMethod s = "Hello " + s; However, I noticed when I was setting up the C# host, I needed to cast to get to access the interface, like this: TestWebService tws = new TestWebService(); ITestWebService itws = tws as ITestWebService; Neither...
  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati

For all the power and flexibility that WCF provides, creating a basic web service in C# is easy enough. Essentially, it's just a POCO adorned with some special attributes. Doing the same thing in F#, then, should also be easy enough. I tried this: #light #I @"C:\Program Files\Reference Assemblies\Microsoft\Framew... #r "System.ServiceModel.dll" open System.ServiceModel [<ServiceContract(Config... = "TestWebService", Namespace = "http://coyote-software.com... [<ServiceBehavior(Instan...
  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati

I previously said that C#’s lambda functions were not curried, and it wasn’t possible to partially apply them. However, it’s usually possible to manually curry functions, if you need to. Here is an example: static void Main(string[] args) { int t = f(1)(3)(5)(7); Console.WriteLine("{0}", t); var g = f(1); var h = g(3); var i = h(5); int j = i(7); Console.WriteLine("{0}", j); } static Func<int, Func<int, Func<int, int>>> f(int a) { return (b => c => d => (a + b + c + d));...
  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati

All this currying and partial application stuff is all very interesting, but surely its has to have some kind of run-time performance hit. What if I just want to keep things straightforward? Firstly, if we have a function that takes only a single argument, there is nothing to curry. It makes no sense to call a function with no arguments, so your only option is to make the exact call. That in mind, we can do this: let repeat(str, n) = ... That syntax is sure to catch out C# programmers (like me),...
  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati

In my last two posts, I described how F# transforms functions with more than one argument into chains of functions with a single argument. Strictly speaking, all functions in F# must have exactly one argument, and return exactly one result. There is a special type, unit, which can be used as a dummy when no argument or return is required, like void in C#. F#’s functions are lambda functions, formally described by lambda calculus which provides the theoretic model for functional languages. Happily,...
  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati

OK, so you define a function that takes 2 parameters, but you actually get a function that takes 1 parameter, and returns a function that will take the second parameter and return the final result. Hmm, this raises lots of questions. What happens if the function has more than two parameters? >let f a b c = a + b + c is of type val f : int -> int -> int -> int So we get a chain of functions, each one taking exactly one parameter, and returning a function that takes the next. If there are...
  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati

I’ve been spending some time recently looking at F# - I have a specific task in mind to which F# seems very well suited, so the motivation is there! After many years doing C then C++ and now C#, it’s easy to fall into the trap of thinking some things work just the same in F#. One example of this is functions. I was happily experimenting with some code, thinking I was getting the measure of F#, but one small detail kept catching my eye - the very strange types reported for functions. It all starts...
  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati