[Task]: Cleanup the semtype generic function implementation #42700
Labels
Area/SemtypePort
Issues related to porting of semantic subtyping
Team/CompilerFE
All issues related to Language implementation and Compiler, this exclude run times.
Type/Task
Description
With #42512 we are using the nBallerian's function type implementation in jBallerina. However nBallrina's implementation doesn't take
@typeParam
annotation in to consideration. Therefore in #42622 we are using a hack to make generic's work where we are keeping track of which function semtypes were created by generics and special casing their type checks infunctionPathIsEmpty
. While this is sufficient to get the internal libraries to work (this is the only place where@typeParam
annotation is allowed) this hack is not correct and we can do a better implementation.Describe your task(s)
To properly type check generics we need to "resolve" the generic at call site. For example assume we have
At call site (1) we know the actual type of
val
isint
(that isF
isint
). Then within the context of that call site we can do normal type checking by replacingF
withint
. This means we don't need to do special cases for the generics in order to support generic functionfoo
here. We'll call this process of replacing generic parameters with specific types at call site "generic resolution". In most cases in the internal library we can resolve the generic purely using the argument types at compile time. When this is not possible (for example in the case ofpublic isolated function 'map(Type[] arr, @isolatedParam function(Type val) returns Type1 func) returns Type1[] = external;
function) we can use the static type variable to which we assign the return value to resolve the other generics (Note this prevents usingvar
for this return value). Combination of these two should be sufficient to determine all the generics define in the internal libraries under the ballerina spec.However we have cases which are not covered under the spec such as
helpers.bal
. These include generic functions that call other generics functions (examplecreateArray
is being called by other generic functions such astoArray
and it call other generic functions such asnext
). Here we can't directly resolve generic type at the call site as I have describe above. Instead I think we need to do something akin to monomorphization at least from a type checking perspective. Each of these nested generic function calls must start at a point where we know the actual parameter type and return type, lets cal this a "resolvable call site". At the resolvable call site we can resolve the generic call. We can also resolve all internal variables of the generic function for that call site. Thus any generic calls inside that function also becomes "resolvable" thus allowing us to recursively apply this logic.Related area
-> Compilation
Related issue(s) (optional)
Depends on #42512
Suggested label(s) (optional)
No response
Suggested assignee(s) (optional)
No response
The text was updated successfully, but these errors were encountered: