[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,
Neil
- Re: eval, (continued)
- 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, 2001/02/11
- 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 <=
- Re: eval, Marius Vollmer, 2001/02/09
- Re: eval, Marius Vollmer, 2001/02/08
Re: eval, Neil Jerram, 2001/02/05