Cammy

Fork

More floating-point operations in Set.

Add the ability to search the hive by name.

Honestly, it's almost better than Tab-completion. Almost.

Take some benchmarks with the JIT.

Factor out calls to cammy-sample.

Finish refactoring RPython tools.

Now the new REPL calls RPython to go fast, but high-level manipulation
is now in CHICKEN Scheme. The resulting hive actions are much simpler
and more direct, while the speedy parts are JIT'd and the relational
parts are reversible.

Disassemble from REPL.

Progress towards draw and animate.

Remove old REPL functionality.

The REPL is still there, still useful, but no longer able to depend on
djinn.

Streamline the RPython arrow-to-CAM workflow.

Also finish refactoring the subcommands.

Get the RPython tool to build on its own.

Also, it is now known as the "sampler", because its primary design goal
is now to take samples from audio/video descriptions, rendering the
result to disk. A dedicated interpreter is appropriate for the task
because we may treat Cammy as a low-level language and directly
construct a JIT for a basic interpretation.

Add more floating-point operations.

Some NaNs are showing up. I wonder how I should deal with them...

Refactor eval° fresh variables.

Fix recursion for decoding, too.

Allows computation of images. FWIW we should eventually refactor this so
that images are computed in the appropriate category; images in Set are
computed by pushing example elements through the interpreter!

Fix recursion in elt->str.

I was hoping that the shadowing would work in my favor, but it does not.
So, I elected to just rename the recursive function, then bind it into
the implementation record.

Hammer out the core of an interpreter for CCCs with NNO.

The only thing I don't really like is the encoding of curries, but I'm
willing to trade readability for speed here.

Add ability to switch between Set and Rel.

I haven't fully written the Set compiler yet, but it should not be
especially difficult. I'll hammer it out after lunch.

Add read-only hive support to new REPL.

cammyo: Rearrange clauses for convergence.

Try turning around cammy°.

Doesn't appear to hurt? But also doesn't help for n-pred-maybe.

Figure out FP multiplication.

Test it out by implementing f-sqrt. It somewhat works? But has some
issues. The image and fiber aren't quite right, and it hangs on inputs
like 1.0. Nonetheless, it's promising!

I'm going to have to think about general principles before doing more
work here. This has been a good experiment, at least.

Correct exponent handling for addition.

Fix FP reificiation.

I had the division backwards. Now, f-one evaluates to 1.0.

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.