[Top][All Lists]

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

Re: eval

From: Neil Jerram
Subject: Re: eval
Date: 14 Feb 2001 22:38:38 +0000

>>>>> "Marius" == Marius Vollmer <address@hidden> writes:

    Marius> Neil Jerram <address@hidden> writes:
    >> `define-module' is the immediate problem, but I still think
    >> that the problem stems from `define-public'/`export'.  I will
    >> try to explain what I mean by the following sequence of
    >> questions.

    Marius> Yes, thanks, this was very helpful.

Thanks for persisting with my attempts to explain myself!

    >> Q. But why does the concept of (current-module) need to be set
    >> up and later restored when the information that `export',
    >> `define-public' etc. need is already available in the `eval'
    >> expression's environment parameter?
    >> A. ???

    Marius> The best answer I have so far is "I don't really know for
    Marius> sure, yet, but I like it that way."

    Marius> [...]

    Marius> I think we could make that move, technically.  [...]

    Marius> On the other hand, I don't know if this isn't more magical
    Marius> than the current-module concept that we have right now.

Yes, I agree that this is questionable, given its reliance on
(the-environment) and climbing up from the lexical environment.

    Marius> I'd say that every useful use of eval will be in something
    Marius> that resembles a repl.  You will probably allow the user
    Marius> to evaluate a sequence of expressions, including module
    Marius> system operations.  In that case, you need the concept of
    Marius> a current module anyway, and you want `define-module' et
    Marius> al to interact with that in the right way.  We could
    Marius> define `define-module' to change the top-level frame of
    Marius> the evaluation environment, but how do we communicate this
    Marius> back to the custom repl so that it can invoke `eval' with
    Marius> the right environment next time?

Well, I would say that we still have the fluid (current-module), that
`define-module' should change (current-module) as it does now, and
that the REPL should do (eval <expression> (current-module)) to
evaluate each expression (with `eval' not saving and restoring).  But
this wouldn't work, at least not without additional complication, for
the subforms of a top-level `begin'.

    Marius> All in all, when writing a repl, I'd say I prefer explicit
    Marius> use of `set-current-module', `current-module', and
    Marius> `primitive-eval' over `eval'.  [...]

That's a perfectly reasonable point of view.  But the system as a
whole still strikes me as not quite beautiful enough.  (My approach is
not very beautiful either, I accept.)  I remain hopeful that we might
be able to think of something more beautiful when we design the new
module system.

    >> Does this make any sense?

    Marius> Yes, it makes a lot of sense.  I'm just not sure if I
    Marius> follow you in that it would be advantageous.  However, I'm
    Marius> trying not to be dogmatic here, of course...

Thanks for listening.  I'm happy now that I've managed to express
clearly what I was trying to say.

Best regards,


reply via email to

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