Mark H Weaver writes:
> Ideally I'd like to allow the user to specify a precise list of
> variables to capture, and perhaps the other two variants should be
> implemented in terms of this one.
If you have to specify a precise _list_ of variables, the-environment is
pretty pointless since you can
Hi Andy and Guile developers,
As the original OP about (local-eval) getting withdrawn please accept
my thanks for the excellent work going on in these threads. I still
follow it even though I barely understand a lot of the stuff that's
being discussed.
Thanks a million, guys, and compliments of
Andy Wingo writes:
> Are you certain that it is desirable to transform it into standard
> Scheme code?
>
> The statement that the-environment acts "as if it were the expression,
> (case-lambda )" doesn't mean that you have to implement it that
> way.
Yes of course, but nonetheless it was temp
Hello,
>> If I understand correctly, Mark wants to restrict the set of variables
>> you can access to those you could access through normal Scheme code.
>> This is an issue because psyntax happens to provide a way to access
>> more variables than standard Scheme. If this is the case, I think we
>>
Let me first state that this thread is arguing at a depth where the only
contributions that remain for me to make are syllogisms without an
actual knowledge of what I am talking about.
In order not to appear ungrateful, I will do that, but there will be
little point in expecting me to be of assis
Hello,
>> Indeed, only the macro expander has enough information to generate an
>> optimal list of "reachable lexicals", i.e. lexical variables that are
>> accessible using normal symbols (as opposed to syntax objects) [more
>> on this below].
>
> Are you certain that you want to restrict the set
On Sun 18 Dec 2011 08:11, Mark H Weaver writes:
> So, it turns out that the best place to transform (the-environment) into
> standard scheme code is in the macro expander itself.
Are you certain that it is desirable to transform it into standard
Scheme code?
The statement that the-environment a
I wrote:
>> Most passes of the compiler will pretend that (the-environment) is
>> replaced by tree-il code corresponding to the following standard scheme
>> code:
>
> I should also mention that perhaps, instead of simply "pretending", it
> might make sense to actually replace (the-environment) with
On 16 Dec 2011, at 13:43, David Kastrup wrote:
>>> Here's what I currently see:
>>>
>>> scheme@(guile-user)> (local-eval #'t (primitive-eval '(let ((t 42))
>>> (or #f (the-environment)
>>> ERROR: In procedure memoize-variable-access!:
>>> ERROR: Unbound variable: t
>>>
>>> This is the correc
Hans Aberg writes:
> On 16 Dec 2011, at 11:33, Mark H Weaver wrote:
>
>> Here's what I currently see:
>>
>> scheme@(guile-user)> (local-eval #'t (primitive-eval '(let ((t 42))
>> (or #f (the-environment)
>> ERROR: In procedure memoize-variable-access!:
>> ERROR: Unbound variable: t
>>
>> Th
On 16 Dec 2011, at 11:33, Mark H Weaver wrote:
> Here's what I currently see:
>
> scheme@(guile-user)> (local-eval #'t (primitive-eval '(let ((t 42)) (or #f
> (the-environment)
> ERROR: In procedure memoize-variable-access!:
> ERROR: Unbound variable: t
>
> This is the correct behavior, no?
Hi Andy, thanks for the quick feedback. I'll respond to the rest of
your email later, but just a few quick notes for now:
> What are the meanings of these expressions:
>
> ;; Toplevel
> (local-eval '(define foo 42) (the-environment))
>
> ;; Lexical, tail context
> (local-eval '(define foo
Andy Wingo writes:
> What are the meanings of these expressions:
I found it amusing to see what my definitions using
with-current-continuation will produce here.
> ;; Toplevel
> (local-eval '(define foo 42) (the-environment))
guile> (my-eval '(define foo 42) (my-env))
guile> foo
42
> ;;
Hi Mark,
This is an interesting plan. I still have some doubts, but perhaps you
can make it work.
First, a couple of notes:
On Fri 16 Dec 2011 08:35, Mark H Weaver writes:
> (quote ) ;; simple list structure
> (quote ) ;; simple list structure
Perhaps syntax-objects can give you wh
Mark H Weaver writes:
> I wrote:
>> For now, I will describe a method that I suspect would do the right
>> thing without any new compiler interfaces, though not as efficiently or
>> robustly: Simply compile the same general-purpose dispatcher as before,
>> except replace the #f (from the first ca
I wrote:
> For now, I will describe a method that I suspect would do the right
> thing without any new compiler interfaces, though not as efficiently or
> robustly: Simply compile the same general-purpose dispatcher as before,
> except replace the #f (from the first case-lambda clause) with the
> e
I wrote:
> The would include a list of lexical variable
> names ( ...), which must exactly correspond to the closure slots of
> the `case-lambda', in order to implement `local-eval'. We _might_ also
> need to include some information about how those variables are stored,
Sorry, this paragraph sh
Hello all,
Although it has not yet been decided whether `local-eval' will be
accepted into Guile 2, I've decided to proceed with a proper
implementation that is fully integrated into the compiler.
I hope to demonstrate that this feature can be implemented easily
without creating any significant m
On 15 Dec 2011, at 18:24, David Kastrup wrote:
>>> The "delayed evaluation" thread is a bit long and confusing, so I would
>>> like to try to summarize it.
>>>
>>> Lilypond has a way to embed Lilypond code in Scheme, and Scheme code in
>>> Lilypond code. The former uses a reader macro, #{#}. Th
Hans Aberg writes:
> On 15 Dec 2011, at 11:21, Andy Wingo wrote:
>
>> The "delayed evaluation" thread is a bit long and confusing, so I would
>> like to try to summarize it.
>>
>> Lilypond has a way to embed Lilypond code in Scheme, and Scheme code in
>> Lilypond code. The former uses a reader
On 15 Dec 2011, at 11:21, Andy Wingo wrote:
> The "delayed evaluation" thread is a bit long and confusing, so I would
> like to try to summarize it.
>
> Lilypond has a way to embed Lilypond code in Scheme, and Scheme code in
> Lilypond code. The former uses a reader macro, #{#}. The latter uses
Andy Wingo writes:
> It took some time for everyone to understand the problem. In the end,
> there were four workable possibilities.
>
> 1) Keep using closures.
>
> 2) Incorporate local-eval and the-environment into Guile 2.0.
>
> 3) Have lilypond use its own evaluator or compiler.
>
> 4
22 matches
Mail list logo
