id,summary,reporter,owner,description,type,status,priority,component,version,resolution,keywords,cc 139,Unification with less cloning,a3moss,,"I have selectively re-introduced deeper clones in the new AST port to handle mutation of forall-parameterized types in a way that keeps the `TypeInstType` instances pointing to the correct `TypeDecl`. This was done as an attempt to get the new AST working without making deeper changes to the compiler architecture, but Thierry's profiling results suggest these deeper clones are actually a performance hot spot. The core reason for these clones is to support distinct type variables //per function call instance//. Consider the following: {{{ forall(otype T) T * foo( T ); foo( foo( 42 ) ); }}} The inner `foo` has `T => int`, the outer foo has `T => int *` -- since this is legal Cforall, both `T` variables need to exist within the same type environment and be able to be disambiguated. The current solution is to clone the type of `foo` and rename the type variables, which is effective, but has undesirable memory-management implications. An alternate approach which avoids this cloning would be to give each `ApplicationExpr` a unique identifier (the pointer may work, but would introduce memory-management complications), and store type variables in an environment or unification calculation as the pair `(, )`. This change should be investigated if cloning types continues to be a performance bottleneck.",task,new,minor,cfa-cc,1.0,,,