In Java, a name that appears in a context of a method is a MethodName term and has a name binding rule:

MethodName(n): 
	refers to Method n

The actual invocation of a method has a separate Invoke term with the following name binding rule:

Invoke(Method(m), a*):
	refers to best Method m 
		of conformant parameter-types pt*
	where a* has type pt*

In this rule m is a MethodName(n) term, where n is annotated with a definition lookup task generated by the first name binding rule. Since there is another refers to clause in the second rule, there will be 2 lookup tasks for the same name, which is not the desired behaviour. The desired behaviour is to filter the lookup task generated by the first rule with the information from the second rule.

There are several issues here:

• m is a MethodName(n), not a name. We can get to the name using a nabl-name rule though.
• Do we change the lookup task from the first name binding rule or do we create a new lookup task in the second rule that filters?
  • If we change the lookup task from the first rule, what would be the semantics if multiple rules try to change the lookup task from the first rule? Is that even possible?
  • If we create a new task, there will be 2 lookup tasks on the same name. Which one is the ‘right’ one? Which one do we use to do reference resolution for example?
• It is not very explicit that filtering is going on here. Maybe a separate keyword in NaBL could fix this, or maybe we’d like it to be implicit.

Submitted by Gabriël Konat on 19 August 2013 at 19:30

Are there different MethodName constructors with different arities?

Yes, here’s another one:

MethodName(q, n):
	refers to Method n 
		in Type q
	otherwise
		refers to Method n
			in Type t 
			where q has type t

This happens in a few places in Java.

I assume inlining works for methods:

Invoke(Method(MethodName(n)), a*):
  refers to best Method n 
    of conformant parameter-types pt*
  where a* has type pt*

Invoke(Method(MethodName(q, n)), a*):
  refers to best Method n 
    of conformant parameter-types pt*
    in Type q
  where a* has type pt*
  otherwise refers to Method n
    of conformant parameter-types pt*
    in Type t
  where a* has type pt*
  where q has type t

The second case might even be simplified, when a type reference is of its own type:

Invoke(Method(MethodName(q, n)), a*):
  refers to Method n
    of conformant parameter-types pt*
    in Type t
  where a* has type pt*
  where q has type t

But I am not sure if inlining also works for other Java cases or if we need indeed a disambiguation clause.

It’s possible to inline everything but that would lead to an explosion of name binding rules. There’s 5 types of Invoke’s and some of them include type names, ambiguous names and type parameters as well. So in practice you cannot manually inline them.

Ah, right, I remember this issue. This leads us to rules which describe the resolution, the rules for AmbName, TypeName, MethodName, and other rules which describe the disambiguation, the rules for Invoke etc.

Proof of concept implemented in https://github.com/metaborg/runtime-libraries/tree/filtering-use. It adds another Use annotation to the inner name that filters using properties. Reference resolution uses the first Use annotation it can find, so if the filtering results in no resolved definitions, it won’t resolve.