Three Dollar Quill

Okay, here's the deal. I think I see how to recover something like the error reporting functionality I had in pure inference mode. The current type-checking code is incapable of reconstructing the context available to the caller, which is where the error used to be generated from. So, if I want to replicate the same error information, then I need to build up some form of context object at the outermost layer of checking, and propagate it towards the leaf nodes. From inspecting rg output on my codebase, I can see that no method ever performs more than one check; the unimplemented nodes are solely types, so that won't change anything. However, I do kind of want to try making kinding bidirectional for the heck of it, which will result in type checking sometimes turning into kind checking, and will lead to some form of branching in the error message generation. Currently, checking failure leads to an exception being raised, but I want to have the way open to generating typing constraints instead, which is going to be a Whole Thing, and means that every validation path will end up being taken...

Convincing Python to suddenly be Prolog sounds like a project all its own. The feeling I'm getting thinking about this is that I'm going to need to do some experimentation to figure out what this code should look like, and how many forms it's going to have to go through.

One thought that comes to mind is that replicating the current behavior doesn't require an exception to be raised in a check function, only in the inference function that called it. So, perhaps I could rework the check functions to return some form of problem report...

Perhaps what is needed is some idea of how more featureful compilers report errors. I'm going to need to track down some more papers, I guess. And get back to taking notes.

Anyway, I need to get ready for bed.

Good night.