Adding the PUnRecurify protocol for replacing the 'recur' form.
Adding protocol implementations to Recur.

Adding implementations for PLoadTrampoline, PUnRecurify, and PWalkable
to the Recur record type. This should allow for adding 'recur' as a
source language expression.
Adding implementations for PUnRecurify to relevant expressions.
Removing useless metadata from backwards-compatibility entry points.
Adding named 'fn' support and auto-naming for 'fn' in the parser.

Previously names for 'fn' expressions were added during CPS, as that
was the first point that having a name was necessary. However, the
unrecurify function implemented by PUnRecurify is run before the CPS
transformation and requires an available name for every 'fn'
expression. To this end, support was added to the parser for named
'fn' expressions where only anonymous 'fn' expressions were accepted
before. Additionally, 'fn' expressions without a name are now given an
assigned name in the parser.
Exposing 'recur' as a top-level CTCO expression.

Updating the parser to accept the 'recur' form, adding unrecurify to
the list of passes performed by the ctco macro, and correcting a bug
in the implementation of load-tramp for the Recur record.
Correcting the gensyms in the unparse tests...again.
Adding the PRecurify protocol for inserting the 'recur' form.
Writing first (and incorrect) draft of implementations for PRecurify.

Implementing the recurify function provided by PRecurify for all
relevant CTCO expressions. However, the given implementations are
incorrect. At present they pass the name of the current function and
whether the expression is in tail position, and replaces all
tail-position function applications using that name with the 'recur'
form. However, Clojure introduces the wrinkle in that overloaded
functions may not use recur to call the current function with a
different arity. That is, a given overloaded version of a function may
only recur to itself. Thus the current implementation of PRecurify
will incorrectly insert the 'recur' form for calls to a different
overloaded version of the same function.

For example, consider the following expression:

	(defn foo
	  ([x] (foo x 1))
	  ([x y] (+ x y)))

Given the current implementation for PRecurify, this would be
transformed into this:

	(defn foo
	  ([x] (recur x 1))
	  ([x y] (+ x y)))

Attempting to evaluate this would result in an "incorrect number of
arguments to recur" error. Seeing as though we're in the business of
correctness-preserving transformations and not
incorrectness-introducing ones, this is a bad thing.

The solution to this problem is to pass an additional argument to the
recurify function of PRecurify denoting the arity of the current
function body and only replace function applications when they have
the same name as the current function, are in tail position, _and_
pass the same number of arguments as the current function body
accepts.
Correcting declaration and implementation of PRecurify/recurify.

Adding arity information to recurify transformation to prevent
erroneously converting function calls to the same overloaded function
with a different arity. See previous commit for further details on the
now-solved issue.
Pushing the Recur record into app.clj to avoid cyclic load dependency.

Previously the Recur record type was defined in its own file,
recur.clj. With the advent of the "unrecurify" transformation, which
converts the 'recur' form into a function application, and the
"recurify" tranformation which does the reverse, the App and Recur
record types came to depend on each other in the implementations for
unrecurify and recurify, respectively. To avoid cyclic load
dependencies, the definition for the Recur record type was pushed into
app.clj, the same file in which the definition for the App record type
resides. This seemed the most logical thing to do, as 'recur' is
something of a special form of function application.

It should be noted that this did not resolve the mutual reference
between App and Recur, and so there is the diry, awful (but necessary)
hack of forward declaration of a function which creates the Recur
record type in app.clj.

An alternative solution to this problem is to simple eliminate the
'recur' form as a separate record type and to represent it as an
ordinary function application with a distinguished operator. This
would, however, complicate the implementation of the compiler passes
for the App record type and violate the philosophy of representing the
core language forms via their own record types.
Trying to fix the unparse tests.
Merging 'recur' into app.clj.
Correcting implementation for PRecurify/recurify for Cont record type.

The previous definition omitted the "arity" parameter, leading to a
very confusing error.
Adding the 'recurify' macro for automatically adding the recur form.

Co-opting the recently-added feature for CTCO which uses the 'recur'
form appropriately instead of explicit, named function application,
the 'recurify' macro takes an arbitrary Clojure expression (as
accepted by ctco) and inserts the 'recur' form appropriately.
Adding implementation for PRecurify/recurify for Do record type.
Correcting file-level documentation for simple_op.clj.

In a move clearly indicating that I blatantly copied the documentation
for simple_op.clj from if.clj, the file-level documentation
incorrectly gave information on the IfCps, IfSrs, and IfTriv record
types instead of the SimpleOpCps, SimpleOpSrs, and SimpleOpTriv record
types. Ooops.
Changing inserted metadata check for 'fn' to use SimpleOpCps.

Previously the inserted test for whether the last argument in the
conflicting arity case of an 'fn' expression used the App record type,
leading to thunkification within the expression. These instances are
being replaced with the SimpleOpCps record type to avoid this. Note
that using this record type is correct given the definition of a
simple operator.
Updating documentation and project version.
Adding canonical group name to project.clj.