[racket-dev] patch for make-base-eval

I'm concerned about this:

+                    [sandbox-namespace-specs
+                     (cons (λ () (namespace-anchor->namespace anchor))

It seems like this would cause all evaluators to share a single 
namespace, if I'm reading the docs right. (That would be a good test to 
add.) Why not just

   [sandbox-namespace-specs
    (append (sandbox-namespace-specs)
            (if ___))]

instead?

Ryan



On 10/03/2013 02:09 PM, Stephen Chang wrote:
> Here's another attempt at a patch. Would someone mind code reviewing it?
>
> Ryan pointed me towards sandbox-namespace-specs and it seems to do the
> trick. I also added some tests and the docs seem to compile ok.
>
> On Wed, Oct 2, 2013 at 7:21 PM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
>> namespace-attach-module sets up shared state between two modules so that, in
>> this case, the racket/pretty in one namespace is the same as the
>> racket/pretty in the other.
>>
>> Try putting a printf in the top-level of racket/pretty (and in various other
>> places in that code as it does what it does) and then doing the
>> dynamic-require with and without the attach.
>>
>> Robby
>>
>>
>> On Wed, Oct 2, 2013 at 4:58 PM, Stephen Chang <stchang at ccs.neu.edu> wrote:
>>>
>>> Ok here's another dumb question. Why is that namespace-attach-module
>>> even needed? It seems the dynamic require on the next line does the
>>> desired thing?
>>>
>>> On Wed, Oct 2, 2013 at 4:16 PM, Stephen Chang <stchang at ccs.neu.edu> wrote:
>>>> Ok thanks for the explanations. I'll try doing one of the last two
>>>> suggestions.
>>>>
>>>> On Wed, Oct 2, 2013 at 4:09 PM, Ryan Culpepper <ryanc at ccs.neu.edu>
>>>> wrote:
>>>>> No, the 'racket/pretty' module might be declared even if the symbol
>>>>> isn't
>>>>> defined (or "mapped") in the namespace:
>>>>>
>>>>>    > (define ns (make-base-namespace))
>>>>>    > (define repl-ns (current-namespace))
>>>>>    > (parameterize ((current-namespace ns))
>>>>>        (eval '(require (only-in racket/pretty))))
>>>>>    > (parameterize ((current-namespace ns))
>>>>>        (namespace-attach-module repl-ns 'racket/pretty))
>>>>>    namespace-attach-module: a different module with the same name is
>>>>>    already in the destination namespace
>>>>>      module name: "/opt/racket-5.3.6/collects/racket/pretty.rkt"
>>>>>      context...:
>>>>>       /opt/racket-5.3.6/collects/racket/private/misc.rkt:87:7
>>>>>
>>>>> And the symbol can be defined in the namespace even if the module is
>>>>> not
>>>>> declared:
>>>>>
>>>>>    > (define ns (make-base-namespace))
>>>>>    > (define repl-ns (current-namespace))
>>>>>    > (parameterize ((current-namespace ns))
>>>>>        (eval '(define pretty-print-handler #t)))
>>>>>    > (parameterize ((current-namespace ns))
>>>>>        (namespace-variable-value 'pretty-print-handler))
>>>>>    #t
>>>>>    ;; but racket/pretty is not declared,
>>>>>    ;; and #t is not a good print handler
>>>>>
>>>>> Ryan
>>>>>
>>>>>
>>>>>
>>>>> On 10/02/2013 03:58 PM, Stephen Chang wrote:
>>>>>>>
>>>>>>> A namespace is a mapping from top-level identifiers to whatever they
>>>>>>> are,
>>>>>>> as
>>>>>>> well as a separate mapping from module names to modules (roughly).
>>>>>>> What
>>>>>>> you
>>>>>>> care about here is the second mapping, but you're checking the first
>>>>>>> with
>>>>>>> the patch.
>>>>>>
>>>>>>
>>>>>> Thanks for the explanation. That helps a lot. So the danger with my
>>>>>> check is when someone has another definition of pretty-print handler
>>>>>> but racket/pretty has not been attached?
>>>>>>
>>>>>> But given the context, ie the dynamic require on the next line, it
>>>>>> seems like there's already an assumption about what the identifier I'm
>>>>>> checking is, so in this specific situation, isnt my check sufficient?
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Robby
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Oct 2, 2013 at 2:45 PM, Stephen Chang <stchang at ccs.neu.edu>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Whether that identifier exists in the namespace has nothing to do
>>>>>>>>> with
>>>>>>>>> whether racket/pretty can be attached.
>>>>>>>>
>>>>>>>>
>>>>>>>> Can you explain this a little more because it's a little unintuitive
>>>>>>>> to
>>>>>>>> me?
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> One option would be for install-pretty-printer! to just catch and
>>>>>>>>> discard
>>>>>>>>> the error. Evaluators for some languages would mysteriously not
>>>>>>>>> have
>>>>>>>>> pretty-printing turned on by default.
>>>>>>>>>
>>>>>>>>> Another option would be to attach racket/pretty before requiring
>>>>>>>>> the
>>>>>>>>> initial
>>>>>>>>> language for the namespace.
>>>>>>>>>
>>>>>>>>> Another option is use #:pretty-print? #f when attaching
>>>>>>>>> racket/pretty
>>>>>>>>> would
>>>>>>>>> fail.
>>>>>>>>>
>>>>>>>>> Ryan
>>>>>>>>>
>>>>>>>> _________________________
>>>>>>>>     Racket Developers list:
>>>>>>>>     http://lists.racket-lang.org/dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>
>>