First Optimizations

[countvajhula]

Summary of Changes

The goals for this PR are:

1. to validate that the core language does not change the semantics of the full language, i.e. there is no information lost in rewriting down to the core language (even taking side effects into account, and e.g. in terms of short-circuiting).
2. to implement a small number of "proof of concept" optimizations.
3. Ideally, the PR should also define the overall structure of "compiler passes," if it is possible to define that at this stage.

I believe (1) is necessary in order to support the introduction of a do form which would abstain from doing optimizations. If the core language already loses information, then this form would not be able to preserve the meaning of the input syntax (including side effects).

Some approaches to consider for optimizations:

• attempt to implement "list-like" operations on values using lists internally instead of values (e.g. investigate loop)
• potentially adding list-oriented core forms that present a list input and output interface, see Core values or core lists?
• identify cases where a small number of arguments may be assumed up front (e.g. amp) and handle those without generic values<->list conversions
• define distinct handling for small vs large number of arguments in the core forms (may require an arity annotating compiler pass) to avoid generic values<->list conversions
• identify other cases of values<->list conversions that could be avoided (e.g. map-values, fold-values)

See A Core Performance Issue Identified for more background.

Public Domain Dedication

• In contributing, I relinquish any copyright claims on my contribution and freely release it into the public domain in the simple hope that it will provide value.

[countvajhula]

@michaelballantyne Feature request: the ability to use ~> as a core form without it colliding with bindingspec production syntax, since it'd be preferable to use ~> in optimization rules in the core language instead of thread.