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 <stch...@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 <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
