Andy Wingo writes:
> Here's the thing, I think: FOO and (local-eval FOO (the-environment))
> should be equivalent.
Agreed. This is the equivalence that we should strive to achieve.
My simple patch honors this equivalence for the bindings that it
supports (which unfortunately does not yet includ
On Fri 16 Dec 2011 20:12, Mark H Weaver writes:
> So, in cases where (the-environment) is found within a macro template,
> I guess I'm still undecided about whether the captured expander
> environment should be at the point of (the-environment), or whether it
> should be at the point of the initi
On Fri 16 Dec 2011 18:44, Mark H Weaver writes:
> Andy Wingo writes:
>>> (define foo 'module-a)
>>> (define-syntax alt-environment
>>> (syntax-rules ()
>>> ((_) (the-environment
>>
>>> and then evaluate the following within module B:
>>
>>> (define foo 'module-b)
>>> (local-eval 'foo (
I wrote:
> Having thought more about this, I'm fully convinced that 'module-a
> should be the answer.
On second thought, I don't think my argument was very solid. My nephew
demanded my attention while I was working on that email, and so I rushed
it out when I should have put it aside and pondered
Andy Wingo writes:
>> (define foo 'module-a)
>> (define-syntax alt-environment
>> (syntax-rules ()
>> ((_) (the-environment
>
>> and then evaluate the following within module B:
>
>> (define foo 'module-b)
>> (local-eval 'foo (alt-environment))
>
>> What should the result be?
>
>> My gue
On 16 Dec 2011, at 16:27, Mark H Weaver wrote:
> As an interesting case, suppose that you define the following macro in
> module A:
>
> (define foo 'module-a)
> (define-syntax alt-environment
> (syntax-rules ()
>((_) (the-environment
>
> and then evaluate the following within module B:
On Fri 16 Dec 2011 16:27, Mark H Weaver writes:
> To my mind, top-level (module) variables are conceptually part of every
> lexical environment placed within that module.
Agreed.
> (define foo 'module-a)
> (define-syntax alt-environment
> (syntax-rules ()
> ((_) (the-environment
> an
Peter TB Brett writes:
> David Kastrup writes:
>
>>> * I still wouldn't be surprised if `local-eval' does the wrong thing if
>>> (current-module) is different from what it was when the associated
>>> `primitive-eval' was called.
>>
>> Before anyone even _defines_ what the "right thing" would
Peter TB Brett writes:
> David Kastrup writes:
>
>>> * I still wouldn't be surprised if `local-eval' does the wrong thing if
>>> (current-module) is different from what it was when the associated
>>> `primitive-eval' was called.
>>
>> Before anyone even _defines_ what the "right thing" would
David Kastrup writes:
>> * I still wouldn't be surprised if `local-eval' does the wrong thing if
>> (current-module) is different from what it was when the associated
>> `primitive-eval' was called.
>
> Before anyone even _defines_ what the "right thing" would be, there is
> little point in
Mark H Weaver writes:
> Here's an improved version of the preliminary evaluator-only
> implementation of `the-environment' and `local-eval'. I renamed the
> primitives to the Guile 1.8 names, fixed the expansion within
> `local-eval' to use `expand' instead of `expand-top-sequence', made the
> m
= 3
scheme@(guile-user)> (local-eval '(set! x (+ x 10)) env2)
$8 = 11
scheme@(guile-user)> (local-eval 'x env1)
$9 = 1
Mark
>From c6748349a833cd61b380259ca8b9d81d7f14128f Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Wed, 14 Dec 2011 03:12:43 -0500
Subject: [PATCH] Implement
12 matches
Mail list logo
