guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: eval


From: Marius Vollmer
Subject: Re: eval
Date: 13 Feb 2001 01:46:30 +0100
User-agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7

Neil Jerram <address@hidden> writes:

> As far as I understand R5RS, `define' should always create a binding
> in the environment in which the `define' expression is evaluated.  It
> has nothing to do with modules at all.  Then, IMO, `define-public'
> should be the same as `define' plus adding the new binding to the set
> of bindings exported from that environment.

This is what is happening, now that we have synced the module returned
by `current-module' and what the evaluator is actually using when
evaluating top-level code.  For non-toplevel code, `export' is now
illegal.

> If `define-public' wasn't mixed up with scm_current_module, there
> would be no need to restore scm_current_module after an `eval', so
> `eval' could be implemented as what we are now calling
> `primitive-eval'.

The problems are not with `define-public' which only refers to the
current module, they are with `define-module' which is changing what
module is designated as the current module.

In my view, R5RS eval can not and does not need to sensibly deal with
switching the current module, because R5RS code has no concept of a
`current module' (other than calling `eval' explicitely).

But I think that the concept of a current module makes good sense for
Guile, and the way it is implemented now is actually not a bad way.
It just needs to be done consistently.

> But this is quite different from what currently happens, so it's a big
> compatibility issue, [...]

I don't regard it to be so much different from what have now,
actually.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]