mflatt at cs.utah.edu
Fri Aug 18 19:55:16 EDT 2006
At Fri, 18 Aug 2006 08:10:59 -0400, William D Clinger wrote:
> I would like to understand this problem. Does the
> problem arise because a library may import a variable
> only for run time, when it should have imported the
> variable for expand time as well?
Yes. Or it should have been imported for run time, and was only
imported for expand time.
You might have an overall program structure like this:
* Library A exists
* Library B imports A for run
* Library C imports A for expand
* Library D imports C for run, and a macro expands to a use of a
variable in A
* Library E imports B and D for run
Then, there's no guarantee that B and A are invoked before D (which has
the reference to A).
It's not so difficult to detect that a reference to A in D is wrong,
since A is not in the transitively closed set of for-run imports of D.
A worse problem, though, is when things appear to work for a while:
* Library A exists [same as before]
* Library B imports A for run [same]
* Library C imports A for expand [same]
* Library D imports C for run, re-exports the macro from C [different]
* Library E imports B and D for run; it uses a macro from D that
expands to a reference to A [different].
In this case, the reference to A in E looks fine, because A is in the
transitively closed set of imports for E. But if we change B so that it
no longer imports A (not a change to E), then E stops working.
This latter example is the sort of problem we kept running into in PLT
Scheme. Or, sometimes E was the only consumer of D for a couple of
years, and then eventually someone else tries to use D and discovers
that its broken. For us, these sorts of problems happened far more
often than phase-0 ordering problems.
More information about the R6RS