SRE GetMember - vilinski/nemerle GitHub Wiki

There is quite severe problem when generating code for a language with type inference using System.Reflection.Emit API.

For example consider:

def dict = Dictionary ();
def count = dict.Count;
dict.Add ("foo", 42);

This piece of Nemerle code creates a generic dictionary, reads number of elements in it and finally add some entry. The same code in C# looks like this:

Dictionary<string,int> dict = new Dictionary<string,int> ();
int count = dict.Count;
dict.Add ("foo", 42);

The key difference is that you need to specify type parameters to Dictionary constructor. Therefore the type of dict local variable is immediately known to the compiler.

Nemerle compiler infers this type (this is exactly the same type, therefore the C# example can be considered redundant to some extent here). However the type can be inferred only after the call to Add. Therefore it works on generic, uninstantiated type Dictionary<K,V>. It then looks up the Count and Add members in it and handles references to generic K and V parameters itself.

The problems shows up when we want to generate IL for this code using S.R.E. We already know the values of K and V parameters of Dictionary so we can create the instantiated type. However next we need to lookup members Count (or exactly get_Count) and Add again, because the members from uninstantiated type cannot be reused. Because member lookup is a very involved process we just try to lookup the same member in instantiated type using signature comparison. This is not very easy as string needs to be substituted for K, and int for V. There are also several more complications with member lookup and equality testing in TypeBuilders.

Note how this problem doesn't occur in C# code -- the compiler can use instantiated type for the member lookup in the first place.

TypeBuilder supports special methods that can be used to retrieve corresponding members from instantiated types, but the methods do not work on RuntimeTypes.

We would therefore propose to either make these methods work on all types, not only on TypeBuilders or add some special GetMember(MemberInfo) overload to System.Type with the same function.

This feature doesn't seem hard to implement in the runtime, but it makes compiler writer work much easier.

This problems is probably going to affect any language with only a very little more type inference than in C#.

http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?FeedbackId=e61d8182-3585-4b27-bb7e-7b5d47d03c1e http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=7f85f92e-4154-4cb2-8f53-8be324bd6e11