Re: [racket-users] Copying a namespace?

[Alex Knauth]

> On Jan 12, 2017, at 5:33 PM, Alex Knauth  wrote:
> 
> 
>> On Jan 12, 2017, at 7:43 AM, Matthew Flatt  wrote:
>> 
>> My thought is similar to Robby's: Does it work to add a fresh scope to
>> every identifier that you bind in the debug REPL and also add that
>> scope to everything evaluated in the REPL?
>> 
>> It seems like `splicing-let...` is more complex than you need, since
>> all the complexity in `splicing-let...` is making the body splice to
>> into a surrounding context that doesn't see the `splicing-let...`
>> bindings. Without that splicing goal, then it should be just an extra
>> scope.
> 
> Okay. Interestingly, this solution works great on 6.7 and HEAD, but not on 
> 6.6 and earlier. What changed?

I think I found what changed. It was your fix to one of my previous emails 
about debug-repl, which ended up being a problem with 
namespace-anchor->namespace and a "namespace has become hopeless" flag.

Alex Knauth

> Alex Knauth
> 
>> At Wed, 11 Jan 2017 18:41:01 -0500, Alex Knauth wrote:
>>> Hello,
>>> 
>>> I want to shadow instead of mutate. 
>>> 
>>> The ideal solution would be to create a new environment that extends the 
>>> old 
>>> one, so that new definitions in the new environment shadow the old 
>>> definitions 
>>> instead of mutating them.
>>> 
>>> But if that isn't feasible with the way namespaces work right now, is there 
>>> a 
>>> way to copy a namespace so that mutating the copy doesn't mutate the 
>>> original? 
>>> If there isn't, is there a way to functionally update a namespace to add 
>>> new 
>>> definitions?
>>> 
>>> I need this for my debug-repl package so I avoid mangling the namespace in 
>>> examples like this:
>>> 
 (define x 1)
 x
>>> 1 ; outside the debug-repl, x is 1
 (define (f x) (debug-repl))
 (f 2)
>>> -> x
>>> 2 ; inside the debug-repl, x is 2
>>> -> ; exit the debug-repl
 x
>>> 2 ; x should be 1, but it mangled the namespace
>>> 
>>> Is there a way to do this without mangling the original namespace?
>>> 
>>> Alex Knauth
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to racket-users+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Copying a namespace?

[Alex Knauth]

> On Jan 12, 2017, at 7:43 AM, Matthew Flatt  wrote:
> 
> My thought is similar to Robby's: Does it work to add a fresh scope to
> every identifier that you bind in the debug REPL and also add that
> scope to everything evaluated in the REPL?
> 
> It seems like `splicing-let...` is more complex than you need, since
> all the complexity in `splicing-let...` is making the body splice to
> into a surrounding context that doesn't see the `splicing-let...`
> bindings. Without that splicing goal, then it should be just an extra
> scope.

Okay. Interestingly, this solution works great on 6.7 and HEAD, but not on 6.6 
and earlier. What changed?

Alex Knauth

> At Wed, 11 Jan 2017 18:41:01 -0500, Alex Knauth wrote:
>> Hello,
>> 
>> I want to shadow instead of mutate. 
>> 
>> The ideal solution would be to create a new environment that extends the old 
>> one, so that new definitions in the new environment shadow the old 
>> definitions 
>> instead of mutating them.
>> 
>> But if that isn't feasible with the way namespaces work right now, is there 
>> a 
>> way to copy a namespace so that mutating the copy doesn't mutate the 
>> original? 
>> If there isn't, is there a way to functionally update a namespace to add new 
>> definitions?
>> 
>> I need this for my debug-repl package so I avoid mangling the namespace in 
>> examples like this:
>> 
>>> (define x 1)
>>> x
>> 1 ; outside the debug-repl, x is 1
>>> (define (f x) (debug-repl))
>>> (f 2)
>> -> x
>> 2 ; inside the debug-repl, x is 2
>> -> ; exit the debug-repl
>>> x
>> 2 ; x should be 1, but it mangled the namespace
>> 
>> Is there a way to do this without mangling the original namespace?
>> 
>> Alex Knauth
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Copying a namespace?

[Alex Knauth]

> On Jan 11, 2017, at 9:10 PM, Robby Findler  
> wrote:
> 
> On Wed, Jan 11, 2017 at 7:59 PM, Alex Knauth  wrote:
>> 
>>> On Jan 11, 2017, at 8:53 PM, Robby Findler  
>>> wrote:
>>> 
>>> That might work. It might be easier to just stick in some `let`s, tho.
>>> I'm not sure of the best way to do it (but you'll find it once you try
>>> out a few), but the general approach of putting the macro system to
>>> work seems like the right approach.
>> 
>> What do you mean by that? What do I stick `let`s around? I don't think I 
>> could do it by overriding current-eval, because I want definitions to work 
>> in the debug-repl. So what did you mean?
> 
> Well, when a debug repl is created, lets say that you know that the
> variables x, y, and z are the ones that aren't supposed to be
> top-level variables, but instead are supposed to be local variables.
> Then, you're going to do something to get input from the user (call
> `read-syntax` or something that calls `read-syntax`). Take that syntax
> object and wrap it like this:
> 
> (let-syntax ([x ...][y ...][z...]) #'that-syntax-object)
> 
> where the transformers for `x` `y` and `z` do whatever they need to
> preserve the right behavior (maybe forward set!s or maybe look in a
> separate table or whatever it is you want them to do).
> 
> Well, anyway, I'm sure you understand the idea now. If it doesn't work
> because of some constraint I don't understand about how debug-repl
> works.

I don't think that will work if that syntax object is a definition in the 
debug-repl. Would `splicing-let-syntax` do that though? Would it work for both 
definitions and expressions?

Alex Knauth

> Robby

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Copying a namespace?

[Robby Findler]

On Wed, Jan 11, 2017 at 7:59 PM, Alex Knauth  wrote:
>
>> On Jan 11, 2017, at 8:53 PM, Robby Findler  
>> wrote:
>>
>> That might work. It might be easier to just stick in some `let`s, tho.
>> I'm not sure of the best way to do it (but you'll find it once you try
>> out a few), but the general approach of putting the macro system to
>> work seems like the right approach.
>
> What do you mean by that? What do I stick `let`s around? I don't think I 
> could do it by overriding current-eval, because I want definitions to work in 
> the debug-repl. So what did you mean?

Well, when a debug repl is created, lets say that you know that the
variables x, y, and z are the ones that aren't supposed to be
top-level variables, but instead are supposed to be local variables.
Then, you're going to do something to get input from the user (call
`read-syntax` or something that calls `read-syntax`). Take that syntax
object and wrap it like this:

(let-syntax ([x ...][y ...][z...]) #'that-syntax-object)

where the transformers for `x` `y` and `z` do whatever they need to
preserve the right behavior (maybe forward set!s or maybe look in a
separate table or whatever it is you want them to do).

Well, anyway, I'm sure you understand the idea now. If it doesn't work
because of some constraint I don't understand about how debug-repl
works.

Robby

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Copying a namespace?

[Alex Knauth]

> On Jan 11, 2017, at 8:53 PM, Robby Findler  
> wrote:
> 
> That might work. It might be easier to just stick in some `let`s, tho.
> I'm not sure of the best way to do it (but you'll find it once you try
> out a few), but the general approach of putting the macro system to
> work seems like the right approach.

What do you mean by that? What do I stick `let`s around? I don't think I could 
do it by overriding current-eval, because I want definitions to work in the 
debug-repl. So what did you mean?

Alex Knauth

> Robby
> 
> On Wed, Jan 11, 2017 at 6:15 PM, Alex Knauth  wrote:
>> 
>>> On Jan 11, 2017, at 6:50 PM, Robby Findler  
>>> wrote:
>>> 
>>> Change how local variables compile at the prompt that's inside the
>>> debug repl? You should have the complete set of them, I think. Compile
>>> them into looking into a table other than the namespace.
>> 
>> Do you mean redefining #%top to look it up?
>> 
>>> Robby
>>> 
>>> 
>>> On Wed, Jan 11, 2017 at 5:41 PM, Alex Knauth  wrote:
 Hello,
 
 I want to shadow instead of mutate.
 
 The ideal solution would be to create a new environment that extends the 
 old
 one, so that new definitions in the new environment shadow the old
 definitions instead of mutating them.
 
 But if that isn't feasible with the way namespaces work right now, is there
 a way to copy a namespace so that mutating the copy doesn't mutate the
 original? If there isn't, is there a way to functionally update a namespace
 to add new definitions?
 
 I need this for my debug-repl package so I avoid mangling the namespace in
 examples like this:
 
> (define x 1)
> x
 1 ; outside the debug-repl, x is 1
> (define (f x) (debug-repl))
> (f 2)
 -> x
 2 ; inside the debug-repl, x is 2
 -> ; exit the debug-repl
> x
 2 ; x should be 1, but it mangled the namespace
 
 Is there a way to do this without mangling the original namespace?
 
 Alex Knauth
 
 --
 You received this message because you are subscribed to the Google Groups
 "Racket Users" group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to racket-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
>> 

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Copying a namespace?

[Robby Findler]

Change how local variables compile at the prompt that's inside the
debug repl? You should have the complete set of them, I think. Compile
them into looking into a table other than the namespace.

Robby


On Wed, Jan 11, 2017 at 5:41 PM, Alex Knauth  wrote:
> Hello,
>
> I want to shadow instead of mutate.
>
> The ideal solution would be to create a new environment that extends the old
> one, so that new definitions in the new environment shadow the old
> definitions instead of mutating them.
>
> But if that isn't feasible with the way namespaces work right now, is there
> a way to copy a namespace so that mutating the copy doesn't mutate the
> original? If there isn't, is there a way to functionally update a namespace
> to add new definitions?
>
> I need this for my debug-repl package so I avoid mangling the namespace in
> examples like this:
>
>> (define x 1)
>> x
> 1 ; outside the debug-repl, x is 1
>> (define (f x) (debug-repl))
>> (f 2)
> -> x
> 2 ; inside the debug-repl, x is 2
> -> ; exit the debug-repl
>> x
> 2 ; x should be 1, but it mangled the namespace
>
> Is there a way to do this without mangling the original namespace?
>
> Alex Knauth
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.