> A `define-values` in a signature adds a definition to any *importing* > context (in contrast to `define-values-for-export` which adds a > definition in any *exporting* context). The `define-values/invoke-unit` > form "imports" the signature into the definition context.
I reread the documentation for define-values/invoke-unit and it makes a bit more sense after reading that the export clause gets treated as an import to a local definition context, but I don't really understand why this is the right thing to do. This seems to differ from simply invoking a unit with the `invoke` form which doesn't need exports to be listed explicitly. Why should the exports be treated as imports in a local definition context, this just seems contradictory to the meaning of exports. >> Since the y^ signature is being exported instead of imported I expected >> that the value of y should not be available in the y@ unit, and furthermore >> there is no need to declare y in the signature as a variable which the unit >> must define. So why is it the case that this unit defines and exports the >> value >> of y, when according to the documentation this shouldn't happen. > As you say, `y` isn't bound in the unit `y@` by the export of `y^`. > With the `define-values/invoke-unit` form in the same context, though, > the unit `y@` will be able to refer to `y`, just like any other binding > in the unit's environment. I can understand how `define-values/invoke-unit` adds a definition for `y` in a local context that the `y@` unit can then refer to, but since the unit doesn't export `y` through an exported signature I don't see why this generates a global binding for `y`? I would expect only the exports of the unit should be added as new bindings, I think this is what the docs say, but since `y@` doesn't export any values there should be no new bindings added. Thanks again, Dan ____________________ Racket Users list: http://lists.racket-lang.org/users
