Re: eval

[Neil Jerram]

>>>>> "Dirk" == Dirk Herrmann <address@hidden> writes:

    Dirk> On 9 Feb 2001, Neil Jerram wrote:
    >> (eval/no-module-restore '(define-module (app one)) '(app two))
    >> 
    >> Either the expression has no effect, or it means that next time
    >> we do `(define-module (app two))', we will actually,
    >> automatically, be in module (app one), which would be silly.
    >> Do you see what I mean now?

    Dirk> Sorry for being dense, but I don't get it.  Maybe the
    Dirk> confusion comes from the fact that I have added an <env>
    Dirk> parameter to eval/no-module-restore, which is not necessary:

Yes - the <env> parameter is exactly what the confusion comes from.
But not because it is unnecessary, rather because it creates the
confusion described in my "Either ..." paragraph above.

    Dirk> Does the example make more sense to you if we read it that
    Dirk> way:

    Dirk>   (eval/no-module-restore '(define-module (app one)))

Yes, this is fine, sense-wise.  But it depends upon implicit
associations between `eval/no-module-restore', `define-module' and
`the-module'.

    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.

    >> - As far as I can tell, my approach [...]

    Dirk> The major point is, that it will break a lot of code.  We
    Dirk> will break a lot of code anyway if the new module system
    Dirk> will be introduced, but we want to try to break code only
    Dirk> _once_.  This means, as long as we don't install the new
    Dirk> module system, we can fix problems with the old system.  But
    Dirk> we should not perform big incompatible changes that may be
    Dirk> changed again.

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?

    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.

Also, note that we don't have to be hyper-careful about introducing a
meta command and then changing it later, since - by definition - these
meta commands can only be typed interactively in a REPL.  They are a
property of the REPL, in other words, just as the idea of the current
module is a property of the REPL.  So we don't need to know _all_ the
problems before we introduce _any_ meta commands.

In contrast, `eval-in-current-module' (or `eval/no-module-restore') is
a feature that people may start to use in their own code, and so could
create a big compatibility problem for the future.

    Dirk> I have not yet thought enough about the different wishlist
    Dirk> items and the requirements that we have for the new system.
    Dirk> I am planning to take the wishlist document, take a look at
    Dirk> each of the points and write down some comments and
    Dirk> questions.

That would be excellent!  I look forward to it.

    Dirk> Best regards, Dirk Herrmann

Best regards, and thanks for having this discussion with me,
        Neil