Examples of Generic Overloadings (Work in Progress)
The Fortress language specification does not allow overloaded functional declarations with different number of static parameters. We are working on relaxing this overloading restriction and here we collect possibly valid and useful generic overloading examples.
PureList.fss by Jan
This is an implementation of finger trees that enforces the constant-depth-leaf invariant. It defines a family of types D0-D4 and a series of supertypes for ranges of sizes D01, D02, D03, D04, D12, D13, ... with the obvious containment. A lot of functions work on types parameterized by D23[\T\] and the like.
It's not 100% clear that all the overloadings you find there will necessarily be accepted by a randomly-chosen new overloading story (though I argued their correctness to myself and have had no trouble from the interpreter). Also, I can argue coverage that lets me call them at higher-up static types. For example deepL can be said to work for the following signature:
Under certain circumstances it's important that we obtain more-specific return type information than this for typechecking to succeed, however (eg in this case we want to know that we've got a NonEmptyFingerTree as a result in many cases).
Array constructing functions by Jan
I found the code from FortressLibrary where I would dearly love to overload at multiple type parameters (I suddenly realized I should have just searched for typecase):
What I really wanted was:
Note this also gives better type information when T is known to extend Number statically, and is dramatically easier to read and understand. We could just add a bogus type parameter:
In the absence of type inference (which can propagate information from the return type back to the call site) the programmer currently *must* provide type information at every single call site of this function. It is my judgement that asking our programmers to provide an *extra* bogus type parameters every time they create an array would be pushing them too far.
You can see exactly the same hack in array2 (only with matrices rather than vectors).
With coercion, I wouldn't necessarily want to have Vector as a subtype of Array1 anymore, but I'm sure this isn't the only case like this one.
More to come...
