Coding 2026-02-09
There are still some ways in which I don't understand 1ML subtyping as well as I'd like, but I think it's at the point where I just have to try to implement it to have any idea of what's up. I've taken some notes on my proposed modifications to the syntax, and I'm not sure I can do more to figure out what I need to know, beyond just trying to write the code. My barrier to that is, I want to fix up the code organization before it gets any more convoluted and arbitrary.
Let's run through my thoughts and see what I can get to make sense.
- I want to move a lot of the existing "node" modules into an ir package, and within that, I want to divide them by feature.
- So, we have the abstract classes (and putting them in a module called abc gets confusing when I want to work with the stdlib abc module at the same time), which need access to the Failure feature, which therefore needs to be importable without importing the module that defines the failure classes.
- Some of the base classes require instances of the other base classes to function properly, so it would make sense to split up the base class definitions, as well. And the convenience method definitions would make more sense as class members, so that's another module for abstract classes; not sure what to call all of these.
- Due to the way 1ML and other extensions interact with variables and labels, those should live outside the ir module.
Writing all of that out inspired me to put together a skeleton of where I think everything should go, but before I move things into place, I want to get the helper classes a little better behaved. I have some ideas there, but it's too late at night to try them out now. I need to wrap up as soon as I can.
Good night.