Coding 2024-12-28
All right, with a bit of thought, I understand that the different papers I was reading were using the word "kind" in compatible fashions. The gamble I have to take is to create several sorts of "field" and "extension" kinds, as well as a "variant" kind, and maybe some other stuff. From there, the key is to make sure that I have type inference rules that are compatible with the new kinds.
I'm reading up on type inference techniques that work with subtyping, which is going to be a must to deal with the row types that all of that is meant to introduce. The complication I have to deal with right now is, I kind of want three things that could reasonably be described as row types, and there are a bunch of questions I need to answer:
- What are the associated kinds?
- What are the corresponding type inference rules?
- Does this break anything at a theoretical level?
- Practically speaking, how do I translate this to code?
- I want to implement these things one at a time; how do I lay out the code so that grafting on more kinds like this isn't a complete pain?
Oh yeah, also: I guess I'm going to need more types (kinds?) at some point for FFI purposes, because I'm planning to have a level of flexibility for internal types that doesn't sensibly apply to external types.
Anyway, it's best if I plan before further prototyping, best if I read more before planning, best if I sleep before reading.
Good night.