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

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

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.

refactor: Put return types as properties on implementations 95f6ccc5a0

feat(PocomathInstance): Add .returnTypeOf method 340dbd436e

feat(PocomathInstance): Add subtypesOf and isSubtypeOf methods dc6921e768

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

feat(PocomathInstance): Add bounded template parameters f7bb3697ed

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.

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

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).

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

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

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

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).

refactor: Convert resolution to two-tier system de42c22ab4

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.

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

feat: Add return types for all generic operations 3957ae8adf

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

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

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

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