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

I definitely agree that consistency is essential.

However, the solution makes the threshold to be able use dynamic evaluations even higher. And I find them one of the most attractice features of Scheme. Even stiching strings together and evaluate them. Again, I'm not saying that the architecture is bad, but instead the provided functions should be easier for basic users. I assume that only a handfull of people can understand what happends under the hood (a bad choice of mailing list :), whereas for most

(eval '(cons 1 2)) 

not working is very counter-intuitive. So, instead of trying to scare people away from dangers or providing various, complex work-around schemes that only advanced developers can confidently use, could there be a way to provide basic users a more intuitive yet safe method to do the obvious?

for example, a derivate from the 15.1 example

(define (obvious-eval arg)
  (define ns (make-base-namespace))
  (eval arg ns))

(obvious-eval '(cons 1 2)) >> '(1 . 2)

or the name could be base-eval?

My experience is though, that you are likely wanting to utilize all definitions from the same file and all requires. Could there be a safe way to do this? This is purely a usability point of view, obviously.

br, jukka



> -----Original Message-----
> From: robby.findler at gmail.com [mailto:robby.findler at gmail.com]On Behalf
> Of Robby Findler
> Sent: 11 August 2011 17:25
> To: Sam Tobin-Hochstadt
> Cc: Matthew Flatt; dev at racket-lang.org; Jukka Tuominen
> Subject: Re: [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
>