Coding 2023-07-15

By Max Woerner Chase

All right, I've given things some thought, and here is what I've concluded: If you're making modules and types for grammars the way I intend to (which is clearly not the only way), then it's going to need a bunch of gnarly compound types, but crucially, they're entirely built up from just two basic types that the user has to pass in. So, if we give those types as arguments in OrderedType modules, then that relieves the user of constructing a bunch of modules to pass in.

The next thing I need to think about is how to handle the whole error-wrapping idea. Is it reasonable to say "If you want an error-correcting grammar, then use the special error-correcting grammar constructor, which will give you back a module for a non-error-correcting grammar, and then you can pass that into a function on the higher-level module"?

Maybe... maybe the error-correcting version should have a different relationship between its input types and the compound types in the grammar, compared to the basic version.

Like, what's the right choice between:

And now I'm realizing that a lot of these types should be abstract, which will hopefully make the code shorter overall. Like, the compound types that the code needs to know about:

So, ultimately, this requires three public types, and one abstract type. Two of the public types need a comparison function to implement the various compound types.

I think this is enough to fix up the interfaces around the grammar, but right now I need to get to bed.

Good night.