[racket-dev] [racket] pretty-big->#lang (was: External connection toFinndesign Liitin)
On Thu, Aug 11, 2011 at 9:38 AM, Robby Findler
<robby at eecs.northwestern.edu> wrote:
> On Thu, Aug 11, 2011 at 8:25 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
>> On Thu, Aug 11, 2011 at 9:20 AM, Robby Findler
>> <robby at eecs.northwestern.edu> wrote:
>>
>>>> How problematic would it be if the DrRacket interactions window didn't
>>>> make the namespace it uses for evaluation available to the expressions
>>>> being evaluated?
>>>
>>> How would that work? Could drracket compile the expression in the
>>> namespace that has the insides of the module and then, when evaluating
>>> it, set the namespace back to the one in effect while running the
>>> definitions window? (That seems a bit strange; I don't have a good
>>> idea how it would work.)
>>
>> What I was thinking was more along the lines of disconnecting the
>> value of `current-namespace' that DrRacket sees from the value that
>> the user program sees -- in other words, having that parameter not be
>> part of the underlying shared portion of Racket like `+', but more
>> like the things that DrRacket doesn't share, like its inspector. I
>> think that would require lower-level changes, though.
>
> Well, lower-level is not a complete magic wand here :). I think there
> would have to be some way to understand what you expect the
> lower-level to be doing and then, after that, figure out what level
> that fits best at.
Yes, I agree.
> Like having two versions of current-namespace: I think what you're
> saying is that drracket should do something like this:
>
> (parameterize ([current-namespace repl-namespace-with-all-the-goodies])
> (eval `(parameterize ([current-namespace
> ,the-actual-likely-empty-users-namespace])
> ,users-program)))
>
> maybe?
Yeah, that seems like a nice and simple way of doing it. Another way would be:
(parameterize ([current-eval
(let ([old (current-eval)]
[ns (current-namespace)])
(lambda (e) (parameterize ([current-namespace
ns]) (old e))))])
(eval users-program repl-namespace/goodies))
Which is basically just a version of the two-argument `eval' that
doesn't do the parameterization.
The lower-level change is, it seems, not needed, since this is already
easily expressible.
--
sam th
samth at ccs.neu.edu