||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.
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.
- Let's assume a language with optional type declarations. Inferring the type of an expression in a method requires a non-local analysis, because in general one will also have to infer the types of parameters, and so on.
- So, to get type information, we need to run a type inference engine of some kind. To promote reuse, the inference engine should not be built into any one of the tools that might want to use it, but should be a separate software component, accessible from any tool.
- To further promote reuse, the client of the inference engine ought to be able to use it without knowing anything about it. The client will of course know about the syntactic structure of the language — it will know about expressions and parameters, etc. Using the inferencer ought to be as simple as asking an expression object for its type. If some analysis needs to be run to fill some tables and some data needs to be synthesized, this should all happen behind the scenes.
- Performance is critical for the e-completion tool. The raison d'être of such a tool is to save the programmer time, so it certainly won't help if the programmer has to wait for it to respond. In general, this may necessitate pre-computing and caching the type information for the pieces of the program that are being edited.
This sample challenge problem was written by AndrewBlack
I'd like to propose some additional requirements, or constraints for this functionality:
Kirill Osenkov (http://www.osenkov.com)
- 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.
- The ubiquitous Compiler Front-End service should provide clear means of transforming any text fragment into an AST.
- 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).
- The API surface could look something like this: "IResolvedType TypeInference.inferType(AstExpressionNode node, bool needsResolvingBeforeInference)"
||Last edited June 16, 2007
Return to WelcomeVisitors