The system has an invariant that if you ever return an error
sentinel (error environment, error type) then that sentinel is caused
by an error that was reported to the user. We have had too many bugs
over the last little while where that was not the case!
(An example is if we mis-interpret the tree by calling `nth_tree` with
the wrong index or something, and get `None`, and think "oh must be a
syntax error", but it was really just the wrong index. Then there's an
error sentinel with no error diagnostic and we don't discover the
mistake until much farther along.)
Now we enforce this by requiring that whoever constructs the error
sentinel *prove* that they can do so by providing a diagnostic. It's
less efficient but prevents the problem.
This actually uncovered a couple of latent bugs where we were
generating error sentinels instead of a more appropriate type! Whoops!
I'm worried that this will turn into something I always have to do
instead of something I just do sometimes: always provide the
provenance of some error type or another. Link error types to
diagnostics, etc.
Going to need to normalize that name though, because right now it
really *really* sucks to have a big \\?\ kinda name. Probably
normalize it relative to the base directory.
- Classes are defined lazily
- Member access is via environment
- Member access is just a binary expression with a weird environment
- Slot loads look like variable loads now
- Associativity in the parser (ugh)
- Check for more error conditions
- Move to more definitive error assertions
- Simpler error messages in some cases
- Test more conditions more thoroughly, revisit old tests
