Despite the drawback of losing static signature information,
unit can be useful in combination with other forms that work
with first-class values. For example, we could wrap a unit
that creates a toy store in a lambda to supply the store’s
color:

This compound-unit form packs a lot of information into one
place. The left-hand-side TF and TS in the
link clause are binding identifiers. The identifier
TF is essentially bound to the elements of
toy-factory^ as implemented by
[email protected]. The identifier TS is
similarly bound to the elements of toy-store^ as implemented
by [email protected]. Meanwhile, the elements bound to TS
are supplied as imports for store[email protected], since
TS follows [email protected]. The elements
bound to TF are similarly supplied to
[email protected]. Finally, (exportTFTS) indicates that
the elements bound to TF and TS are exported from
the compound unit.

The above compound-unit form uses
[email protected] as a first-class unit, even though
its information could be inferred. Every unit can be used as a
first-class unit, in addition to its use in inference contexts. Also,
various forms let a programmer bridge the gap between inferred and
first-class worlds. For example, define-unit-binding binds a
new identifier to the unit produced by an arbitrary expression; it
statically associates signature information to the identifier, and it
dynamically checks the signatures against the first-class unit
produced by the expression.