[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Eval, tail calls, (current-module), and backward compatibility
From: |
Mark H Weaver |
Subject: |
Re: Eval, tail calls, (current-module), and backward compatibility |
Date: |
Sat, 21 Jan 2012 13:28:59 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
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
- Re: Eval, tail calls, (current-module), and backward compatibility, (continued)
- Re: Eval, tail calls, (current-module), and backward compatibility, Andy Wingo, 2012/01/18
- Re: Eval, tail calls, (current-module), and backward compatibility, Mark H Weaver, 2012/01/18
- Re: Eval, tail calls, (current-module), and backward compatibility, Andy Wingo, 2012/01/18
Re: Eval, tail calls, (current-module), and backward compatibility, Ludovic Courtès, 2012/01/18
- Re: Eval, tail calls, (current-module), and backward compatibility, Andy Wingo, 2012/01/18
- Re: Eval, tail calls, (current-module), and backward compatibility, Ludovic Courtès, 2012/01/18
- Re: Eval, tail calls, (current-module), and backward compatibility, Andy Wingo, 2012/01/18
- Re: Eval, tail calls, (current-module), and backward compatibility, Ludovic Courtès, 2012/01/18
- Re: Eval, tail calls, (current-module), and backward compatibility, Andy Wingo, 2012/01/18
Re: Eval, tail calls, (current-module), and backward compatibility, David Kastrup, 2012/01/21
- Re: Eval, tail calls, (current-module), and backward compatibility,
Mark H Weaver <=
- Re: Eval, tail calls, (current-module), and backward compatibility, David Kastrup, 2012/01/21
- Re: Eval, tail calls, (current-module), and backward compatibility, Mark H Weaver, 2012/01/21
Re: Eval, tail calls, (current-module), and backward compatibility, Andy Wingo, 2012/01/23
- Prev by Date:
Re: Eval, tail calls, (current-module), and backward compatibility
- Next by Date:
Re: Eval, tail calls, (current-module), and backward compatibility
- Previous by thread:
Re: Eval, tail calls, (current-module), and backward compatibility
- Next by thread:
Re: Eval, tail calls, (current-module), and backward compatibility
- Index(es):