Closure in a Loop

Closures are one of those things that when you get used to them it seems absurd that a modern language does not implement them (hey java, wake up, it's time for you too...)
They're really important in JavaScript for the Asynchronous Ajax calls and callbacks or the binding of "this" to an event handler.
I've also done good use of them in C#, saving me from having to write "intermediate classes" just to hold parameters to be passed to a method when inside a parameterless delegate... yes, it sounds confusing, this sample with ThreadStart delegate makes it clear, though:

//we have this method that expects two parameters:

public static void Format(string title, string txt)

{

Console.WriteLine( "<h1>" + title + "</h1>"

+ "<p>" + txt + "</p>");

}

//and we want to run it in its own thread, but ThreadStart delegate does not accept any parameters, so what? just create a parameterless closure that captures the needed values and passes them on to our method:

string s1 = "title";

string s2 = "description";

Thread th1 = new Thread( new ThreadStart(() => HtmlFormatter.Format(s1, s2)));

th1.Start();

How a language implements closures is interesting and bizarre at the same time. Scope chains in JavaScript, auxiliar classes generated by the C# compiler...

Well, I've come across several times with a case that does not work the same in JavaScript and C# and that makes you think about how language semantics and internal implementation shaped this case. It's when you create a closure in a loop.

Let's say we have loop like this in C#:

for(int i=0; i<5; i++)

    actions.Add(()=>print("value = " + i));

or in javascript:

for(var i=0; i<5; i++)

    actions.push(function(){print("value = " + i);});

if now we invoke the functions in the actions array, it's not 0, 1, 2, 3, 4 what we're going (and that in principle would be desired behavior) to obtain, but 5, 5, 5, 5, 5.

This makes good sense in both cases if we think in terms of scope.
In the JavaScript case, the scope for i is the whole function, in the C# case, the whole loop, so in both cases, all actions are capturing the same i variable and all of them see any change done to the variable.
Thinking in implementation terms, if we know how closures are implemented in each language, this makes perfect sense with JavaScript, when each function is declared it captures the execution context object of the function where it's declared, so all these new functions point to the same execution context that contains that i variable.
However, in C# this behavior caught me by surprise. In principle, the compiler generates a class where the method for the delegate and the free vars are stored, so there should be one instance of that class per method and then a different i variable (data field) in each case. I was wrong, in this case an only instance of the class is used, so i is shared.

To obtain the intended behavior, we would have to go this way in C#:

for (int i = 0; i<5; i++)

{

int k = i;

actions.Add(() => print("value = " + k));

}

in this case we're using a new variable k, that is scoped only for each loop iteration, so each closure captures a different k variable.

however, if we do the same in JavaScript:

for (var i = 0; i<5; i++)

 {

  var j = i;

  actions.push(function(){ print("value = " + j);});

 }

we still get the initial results: 5, 5, 5, 5, 5.
This is the right thing according both to semantics and implementation. In spite of being declared inside the loop, the scope for the j variable is the whole function... so this it the same as for the first case. Likewise, from the implementation standpoint, we have an only variable in the execution context of the main function... so that's fine.

So for JavaScript in order to achieve the intended behavior, we need to add an extra function with it's extra scope, execution context:

for (var i = 0; i<5; i++)

  actions.push(function first(it){return function second(){print("value = " + it);}}(i));

when the "second" function is declared, it captures the it parameter passed to the "first" function where it's declared. We have 5 "instances" of the "first" function, each one with its own "it" parameter, that will be captured by the "second" function.

The equivalent c# code would be something like this:

for (int i = 0; i<5; i++)

{

 Func<int, Action> intermediate = it => (() => Console.WriteLine(it));

 actions.Add(intermediate(i));

}

You can check the source code:

• JavaScript


• C#

Hey, I've got an update to this

Some JavaScript Magic

It's not a secret that I consider JavaScript one terribly interesting language. I quite like its Prototype based object orientation and how its enormous flexibility allows us to simulate class orientation. I've got a certain amount of experience with JavaScript and I'm sort of a Language freak (I don't know a word about compilers-interpreters programming, but I'm very much interested in the different features and idioms provided by different languages), but anyway JavaScript continues to wonder me with new pieces of wisdom.
So, I'm going to talk of some of the last ones I've found (or rediscovered) lately:

• JavaScript closures are one of its more important features. It's very interesting to learn how the [[scope]], execution context, scope chain... work together. Yesterday I found a use of closures that I'd never seen before and really amazed me, using closures for anonymous recursive functions:
  
  var count = function countToTen(i) {
  if (i <= 10) {
  console.log(i);
  count(i+1); // Call count with the power of closures
  }
  }
  when countToTen is declared, it's [[scope]] property traps the count variable, so when countToTen is executed, it can find count in its execution context.
  as the article says, you no longer need arguments.callee nor named functions (thought anyway, for debugging purposes I think all functions should be de-anonymized)
  


• Functions with return values being used as constructors. This is rather interesting. In most languages I know constructors do not return any value. In JavaScript, the concept of constructor not rigid at all, in fact, I think we can say that we don't have constructors, we just have functions, and when a function is called following a new statement it works as a constructor.
  
  var p1 = new person();
  
  I think it works this way: new creates a new object, the object gets its constructor [[Prototype]] property pointed to person() and then is passed to person() as this. person does whatever it wants with this and if it does not have a return statement, the new object-this is assigned to p1. Nothing unusual so far. But, what happens if person has a return statement? in that case it's the object returned by the function what gets assigned to p1. This, apart from being a rather freak feature, could not seem way too useful, but for example it could be useful for implementing a singleton pattern this way.
  What I like of that implementation is that the singleton no longer looks like a singleton to the outside world when referencing it. What I mean with this is that instead of the classic singleton.instance... we can call new as many times as we want, and we'll be receiving the same object...
  It's as if the class was no longer expressing in its contract that it's a singleton, is this really a good idea?
  Also, this thing reminds me of __new__ in Python, that is sometimes (ab)used to implement sort of a factory.
  


• I really like when something makes you scratch your head, even if it's not especially useful. First time I saw somewhere a JavaScript line like this:
  this();
  it really caught me by surprise.
  Well, it's not that strange (taking into account that functions are objects and as such can be "expanded"), if "this" can be invoked it means "this" points to a function, so if we think how the "this" gets assigned, an example would be just something like this:
  
  var f1= function(){print("I'm f1");};
  f1.hi = function(){this();};
  f1.hi();
  
  Thinking around this a bit more it came to my mind how we could write a rather confusing line. Let's say we have a person "class" and we're going to add some "static" methods to it:
  
  function person()
  { this.name=....};
  //instance methods
  person.prototype.dump = function(){...};
  //static methods
  person.static1 = function(){...};
  //this looks rather confusing, cause having a "this" in a "static" does not seem too natural
  person.static2 = function(){this.static1();}
  //this one looks much more natural way to call a static method
  person.static3 = function(){person.static1();}
  


• While checking some more JavaScript code in the web I came across this lazy function definition pattern. It's both simple and interesting. A problem with this is that we're just changing where the reference points to. If we had more than 1 reference to the function object, it would only work for one of them. It would be beautiful if we could replace the code inside the function itself, something like:
  arguments.callee.code = function(){...}.code;
  it would just involve that functions had a code property containing their code itself.
  

Ordered enumeration

The other day while writing some WSH code (yes, this old, but really powerful, technology is still alive and well, and I guess it will take a very long time until it gets fully replaced by .Net and PowerShell), I came up with something that could be good to share.

I have different scripts each one using a different logInfo "data object" that is passed to a generic logToCSVFile method. It's no wonder that the method enumerates the data fields in the logInfo object and writes a line to the csv file.
So, I need to enumerate these data fields always in the same order (and also get the data fields name, so that each time I create a new log file I write those names as column headers).
I had a problem here:
Traversing a JavaScript object (in the end a dictionary) with for in does not guarantee the order in which items will be returned. Well, in practice it seems it does, but we can say it's an implementation detail, not an interface contract. So, in principle, I can't count on fields being returned in the same order as I added them. Also, it could happen that I would not always add them in the same order... so I definitely need something more...

In C# (and Python) setting the enumeration order would be that simple and elegant as using an iterator block (a generator in Python) letting the compiler generate the Enumerator object for us. (for obtaining the Fields order I had to do some extra code, see the source)

public class LogInfo:IEnumerable<String>

{

    public IEnumerator<String> GetEnumerator()

    {

        yield return this.User;

        yield return this.Computer;

        yield return this.Result;

    }

    IEnumerator IEnumerable.GetEnumerator()

    {

        return this.GetEnumerator();

    }

}

but in JavaScript I had to write some more code (well, JavaScript 1.8, implemented in last Firefox versions, provides generators, but that's rather unknown to the %systemroot%\System32\jscript.dll engine used by WSH...) In the end I came up with an object that can be iterated with 2 slightly different for-in constructions:

var orderedEnumerator = function(orderAr, source)

{

    this.order = orderAr;

    this.enumerable = source;

    this.curPos = -1;

};

orderedEnumerator.prototype.get = function(i)

{

    return this.enumerable[this.order[i]];

};

orderedEnumerator.prototype.count = function()

{

    return this.order.length;

};

orderedEnumerator.prototype.current = function()

{

    return this.enumerable[this.order[this.curPos]];

};

orderedEnumerator.prototype.moveNext = function()

{

    if (this.curPos < this.order.length-1)

    {

        this.curPos++;

        return true;

    }

    return false;

};

You can get the code here:

• javascript (you can easily test it with cscript, rhino or firebug)


• c# (I've added some stuff to get the "columns order" thing)

Platform evolution and inconsistencies

It's not easy to evolve a platform, avoid breaking code and being consistent.

So far, one of the main changes undergone by the .Net Framework was the inclusion of generics both at the CLR level and the language level.

With this, we saw the arrival of a common creational idiom:

T Create<T>(){/*implementation here*/}
T myObject = Factory.Create<T>();

so, we can write code like this:

MyType instance = Factory.Create<MyType>();

instead of this

(MyType) instance = Factory.Create(typeof(MyType));
//note the need of a casting due to a method signature like this:
Object Create(Type t){/*implementation here*/}

We have a sample of both styles in Activator.CreateInstance, which among other overloads has:

• public static Object CreateInstance(Type type) //old style, available since framework 1


• public static T CreateInstance<T>() //new style, available since framework 2.0

Note that version 1 is not marked as deprecated. That makes some sense due to its dynamic nature. Doing a CreateInstance(otherInstance.GetType) means that we don't need to know at compile time (as happens with the generic version) the type of the object to create. Anyway, we would be returning an Object, and as we could not cast it (cause we don't know what to cast to) it would not be much usable (only through Introspection). In .Net 4, the dynamic keyword would make it more convenient to use.

Today, when checking more in depth the list of new features in .Net I came across something that looked a bit inconsistent to me. We have a new Enum.TryParse that is rather welcome and uses the second style, but when compared with "classic" Enum.Parse that uses the first style, the whole picture looks a bit inconsistent:

Parse(Type, String)
Parse(Type, String, Boolean)

TryParse<TEnum>(String, TEnum)
TryParse<TEnum>(String, Boolean, TEnum)

in this case, given that I don't think that there's any dynamic scenario that needs of a Parse(myInstance.GetType(),...), I believe the best would have been marking the current Parse implementations as deprecated and add 2 new ones:

Parse<TEnum>(String)
Parse<TEnum>(String, Boolean)

.Net 4 oddities

I installed .Net 4 some days ago, but have not been able to play much with it (apart from "agenda reasons"... the SDK for .Net 4 was not released until last friday, SharpDevelop 4 is still in the works, Reflector support for .Net 4 is also a bit limited...).

Anyway, as I've ever had some interest in "low level" details, I checked a bit what had been installed and found a few things I'd like to mention:

• If you check the %systemroot%\Microsoft.NET\Framework\v4.0.30319\ folder, you won't find there either mscorjit.dll or mscorwks.dll-mscorsvr.dll (the CLR engine). This does not make sense, while .Net 2, 3 and 3.5 were all running on CLR 2 (so, using the JIT compiler and CLR Engine in Framework\v2.0.50727), .Net 4 is running on CLR v4, so there has to be a new CLR engine somewhere. Also, there have been some performance improvements to the JIT compiler (but no new additions to CIL, as far as I know the only changes to it were the addition of generics back in v.2), so there should be a new JIT. I was googling a bit and found this. In brief, the new JIT is in the clrjit.dll Dll, and the new Engine in the clr.dll Dll


• I had a look at the GAC to see the new installed assemblies, and imagine my surprise when I could not find any 4.0 assembly there. I found an entry in Stack Overflow that explains that there's a new GAC for version 4 assemblies, located in %systemroot%\Microsoft.NET\assembly\
  What that entry does not seem to answer clearly is why do we need 2 GACs, hadn't the GAC been designed as the solution to the Dll Hell issues?


• While trying to locate the "missing" assemblies I noticed some repeated ones, so I did this question in Stack Overflow

Daybreakers

I rather like modern vampire films, especially those were vampires are depicted as some sort of an aristocratic elite above the poor simple humans, that continue with their lives of weakness and fragility. I'm talking about the Vampires in films like Underworld, Blade or Rise.

Since I learned that there was a new Vampires film I was keen to watch it, and cinetube made my night yesterday :-)
Daybreakers is a rather good film, I watched it non stop (something not too usual in me that tend to interrupt my home film sessions several times with some web search, mail checking... I could say that it's cause I've got so many interets... but actually it's more that I'm a bit disperse sometimes :-)
To the point, the film is a bit different from what I expected (I was thinking of something revolving around the common elements in the aforementioned films). Vampires are not an elite, but rather the majority of the population, while humans have been reduced to an almost extint sort of cattle. Same as farms of humans provided energy in Matrix, they provide blood here (there's an scene purely reminiscent from Matrix).

Spoiler Warning Begins
As the lower level in the food chain dies out, the upper level begins its decline... so vampires are crazy to find a solution: artificial blood.
In the end another solution is found, reverting vampires back into humans, but would you be willing to renounce to your immortality as an eternally young vampire to turn back into a perishable being whose life is a countdown to the end?
It's a classical moral dilemma, that reminds me in some way the moral conflicts in recent SciFic films like Aeon Flux or The Island (I really enjoyed both films at the time).
Spoiler Warning Ends
One element of this film that can be striking is how bloody some moments are. Vampires act as bloody beasts, reminding me of the horrific vampires in 30 Days of Night, an excellent underrated film that amazed me for how it represented vampires as horrible, revolting monsters, so far from the fashionable "beautiful monster" style in other films.

I won't close this review without praising the impressive opening scene, very beautiful both in visual and meaning terms.

The money of Islam

In the XIX century Karl Marx said this famous sentence with which in general terms (I accept some nuances: religion vs spirituality, individual interpretations) I agree so much:
"Religion is the opiate of the people"

Nowadays we can reformulate it a bit and say:
Drugs are the money of Radical Islam.

Yes, we all know how the Taliban have used drug traffic (heroin) to fund their crimes against humanity, but it seems this trend has spread to other fundamentalist groups.

This interesting documentary (sorry, it's in Spanish) tells us about the relation between Al-Qaeda in Maghref and South American drug dealers. The Wahhabist controlled area of the Sahara desert in Mali is a good place for planes from South America to take land and from there cross the Argelian border all the way to poison Europe. Well, I'm not blaming them for that, nobody forces you to sniff cocaine, it's not the dealer's fault, it's the consumer's fault... From the rotten mind of a Fundamentalist weakening and poisoning the infidels is a good way of carrying out their filthy yihad... but sometimes it's other muslims who fall into addiction, well, sure it's that they're not "devote enough"...

Of course, drugs are not the main source of funding for Radical Islam, petrodollars from the government of Saudi Arabia is the main source of funding, maybe not directly to the armed groups, but sure for the radical clerics that brainwash their congregations and infuse into them their distorted, false and radicalized interpretation of Islam.
Wahhabism, the radical sect that is majoritary in Saudi Arabia hates us cause we're Kafirs (they even hate other muslims that not fit in their mold, like Shia muslims).
They're at war with us (but many of us seem not to want to realize), and because of that they spend millions printing modified versions of Qur'an containing such lunatic sentences for a book written in the VII century as "use tanks and machineguns against the infidels". These versions of Qur'an are sent for free to mosques all over the world... They also spend millions funding madrasas and mosques and paying salaries to radical anti-Western clerics that spread from there their message of hate and bigotry.

Regarding this, wikipedia extracts this sentence from this excellent documentary:

Saudi Arabia began to spend tens of billions of dollars throughout the Islamic world promoting Wahhabism, which was sometimes referred to as "petro-Islam".[47] According to the documentary called The Qur'an aired in the UK, presenter Antony Thomas suggests the figure may be "upward of $100 billion"

I really recommend the documentary, it's not an attack on Islam, but an objective documentary that shows both good and bad things in Islam and attempts to explain why the radical bastards have won the battle to the moderate muslims, and what parts of the book can be mistakenly read to support their fanatical views.

Do you renember the "bearded guys" demonstrating in Trafalgar Square in early 2006 because of the Muhammad cartoons controversy? (those days I really fancied hanging a Danish Flag in my window), claiming for the destruction of Europe (the same Europe that provides them with a salary and a free health system... quite different to what they have in their shit countries...) I bet those bastards got some petrodollar educational aid.

Much more than Iran (where good part of the population is rather moderate and where other religious minorities are respected) the biggest "devil" in the Islamic world is Saudi Arabia (that mediaval country where people are hanged in public squares and where the public practice of non-Muslim religions is prohibited). I don't see the Iranian government (with all the revolting that Ahmadinejad is) funding the world wide spread of Islam (even when they're financing Hezbollah or some Iraqui shia militias).

Of course the problem is that Saudi Government is an "alley" of the USA (and the Western world in general) that aids them to satisfy their need for petrol... Back in the 80s the talibans where also allies of the USA in their war on "Communist Devil". Years later the relationship proved rather wrong, and we all know what came next... when the Saudi-USA alliance proves wrong, I'm afraid the outcome will be much worse...

Update:
while visiting different sources preparing this post, I knew about the Undercover Mosque documentary. I've just watched it and it absolutely backs up all what I claim above about Saudi Arabia. If I were British, I would feel terrified at the prospect of these fundamentalist bastards outnumbering "Kafirs" (we know that they tend to keep here their third world birthrate) and seizing power...