Lambda the Ultimate

How do you plan on handling disambiguation? By having the user select from a pop-up menu whether n is say a string or a number, or based on which operation the user selects to perform on n?

I would recommend the latter: in the intellisense popup, show the operations that can be performed on all of n's possible types (maybe in bold) as well as those that can be performed on at least one of n's possible types (maybe in gray). If the user selects an operation or method that works with all of n's possible types, great. If the user selects an operation that only works with some possible types, then you've narrowed down n's possible type. You might look into union types and type inference for more ideas.

Now, the case you mentioned could actually occur either because the IDE doesn't know enough about the program, or because the program actually has a lurking type error that may be manifested at run time. Are you also planning on providing indicators for possible bugs?

If you have a visual debugger that lets you edit code while the program is at a breakpoint, then you'll have runtime type information available. Of course the danger would be that the user will enter code that won't work next time around because the type will be different.

I like Sameer's idea of color-coding operations that are common to all possible types.

I guess another option could be to let the user stick in some kind of type assertion at the top of some block of code (e.g. assertType(obj, MyWidgetType)) to clue intellisense in to what type you expect.

Off the top of my head, I would suggest looking for either intersection types or abstract interpretation (both were discussed on LtU several times).

With intersection types you would not bother to know which branch of the if statement is executed, you just assume both are possible, so n has type MT ∩ NT (MT intersected with NT - inhabited by all values that are both MT and NT - where MT and NT are types of M and N).

With abstract interpretation you try to "execute abstractly", informally meaning you only resolve enough information to give you the answer you want (e.g., you are not interested in values of M or N, but you want yes/no differentiation for x).

Hope that helps.

You will probably want to read upp on success typings for ideas on how to implement this.

Whether explicit or implied. In you code sample shown above, you can only call the intersection of method names or you'll throw a runtime error. Even if you're returning n to the calling function, the same issue is applicable.

In practice, it seems like most auto-complete for dynamic languages uses reflection to interrogate objects and then ends up guessing.

While looking for something else, I stumbled upon "Towards Type Inference for JavaScript" by Christopher Anderson, Paola Giannini, and Sophia Drossopoulou: Citeseer link, which attempts to analyze (a subset of a simplified form of) Javascript with the goal of type-checking flexible objects. There is also Peter Thiemann's "Towards a Type System for Analyzing JavaScript Programs", which I haven't read although it sounds interesting (Springerlink abstract).

The former paper also has some interesting references in its bibliography which might be worth investigating.

Applying the methodology to Lua should be straightforward, but I suspect that the absence of Lua syntax for declaring prototype relationships would make the task rather more difficult. (In Lua, a prototype relationship is established by associating a table of metamethods with a simple table; one of the metamethods extends member lookup either by deferring lookup to a prototype table or by providing a function to implement member lookup.) There are standard Lua patterns for creating such "types", though, so it might be possible to use some simple source annotation to ease the job of source analysis; this would certainly be good enough for "intellisense".

Both Lua and Javascript allow access to undefined table keys. (Lua simply returns nil while Javascript returns the undefined value.) In Lua, as mentioned above, access of an undefined key may trigger an arbitrary Lua program which could produce a run-time error; however, Lua style is to return nil for undefined keys.

In effect, this means that every Lua table is (semantically) a complete mapping of all Lua objects into the set of Lua objects -- in other words, not much different from a function. This is what gives Lua its unique flavour; it is both extremely flexible, and extremely resistent to analysis. (Undoubtedly LtU readers will differ in their opinions of whether this is a Good Thing; I'm not going to comment here on that question. I'm simply trying to present the semantics.)

There have been some attempts to provide tab-completion (as we used to call "intellisense") in the context of a Lua interpreter, through run-time enumeration of table members. While this can be implemented adequately, it is not perfect; unlike Javascript, there is no defined mechanism for enumerating all the keys which a table might map to a non-nil value (and, indeed, there is no a priori reason to believe that a mapping to nil is not meaningful in the context of a particular program). Furthermore, it's possible that triggering a table's lookup metamethod might alter the state of the table object.

Doing this analysis statically in the context of an IDE does not necessarily suffer from the above problems. It does not need to be 100% accurate to be useful, particularly if there were some mechanism (source code annotations or retained programmer-provided "hints") to correct deficiencies.

I just tried Lua once some years ago ... so I'm not sure about that. But I assume it has some kind of eval statement.
As python has.
x = "5 * 3"
y = eval(x) #=> 15

And it seems pretty impossible to tell the type of an eval statement that evaluate a string that is built at runtime.

Well anyway, even if in some cases you cannot tell the type of a variable for sure, you're doing something very useful.
This is one the thing that python miss IMHO.