invoke-unit

[Matthew Flatt <mflatt@cs.utah.edu>]

In version 103, `invoke-unit' is special in MzScheme. It is able to
grab the location of global and lexical variables, and use the
locations to satisfy the imports of a unit.

In version 200, `unit' et al. are currently implemented via
`define-syntax'. Compound unit linking allows units to share locations
in the usual way, because imported and exported variables are
implemented as boxes. But `invoke-unit' can no longer grab the address
of global and lexical variables. [*]

A quick scan of plt/collects suggests that we don't use `invoke-unit''s
current power. In other words, it looks like creating a new location
and copying a value there would work just as well. (Robby: I'm not
enitrely certain about the use in "drscheme/tool.ss"; can you check?)

Is it ok with everyone to change the semantics of `invoke-unit' so that
it makes up new locations to satisfy the invoked unit's imports? 

It's no coincidence, of course, that we made a similar change
export-side when we replaced `invoke-open-unit' with
`define-values/invoke-unit'.

Matthew

 [*] An "InvokeScheme" language might define new `lambda', etc.
     constructs that cooperate with `invoke-unit'. It might even
     exploit `local-expand' to re-map uses of the kernel's `lambda'
     post-expansion, which would allow "InvokeScheme" work with syntax
     extensions of Scheme. It's nice that this is possible, but I don't
     think it's necessary.