~jojo/kapreolo

add some commented test ideas
Collapse chain of decision tree tests to switch
subst all tvars in expr tree when done checking def
tuples & more complete pattern matching

Pattern matching is almost complete at this point. Just need to add
tagged union types and handle matching on those, but the foundation is
there already. Went with a version of the good ol' Sestoft 1996.
Replace pattern match loop w/ Peter Sestofts alg

Still only handles integers & vars.
Tuples will be next.

I realized that the simple loop solution would of course break down in
the face of nested patterns. Matching on a linked list could result in
an arbitrarily deep pattern. We need something more complex to handle
that.

I've used this alg before, so it's a natural starting point.
I think it's a bit hard to follow though, so I want to try my hand at
adapting it a bit.
primitive pattern matching

Can only do integral patterns & variable patterns atm, nothing nested.
But exhaustiveness & redundadcy checking is no problem so far.
I think we can get something much more readable than Sestoft's
algorithm if we just work our brain muscles a bit.
seems we've got higher-rank polymorphism working now as well :)
rank 1 polymorphism seems to be working ok
use (limited) unification in checker

Inference variables may not escape the scope they were introduced in.
So if we use inference vars to infer the params of a lambda, they must
have substitutions at the point where we add the lambda expression's
type to `expr_types` and return.

We can infer params for lambdas now.

I hope this paves the way for some parametric polymorphism.
nested type annotations
flatten resolve & use Expr from kapo

Now, check only generates on out-of-band arena of ExprRef->Type.
Fairly elegant imo.
rename file ext from .fm to .reolo & lib.fm to kap.reolo

Also, kap.reolo doesn't necessary have to be a library entrypoint.
It can contain the main function as well.
So a simple kapreolo library or executable would both only have a
single kap.reolo file.
But you could also have a separate main.reolo or app.reolo or whatever
if you wish to keep the executable part separate from the rest of the program.
proper type Arena for arenas instead of just Vec
get rid of PubIdent on fun params in Kapo
rename name::{ParsedName, PrivIdent} to parse::{Name, IdentSpan}
initial flattening of Kapo

We don't really exploit the flatness and do anything different yet,
but that will come once all stages are flatter
Rename lang to Kapreolo (esperanto for "roe deer")

from Effem.
It just didn't really reflect my goals with the language.
I'm more into the interactivity / on-demand / incremental part now,
and less so about the algebraic effects.
Not that I don't still want them, they're just not at the very top.
And the FM was kind of arbitrary.
Animals are better.
I like the names & vibes of languages like Carp & Hare.

also, add a temporary logo
pretty print Base IR
flatten the Base IR

Application of data oriented design.

Pros of flattening trees:
- Better cache locality.
- Smaller references (u32 vs Box (= usize often= u64))
- Cheaper allocation. Instead of individual `Box`es each requiring a
  heap alloc, just push to the same arena `Vec` (which only rarely
  allocates).
- Possibilities for easy deduplication (e.g. via a
  `HashMap<Stm, StmRef>`)
- Nodes are in topological order (I think?). This might be
  exploitable.
tweak base IR to separate divergence from operations more clearly

partly for prepping for flat tree in base
Next