On Thu, Aug 11, 2011 at 8:25 AM, Sam Tobin-Hochstadt <sa...@ccs.neu.edu> wrote:
> On Thu, Aug 11, 2011 at 9:20 AM, Robby Findler
> <ro...@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.
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?
Robby
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
