Search code examples
compiler-constructionmoduleprogramming-languagesstatic-typing

Resolving the types of functions in external modules


Suppose we have an imaginary statically typed programming language - let's call it SL. Each SL file corresponds to a module - SL's logical grouping of related functions into namespaces.

Calls to functions in the current module are easily checked: A compiler pass discovers all declared functions and stores their signatures. We can later verify any such calls by comparing the argument types to the types of the formal arguments in the signature.

However, handling calls to functions in other modules seems a bit more involved. In particular, assuming the compiler can locate the source/object code corresponding to the name of an imported module, how does it extract the type information? Does it:

  • Scan and parse the imported module's source code until it finds the function declaration?
  • Read some kind of metadata from the object file?
  • Encode the function return type and parameter types in the symbol name and read the symbol table during compile time?
  • Find metadata elsewhere?

I'm curious as to what approach compilers for modern languages like Haskell, D and Go take.


Edit: I'm aware that C and C++ solve this problem using header files. I am not interested that approach. Ideally, I'm looking for a solution that doesn't involve any parsing at all.


Solution

  • First, please note that this kind of type resolution is a property of the compiler, not the language as such. Different implementations of C/C++ actually provide different features along these lines -- e.g., Microsoft's "precompiled headers" option.

    Haskell's GHC compiler handles this by generating interface files (with ".hi" suffixes) that contain the necessary type information. I suppose this qualifies as "find the metadata elsewhere".