Provides the infrastructure to allow annotating the return types of functions, and does so for essentially every operation in the system (the only known exceptions being add, multiply, etc., on arbitrarily many arguments).
One main infrastructure enhancements are bounded template types, e.g. `T:number` being a template parameter where T can take on the type `number` or any subtype thereof.
A main internal enhancement is that base template types are no longer added to the typed universe; rather, there is a secondary, "meta" typed universe where they live. The primary point/purpose of this change is then the necessary search order for implementations can be much better modeled by typed-function's search order, using the `onMismatch` facility to redirect the search from fully instantiated implementations to the generic catchall implementations for each template (these catchalls live in the meta universe).
Numerous other small improvements and bugfixes were encountered along the way.
Co-authored-by: Glen Whitney <glen@studioinfinity.org>
Reviewed-on: #53
This means that the real and imaginary parts of a Complex must now be
the same type. This seems like a real benefit: a Complex with a number real
part and a bigint imaginary part does not seem sensible.
Note that this is now straining typed-function in (at least) the following
ways:
(1) In this change, it was necessary to remove the logic that the square root
of a negative number calls complex square root, which then calls back
to the number square root in its algorithm. (This was creating a circular
reference in the typed-function which the old implementation of Complex
was somehow sidestepping.)
(2) typed-function could not follow conversions that would be allowed by
uninstantiated templates (e.g. number => Complex<number> if the latter
template has not been instantiated) and so the facility for
instantiating a template was surfaced (and for example is called explicitly
in the demo loader `extendToComplex`. Similarly, this necessitated
making the unary signature of the `complex` conversion function explicit,
rather than just via implicit conversion to Complex.
(3) I find the order of implementations is mattering more in typed-function
definitions, implying that typed-function's sorting algorithm is having
trouble distinguishing alternatives.
But otherwise, the conversion went quite smoothly and I think is a good demo
of the power of this approach. And I expect that it will work even more
smoothly if some of the underlying facilities (subtypes, template types) are
integrated into typed-function.
This should eventually be moved into typed-function itself, but for
now it can be implemented on top of the existing typed-function.
Uses subtypes to define (and error-check) gcd and lcm, which are only
defined for integer arguments.
Resolves#36.
Glen Whitney