Re: eval

[Dirk Herrmann]

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