Cammy

Fork

Debug FP multiplication somewhat.

For some reason, ground inputs are not giving a ground output. This
might be an issue with the structure of eval°, but I'm not seeing how.

Finish implementing FP.

Does it work? Kind of! We can evaluate f-add and f-mul at 0.0, for
example. We can't print either in general, though.

At this point, it's down to individual missing cases. I personally think
that we'll have fewer special cases overall, but I think that at least
fp-overflow° will need to change since we don't represent infinity with
a maximum exponent.

Clean up imports, fix FP unifications.

FP values are still off by a bit, but this seems to work for f-lt and
f-sign, at least.

More FP.

Strangely, these relations don't want to run forward *or* backward. I'm
starting to think that I've done something wrong with sample-elements,
or maybe build-fp.

Really start implementing FP.

1.0 becomes 4.0, which is wrong. Also f-sign doesn't evaluate, although
I can compute its image. I suspect that I'll need to go back to the
paper and really focus on implementing each case carefully.

Make jelly acceptance jelly-specific.

Factor eval° more; make n-pred-maybe reversible.

I'm starting to notice some general patterns about reversibility. I'm
not sure whether I fully understand what's going on, though.

Implement sums; start implementing floats.

Implement relational currying.

I was worried about this, but it turns out to be pretty simple. It
doesn't really want to run backwards, which is fair. It also doesn't
want to run forwards, unless the input is ground. This might be a more
fundamental problem, and we might need to have a curry° to make a more
tractable search.

Search backwards through eval° and cammy°.

I figured it out for eval°, but I do not at all understand why cammy° is
improved by this. Nonetheless, I was able to replace cammy-synth° and
the entire pile of hacks. As a bonus, previous tests which timed out are
now successfully finding valid expressions; djinn is cleverer!

Use a faster sorting routine.

SRFI-132 replaces SRFI-1's quadratic-time approach with a good old
O(n lg n) approach.

Delete Honey.

Cool idea, no users, no use cases, more complex than just writing a
better REPL. Maybe we can do this later in the future, but for now, I
want to focus on sharing and merging JSON hives.

Add a djinn to the new REPL.

So much easier!

Genuine computation of images and fibers.

Some seemingly-simple functions like (comp succ succ) do not run
backwards very well, and I don't understand why. Also, empty fibers over
2 are decidable, but over N they appear to diverge; I can guess why, but
it's frustrating to see.

Evaluate images and preimages directly.

I've gotta figure out how to extract the results decently, but this is
amazing in general. The one thing I don't like is that 1 is in the image
of (comp succ succ), which suggests that succ° is broken somehow.

First swing at computing the image of functions.

Works for zero but not succ. Groundness issues.

Print out elements and time taken.

Format types nicely.

Fuck it. Scheme REPL.

It's all just trash, isn't it?

Tab-complete templates too, not just dippers.

Optimize dissolved expressions, always.

Similar to the old logic, but now that I have a REPL again, I can
quickly iterate.

Get new REPL to extract complete terms.

We're gonna hack a bit on new REPL, I guess.

Factor out some useful relations.

I'm likely going to rewrite all the WASM compiler stuff, but I want to
save the useful stuff so that I don't have to write it again.

It's pretty cool that macros can be modularized. TIL.

Try putting together all of the port stuff.

I think I need to rethink this. It is a tangled nest. Some
supposedly-easy small fragments diverge, and I cannot tell why.

Use a macro to simplify some append°.

This is a 40% efficient abstraction (5 lines added, 2 lines removed); it
is not worthwhile on its own. It might be more useful in a few minutes,
though.

Reach a point of miscompilation.

I think I need to break this compilation action into two pieces. First,
I should convert to ANF or SSA; then, compilation to WASM should be much
easier. This whole ports-and-locals business is not easy to get right.

Encode pairs on the WASM stack.

I realize that implementing (pair f g) properly will require some extra
stack-saving work. Really, we should still have "stack ops", but now the
property is whether or not the stack is saved; our "spilless ops" would
compose without using any locals.

I know that we could spill after every op, and let an optimizer clean it
up, but what if the optimizer can't figure it out? I have been told many
times that my codegen output is bulky, and I think I can get this case
correct on my own.

Figure out a viable encoding for ports.

Something about this is cognitively challenging. But I think I've
figured it out well enough to start porting the rest of the compiler.

After this, only curries will be left to figure out, and I've got a
couple different defunctionalization approaches to try.

Try a new approach to compiling to WASM.

This is based on a graph-and-ports architecture, as used in Elliott's
"Compiling to Categories" and almost certainly elsewhere.