Add support for variadic type parameters

[jtoman]

Variadic type parameters are already a member of the type grammar. However, there is no support for them yet in types.rb. Adding these would allow us to write the type of Proc for example

rtc_typesig("class Proc<^args,ret>")
class Proc
   rtc_annotated
   typesig("call: (^args) -> ret")
end

[sstrickl]

From issue #48:

While we can do Enumerators over a single type initially to get support rolling, I imagine that for Enumerators (and things like Tuples), in the long run we eventually want support for something akin to Variable-Arity Generic Interfaces.

There's also Practical Variable-Arity Polymorphism, which would be useful if there are any block-taking methods that work like Scheme's map. (That is, you take a block and an arbitrary number of collections, where the arity of the block is related to the number of collections and the type of each block argument is the same as the corresponding collection element type. The latter paper shows off such examples.)

[sstrickl]

The first paper also includes examples of interfaces similar to, but not the same as, the Proc suggested in the OP. In the paper, the return comes first, so that the rest of the method argument types can be collected in a rest arg. Given Ruby's very flexible semantics when it comes to where a rest arg can appear, maybe it'd be Ruby-like to support non-final rest args in types.

[jtoman]

One thing I just thought of is that we need to find a way to indicate variadic parameters that does not involve the typesig method (that is, as we no longer have the class annotations to use the "^" notation)

[sstrickl]

Hmm, yes. Well, we'd probably just want to have some way of tagging a type variable as passed to rtc_annotated as a rest arg. Since currently the types of arguments allowed are:

• Symbol - name of a non-inferable type variable
• Tuple < Symbol, Enumerator > - name and enumerator for an inferable type variable

We'd just need to add a non-conflicting branch to this. Maybe Tuple < Symbol, :rest >, or something like that. I've not thought about what kind of support we'd need for inferring them (if we can).