Planned minimal path to operable Dispatcher #20

New Issue

glen · 2023-10-26T19:10:28Z

glen commented

2023-10-26 19:10:28 +00:00

Adopt a data structure for a signature of an operation (keep it close to what the current type parser returns)
Write a sort function for such signatures compatible with the order we want to try them against arguments
Associate to each operation name an array of [signature, "fulfilled implementations"] pairs in sort order, where a "fulfilled implementation" is the result of calling the supplied implementation for that signature with all its dependencies, to obtain an actual function whose signature matches that specification. The "fulfilled implementations" should all start null and be filled in lazily, to reduce startup time.
Associate to each operation name the function that simply looks through all the signatures, trying to match each in turn, finally calling the right one, rather than doing the cleaver bundling-into-a-dedicated-js-function-object tricks that typed-function does, just to get something running.

- [ ] Adopt a data structure for a signature of an operation (keep it close to what the current type parser returns) - [ ] Write a sort function for such signatures compatible with the order we want to try them against arguments - [ ] Associate to each operation name an array of [signature, "fulfilled implementations"] pairs in sort order, where a "fulfilled implementation" is the result of calling the supplied implementation for that signature with all its dependencies, to obtain an actual function whose signature matches that specification. The "fulfilled implementations" should all start null and be filled in lazily, to reduce startup time. - [ ] Associate to each operation name the function that simply looks through all the signatures, trying to match each in turn, finally calling the right one, rather than doing the cleaver bundling-into-a-dedicated-js-function-object tricks that typed-function does, just to get something running.

glen commented

2023-10-26 19:22:06 +00:00

This is a pretty rough outline, and there are definitely some additional challenges that will have to be overcome already to get to the point that all of the existing operations are working on all of the types. As two examples:

Some of the type annotations from ts-macros still have RealType<T> and things like that occurring in them. We will need to be able to compute from the name of a type, what the name of its RealType is, etc. For that we might need the contents of the .d.ts file from compiling interfaces/type.ts, for example, or need to reflect the data in the AssociatedTypes<T> generic in some other way.
Generic implementations need to be "super-lazy" and never fill in their "fulfilled implementation" -- instead, they figure out what type parameter the generic needed to be instantiated with for the current arguments, and then add that instantiated signature to the list of signatures, along with the fulfilled implementation just for that signature. That avoids the combinatorial explosion of trying to instantiate the generic implementation for all the argument types that might come up; we just wait to see what it's called with.
We need to fill in the implementations of typeOf automatically (there may be other methods we generate automatically, too? I can't quite remember, but I think there may be some operation like joinTypes that I needed in pocomath).

There will likely be others. Also, Jos agreed to take first crack at writing the code to generate a .d.ts file describing a particular output of createDispatcher, if Glen can get some first pass at an actual callable dispatcher object running.

This is a pretty rough outline, and there are definitely some additional challenges that will have to be overcome already to get to the point that all of the existing operations are working on all of the types. As two examples: - [ ] Some of the type annotations from ts-macros still have `RealType<T>` and things like that occurring in them. We will need to be able to compute from the name of a type, what the name of its `RealType` is, etc. For that we might need the contents of the .d.ts file from compiling interfaces/type.ts, for example, or need to reflect the data in the `AssociatedTypes<T>` generic in some other way. - [ ] Generic implementations need to be "super-lazy" and never fill in their "fulfilled implementation" -- instead, they figure out what type parameter the generic needed to be instantiated with for the current arguments, and then add that instantiated signature to the list of signatures, along with the fulfilled implementation just for that signature. That avoids the combinatorial explosion of trying to instantiate the generic implementation for all the argument types that might come up; we just wait to see what it's called with. - [ ] We need to fill in the implementations of `typeOf` automatically (there may be other methods we generate automatically, too? I can't quite remember, but I think there may be some operation like `joinTypes` that I needed in pocomath). There will likely be others. Also, Jos agreed to take first crack at writing the code to generate a .d.ts file describing a particular output of createDispatcher, if Glen can get some first pass at an actual callable dispatcher object running.

josdejong commented

2023-10-27 07:13:22 +00:00

Thanks Glen for writing out this plan👍

Sign in to join this conversation.