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 <stch...@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 <ry...@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 <stch...@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 >>>> >>>> >>>> >> _________________________ Racket Developers list: http://lists.racket-lang.org/dev
