Not so much an actual blog today, rather a link to a presentation I recently gave as an introduction to the .NET framework and C# - to a mixed audience of C, C++, Java and web developers.
It's mainly a high level overview of the .NET framework and then an introduction to the C# language, from a programmers perspective, for programmers familiar with other languages like Java and C++, to help get familiar with the basics.
Available in OpenOffice format ODP:
http://www.chillipower.com/Primers/IntroductionToDotNetandCsharpPresentation.odp
Or MS PowerPoint presentation format PPT:
http://www.chillipower.com/Primers/IntroductionToDotNetandCsharpPresentation.ppt
.
Showing posts with label C#. Show all posts
Showing posts with label C#. Show all posts
Thursday, 2 April 2009
Wednesday, 18 February 2009
Currying, some examples and comparisons between C# and Scala
I'm back again! It's been some 3 weeks since my last blog - I've been in New York for 5 days and busy either side sorting out commitments and work and home.
So, in this posting I'd like to continue on the theme of Lamda and functional programming with some simple examples of Currying in both C# .Net (3.0+) and Scala.
I've tried to keep the examples equivalent as closely as possible but Scala has a few different options when it comes to syntax, so the Scala version is a little longer as it delves into these extra possibilities.
What is currying?
In a nutshell currying is "the process of reducing a function that takes multiple arguments into a series of functions that each take one argument"
Named after Haskell Curry - http://en.wikipedia.org/wiki/Haskell_Curry
A good explanation and definition can be found here http://www.haskell.org/haskellwiki/Currying
C# .Net example using C# 3.0+ syntax for Lamdas:
Results:
Notes:
Extension Method:
static Func<TArg1, Func<TArg2, TResult>> Curry<TArg1, TArg2, TResult>(this Func<TArg1, TArg2, TResult> f)
Take the above definition of a method, the this keyword in the (this Func...) parameter definition makes the function an extension method, so it can be used as if it were declared on the add function - to illustrate the point, without the extension syntax the Curry function could only be invoked in the regular way as follows:
var curriedAdd = Curry(add);
As an extension method, it's valid to use the original add.Curry() or Curry(add) syntax interchangeably.
Scala example:
Results:
Notes:
Update:
I realised that the way I'd defined the curried add functions in the Scala example is perhaps not as verbose or explicit as it could have been, and therefore perhaps less easy to understand or compare to the C# example. So here is another code snipped that shows a more verbose currying:
Results:
Resourses:
Good explanation of currying in C#.Net http://diditwith.net/2007/08/15/TheArtOfCurrying.aspx
.
So, in this posting I'd like to continue on the theme of Lamda and functional programming with some simple examples of Currying in both C# .Net (3.0+) and Scala.
I've tried to keep the examples equivalent as closely as possible but Scala has a few different options when it comes to syntax, so the Scala version is a little longer as it delves into these extra possibilities.
What is currying?
In a nutshell currying is "the process of reducing a function that takes multiple arguments into a series of functions that each take one argument"
Named after Haskell Curry - http://en.wikipedia.org/wiki/Haskell_Curry
A good explanation and definition can be found here http://www.haskell.org/haskellwiki/Currying
C# .Net example using C# 3.0+ syntax for Lamdas:
using System;
static class Program
{
static void Main()
{
Func<int, int, int> add = (x, y) => x + y;
var curriedAdd = add.Curry();
var curriedIncrement = add.Curry()(1);
var curriedDecrement = add.Curry()(-1);
Console.WriteLine("curriedAdd(10)(11) = " + curriedAdd(10)(11));
Console.WriteLine("curriedIncrement(41) = " + curriedIncrement(41));
Console.WriteLine("curriedDecrement(41) = " + curriedDecrement(41));
}
// a simple 2 arg curry template function
static Func<TArg1, Func<TArg2, TResult>> Curry<TArg1, TArg2, TResult>(this Func<TArg1, TArg2, TResult> f)
{
return a1 => a2 => f(a1, a2);
}
}
Results:
curriedAdd(10)(11) = 21
curriedIncrement(41) = 42
curriedDecrement(41) = 40
Notes:
- The use of the var keyword for implicit typing
- C# does not provide implicit functions/ partial application so a Curry template function for 2 arguments has been provided explicitly.
- The Curry method is defined as an extension method so it appears as-if defined on add
Extension Method:
static Func<TArg1, Func<TArg2, TResult>> Curry<TArg1, TArg2, TResult>(this Func<TArg1, TArg2, TResult> f)
Take the above definition of a method, the this keyword in the (this Func...) parameter definition makes the function an extension method, so it can be used as if it were declared on the add function - to illustrate the point, without the extension syntax the Curry function could only be invoked in the regular way as follows:
var curriedAdd = Curry(add);
As an extension method, it's valid to use the original add.Curry() or Curry(add) syntax interchangeably.
Scala example:
package test;
object Currying {
def main(args : Array[String]) {
// regular syntax function add
def add(x : int, y : int) = {
x + y
}
// create curried add using 1 and -1 for increment and decrement by invoking partial function (a:int, _:int):int
var curriedIncrement = add(1, _ : int)
var curriedDecrement = add(-1, _ : int)
// test funtions
println("add(10, 11) = " + add(10, 11))
println("curriedIncrement(41) = " + curriedIncrement(41));
println("curriedDecrement(41) = " + curriedDecrement(41));
// curried syntax function add
def add2(x : int)(y : int) = {
x + y
}
// create curried functions using partial functions
var curriedIncrement2 = add2(1)(_ : int)
var curriedDecrement2 = add2(-1)(_ : int)
println("add2(10)(11) = " + add2(10)(11))
println("curriedIncrement2(41) = " + curriedIncrement2(41));
println("curriedDecrement2(41) = " + curriedDecrement2(41));
// special {} syntax
val res1 = add2(10) {
11
}
println("res1 = " + res1)
// more complex example
val x = 1
val y = 2
val z = add2(10) {
add2(20) {
x + y
}
}
println("z = " + z)
}
}
Results:
add(10, 11) = 21
curriedIncrement(41) = 42
curriedDecrement(41) = 40
add2(10)(11) = 21
curriedIncrement2(41) = 42
curriedDecrement2(41) = 40
res1 = 21
z = 33
Notes:
- Scala supports f(x:int)(y:int) syntax for explicit curried functions
- Scala supports implicit currying using partial application, using the placeholder _ syntax
- Scala supports curried parameter in {} syntax for functions that appear to extend the language by taking parameter from the body of the call.
Update:
I realised that the way I'd defined the curried add functions in the Scala example is perhaps not as verbose or explicit as it could have been, and therefore perhaps less easy to understand or compare to the C# example. So here is another code snipped that shows a more verbose currying:
object Currying {
def main(args : Array[String]) {
def add3(x : int) = {
(y : int) => {
x + y
}
}
println("add3(1)(2) = " + add3(1)(2));
val res = add3(5){
3
}
println("res = " + res)
}
}
Results:
add3(1)(2) = 3
res = 8
Resourses:
Good explanation of currying in C#.Net http://diditwith.net/2007/08/15/TheArtOfCurrying.aspx
.
Labels:
.NET,
C#,
Curried functions,
Currying,
Lamda,
partial application,
partial functions,
Scala
Sunday, 9 November 2008
c# code generation added rest describe code gen
Announcement: c# code generation added to google rest describe code gen api:
At last, the google rest describe code gen api now has a c# code generator. Targeting c# .net 3.5 WCF. This gives an easy route from existing services or WADL to c# client code/framework. I hope to be blogging about it soon, with some details of how it works and any limitations you shoud be aware of...
At last, the google rest describe code gen api now has a c# code generator. Targeting c# .net 3.5 WCF. This gives an easy route from existing services or WADL to c# client code/framework. I hope to be blogging about it soon, with some details of how it works and any limitations you shoud be aware of...
Thursday, 10 July 2008
C# delegates
A quick note on c# delegate functions:
I found the standard way to define delegates a little clumsy and verbose in some situations, for example when wanting to pass a function to a .Invoke method of a control to add it to its thread work queue. In this situation the delegate's purpose is really just to pass the method to the invoker, there is no other use of the delegate so declaring it at class level is a much wider scope that I would like. What I wanted is a more terse, compact and locally scoped way to achieve the same thing, here it is:
The simple way:
Declare delegate within class, e.g.
public delegate void updateStockView(Stock[] stocks);
use to create a new delegate instance to pass to invoke on a control, e.g.
instrumentDgv1.Invoke(new updateStockView(this.updateStockView), new object[] {instrumentResponse.Stocks});
This approach, whilst perfectly valid feels a little cumbersome. Firstly the delegate is at an uneccessarily high level of scope, secondly, the statment requires a new instance of the delegate to be created, passing the delegate's parameters down as an object array.
A more compact form:
instrumentDgv1.Invoke((MethodInvoker)delegate { this.updateStockView(instrumentResponse.Stocks); });
Here we see, no unnecessary declaration of the delegate type, no creation of the delegate instance, no passing of parameters as an object array - all round much tighter syntax for this type of use.
The key thing to make this work is the MethodInvoker cast. MethodInvoker is from the System.Windows.Forms namespace and is used to cast the existing method to the delegate type without requiring the declaration/instantiation of a new delegate.
.
I found the standard way to define delegates a little clumsy and verbose in some situations, for example when wanting to pass a function to a .Invoke method of a control to add it to its thread work queue. In this situation the delegate's purpose is really just to pass the method to the invoker, there is no other use of the delegate so declaring it at class level is a much wider scope that I would like. What I wanted is a more terse, compact and locally scoped way to achieve the same thing, here it is:
The simple way:
Declare delegate within class, e.g.
public delegate void updateStockView(Stock[] stocks);
use to create a new delegate instance to pass to invoke on a control, e.g.
instrumentDgv1.Invoke(new updateStockView(this.updateStockView), new object[] {instrumentResponse.Stocks});
This approach, whilst perfectly valid feels a little cumbersome. Firstly the delegate is at an uneccessarily high level of scope, secondly, the statment requires a new instance of the delegate to be created, passing the delegate's parameters down as an object array.
A more compact form:
instrumentDgv1.Invoke((MethodInvoker)delegate { this.updateStockView(instrumentResponse.Stocks); });
Here we see, no unnecessary declaration of the delegate type, no creation of the delegate instance, no passing of parameters as an object array - all round much tighter syntax for this type of use.
The key thing to make this work is the MethodInvoker cast. MethodInvoker is from the System.Windows.Forms namespace and is used to cast the existing method to the delegate type without requiring the declaration/instantiation of a new delegate.
.
Subscribe to:
Posts (Atom)