so functions close over their arguments.

Laziness can come with a performance cost, but the Haskell folks have
done lots of good work on strictness analysis. In exchange, you can
write conditional constructs without needing macros, streams, infinite
data structures, some performance <em>gains</em>, and easier semantics
for recursive expressions.
s
Uniqueness typing has <a href="http://home.pipeline.com/~hbaker1/Use1Var.html">many many
advantages</a>, so we'll
use that instead of nasty monads. But we can do monads too, when
they're useful.

Haskell-style typeclasses and generic functions are used to provide
polymorphism, rather than class- or prototype-based object

arithmetic and other core functions that can't practically be
implemented otherwise. These primitives are what core language symbols
are bound to. They are a subtype of functions, in that they can be
applied directly, but unlike functions in general, they allow equality
comparison. A macro can tell if an application is a primitive, and
which one it is.

Bounded-space tail calls and first-class <a
href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.63.1754&rep=rep1&type=pdf">partial
continuations</a> provide for flow control, but I need to think more
about how that will interact with the uniqueness types. A continuation
may contain many closed-over unique values, so the continuation itself
<em>must</em> be a unique object. That's fine for implementing
threading with continuations, but what about <tt>amb</tt>, exceptions,
and so on?  Perhaps we need a means for capturing a non-unique
continuation that only works if the dynamic environment we close over
in the continuation contains no unique values (which can only be
checked at runtime, unless we constrain the language to make static
checking possible). Code that handles mutation by passing a chain of
unique values through it, but which contains try/throw/catch
exceptions, would need the <tt>throw</tt> to embed ALL unique values
currently in scope (but not in scope at the <tt>catch</tt>, which is
possible of the <tt>throw</tt> is within the lexical scope of the
<tt>catch</tt>) in the exception object to avoid leaving them in the
abandoned continuation; so invoking a continuation (and thus
abandoning the current continuation) would be forbidden if the current
continuation closed over unique values (and was therefore
unique). You'll need to explicitly destroy them, or pass them to the
new continuation.

There's no need for <tt>unwind-protect</tt> or <tt>dynamic-wind</tt>
in a pure language, thankfully.

Dynamically-scoped parameters are a boon in Scheme, so we'll have
them, too.