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

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
> >>>>
> >>>>
> >>>>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20131002/78cdf808/attachment-0001.html>