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

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
>>>>
>>>>
>>>>
>>