This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> From: thi <ttn@netcom.com> > > (define f-there > (variable-ref (module-variable (resolve-module '(there)) 'f))) > > (f-there 3) => 9 > (f 3) => 6 > > this is not in any manual because the module system is slated for > redesign. although it's been pointed out that implementation details > should not be made available, i still am wondering about the new > module system spec. ie, will `module-variable' and `resolve-module' > still be around? > I hope not. "First class variables" and procedures to turn arbitrary symbols computed at run-time into variables both throw a monkey wrench (spanner) into the Scheme system of lexical binding, and are impossible to compile effectively. If it must be done the appropriate syntax is: (eval 'f module-envirionment) this makes it clear that you are invoking the entire compiler/interpreter, and not just loading a value from an address. The module system should not require anything like this. Instead there should be a special syntax for importing a module while systematically re-naming its exported variables. This should be done in such a way that a straight-forward scan of the source code of the program and the module will yield a list of all identifiers that can be bound to a given storage location (in a given lexical scope and environment etc...). -- --Keith This mail message sent by GNU emacs and Linux. Food, Shelter, Source code.