[racket-dev] [racket] pretty-big->#lang (was: External connection toFinndesign Liitin)

On Thu, Aug 11, 2011 at 8:56 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
> 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.

If you wanted to experiment with these three variants to try to
understand which one works best, etc., that would be very welcome. (My
guess is that there are some subtle differences between these and so
I'm not sure I'd want to just pick one and stick it in without someone
trying things out for a while. There are test suites (specifically the
'repl-test.rkt' file in tests/drracket, but it probably needs more
tests that try to break things with the knowledge of which one of
these options does what.)

Robby