[plt-scheme] associating names with static data

Sorry, I should have been more specific. I'm designing a new version of 
`define-datatype' (a la EoPL) that works with the contract system (via a 
`provide-datatype/contract' special form). In order to register static 
information with each variant, keyed by the variant name, I need to 
provide the variant name from the defining module. Here's the catch: if 
I want variant constructor names to be the same as the variant names (as 
in EoPL) rather than make-<variant>, then I have to be able to use the 
constructor name as a key (compared with module-identifier=?) for the 
static data.

> I'm not sure how I can help, but I'll just say that provide/contract
> makes up a new name and provides that name instead of your definition's
> name. Also do keep in mind that the value inside the module does not
> have the same behavior as the one outside, which is where this problem
> stems from, I suppose.

Right, so when I provide/contract a constructor, it gets wrapped with a 
macro with a new name and then provided but renamed to the original 
name--and the registry information is no longer accessible outside of 
the module, because the old key is lost. This means no one outside of 
the defining module can use `cases' or `match', which rely on the static 
information.

> You can probably write a variation of provide/contract that does what
> you want and expands into provide/contract, but I'm just guessing,
> since I'm not sure what exactly you're doing.

AFAICT, if you define an identifier x inside of module m, and then 
provide y renamed to x, there's no way *inside* of m to get an 
identifier that's module-identifier=? to the *exported* identifier x, 
and there's no way *outside* of m to get an identifier that's 
module-identifier=? to the original *internal* identifier x. This means 
that inside of m you can't register anything in a 
module-identifier-mapping with an identifier that gets exported with 
provide/contract, because the key is lost forever to external clients of m.

I think for this to work, the module system would need to provide some 
sort of channel by which external clients and internal macros could 
share a name even in the face of provide + rename.

Thanks again,
Dave