Re: [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.find...@gmail.com [mailto:robby.find...@gmail.com]On Behalf Of Robby Findler Sent: 11 August 2011 17:25 To: Sam Tobin-Hochstadt Cc: Matthew Flatt; dev@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 sa...@ccs.neu.edu wrote: On Thu, Aug 11, 2011 at 9:38 AM, Robby Findler ro...@eecs.northwestern.edu wrote: 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. 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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] pretty-big-#lang (was: External connection toFinndesign Liitin)
[switch to dev] On Thu, Aug 11, 2011 at 12:11 AM, Matthew Flatt mfl...@cs.utah.edu wrote: DrRacket's interactions window has to use `eval' in the sense that it reads an expression to evaluate and then passes it on to the program for an answer. When you run a module in DrRacket, the interactions window treats expressions as being in the language of the module body. Furthermore, since the interactions window works through `eval', it turns out that DrRacket sets `eval' globally to use the module's language while evaluating expressions in the interactions window. In Racket terminology, DrRacket sets the `current-namespace' parameter to the module's namespace when it initializes the interactions window. I think this paragraph (the rest is great!) points to the key problem. The fact that insufficiently-namespaced uses of `eval' work in the interactions window leads people to the wrong conclusion about how things work in general. Also, whereas everything else has a good reason given, this behavior is described with it turns out that and an explanation about the implementation. 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? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] pretty-big-#lang (was: External connection toFinndesign Liitin)
On Thu, Aug 11, 2011 at 8:17 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: [switch to dev] On Thu, Aug 11, 2011 at 12:11 AM, Matthew Flatt mfl...@cs.utah.edu wrote: DrRacket's interactions window has to use `eval' in the sense that it reads an expression to evaluate and then passes it on to the program for an answer. When you run a module in DrRacket, the interactions window treats expressions as being in the language of the module body. Furthermore, since the interactions window works through `eval', it turns out that DrRacket sets `eval' globally to use the module's language while evaluating expressions in the interactions window. In Racket terminology, DrRacket sets the `current-namespace' parameter to the module's namespace when it initializes the interactions window. I think this paragraph (the rest is great!) The rest is really excellent, I agree. (I even liked this part :) points to the key problem. The fact that insufficiently-namespaced uses of `eval' work in the interactions window leads people to the wrong conclusion about how things work in general. Also, whereas everything else has a good reason given, this behavior is described with it turns out that and an explanation about the implementation. 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.) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] pretty-big-#lang (was: External connection toFinndesign Liitin)
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. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] pretty-big-#lang (was: External connection toFinndesign Liitin)
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
Re: [racket-dev] [racket] pretty-big-#lang (was: External connection toFinndesign Liitin)
On Thu, Aug 11, 2011 at 9:38 AM, Robby Findler ro...@eecs.northwestern.edu wrote: 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. 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 sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] pretty-big-#lang (was: External connection toFinndesign Liitin)
On Thu, Aug 11, 2011 at 8:56 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Thu, Aug 11, 2011 at 9:38 AM, Robby Findler ro...@eecs.northwestern.edu wrote: 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. 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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
