This module, along with the Typecheck.Typecheck class, define a little
DSL to express function signatures. Check existing calls for examples.

Argument passing, in an effort to be flexible, got a bit complicated. Each
Arg has a name and a possible default. So right off there are three ways
to provide an argument:

Pass it explicitly.

If it is omitted, or _ is passed explicitly, it will be sought in the
dynamic environ, under the name <call_name>-<arg_name>. E.g. given
a call generator "name" $ \args -> call (required "arg1") ... then
name-arg1 = 42 | call _ will get 42. Note that it uses the call name,
and not the symbol it happens to bound to in this scope. This is because,
while you may bind different kinds of trills to tr depending on the needs
of the score, the two kinds of trills may have different arguments with
different meanings.

If it's omitted, and not in the dynamic environ, the default will be
used, provided there is one.

In addition, an arg may be a BaseTypes.VPControlRef or
BaseTypes.ControlRef, which introduces yet another way to provide the
value. An argument required_control "c" will pass
a BaseTypes.LiteralControl. Technically it's then up to the call to
decide what to do with it, but it will likely look it up at its chosen
point in time, which means you can provide the value by providing a c
control track or binding it explicitly e.g. %c = .5 | call.

To further complicate the matter, the control arg may itself have a
default, to relieve the caller from always having to provide that control.
So an argument control "c" 0.5 or an explicitly provided control val
call %c,.5 will default to 0.5 if the c control is not in scope.

Since the arg defaulting and control defaulting are orthogonal, they can be
combined:

Pass it explicitly with a default: call %c,.5. This is either the
value of %c or 0.5.

Pass it via the dynamic environ: call-arg1 = %c,.5 | call. This is
the same as the above, only the argument is provided implicitly.

Fall back on the built-in default: control "c" 0.5 and then just
call.

I originally envisioned the dynamic environ passing scheme to be a way to
default certain arguments within the context of a track, to be used in
a relatively ad-hoc way in specific parts of the score (e.g. all trills
within this section of melody default to minor thirds), is not limited to
numeric types, and is constant in time. A control, however, is intended to
capture musical parameters that change in time over the course of the
piece, and is numeric or a pitch. So while dynamic environ args are forced
to be specific to a certain call by prepending the call's name, control
names should generally have more general and abstract names.

On the subject of controls, controls (and numeric vals in general) have
another layer of complexity since they carry types. For example, here's
a gloriously complicated argument: defaulted "speed" (typed_control
"tremolo-speed" 10 Score.Real). This argument defaults to
%tremolo-speed,10s. If it's not given, it will have the value 10s. If
the %tremolo-speed control is in scope but untyped, its values will be
interpreted as RealTime. If it's in scope and typed (e.g. with
a tremolo-speed:t track), then its values will be interpreted as
ScoreTime.

Another wrinkle in argument passing is that, in addition to being
required, which has no default, or being defaulted, which has
a default, they can be defaulted with a default of Nothing. This passes
the argument as a Maybe a instead of a and lets the call distinguish
whether an argument was provided or not. This is for arguments which are
defaulted but need a more complicated defaulting strategy than simply
a constant.