Re: The empty string and other empty strings

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13-01-12 17:39, Mark H Weaver wrote: > David Kastrup writes: > > However, my mind is not set in stone on this. Does anyone else > here agree with David? Should we defend the legitimacy of this > optimization, and ask the R7RS working group to in

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

David Kastrup writes: > (define current-module > (let ((top-level (the-environment))) > (lambda () (eval '(the-environment) top-level Some more notes about the above code (changing `eval' ==> `local-eval'): * (local-eval '(the-environment) ) is a no-op: it always returns the same en

Re: The empty string and other empty strings

Marijn writes: > On 13-01-12 17:39, Mark H Weaver wrote: >> David Kastrup writes: >> >> However, my mind is not set in stone on this. Does anyone else >> here agree with David? Should we defend the legitimacy of this >> optimization, and ask the R7RS working group to include explicit >> langu

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

I wrote: > * Also note that the real `current-module' simply accesses a fluid, > which can also be set by `set-current-module'. (Fluids are a scheme > analogue to "dynamically-scoped" variables in Lisp). Conceptually, it > is variable that is explicitly set by the user. It has no relation

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

Mark H Weaver writes: > David Kastrup writes: > >> (define current-module >> (let ((top-level (the-environment))) >> (lambda () (eval '(the-environment) top-level > > Some more notes about the above code (changing `eval' ==> `local-eval'): > > * (local-eval '(the-environment) ) is a no

Re: local-eval on syntax-local-binding, bound-identifiers

Hi Mark, Thanks for the review! My summary comments are at the bottom. On Mon 16 Jan 2012 04:30, Mark H Weaver writes: > [... skipped the first patch, which looks very well implemented, though > I'm still not sure that we should be exposing this in our API ...] Yeah, not sure what to do

Re: local-eval on syntax-local-binding, bound-identifiers

Hi Andy! Andy Wingo writes: >>> + (cons (wrap (car symnames) >>> + (anti-mark (make-wrap (car marks) subst)) >> >> * Why are you adding anti-marks here? > > As the changelog noted (and a comment should have noted ;), the > identifiers are an

Re: local-eval on syntax-local-binding, bound-identifiers

Hi Mark, Thanks for the comments :) On Mon 16 Jan 2012 14:28, Mark H Weaver writes: > Andy Wingo writes: + (cons (wrap (car symnames) + (anti-mark (make-wrap (car marks) subst)) >>> >>> * Why are you adding anti-marks here? >> >

bound identifiers

why are these two not equal in the sense of bound-identifier=? #(syntax-object x ((top) #(ribcage () () ()) #(ribcage () () ()) #(ribcage #(x) #((m1104 top)) #("i1105"))) (hygiene guile-user)) #(syntax-object x ((#f top) shift #(ribcage () () ()) #(ribcage #(x) #((m1104 top)) #("i1105"))) (hygiene

Re: Throw without catch before boot:

Mark H Weaver writes: > David Kastrup writes: >> Well, deciding to use my guile checkout not just for reference, I tried >> ./autogen.sh, ./configure and make on master. > > For now, it's best to stay on the "stable-2.0" branch. > That's our current focus. I see. CCLD guile ./.libs/libguil

Re: local-eval on syntax-local-binding, bound-identifiers

Hi Andy! Thanks again for working on this. Andy Wingo writes: * Why are you adding anti-marks here? >>> >>> As the changelog noted (and a comment should have noted ;), the >>> identifiers are anti-marked so that syntax transformers can introduce >>> them, as-is. >>> >>> The purpose of t

Re: bound identifiers

On Mon 16 Jan 2012 20:46, Stefan Israelsson Tampe writes: > why are these two not equal in the sense of bound-identifier=? > > #(syntax-object x ((top) #(ribcage () () ()) #(ribcage () () ()) #(ribcage > #(x) #((m1104 top)) #("i1105"))) (hygiene guile-user)) > #(syntax-object x ((#f top) shift

Re: bound identifiers

In syntax parse the racket code stores syntax values inside structs and then transport them down the macro chain as argument to macros. Then when unpacking the struct they are compared with arguments of syntax values. I think that this is the reason. I tried to experiment with psyntax macro expande

Re: bound identifiers

On Mon 16 Jan 2012 22:28, Andy Wingo writes: > On Mon 16 Jan 2012 20:46, Stefan Israelsson Tampe > writes: > >> why are these two not equal in the sense of bound-identifier=? >> > But that's not the right question or answer. Can you should where these > identifiers come from? Sorry, I've been

Re: local-eval on syntax-local-binding, bound-identifiers

Hi Mark, On Mon 16 Jan 2012 21:36, Mark H Weaver writes: > Thanks again for working on this. And thank you again for all your work, and patience with my pigheadedness. > if you insist in this foolish quest to banish `the-environment' to > sleep in the shed as a second-class citizen, I cannot s

Re: bound identifiers

On Mon 16 Jan 2012 22:56, Stefan Israelsson Tampe writes: > As you see, it's just wild west to get the racket code working. :) Can you give a stripped-down test case for this particular behavior? That code is paged into my and Mark's minds right now :) Andy -- http://wingolog.org/

Eval, tail calls, (current-module), and backward compatibility

Hello all, There's a problem with Guile's `eval'. It doesn't do proper tail recursion as mandated by R5RS et al, and unfortunately we can't fix this without changing its behavior in a potentially incompatible way. The problem is that `eval' uses dynamic-wind to temporarily set (current-module) d