Does the Kernel Instantiation node check the type arguments.

[rakudrama]

Can the Kernel Instantiation node throw?

It would throw if type bounds are checked at instantiation, and potentially every generic method would need different instantiation code.

@leafpetersen said:

Yeah, good question, this has been nagging at me. The only situation in which there is an implied dynamic check on type arguments in a static invocation is when the bound of a type parameter itself involves a covariant type parameter from an outer class:

class A<T> {
  void foo<S extends T> (S x) {};
}

class B extends A<int> {
  void foo<S extends int> (S x) {x.isEven; }
}

A<Object> a = new B();
void Function(Object) foo = a.foo;  // Throws?
a.foo<Object>("hello"); // Throws
a.foo<Object>(3); // Still throws
foo("hello"); // Throws?

So the question is which of the two places should throw?

My assumption has been that implementations would put the check in the body of the method, and so the "convenient" place to throw is at the actual call site, not the instantiation site. This is what DDC does.

It's probably slightly nicer to the user to throw at the instantiation site, but this is a pretty corner case example.

Thoughts from the implementations? Things I'm missing? Lasse, Erik, thoughts?

[eernstg]

I think we need to specify this (it is not implied by anything that we have already specified).

First, generic function types have no subtyping relationships to each other if they have different bounds (so Function<X extends num>(X x) and Function<X extends int>(X x) are simply unrelated types rather than subtypes of each other, in any order).

This means that an expression like a.foo is similar to what I've called a "contravariant expression", but it's even worse: Covariance in the type argument to the value of a doesn't impose contravariance on the type of a.foo, it causes a.foo to have completely unrelated types for different values of that type argument (that is, "the actual value of T"). You could say that it is a "wildly variant expression".

Hence, a.foo should be typed as a plain Function --- nothing more specific than that can soundly be assumed about the type of this expression. We do know that it takes exactly one type argument, and given that type argument, call it T0, we know that it is a void Function<S extends T0>(S) or a subtype thereof, but we have no way to express that in a type when we don't know the associated bound.

So we should rejoice in the fact that this situation will not arise very frequently (especially if we make sure to tell developers how unpredictable its typing properties are, and constantly nudge them away from using a class type parameter as a generic function bound!). But when it does arise and it is used for things like generic instantiation, it is basically a dynamic operation (same thing is true for a plain invocation of the function).

The next issue is whether to fail during generic instantiation, or at call sites.

If a generic instantiation (based on inference, in particular the type-from-context) is considered to be an application of a curried function (1, done here: provide type arguments, 2, done later: provide value arguments) then it seems natural to me that the provision of actual type arguments should be subject to static verification or (if static analysis cannot prove that the chosen type arguments will conform to the given constraints) dynamic checking, and failure must happen as a compile-time error, resp. a dynamic error at the time where the generic instantiation expression is evaluated. When the bound is not known we are in the dynamic case, so it's a dynamic error, at generic instantiation.

If a generic instantiation is considered to be syntactic sugar for the creation of a wrapper function whose signature is obtained from the signature of the target function by replacing the formal type parameters by the chosen type arguments (so void foo<S extends T>(S x) is wrapped as "void foo_wrapper(S1 x) => foo<S1>(x)", where S1 is the actual type argument used for the instantiation) then you could argue that we're simply creating that wrapper as requested by the developer, and the possible failure of calling foo<S1>(x) in the body of foo_wrapper will arise every time the wrapper is executed. Of course, that wrapper would presumably be created by an extra, synthetic getter on the class of the value of a, taking the type argument list and returning a closure (because we need access to the actual value of T when we create that closure, and that's a bit inconvenient at the call site).

I don't have a strong preference for one or the other conceptual model, but the second approach (the non-curried one, where the actual type arguments are provided together with value arguments rather than as a separate invocation) does readily admit a natural semantics for invocations where the type arguments are omitted: We just treat formal type parameters like optional formal value parameters and provide a default value for them based on instantiate-to-bound.

If we take that route then I think we can be justified in delaying the error to the call site.

[sjindel-google]

Currently the VM is implementing the second approach.

[sjindel-google]

Why is an Instantiation node is being placed here instead of an implicit downcast?

I thought the Instantiation node would be used for cases of type inference where we are sure
that we are passing in correct type arguments.

The kernel currently being generated from this examples is:

  class A<T extends core::Object> extends core::Object {
    default constructor •() → void
      : super core::Object::•()
      ;
    method foo<generic-covariant-impl generic-covariant-interface S extends test::A::T>(test::A::foo::S x) → void {}
  }
  class B extends test::A<core::int> {
    default constructor •() → void
      : super test::A::•()
      ;
    method foo<generic-covariant-impl S extends core::int>(test::B::foo::S x) → void
      return x.{core::int::isEven};
  }
  static method main() → dynamic {
    test::A<core::Object> a = new test::B::•();
    (core::Object) → void foo = a.{test::A::foo}<core::Object>;
    a.{test::A::foo}<core::Object>("hello");
    a.{test::A::foo}<core::Object>(3);
    foo.call("hello");
  }

The front-end is inserting an instantiation node with Object as the type argument without any reason
as I can tell.

[stereotype441]

@sjindel-google The reason an instantiation node is being placed here rather than an implicit downcast ((core::Object) → void foo = a.{test::A::foo}<core::Object>) is because generic function types and non-generic function types are not related, and we don't insert implicit casts between unrelated types. Rather, when a generic function is torn off in a context where a non-generic function is expected, we insert an instantiation node to convert between the two unrelated types, and we infer the type parameter for the instantiation based on the context. Since the context in this case is (core::Object) -> void), and the tear-off's static type is <S>(S) -> void, instantiating with to <Object> is what's required to make the types match.