Hygienic typedefs

ECMAScript Edition 4 will have ML/C-style typedefs to allow the creation of type synonyms. You can think of these like macros in that, intuitively, references to such types are substituted by their definitions. This is simpler than a general macro system, because they are only substituting types in type contexts, not expressions in expression contexts. But even though types are a simpler subset of the syntactic structure of ES4 programs, due to generics, they still have binding structure!

Consider this example:

class C.<T> {
   type A = T
   function f.<T>() {
       var x : A = ...
   }
}

If we want to substitute away the type definition, we might naively get:

class C.<T> {
   function f.<T>() {
       var x : T = ...
   }
}

But then x's type annotation is referring to the wrong T! This corresponds exactly to the notion from hygienic macros (commonly referred to as referential transparency) that references in a macro definition should retain their meaning from the macro definition environment, never the macro use environment.

In other words, the above program should really be resolved to:

class C.<T> {
   function f.<T'>() {
       var x : T = ...
   }
}

Now consider another example, this time with a parameterized typedef:

type A.<X> = function.<T>():[X,T]
class C.<T> {
   var a : A.<T> = ...
}

A naive substitution would produce

class C.<T> {
   var a : function.<T>():[T,T] = ...
}

This time the bug is that we've allowed a type definition to introduce a binding that captured a binding in the context of the use of the typedef. This is an example of the hygiene condition, which states that bindings introduced by a macro should not capture variables in the macro application site. The proper expansion of the typedef would instead be:

class C.<T> {
   var a : function.<T'>():[T,T'] = ...
}

These are exactly the same conditions that hygienic macro expanders must meet in order to prevent unintended variable capture; the only difference is that here we're concerned with type variables rather than program variables.