Declare implementations and dependencies via standard interfaces for operations #8

glen · 2023-01-22T01:34:21Z

glen commented

2023-01-22 01:34:21 +00:00

Adds a new subdirectory interfaces where standard interfaces
are defined. Additional interfaces for a given operation can
be added with an AliasOf type operator. Provides type
operators that give the return type, full function type, and
the type of a dependency on, a given operator.

Resolves #6.

Adds a new subdirectory `interfaces` where standard interfaces are defined. Additional interfaces for a given operation can be added with an `AliasOf` type operator. Provides type operators that give the return type, full function type, and the type of a dependency on, a given operator. Resolves #6.

glen added 20 commits 2023-01-22 01:34:22 +00:00

refactor: entirely new scheme for specifying return types 1eb73be2fa

refactor: Convenience type operator for specifying concrete signatures d55776655f

feat: Implement complex arithmetic through sqrt fbec410c42

Together with any auxiliary functions needed for that goal. Also
  strives to ensure the same functions are being defined for
  number and for `Complex<T>`.

feat: Add generic operation square and numeric unequal (#4 ) 8c06c8f36e

Co-authored-by: Jos de Jong <wjosdejong@gmail.com>
Co-authored-by: Glen Whitney <glen@studioinfinity.org>
Reviewed-on: #4

experiment: convert all implementations to plain types cbd1719227

fix a TS issue 04024a2a8d

convert code to type aliases 60ce6212b4

fix and test absquare for quaternion a5848125e4

refactor: tighter universal interface types 74e2aef524

refactor: Streamline publishing operations 072b2a1f79

Avoids clumsy naming properties by making the names the keys in
  an interface to which the signatures of all operations must be
  published. This also reduces the number of different symbols and
  avoids long lists of imports in the modules implementing multiple
  operations, which were redundant with the list of functions
  exported from such modules.

refactor: Streamline types and signature specfications 6d63d23498

The main mechanism for simplification was simply to assume that
  ZeroType<T> and OneType<T> will always be in T. That removed a lot
  of specialized typing, and presumably will be true in practice.

  Otherwise, removes extraneous type definitions and adds/clarifies
  a number of comments to hopefully make the scheme as clear as possible.

docs: describe how to run the prototype 63c2d448c1

chore: rename OpType to Signature a0b21181e6

chore: use direct function definitions instead of { params, returns } 1b9d6b6428

chore: implement AliasOf d147d0a576

chore: show how to inject multiple instances of the same function (WIP) 0ea786dcc2

chore: rephrase two todo's e468ec72dd

chore: make SignatureKey generic instead of using unknown bd05dc9267

refactor: clarify implementation names in sqrt 637e339b17