guile-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] local-eval, local-compile, and the-environment (v3)


From: David Kastrup
Subject: Re: [PATCH] local-eval, local-compile, and the-environment (v3)
Date: Sun, 15 Jan 2012 21:36:56 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

David Kastrup <address@hidden> writes:

> In the light of local-eval evaluating a _form_ rather than a _body_
> (stupid of me to forget), and seeing the weird semantics of begin, I
> agree that an implicit (let () ...) wrapper for a single form does not
> really appear to add significant gains.  It would be marginally
> convenient and marginally confusing.
>
> So one might as well forget about it.

Except possibly for symmetry: how does plain eval handle it?

guile> (let ((x 2)) (eval '(begin (define x 4) x) (current-module)))
4
guile> x
4
guile>

Right through to the top.  And we couldn't do that in local-eval.  But
it also has no qualms just because previously evaluated forms would have
used a previous definition of x.  But that's because of top-level.  Eval
is always top-level, and define acts like set! there.

What if the-environment had been taken at top-level (basically just
carrying the information of (current-module))?  Should local-eval then
behave accordingly?  If so, could we not just fold eval and local-eval
into one function?  And one could then define
(define current-module
  (let ((top-level (the-environment)))
    (lambda () (eval '(the-environment) top-level))))
if the-environment just returns the current module when at top level?

Basically, I can accept your reasoning.  This is just putting out a bit
of brainstorming.

-- 
David Kastrup




reply via email to

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