We have three special cases of parameterized types in Fan:

• List: parameterized value
• Map: parameterized key and value
• Method: parameterized call signature

This is what I'm thinking for how parameterized types are exposed via reflection:

Type t = acme::Foo[].type
t.pod.name  -> "sys"
t.name      -> "List"
t.qname     -> "sys::List"
t.signature -> "acme::Foo[]"
t.toStr     -> "acme::Foo[]"
t.method("slice").returnType -> acme::Foo

Type t = |Str a -> Int|.type
t.pod.name  -> "sys"
t.name      -> "Method"
t.qname     -> "sys::Method"
t.signature -> "|Str a -> Int|"
t.toStr     -> "|Str a -> Int|"
t.method("call").returnType -> sys::Int
t.method ("call1").params[0].paramType -> sys::Str

The big thing to notice is that pod/name/qname represents sys::List, sys::Map, or sys::Method directly. The parameterization is somewhat "hidden" in the signature() method. The signature() method returns the type as it would appear in Fan source code. Plus reflecting the methods show the parameterization too. Method.call(List) is a bit weird and probably can't be parameterized, but parametering call0, call1, etc would work just like List - so I'm thinking that should be good enough since that will be the common case.

Parameterized types will manifest themselves in the pod format too. I'm thinking that everywhere qname is used now, will be replaced by a special structure which specifies the parameterization. I'll post that when I figure it all out.