[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: eval
From: |
Dirk Herrmann |
Subject: |
Re: eval |
Date: |
Mon, 12 Feb 2001 02:22:43 +0100 (MET) |
On 10 Feb 2001, Neil Jerram wrote:
> Dirk> With the <env>
> Dirk> parameter added (which was just done as an example - I
> Dirk> actually like the version without <env> parameter better,
> Dirk> and that's the way that Marius will implement
> Dirk> 'primitive-eval') it is just an additional switch to the
> Dirk> given environment at the beginning of the evaluation,
> Dirk> nothing more.
>
> No. It specifies the environment in which the evaluation will be
> performed. This isn't a "switch" because the evaluator doesn't have
> any idea of its "current" environment. Every call to SCM_XEVAL
> requires an environment parameter.
>
> Dirk> It's a matter of interpretation: primitive-eval does not
> Dirk> 'implicitly use' the-module: It does not care about it.
>
> So how does scm_primitive_eval call SCM_XEVAL then? I thought:
>
> SCM_XEVAL (exp, scm_fluid_ref (SCM_CDR (the_module)));
>
> If I've got this wrong, then I've misunderstood Marius's proposal.
You got that right. the-module _is_ needed for the call to SCM_XEVAL.
Well, seems that I should think more before posting.
> OK. I absolutely agree with the general point, that we cannot justify
> breaking a lot of code twice. But I don't see that my approach does
> break of lot of code. The only compatibility problems that I can see
> are
>
> - the typing of `(define-module ...)' interactively at the REPL
>
> - the `(define-module (guile-user))' line that many people have in
> their .guile, which is needed because .guile is loaded into the
> (guile) module.
>
> The first is not stored code at all (except in the history file :-).
> The second can be made to work without any user code changes by
> loading .guile into the (guile-user) module.
>
> What other breakages are there to consider?
All those (define-module (my-module)) lines that are spread throughout the
different .scm files. For example, guile-core/guile-readline/readline.scm
begins with:
(define-module (ice-9 readline)
:use-module (ice-9 session)
:use-module (ice-9 regex)
:no-backtrace)
The point is, that 'load' also performs a read/eval loop and has to switch
to a different module with every call to define-module.
> Dirk> I consider meta commands as a potential solution to avoid a
> Dirk> couple of problems, but currently I am not even sure which
> Dirk> kind of problems we actually want to avoid.
>
> In my mind, the problem that we want to avoid in _this case_ is
> introducing a strange form of eval, just to support interactive module
> switching.
And module switching in general. If we don't want a strange form of eval,
we would have to define modules in a different way, for example instead of
writing
(define-module <name>)
(define foo ...)
(define bar ...)
in a file, we would need a way to enclose top level expressions that shall
be evaluated in a certain module in an expression like:
(module <name>
(define foo ...)
(define bar ...))
With such an approach, however, a lot of other questions have to be asked,
like whether (module ...) forms may nest, whether bindings outside of a
module form will be visible within the module form etc...
Alternatively, it is always possible to do
(eval '(define foo ...) (resolve-module <name>))
(eval '(define bar ...) (resolve-module <name>))
This means, that there is no _current_ module for normal code. However,
the repl would still be able to use a current module, but this would have
no influence on the rest of the system. If the system was designed this
way, we could (instead of 'current-module') use 'interactive-environment
for the repl, which is what I assume to be the intention of R5RS.
Best regards,
Dirk Herrmann
- Re: eval, (continued)
- Re: eval, Marius Vollmer, 2001/02/07
- Re: eval, Dirk Herrmann, 2001/02/07
- Re: eval, Neil Jerram, 2001/02/07
- Re: eval, Dirk Herrmann, 2001/02/09
- Re: eval, Neil Jerram, 2001/02/09
- Re: eval, Marius Vollmer, 2001/02/09
- Re: eval, Neil Jerram, 2001/02/10
- Re: eval, Dirk Herrmann, 2001/02/09
- Re: eval, Marius Vollmer, 2001/02/10
- Re: eval, Neil Jerram, 2001/02/10
- Re: eval,
Dirk Herrmann <=
- Re: eval, Neil Jerram, 2001/02/12
- Re: eval, Marius Vollmer, 2001/02/12
- Re: eval, Neil Jerram, 2001/02/13
- Re: eval, Marius Vollmer, 2001/02/13
- Re: eval, Michael Livshin, 2001/02/14
- Re: eval, Neil Jerram, 2001/02/14
- Re: eval, Marius Vollmer, 2001/02/09
- Re: eval, Marius Vollmer, 2001/02/08
Re: eval, Neil Jerram, 2001/02/05