Template type implementation #49

New Issue

glen · 2022-08-07T03:50:34Z

glen commented

2022-08-07 03:50:34 +00:00

Currently Pocomath implements the base (say Tuple) of a template type (like Tuple<T>) as its own separate type (which is intended not to really be much used, it's just there for type deduction, although one can allow functions that can operate generically on Tuples without needing any information about the element types, like length, to take arguments of type Tuple).

In retrospect, it seems to me this added an unecessary wrinkle, and that things would be more straightforward (and some code would be saved) if templates were strictly templates, with no "base" type. Then if the infrastructure needs a place to hang "backstop" implementations that catch uninstantiated templates (for example if it remains built on top of typed-function, rather than integrated into it), it can simply instantiate e.g., Tuple<any> for that purpose.

Currently Pocomath implements the base (say `Tuple`) of a template type (like `Tuple<T>`) as its own separate type (which is intended not to really be much used, it's just there for type deduction, although one can allow functions that can operate generically on Tuples without needing any information about the element types, like `length`, to take arguments of type `Tuple`). In retrospect, it seems to me this added an unecessary wrinkle, and that things would be more straightforward (and some code would be saved) if templates were strictly templates, with no "base" type. Then if the infrastructure needs a place to hang "backstop" implementations that catch uninstantiated templates (for example if it remains built on top of typed-function, rather than integrated into it), it can simply instantiate e.g., `Tuple<any>` for that purpose.

glen added the

Design

label 2022-08-07 03:50:41 +00:00

glen changed title from ~~Design Note: template type implementation~~ to Template type implementation

2022-08-07 03:51:02 +00:00

glen commented

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

PR #53 switched to the suggested system internally, using a second typed universe of "catchall" implementations, rather than instantiations like Typed<any>.

PR #53 switched to the suggested system internally, using a second typed universe of "catchall" implementations, rather than instantiations like `Typed<any>`.

glen closed this issue

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

Sign in to join this conversation.