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.