express in the type system whether a function handles specific type forms, but not others, or handles some in a different manner from others.
I expect that runtime functions which accept a TypeForm as input - many of which will attempt to support all possible forms - will nevertheless vary (from each other) in many small details RE what specific forms they recognize.[1]
I’m not sure that its desirable (or even possible) to write out the exact constraints on what kinds of forms a particular function will accept. (And I think that’s OK.) I’m planning to discuss & elaborate on this consideration (among others) for functions accepting TypeForms as input in a “How to Teach This” section in the next draft.
there was a suggestion to be able to encode this information into the type system’s handling of TypeForm by having the first argument to TypeForm be the form, and the remainder the inner annotations […]
Aye. For that particular example I have some specific thoughts I’d like to articulate carefully but I’ve run out of time this weekend. Let me get back to you in a few days.
For example a stringified type annotation object like
"SomeTypeAlias"is difficult/impossible for a runtime type checker to support in the general case, assuming information about which module the string was defined in is absent. ↩︎