Type Inference Engine Reuse

The challenge is to build a type inference engine in such a way that tool builders can easily use it for disparate purposes, for example, in an e-completion widget and in a refactoring that replaces untyped collections with typed collections.

More Details

So, the challenge problem is how to organize all of this: how to divide the necessary softwaer into components that have clean, easy to undersatnd interfaces, so that it performs well, and so that a third client can easily use the inference engine.

This sample challenge problem was written by AndrewBlack

I'd like to propose some additional requirements, or constraints for this functionality:

  1. The input of the type inference shouldn't be in text form, it should be a pre-parsed AST (maybe with unresolved references?). Or maybe the references should be resolved.
  2. The ubiquitous Compiler Front-End service should provide clear means of transforming any text fragment into an AST.
  3. Again, it is very important, that the type inference engine doesn't know anything about TextCoordinates (line and column numbers). There are tools (which directly operate on the AST), which don't have the text coordinates available (for example, if the AST was reconstructed from the binary using a decompiler or a reflector).
  4. The API surface could look something like this: "IResolvedType TypeInference.inferType(AstExpressionNode node, bool needsResolvingBeforeInference)"

Kirill Osenkov (http://www.osenkov.com)


Last edited June 16, 2007
Return to WelcomeVisitors