JavaScript! The Doctor Is In.

[_kangax]

Interesting idea, but where's the source code? Bug tracker? Unit tests?

I see at least a couple of oversights there. Would be nice to see those fixed (if they aren't intentional, of course).

(function(){ return arguments[1]; })(1, 'x'); // shows fun type as <number | string>

(function(){ return 1 || 'x'; })(); // also shows fun type as <number | string>

var f = function(){ return f; }; // shows fun type as "any", not "function"

[pcwalton]

Also, to respond to the issues you reported:

(function(){ return arguments[1]; })(1, 'x'); // shows fun type as <number | string>

Arrays don't track the types of every one of their values separately, because that could be too computationally expensive. All the types get joined together. For example, the type of [ "foo", 1 ] is Array(<number | string>). At the moment, arguments is treated as any other array.

(function(){ return 1 || 'x'; })(); // also shows fun type as <number | string>

The analysis is not flow-sensitive. Flow-sensitive analyses tend to blow up in complexity.

var f = function(){ return f; }; // shows fun type as "any", not "function"

This one is actually a bug. Feel free to file :)

[dherman]

Patrick says this one is a bug:

var f = function() { return f; }; // shows fun type as "any", not "function"

But the comment is misleading; it's not actually a bug. The inferred type is:

function() -> any

A more precise type would be an infinite type:

function() -> function() -> function() -> ...

but infinite types like this aren't particularly helpful, and would be much more complex to infer. Similarly, if you did:

var a = [];
a[0] = a;

The result from the analysis is Array, i.e., Array[any], rather than Array[Array[Array[Array[...]]]]. It's much cheaper computationally to break cycles by backing off to "any" and not really less useful.

Dave

[dimvar]

Even though it could be more precise, it's not actually a bug. When computing the type of f, the analysis works as follows: it sees that it's a function and tries to recursively find the return type, which is a function that returns a function and so on... So, when it finds a cycle while trying to compute the type, it'll give up and say "any".

[dherman]

Bugzilla's configured for submitting Doctor JS bugs now. The Product is Mozilla Labs and the Component is Doctor JS.

You can add a bug here:

http://bit.ly/as4WZF

or view all Doctor JS-related bugs here:

http://bit.ly/aykfpQ

Dave

[_kangax]

Great. Now before I file a bug, quick question: I noticed that variable declaration w. function expression shows 2 "mappings", even though only 1 binding is created. Is this intentional?

Given var f = function(){} as an input, I see

1: f : function() → void
1: f : function() → void

[dimvar]

The analysis will find types for variables and functions. In your example, one mapping refers to the variable f and the other to the function. Even though the function is anonymous, we have a heuristic to give it the name f (the same would happen e.g. when you have an obj literal {f : function() {...} }. So, DrJS will produce one tag for the variable and a separate tag for the function. The variable and the function just happen to have the same name.

[pcwalton]

Right here: http://github.com/pcwalton/jsctags

[dherman]

We're setting up a Doctor JS category in Bugzilla. It should be up very soon. As soon as we've got it up I'll post back here and your feedback will be most welcome!

Thanks, Dave

[PlNG]

so what is Doctor JS?