Allow dependently-typed function to be implemented in Ballerina

[jclark]

The dependently-typed function feature (#426 and #386) currently has the major restriction that the definition can only be external and cannot be defined by a function body written in Ballerina. The reason for this restriction is that the kind of information that our type system provides is that the result of an expressions will belong to a type that is known at compile-time.

A first step would be to allow functions that produce a dependently typed value using a langlib function such as cloneWithType or ensureType.

[jclark]

@hasithaa Please describe what functionality is needed by existing library functions.

[jclark]

Actually, I think there is a simple solution to this.

We have in the past discussed a potential feature that allows a reference to a variable of type typedesc in places where a type descriptor is expected. For example, if t is a parameter of type typedesc, I ought to be able to say if v is t { }. Now if we extend this to type casts, I should be able to say <t>v. But this is exactly what we need to be able to write the body of a dependently-typed function: I construct the return value ret however I want and then do return <t>ret; to return it and check at runtime that it belongs to the right type.

[sanjiva]

Perfect .. if its that simple and it can be implemented then can we put it in Swan Lake? Implementation can come a bit later but good if the design can go in IMO.

[jclark]

It gets more complicated in cases like this:

function query(string q, typedesc<record{}> r = <>) returns stream<r, sql:Error> {
}

The general concept is that within the function body, you can refer to the r as type descriptor; the job of the type checker then is to treat r as a variable ranging over types and check that for every value of r that is a subtype of record {}, the function body would type check according to normal rules.

This would be quite hard to implement, but I think we can define an easily implementable subset of this that is sufficient for a useful subset of the cases we need to support. This would certainly be a big improvement over what we have now. But it needs serious thought and design.

[sanjiva]

@hasithaa any thoughts on implementability? I would love to see this done, even for a subset of simple(r) cases.

[jclark]

This is related to #252