Language Pitfalls

From dis-Emi-A

Automatic types unlimited scenarios

Note: See the [Language Limitations] page for a description on why this pitfall doesn't exist in the exact form shown below.

In the theoretical evaluation of up-typing it is quite easy to arrive in a situation where the number of possible scenarios grows quickly, to a point where a brute force compiler could not properly compile the code. As a quick example, given the basic numeric types Integer, Float, and Complex and this function:

explode :> ( a, b, c -> ra, rb, rc )
{
 ra = a + 1;
 rb = b + 1;
 rc = c + 1;
}

The number of scenarios is 27. This is due to each parameter being unrelated to the other parameters, thus each can assume any of the numeric types regardless of the type of the others.

As the number of unrelated parameters or variables grows, the number of scenarios exponentially increases.

This even causes a problem if indeed the parameters are related, for in a dumb compiler (like the one I'm building first), all scenarios up to the current processing line are maintained, so even if they are all related, if that happens too late in the function the compiler still won't be able to handle it.

Compilers will have to be aware of this eventuality and find a way to deal with it. In general one could order the constraints being applied such that the most relating constraints are done first to avoid ballooning scenarios. Additionally a compile would probably need to maintain a scenario graph, such that disjoing context subsets are typing indepently, in which case the above has 27 theoretical scenarios, but the compiler manages this as 3 disjoint sets of 3 scenarios.

Automatic types ambiguous signature

In certain cases, functions will appear that have differing scenarios though the signature is exactly the same. (This extends logically to type definitions where all access to the type is equivalent.)

For example, given this code:

ambig :> ( a, b -> c )
{
  d = 2 + 3;
  c = a + b;
}

There are multiple scenarios involving "d" where the signature does not change (thus top-down typing cannot select a scenario). This example is rather contrived though as the first statement has no influence on the code -- we need a good example where this is not the case... we could argue that unless there is such an example that uninfluential code is simply removed from the function and then the scenario set collapses?