Add some Curry to your delegates

I started my love relationship with Groovy 1 year ago, but unfortunately since then I haven't had almost any time to devote to it. In the last days I'm trying to go back to it, and one of the first things to do was reading the list of additions to Groovy 1.8, and among all that sweet stuff, the Closure related things immediatelly caught my eye.

I very much like having a curry method in the Closure class. Well, first of all, let's clarify a bit. The "Curry" term is wrongly used here (it's not a crime, even the clever guys at Prototype.js seem to use the term incorrectly), what they are calling currying is in fact Partial Function Application. Well, we have to bear in mind that the term Closure itself is used in a bit inappropiate way in Groovy, I would say when these function objects are not trapping the free vars (cause they are not using them), we should not call them closures, they're just Function Objects (implemented same as in C# via compiler wisdom that creates new classes inheriting from Closure and with a new doCall method).
OK, let's forget this nomenclature thing, and back to the business... What mainly called my attention is that I remember having implemented my own Partial helper methods in C# sometime ago, but due to the (mainly) static character of C# and its delegates, we need a different Partial implementation for each type of delegate that we're using. Let's see an example:

public static Func<T2, R> Partial1<T1, T2, R> (this Func<T1, T2, R> originalFunc, T1 arg1)
 {
  return (arg2) => originalFunc(arg1, arg2);
 }

if we wanted this to work for another delegate, let's say Func we would need a new Partial method, and so on, and so on. Then, the question seems obvious, can't we write a generic Partial method that will work for all sorts of delegates that we happen to throw at it?

Well, each time we define a new delegate type the compiler creates a new class that inherits from the abstract class MulticastDelegate and has an Invoke method with the correct signature for this delegate. MulticastDelegate has a concrete DynamicInvoke method that works for any sort of parameters (receives a params array...). Obviously this kind of invocation involves a lot of runtime checks (as contrary to what happens with a normal delegate invocation done through the autogenerated Invoke method, because nothing is known at compile time with regards to the correctness of these parameters...).

So, with this DynamicInvoke method in mind, let's leave performance aside as this is mainly a proof of concept thing, and let's see what we can come up with:

public delegate Object GenericDelegate(params object[] args);

public static GenericDelegate Partial (this Delegate originalDelegate, object arg1)
 {
  GenericDelegate deleg = delegate (object[] args)
  {
   List<Object> lst = args.ToList();
   lst.Insert(0, arg1);
   return originalDelegate.DynamicInvoke(lst.ToArray());
  };
  return deleg;
 }

It's rather interesting to note two gotchas that I came across while doing this:

• You can't use the params keyword when you declare an anonymous method. Well, it makes sense, the place where it really has to go is when you declare the delegate type that you'll use to refer to that anonymous method (GenerateDelegate in our case).
• The other important, and at first sight shocking, point, is that my initial code:

    Delegate deleg = delegate (object[] args)
    {
     List<Object> lst = args.ToList();
     lst.Insert(0, arg1);
     return originalDelegate.DynamicInvoke(lst.ToArray());
    };
  

  was raising this compilation error:
  error CS1660: Cannot convert anonymous method to type "System.Delegate" because it is not a delegate type
  Seems pretty odd, how is it that a System.Delegate is not a delegate type?
  Well, let's forget about the wording and let's see it this way: the compiler needs to invoke the constructor of a concrete Delegate type to "sort of wrap" the Anonymous Method. System.Delegate and System.MulticastDelegate are abstract types, so they are of no use here, we need a Concrete Delegate type, that's why I needed to declare a new delegate type for this, in my case:
  public delegate Object GenericDelegate(params object[] args);

You can download the code here

Closures and Local Variables

When reading about Java pseudoClosures in the form of Anonymous classes, something that seemed really odd to me is that the local variables or parameters to be trapped by the pseudoClosure had to be final.

As answered here the reason for this is that as those variables are turned by the compiler into local fields of the anonymous class (same as the C# compiler does with delegates and closures) it could seem wrong if we modified those trapped variables inside the closure but they kept its old value when used in the method where the closure was defined.

Well, the explanation makes sense, and is a problem that does not exist with JavaScript closures given how these are implemented there (all the Execution Context object thing...) but, how do things work in C# then?

We should have the same problem, in fact it's something that I had never thought about before, but this excellent article explains that it's different in C#, where we get the same behaviour (that is the correct one for a closure) as in JavaScript: if we modify the trapped variable inside the closure, other closures using that same variable, and the outer method where they were defined, will see that change. It's really surprising in terms of how the Compiler does that, so I had to write some code and open it up with ILSpy to see what's happening under the covers.

The thing is that C#'s compiler is astonishingly intelligent, and we can see how the code where the local variables is defined ends up using the corresponding field added to the generated Class used for containing the closure. Really neat stuff.

The highlighted code in the IL below:

corresponds to the last WriteLine in this C# code:

Person p1 = new Person(){Name = "Xana"};
  Console.WriteLine("TestReferenceType, p1.Name: " + p1.Name);
Action personClosure1 = () => {
   Console.WriteLine("inside personClosure1, p1.Name: " + p1.Name);
   p1.Name += " Llera";
   Console.WriteLine("inside personClosure1, p1.Name: " + p1.Name);
  };
  personClosure1();
  Console.WriteLine("TestReferenceType, p1.Name: " + p1.Name);

so as I said below, the compiler is turning the access to that local variable (in that IL it would be a ldloc.2 instruction) into an access to a field in the class supporting the closure (what we see in that IL as Person App/'<>c__DisplayClass7'::p1

)

You can find the whole code here

Classic ASP and JSON

Yes, sure having to deal with some classic ASP code in 2012 does not seem like the most exciting programming task that you can come across... but there are still tons of classic asp sites running out there (for example easyjet.com used to have some visible classic asp pages till rather recently), so, if for some reason you need to do some addition to a classic ASP site, instead of changing your mindset to the programming paradigm of the late 90's with which the site was originally developed, why not go the other way around and try to apply a modern paradigm to to that old technology

The other day I had to send the data in a "complex" form (well, it had different sections that could be dynamically added) to an asp page. I've used Ajax to call into a classic ASP backend many times before, but in this occasion the type of data to send didn't lend itself too well to be formatted as the classic "&=" chain (I'm not sure what's the proper name for this, form encoded?) but should be sent as JSON. So, the thing is, how do I read the JSON data on the classic ASP side?

• First, you'll need something to savely parse the incoming JSON (needless to say that just applying eval to a user supplied string is a recipe for disaster). Probably you've already used json2.js on your client code, so take advantage of the fact that classic ASP was one of the first Server Side JavaScript frameworks in the market and use it on the Server too.
• Second, you'll have to read the JSON string to pass it over to JSON.parse(). This is the part that proved to be more tricky.
  First I thought I could get the JSON string by accessing the Request.Body property (after all you're trying to get access to the Body of the Http Request), but this didn't work, in fact I didn't realize it was that what was failing until I threw the Visual Studio debugger into the corresponding dllhost.exe process. In Asp.Net you have access to this using the Request.InputStream, but the only similar thing to this in classic ASP seems to be using the BinaryReader method, which appears to me like too much hassle. The work around I used was sending from the client a normal Form key-value chain, with just a key (data for example) and the JSON string as value. That is, in the end I had to change my initial code from this:

  //client side:
  $.ajax({
      async: true,
      url: .........
      type: "POST",
      dataType: "text",
      contentType: "application/json, charset=utf/8",
      data: JSON.stringify(self.formToObject()),
      ....
  
  //server side:
  JSON.parse(Request.Body);
  

  to this:

  //client side:
  $.ajax({
      async: true,
      url: .........
      type: "POST",
      dataType: "text",
      contentType: "application/x-www-form-urlencoded",
      data: "data=" + JSON.stringify(self.formToObject()),
  ...
  
  //server side:
  JSON.parse(Request.Form("data"));
  

Linq IndexOfFirst

Well, time for a very simple post (not that my posts tend to be complex, but this is even more basic stuff). The other day I needed to obtain the index of the fist item in one collection that satisfies some condition. Oddly enough, there's not any method for that in the System.Linq.Enumerable class, so you'll have to write your own.
While searching the net to confirm that I was not missing something, I found that the solution used by many people was doing a Select of the given collection generating the initial items plus an index, and then applying the condition to that new collection and getting the index. Well, I better show the code to see how simple that is (I guess my explanation above is somewhat confusing)

public static int IndexOfFirst1<T>(this IEnumerable<T> items, Predicate<T> condition)
 {
  return items.Select((it, index) => new { Item = it, Index = index}).First(indexedIt => condition(indexedIt.Item)).Index;
 }

Well, if you're not aware of that overload of the Select method that expects an index, you could use the normal Select plus the power of closures like this:

public static int IndexOfFirst2<T>(this IEnumerable<T> items, Predicate<T> condition)
 {
   int i = 0;
  return items.Select(it => new { Item = it, Index = i++}).First(indexedIt => condition(indexedIt.Item)).Index;
 }

Simple, but the code seems to verbose for that basic operation, so pondering over this for a moment I realized of a shorter way to accomplish this, using TakeWhile and Count:

public static int IndexOfFirst3<T>(this IEnumerable<T> items, Predicate<T> condition)
 {
  return items.TakeWhile(it => !condition(it)).Count();
 }

We would use any of the above extension methods like this:

List<string> cities = new List<string>()
  {
   "Xixon",
   "Berlin",
   "Vienna",
   "Prague"
  };
  Console.WriteLine(cities.IndexOfFirst3(it => it.StartsWith("V")).ToString());  

You can get the code here