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
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
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
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
module handling more robust, and va
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:
> 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
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 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
Hi guilers,
The documentation for this in the manual is pretty sparse. Is it
possible to lift the documentation for the procedures in the source up
to the manual where people who don't read the source can find it?
As an example, the function 'find-string-from-port?' in (sxml ssax
input-parse) ha
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?
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
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
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
On Fri 16 Dec 2011 11:52, Ian Price writes:
> Hi guilers,
>
> The documentation for this in the manual is pretty sparse. Is it
> possible to lift the documentation for the procedures in the source up
> to the manual where people who don't read the source can find it?
>
> As an example, the functi
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
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
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
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:
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
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
Hello!
Nala Ginrut skribis:
> Since Guile provides flexible optional arguments handling, why we can not
> do this:
> let (execlp "ls") equal to (execlp "ls" "") if the second argument is
> unbounded?
Because it would differ from what the underlying system call allows, and
would also be an inco
l...@gnu.org (Ludovic Courtès) writes:
> Hello!
>
> Nala Ginrut skribis:
>
>> Since Guile provides flexible optional arguments handling, why we can not
>> do this:
>> let (execlp "ls") equal to (execlp "ls" "") if the second argument is
>> unbounded?
>
> Because it would differ from what the und
22 matches
Mail list logo
