feat: Return type annotations #53

glen · 2022-08-30T19:36:20Z

glen commented

2022-08-30 19:36:20 +00:00

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.

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.

glen added 15 commits 2022-08-30 19:36:21 +00:00

4b28f8eac0 refactor: Add a stub for supplying return type information

With this commit, there's a rudimentary function that attaches return-type
  information, so it can be supplied, and PocomathInstance then proceeds
  to check for it everywhere necessary (and supply it in all the internal
  operations it builds). But so far in all of those place where it's checked
  for, it's just ignored.

  I think the next step will be just to put the return type info as a property
  on the function itself. That should actually ease all of the code.

95f6ccc5a0 refactor: Put return types as properties on implementations

340dbd436e feat(PocomathInstance): Add .returnTypeOf method

dc6921e768 feat(PocomathInstance): Add subtypesOf and isSubtypeOf methods

Note this involves refeactoring the internal subtype tracker to keep
  subtypes in a list sorted in topological order.

f7bb3697ed feat(PocomathInstance): Add bounded template parameters

This feature helps specify the return type of implementations where
  the return type depends on the exact subtype that the implementation
  was called with, such as negate.

775bb9ddb7 feat(returnTypeOf): Support template and upper bound types

Also changed the notation for an upper bound template to the more
  readable 'T:number' (instead of 'T (= number', which was supposed to
  look like the non-strict subset relation).

0950d7d585 feat(PocomathInstance): Specify return types of all core methods

bc434c7163 feat(bigint): Specify return types for all methods

a2f76a55b8 feat(return types): Add more return types for complex functions

These changes greatly increased the need for precision in generating
  implementations for signatures of operations whenever possible. So this
  commit also includes a refactor that basically caches all of the
  conversions of Pocomath implementations to typed-function implementatios so
  that they are more often externally available (i.e., not disrupted so much
  after invalidation).

de42c22ab4 refactor: Convert resolution to two-tier system

Typed-function's sort order/matching algorithm was interfering with
  template resolution. This commit solves the difficulty by moving the
  "catchall" implementations that implement generation of new template
  instances into a separate "fallback" typed-function universe, so that
  Pocomath can control exactly when that is searched.

  Removes a couple of the matching anomalies already noted in the tests.

  Also extends return types to somewhat more functions.

23b3ef4fdd feat(Complex): Define return types of all operations

3957ae8adf feat: Add return types for all generic operations

1ee6da4294 feat(number): Provide return types for all operations

be9794fd4c feat(ops): Provide return types in all of the operation-centric examples

d83f2a7f23 feat: Instantiate instances of template instantiation need for self-reference

Formerly, when a self-reference like `self(Tuple<number>)` was encountered,
  but the `Tuple<number>` instance of a `Tuple<T>` implementation for this
  operation had not yet been instantiated, the reference would be fulfilled
  with a call to the catchall implementation for `Tuple`. Now the
  necessary instance is instantiated on the spot and referred to instead.

  This change is used to complete return-type specification for all of the
  Tuple functions.

glen merged commit 31add66f4c into main

2022-08-30 19:36:44 +00:00

glen referenced this issue from a commit

2022-08-30 19:36:44 +00:00

feat: Return type annotations (#53)

glen referenced this pull request

2022-08-30 19:37:19 +00:00

Return type annotations #52

glen referenced this pull request

2022-08-30 19:37:49 +00:00

Unexpected negative interaction between subtypes and templates #51

glen referenced this pull request