Re: Eval, tail calls, (current-module), and backward compatibility

[Mark H Weaver]

David Kastrup <address@hidden> writes:

> Mark H Weaver <address@hidden> writes:
>
>> Ideally, I think that `eval' should set (current-module) during
>> expansion, but _not_ during evaluation.  Then it can be properly tail
>> recursive.  However, some code out there might depend on the existing
>> behavior, so I guess we can't change this, at least not in 2.0.
>> Bummer.
>
> It just occured to me that the _only_ way of getting and setting
> variables under a computed name (apart from using macros) is using
> (module-set! (current-module) (compute a symbol))
> since symbol-set! apparently has been deprecated.

If you want to get or set a top-level variable with a computed name,
then you need to know which module to use.  Otherwise, how could Guile
possibly know which module you intended?

Remember, (current-module) is a compile-time concept, not a run-time
concept.  It is probably not the right choice except in something like a
REPL, and only if you specifically want the same module that's being
used to compile new top-level forms (using `primitive-eval').

It's unfortunate, but just as support for multiple string encodings
forces us now to think clearly about which encoding to use for a given
bytevector in our code (and there's really no way around this), the same
is also true of modules.  For non-computed variable references, there is
a robust automatic answer: use the module that was baked into the source
identifier before macro expansion.  However, this cannot be done for
computed variable names.

    Thanks,
      Mark