f# essential - part 1 binding

I was very puzzled with some concept when learning F#. Here is some. Even I explain it here, you may be still confused, but it is ok, as you read on.

let t1 = 1
//fsi shows val t1 : int = 1
//think of it as (val t1) bind to (int = 1)

Based on the concept of other language, you think t1 is variable, and it is initialized or assigned with value 1. But here it should be understood as identifier t1 is bind to a value, the value is not function value, it is int 1. So what is the big deal of "identifier", "bind", "function value", and "value", we will see later. If you run the following expression in fsi

t1
//fsi shows val it: int =1

This is evaluation of expression "t1", the process is to bind value int 1 to unknown identifier. Let's read another example.

let t2() = 1
//fsi shows  val t2 : unit -> int
//here fsi should shows
//val t2: unit -> int = <fun:it@91-2>

Here it means identifier t2 is bind to a value, the value is a function value, and the value is a function take unit type parameter and return a int type value. Here unit is similar the concept of "void" in other language. How do I prove my remark "here fsi should shows...", because we can find out what is the value of t2, by evaluating expression "t2" like below, it return the value of t2, here what I really means "the value that t2 is bind to "

t2
//val it : (unit -> int) = <fun:it@91-2>

t2 is different from t1 in that the value t2 bind to is a function, while the value that t1 bind to is not. Because the value is function, we can call the function like below. The concept of "function is a value" is an important concept in functional language, it may not looks a big deal for you. But it is very powerful. Please note the function here is not a traditional function in VB, a method in c#, conceptually it is like C#'s delegate, or javascript's function, people call it lamda in other functional language.

t2();
//fsi shows val it : int = 1

The type description generated by fsi need some explanation.

t2();
int //int type
int -> string //function type take one int input, return one string
int -> string -> double // a function take one int, one string, return one double
int * string -> double // a function take a (int, string) tuple , and return one double

Semantics of undefined and null in javascript

Recently, I was discussing with a friend about the difference between undefined and null in javascript. I am surprised that I gave an explanation that he can understand, more surprisingly, I can understand too. Sometimes, people give an explanation, which they don't understand themselves, and also confuse others. Before going further, here is the explanation from JavaScript: The Definitive Guide

You might consider undefined to represent a system-level, unexpected, or error-like absence of value and null to represent program-level, normal, or expected absence of value. If you need to assign one of these values to a variable or property or pass one of these values to a function, null is almost always the right choice.

The explanation is confusing to me. What does this means in my daily coding, in what scenario I must use one but not the other or a scenario I can use either of them? So if null is almost the right choice, but why we have "undefined", is there any technical reason or semantic reason? Let's see why we have "undefined" value in javascript from technical perspective. When we write the following code, I can say, I declare two variables and they are not assigned with any value, and the default value of each is undefined.

var x;
var loooooooooooooooooooooooooong;

After reading the article Understand delete, I understand that, javascript variable mechanism. When you declared variable like above, you add a key/value pair entry to a mysterious object, VariableObject, which is dictionary. Here is pseudo code, that the engine will convert to

VariableObject["x"] = undefined;
VariableObject["loooooooooooooooooooooooooong"] = undefined;
//semantically, it means the following
//VariableObject.add("x", undefined);
//VariableObject.add("loooooooooooooooooooooooooong", undefined);

If the above example, two key/value pairs are added to the VariableObject dictionary. So both the key and value consume memory, so if you have a longer variable name, regardless its value, it use more memory than short variable. This is different from c++. In c++, a variable name is nick name of memory address. So practically, we should use shorter variable name, or use minifier to rename your variable. The VariableObject is special in that it is created by runtime. If the code is run in Global scope, the VariableObject is accessible as window. If it is run function scope, it is not accessible at all, which is known as Activation Object. Supposed it is run in global scope, it is same as the following.

window["x"] = undefined;
window["loooooooooooooooooooooooooong"] = undefined;

In the above case, variable x is said declared because its key is in the dictiobary, but its value is undefined. If the key is not even in the dictionary, then it is undeclared. Technically, there is difference between "undeclared" and "declared but undefined". But the following undefined check does not tell the difference.

//suggested by jQuery Code Style Guildeline
//http://docs.jquery.com/JQuery_Core_Style_Guidelines
//undefined check
//Global Variables: 
typeof variable === "undefined"
//Local Variables: 
variable === undefined
//Properties: 
object.prop === undefined

If you really need to know the difference, you need to use catch, because accessing undeclared variable directly will throw an exception.

function test(variableName) {
  try {
     var temp = eval(variableName);
    if (temp === undefined) {
       return "\"" + variableName + "\" is declared, its value is undefined"; 
    } else {
       return "\"" + variableName + "\" is declared, its value is not undefined"; 
    }
  } catch (e) {
      return "\"" + variableName + "\" is undeclared";
  }
}

matrix.js introduction

Essentially, matrix.js is like other script loader, but it does other things such extensible resource type, dependencies registration and reload, resource locations, resource release and others. In the following, I will explain what the library can do. All these example presented here can be found at GitHub

tweaking HTTP header to imporve performance

Lately, I am doing some client side optimization. One of the techniques is cache. When browser firstly request a resource and get the response, the cache subsystem of the browser need to determine whether to cache resource. It is based on the response header Cache-Control, and Expires. When neither of them exists in the response header, browsers use their own strategy to cache, these strategies vary from browser to browser, so they are not predictable, we should explicitly set these headers. To explicitly disable cache in browser, we can use the following

Pragma: no-cache 
or
Cache-Control: no-cache 
or
Cache-Control: no-store

The Pragma: no-cache header is included in HTTP 1.1 for backward compatibility with HTTP 1.0+. It is technically valid and defined only for HTTP requests; however, it is widely used as an extension header for both HTTP 1.0 and 1.1 requests and responses. HTTP 1.1 applications should use Cache-Control: no-cache, except when dealing with HTTP 1.0 applications, which understand only Pragma: no-cache. According RFC 2616, Cache-Control: no-cahce is semantically different from Cache-Control: no-store. non-cache still allows browser cache a response, and the cache needs to re-validate the response with the origin server before serving it. no-store request browser not to cache response at all. However most browser treat "no-cache" as "no-store".
To implement the semantics of "no-cache", we should use Cache-Control: max-age=0 or Cache-Control: s-maxage=0 or Cache-Control: must-revalidate.

To explicitly to cache resource, we should use the following.

Cache-Control: max-age=3600
Cache-Control: s-maxage=3600
//or
Expires: Fri, 05 Jul 2002, 05:00:00 GMT

The Cache-Control: max-age header indicates the number of seconds since it came from the server for which a document can be considered fresh. There is also an s-maxage header (note the absence of a hyphen in "maxage") that acts like max-age but applies only to shared (public) caches. The deprecated Expires header specifies an actual expiration date instead of a time in seconds. The HTTP designers later decided that, because many servers have unsynchronized or incorrect clocks, it would be better to represent expiration in elapsed seconds, rather than absolute time. An analogous freshness lifetime can be calculated by computing the number of seconds difference between the expires value and the date value.

If browser hit the same url again, browser will firstly ask the cache sub-system to get a cache copy. If the cache is still fresh based on "Cache-Control" or "Expires" header, the cache is returned, and no request is sent to server. If the cache expired, determined whether a validator was send from the previous response, different request will be sent. If a validator of previous response is "Last-Modified", the following will apply.

//validator of previous response
Last-Modified: Sun, 03 Apr 2011 14:34:43 GMT

A enhanced curry method

JavaScript is a functional language, it supports function composition, we can do curry with JavaScript. Douglas Crockford has defined "curry" method in his book JavaScript: The Good Parts to facilitate the steps to define curried function.

Function.prototype.method = function ( name, func ) {
 if ( !this.prototype[name] ) {
  this.prototype[name] = func;
 }
};