Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
On Thu, Oct 20, 2011 at 9:29 AM, Robby Findler wrote: > On Thu, Oct 20, 2011 at 8:25 AM, Sam Tobin-Hochstadt > wrote: >> I've certainly wanted this in the past. Ryan came up with some tricks that >> made it easier, but I think a separate REPL that basically ran >> (begin-for-syntax (print e)) would be a very nice addition. >> >> I'm also with Eli in thinking that this should be separate from online check >> syntax, unless we make the whole repl use the results of online check >> syntax. > > I don't understand your "unless". > > Just to be clear, I am imagining two different REPLs. One REPL you get > when you click "Run". One REPL you get when you click some other > button and the second REPL has the compile-time bindings of the > program in the definitions window. This sounds very nice, although I don't see why they need to be separate. We could just have a way to switch one repl back and forth (as Eli just suggested), or two tabs in the interaction window, or something else. But I would think one click of Run should be sufficient. For programs that take a while to run, I'd be frustrated having to do that multiple times. > The second RPEL may or may not be "instantly available" depending on > whether or not it is (internally) using the results of the online > expansion. I guess I don't see why online check syntax is even relevant here. This seems like a case of premature optimization, and one with semantic restrictions. In addition to the issues discussed already, there would be a bunch of things that a REPL hooked up to a separate place couldn't do. For example, syntax snips would be really important at a syntax-time REPL, and they would be tricky if not impossible in the architecture. So would writing out code to a separate file. > Eli's argument boil down to saying that there are programs that don't > work in online check syntax (and implicitly saying we should support > those programs in this new REPL). If you agree with that, then what > programs have you written that have this property? I think here's it's important to draw a distinction between two kinds of compile-time I/O. One kind is done whenever a module is visited, eg (begin-for-syntax (printf "foo")). This isn't very well handled at the moment in Racket, because how many times that happens is hard to predict. The other kind is I/O done in the course of a particular transcription step, such as `include'. That's quite well supported at the moment by Racket, and something that we shouldn't break. For examples of the second kind, here are a few I've written, used, or wanted to use: - logging to a file during expansion - opening up a macro-debugger window during expansion - Dave Herman's or Jay's C compiler libraries - Felix Klock's FFI generation tools (for Larceny, but a really nice idea that we could use) run the C compiler at expansion time - Invoking an external SAT solver for Typed Racket type checking -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
An hour and a half ago, Robby Findler wrote: > On Thu, Oct 20, 2011 at 2:08 AM, Eli Barzilay wrote: > > > > Well, at this point you're talking about an optimization that > > happens to be possible because of the on-line check syntax. But I > > still think that there is too many differences between the two > > uses which will lead to problems when you try to do things this > > way. For example: > > > > * The REPL will need to run via messages to the existing place -- > > and that will probably make it different from running the REPL > > when the online syntax check is disabled. Either that, or you > > end up using a place for the REPL even when it's disabled. > > It would not work if online check syntax were disabled. There would > be a message about it in the REPL. Unless there was some reason to > support this behavior and then we could consider having two modes > for this REPL. I can definitely say that I would be very surprised at such a decision. I see debugging syntax level code as something much more important and needed than online syntax checking. The latter is a kind of a nice bonus to have, one that I could do without at a minor cost of losing immediate reactions, but it's far less needed than a REPL (of any kind). > > * What happens with other side effects that you cannot stash away > > somewhere? Like making a network connection, a sound, or > > popping up a window? (Yes, the gui happens to not be available, > > but that's a technicality...) > > They would continue to be disallowed via security guards. You'd get > errors in the REPL. Touching files and running sub-processes was a very relevant example here. It's something that is very useful if you want to do some C compilation at the syntax level -- for example, to allow the runtime code to use it (as with Jay's C-in-Racket planet package), or to find out information from the C world (as was done with the sgl compilation that would create a C file to find out data sizes). So it looks like what you're talking about is not excluding these completely -- just making the online syntax check useless when they're used (which seems to me like a perfectly fine and even desirable choice). And in addition, you're saying that such a syntax REPL would not be usable for such code -- and *that* sounds like a major disadvantage. If anything, it's such side-effectful code needs much more REPL-style debugging support than the usual pure code where the syntax stepper is perfectly fine. > I think that this is not a big deal since most of the programs that > run at compile time don't do this. If they did, we'd have to > reconsider, of course. Even better, we might turn these > restrictions on in 'raco setup'. (That would be "better" in terms of getting everything uniform, but it's achieving that by crippling all syntax code, making perfectly fine tools invalid.) > Just to be clear, what you're saying is making a tradeoff in a > different way; getting the REPL ready slower in return for the > ability to run more programs. I don't see this as "slower" -- I see it as "giving me proper semantics to interact with since I need that to be able to debug the code". This is in contrast with the online syntax checker, which I view as "if you can, show extra information, otherwise don't -- no major harm done". > In addition to the point I made above (that I think no one cares > about these programs), I also believe that we don't support these > programs well as it is. Calls to particular transformers can happen > at unpredictable times already (like when errortrace is turned on). Yes, and that's a problem that does surprise people every once in a while, but the online syntax checker is worse since it's not only running the syntax level twice more -- it's running it N times based on interaction, and worse, it will abort it mid-way every once in a while. Actually, the fact that people do get surprised by the current thing is a good indication that such programs are used... > > Probably far enough to not be realistic... This is possibly closer: > > > > -> (define-for-syntax x 100) > > -> x > > ; reference to undefined identifier: x [,bt for context] > > -> (begin-for-syntax (read-eval-print-loop)) > > -> x > > 100 > > How do you get a module's syntax definitions into the REPL in the > first place? You just require it as usual. With a slight improvement to xrepl: Welcome to Racket v5.2.0.1. -> (module foo racket (define-for-syntax x 10) (define x 20)) -> ,enter foo 'foo> x 20 'foo> (begin-for-syntax (read-eval-print-loop)) 'foo[1]> x 10 In fact, it seems to me now that this is a good approach for implementing this -- and it also looks like there's no need to do anything drracket... Instead, just have some macro that does that, so instead of that long thing you just type something like (meta!) or something similar. (The only drr extension would be to make the prompt show where you are.) -- ((lam
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
On Thu, Oct 20, 2011 at 8:25 AM, Sam Tobin-Hochstadt wrote: > I've certainly wanted this in the past. Ryan came up with some tricks that > made it easier, but I think a separate REPL that basically ran > (begin-for-syntax (print e)) would be a very nice addition. > > I'm also with Eli in thinking that this should be separate from online check > syntax, unless we make the whole repl use the results of online check > syntax. I don't understand your "unless". Just to be clear, I am imagining two different REPLs. One REPL you get when you click "Run". One REPL you get when you click some other button and the second REPL has the compile-time bindings of the program in the definitions window. The second RPEL may or may not be "instantly available" depending on whether or not it is (internally) using the results of the online expansion. Eli's argument boil down to saying that there are programs that don't work in online check syntax (and implicitly saying we should support those programs in this new REPL). If you agree with that, then what programs have you written that have this property? Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
I've certainly wanted this in the past. Ryan came up with some tricks that made it easier, but I think a separate REPL that basically ran (begin-for-syntax (print e)) would be a very nice addition. I'm also with Eli in thinking that this should be separate from online check syntax, unless we make the whole repl use the results of online check syntax. sam th On Oct 20, 2011 9:17 AM, "Matthias Felleisen" wrote: > > On Oct 20, 2011, at 8:21 AM, Robby Findler wrote: > > > I also believe that we don't support these programs well as it is. > > I didn't program with closures until I experienced them in Scheme 84 in > 1984. > Perhaps people haven't programmed in syntax REPLs because there aren't any. > But then again, perhaps people see no need. I do start seeing a need and I > am surprised why we haven't thought of this before. Or someone has and I > can't > recall -- Matthias > > > > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
On Thu, Oct 20, 2011 at 8:16 AM, Matthias Felleisen wrote: > > On Oct 20, 2011, at 8:21 AM, Robby Findler wrote: > >> I also believe that we don't support these programs well as it is. > > I didn't program with closures until I experienced them in Scheme 84 in 1984. > Perhaps people haven't programmed in syntax REPLs because there aren't any. > But then again, perhaps people see no need. I do start seeing a need and I > am surprised why we haven't thought of this before. Or someone has and I can't > recall -- Matthias Just to clarify: my "these programs" refers to programs that, at compile time, make network connections, or call out to gcc. Are you making an argument that we should be supporting them better? (If so, then Eli is right and we should not base a syntax-time REPL on online check syntax.) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
On Oct 20, 2011, at 8:21 AM, Robby Findler wrote: > I also believe that we don't support these programs well as it is. I didn't program with closures until I experienced them in Scheme 84 in 1984. Perhaps people haven't programmed in syntax REPLs because there aren't any. But then again, perhaps people see no need. I do start seeing a need and I am surprised why we haven't thought of this before. Or someone has and I can't recall -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
On Thu, Oct 20, 2011 at 2:08 AM, Eli Barzilay wrote: > 7 hours ago, Robby Findler wrote: >> On Wed, Oct 19, 2011 at 6:56 PM, Eli Barzilay wrote: >> > >> > But this is very different from what the online check syntax is >> > doing, and the current problem of letting the output go to the >> > console still needs to be solved. (And IMO, it should be >> > discarded, still.) >> >> This would be one way to solve it. Online check syntax would just >> save up its IO (for the most recent run, anyways) and when you >> opened up this new compile-time REPL, you'd see all that IO and the >> REPL would be ready to go much more quickly than you might expect >> (since opening the REPL will amount to just sending a message over >> to the other place and asking for the IO (which would block if the >> expansion were still pending)). > > Well, at this point you're talking about an optimization that happens > to be possible because of the on-line check syntax. But I still think > that there is too many differences between the two uses which will > lead to problems when you try to do things this way. For example: > > * The REPL will need to run via messages to the existing place -- and > that will probably make it different from running the REPL when the > online syntax check is disabled. Either that, or you end up using a > place for the REPL even when it's disabled. It would not work if online check syntax were disabled. There would be a message about it in the REPL. Unless there was some reason to support this behavior and then we could consider having two modes for this REPL. > * What happens with other side effects that you cannot stash away > somewhere? Like making a network connection, a sound, or popping up > a window? (Yes, the gui happens to not be available, but that's a > technicality...) They would continue to be disallowed via security guards. You'd get errors in the REPL. I think that this is not a big deal since most of the programs that run at compile time don't do this. If they did, we'd have to reconsider, of course. Even better, we might turn these restrictions on in 'raco setup'. > * What happens when Matthias wants more stuff from that REPL, like > getting more debugging information? Running the syntax level with > debugging for the online checker doesn't make much sense, so you end > up dumping whatever you get anyway. It is actually doing that now, I believe. If the language dialog says errortrace & profiling, then the code is compiled with those things on. I'm not sure how well they work, but hey. > * And there's also a related problem that is already there: what > happens if my syntax code does something really heavy, like run the > C compiler for something, accumulating output in some log file, > delete files, etc? (Or maybe requiring some planet library, which > somehow fails and re-installs on the next update? Though I see an > access error in this case, so maybe you're running it in a sandbox > already?) > > That means that running it on almost every keystroke is very > undesirable. And trying to avoid it, perhaps like that access error > that I've seen with requiring planet code, means that syntax code > runs in a more restricted environment, which might lead to different > behavior than an actual run -- so you'll want to re-run the syntax > code anyway before you give the user a REPL, otherwise it's a "kind > of a REPL that might have problems that you won't really have when > you run the code as usual". From my perspective, this is a restatement of bullet 2 (I have the same answer, anyways). > Because of these differences, I think that it's perfectly fine to just > avoid any such side effects as much as possible, and freely abort when > the code tries to run some process, make a network connection, or pop > up a window. It's easy to explain too: the online checker does its > work unless the syntax code is trying to do these kind of side > effects, in which case it'll just give up to avoid nasty surprises. > The syntax level REPL is still useful, and of course in an > unrestricted environment (other than the usual memory limits). I think the syntax REPL would still be useful in a restricted environment. Just to be clear, what you're saying is making a tradeoff in a different way; getting the REPL ready slower in return for the ability to run more programs. In addition to the point I made above (that I think no one cares about these programs), I also believe that we don't support these programs well as it is. Calls to particular transformers can happen at unpredictable times already (like when errortrace is turned on). >> > You can fake it: >> > [...] >> > -> (define-syntax-rule (#%top-interaction . x) (begin-for-syntax x)) >> >> Interesting thought. I have no idea how close that is to what you'd >> really want, tho. Is it close? > > Probably far enough to not be realistic... This is possibly closer: > > -> (define-for-syntax x 100) > -> x > ; r
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
7 hours ago, Robby Findler wrote: > On Wed, Oct 19, 2011 at 6:56 PM, Eli Barzilay wrote: > > > > But this is very different from what the online check syntax is > > doing, and the current problem of letting the output go to the > > console still needs to be solved. (And IMO, it should be > > discarded, still.) > > This would be one way to solve it. Online check syntax would just > save up its IO (for the most recent run, anyways) and when you > opened up this new compile-time REPL, you'd see all that IO and the > REPL would be ready to go much more quickly than you might expect > (since opening the REPL will amount to just sending a message over > to the other place and asking for the IO (which would block if the > expansion were still pending)). Well, at this point you're talking about an optimization that happens to be possible because of the on-line check syntax. But I still think that there is too many differences between the two uses which will lead to problems when you try to do things this way. For example: * The REPL will need to run via messages to the existing place -- and that will probably make it different from running the REPL when the online syntax check is disabled. Either that, or you end up using a place for the REPL even when it's disabled. * What happens with other side effects that you cannot stash away somewhere? Like making a network connection, a sound, or popping up a window? (Yes, the gui happens to not be available, but that's a technicality...) * What happens when Matthias wants more stuff from that REPL, like getting more debugging information? Running the syntax level with debugging for the online checker doesn't make much sense, so you end up dumping whatever you get anyway. * And there's also a related problem that is already there: what happens if my syntax code does something really heavy, like run the C compiler for something, accumulating output in some log file, delete files, etc? (Or maybe requiring some planet library, which somehow fails and re-installs on the next update? Though I see an access error in this case, so maybe you're running it in a sandbox already?) That means that running it on almost every keystroke is very undesirable. And trying to avoid it, perhaps like that access error that I've seen with requiring planet code, means that syntax code runs in a more restricted environment, which might lead to different behavior than an actual run -- so you'll want to re-run the syntax code anyway before you give the user a REPL, otherwise it's a "kind of a REPL that might have problems that you won't really have when you run the code as usual". Because of these differences, I think that it's perfectly fine to just avoid any such side effects as much as possible, and freely abort when the code tries to run some process, make a network connection, or pop up a window. It's easy to explain too: the online checker does its work unless the syntax code is trying to do these kind of side effects, in which case it'll just give up to avoid nasty surprises. The syntax level REPL is still useful, and of course in an unrestricted environment (other than the usual memory limits). > > You can fake it: > > [...] > > -> (define-syntax-rule (#%top-interaction . x) (begin-for-syntax x)) > > Interesting thought. I have no idea how close that is to what you'd > really want, tho. Is it close? Probably far enough to not be realistic... This is possibly closer: -> (define-for-syntax x 100) -> x ; reference to undefined identifier: x [,bt for context] -> (begin-for-syntax (read-eval-print-loop)) -> x 100 -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
On Wed, Oct 19, 2011 at 6:56 PM, Eli Barzilay wrote: > An hour and a half ago, Robby Findler wrote: >> On Wed, Oct 19, 2011 at 4:47 PM, Matthias Felleisen >> wrote: >> > >> > On Oct 19, 2011, at 5:30 PM, Robby Findler wrote: >> >> >> >> I imagine it would work as by having an alternative to "run" that >> >> would just put you somehow into level 1. >> > >> > That's precisely what I imagine. >> > >> > Better still. It would be hidden all the time unless explicitly >> > opened. You could then use it to perhaps inspect what live CS >> > really 'thinks.' > > But this is very different from what the online check syntax is doing, > and the current problem of letting the output go to the console still > needs to be solved. (And IMO, it should be discarded, still.) This would be one way to solve it. Online check syntax would just save up its IO (for the most recent run, anyways) and when you opened up this new compile-time REPL, you'd see all that IO and the REPL would be ready to go much more quickly than you might expect (since opening the REPL will amount to just sending a message over to the other place and asking for the IO (which would block if the expansion were still pending)). >> Yes, that seems doable, too. Probably we're missing something like >> "module->namespace" where you can specify a phase level. Or maybe >> there is a way to do it already(?). > > You can fake it: > > -> (define-syntax foo 123) > -> (begin-for-syntax (define bar 456)) > -> foo > ; stdin:3:0: foo: illegal use of syntax in: foo [,bt for context] > -> bar > ; reference to undefined identifier: bar [,bt for context] > -> (define-syntax-rule (#%top-interaction . x) (begin-for-syntax x)) > -> foo > ; reference to undefined identifier: foo [,bt for context] > -> bar > -> (printf "bar = ~s\n" bar) > bar = 456 Interesting thought. I have no idea how close that is to what you'd really want, tho. Is it close? Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
An hour and a half ago, Robby Findler wrote: > On Wed, Oct 19, 2011 at 4:47 PM, Matthias Felleisen > wrote: > > > > On Oct 19, 2011, at 5:30 PM, Robby Findler wrote: > >> > >> I imagine it would work as by having an alternative to "run" that > >> would just put you somehow into level 1. > > > > That's precisely what I imagine. > > > > Better still. It would be hidden all the time unless explicitly > > opened. You could then use it to perhaps inspect what live CS > > really 'thinks.' But this is very different from what the online check syntax is doing, and the current problem of letting the output go to the console still needs to be solved. (And IMO, it should be discarded, still.) > Yes, that seems doable, too. Probably we're missing something like > "module->namespace" where you can specify a phase level. Or maybe > there is a way to do it already(?). You can fake it: -> (define-syntax foo 123) -> (begin-for-syntax (define bar 456)) -> foo ; stdin:3:0: foo: illegal use of syntax in: foo [,bt for context] -> bar ; reference to undefined identifier: bar [,bt for context] -> (define-syntax-rule (#%top-interaction . x) (begin-for-syntax x)) -> foo ; reference to undefined identifier: foo [,bt for context] -> bar -> (printf "bar = ~s\n" bar) bar = 456 -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
On Wed, Oct 19, 2011 at 4:47 PM, Matthias Felleisen wrote: > > On Oct 19, 2011, at 5:30 PM, Robby Findler wrote: > >> That sounds cool to me. Now that I think about it, I think we used to >> have something like this (it was a mixin tied to a specific language, >> not something that worked for all #lang languages) but it was back >> before we had the macro system to support it, I think. >> >> I imagine it would work as by having an alternative to "run" that >> would just put you somehow into level 1. > > That's precisely what I imagine. > > Better still. It would be hidden all the time unless explicitly opened. > You could then use it to perhaps inspect what live CS really 'thinks.' Yes, that seems doable, too. Probably we're missing something like "module->namespace" where you can specify a phase level. Or maybe there is a way to do it already(?). Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
On Oct 19, 2011, at 5:30 PM, Robby Findler wrote: > That sounds cool to me. Now that I think about it, I think we used to > have something like this (it was a mixin tied to a specific language, > not something that worked for all #lang languages) but it was back > before we had the macro system to support it, I think. > > I imagine it would work as by having an alternative to "run" that > would just put you somehow into level 1. That's precisely what I imagine. Better still. It would be hidden all the time unless explicitly opened. You could then use it to perhaps inspect what live CS really 'thinks.' > Probably if it is possible, it is easy. :) Possibly worth a small paper somewhere. And I am sure Ryan would/should help. > > Robby > > On Wed, Oct 19, 2011 at 4:17 PM, Matthias Felleisen > wrote: >> >> The first step would be a compile-time IO console. >> >> The second step would be a compile-time interaction mode. >> This would fit right in with Ryan's past work. It would mean >> compile the Def Window (as in CS) and make for-syntax values >> available at the repl for experimentation. Then again, I might >> have had too much coffee :-) >> >> >> >> >> On Oct 19, 2011, at 5:13 PM, Robby Findler wrote: >> >>> With a REPL? That's a lot more than I had been thinking about. I'm not >>> sure how to do it, either. >>> >>> Robby >>> >>> On Wed, Oct 19, 2011 at 4:12 PM, Matthias Felleisen >>> wrote: May I propose a compile-time interaction window in drracket? -- Matthias On Oct 19, 2011, at 5:08 PM, Robby Findler wrote: > Well, when you do IO at compile time there isn't really a good place > to put it (at least not at the moment) so instead of making a good > place to put it, I just let it go to drracket's stdout. Probably > reasonable to consider this a bug. > > Robby > > On Wed, Oct 19, 2011 at 4:06 PM, Matthias Felleisen > wrote: >> >> Yeap, I have live CS running all the time. Interesting effect. >> >> >> On Oct 19, 2011, at 5:02 PM, Robby Findler wrote: >> >>> Probably when you were running check syntax? (Or maybe when it was >>> being run for you?) >>> >>> Robby >>> >>> On Wed, Oct 19, 2011 at 4:01 PM, Matthias Felleisen >>> wrote: I am running the silly program below (no meaning), and on occasion I see the output of the *** line in the console from where I launched drracket. 5.2.0.1 from 10/16 #lang racket (require (for-syntax syntax/parse)) (define-for-syntax (postfix stx word stem) (datum->syntax stx (string->symbol (string-append word "-" (symbol->string stem) (define-syntax (define-un-serialize stx) (syntax-parse stx [(_ name:id (argument:id ...) unparser:expr parser:expr) (define serialize (postfix stx "serialize" (syntax-e #'name))) (define deserialize (postfix stx "deserialize" (syntax-e #'name))) (displayln `(,serialize ,deserialize)) ;; #`(define-values (#,serialize #,deserialize) (values (lambda (argument ...) unparser) (lambda (msg) parser)))])) (define-un-serialize f (x y) values values) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev >> >> >> >> _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
That sounds cool to me. Now that I think about it, I think we used to have something like this (it was a mixin tied to a specific language, not something that worked for all #lang languages) but it was back before we had the macro system to support it, I think. I imagine it would work as by having an alternative to "run" that would just put you somehow into level 1. Probably if it is possible, it is easy. :) Robby On Wed, Oct 19, 2011 at 4:17 PM, Matthias Felleisen wrote: > > The first step would be a compile-time IO console. > > The second step would be a compile-time interaction mode. > This would fit right in with Ryan's past work. It would mean > compile the Def Window (as in CS) and make for-syntax values > available at the repl for experimentation. Then again, I might > have had too much coffee :-) > > > > > On Oct 19, 2011, at 5:13 PM, Robby Findler wrote: > >> With a REPL? That's a lot more than I had been thinking about. I'm not >> sure how to do it, either. >> >> Robby >> >> On Wed, Oct 19, 2011 at 4:12 PM, Matthias Felleisen >> wrote: >>> >>> May I propose a compile-time interaction window in drracket? -- Matthias >>> >>> >>> >>> On Oct 19, 2011, at 5:08 PM, Robby Findler wrote: >>> Well, when you do IO at compile time there isn't really a good place to put it (at least not at the moment) so instead of making a good place to put it, I just let it go to drracket's stdout. Probably reasonable to consider this a bug. Robby On Wed, Oct 19, 2011 at 4:06 PM, Matthias Felleisen wrote: > > Yeap, I have live CS running all the time. Interesting effect. > > > On Oct 19, 2011, at 5:02 PM, Robby Findler wrote: > >> Probably when you were running check syntax? (Or maybe when it was >> being run for you?) >> >> Robby >> >> On Wed, Oct 19, 2011 at 4:01 PM, Matthias Felleisen >> wrote: >>> >>> I am running the silly program below (no meaning), and on occasion I >>> see the output of the *** line in the console from where I launched >>> drracket. 5.2.0.1 from 10/16 >>> >>> >>> #lang racket >>> >>> (require (for-syntax syntax/parse)) >>> >>> (define-for-syntax (postfix stx word stem) >>> (datum->syntax stx (string->symbol (string-append word "-" >>> (symbol->string stem) >>> >>> (define-syntax (define-un-serialize stx) >>> (syntax-parse stx >>> [(_ name:id (argument:id ...) unparser:expr parser:expr) >>> (define serialize (postfix stx "serialize" (syntax-e #'name))) >>> (define deserialize (postfix stx "deserialize" (syntax-e #'name))) >>> (displayln `(,serialize ,deserialize)) ;; >>> #`(define-values (#,serialize #,deserialize) >>> (values (lambda (argument ...) unparser) >>> (lambda (msg) parser)))])) >>> >>> (define-un-serialize f (x y) values values) >>> _ >>> For list-related administrative tasks: >>> http://lists.racket-lang.org/listinfo/dev >>> > > >>> >>> > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
A few minutes ago, Matthias Felleisen wrote: > > The first step would be a compile-time IO console. > > The second step would be a compile-time interaction mode. > This would fit right in with Ryan's past work. It would mean > compile the Def Window (as in CS) and make for-syntax values > available at the repl for experimentation. Then again, I might > have had too much coffee :-) How would that work with the online checker? Having a console that gets cleared every time I type something sounds very distracting. (And FWIW, I think that it's perfectly reasonable to discard that output and generally avoid other interactions by sandboxing the online checker...) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
The first step would be a compile-time IO console. The second step would be a compile-time interaction mode. This would fit right in with Ryan's past work. It would mean compile the Def Window (as in CS) and make for-syntax values available at the repl for experimentation. Then again, I might have had too much coffee :-) On Oct 19, 2011, at 5:13 PM, Robby Findler wrote: > With a REPL? That's a lot more than I had been thinking about. I'm not > sure how to do it, either. > > Robby > > On Wed, Oct 19, 2011 at 4:12 PM, Matthias Felleisen > wrote: >> >> May I propose a compile-time interaction window in drracket? -- Matthias >> >> >> >> On Oct 19, 2011, at 5:08 PM, Robby Findler wrote: >> >>> Well, when you do IO at compile time there isn't really a good place >>> to put it (at least not at the moment) so instead of making a good >>> place to put it, I just let it go to drracket's stdout. Probably >>> reasonable to consider this a bug. >>> >>> Robby >>> >>> On Wed, Oct 19, 2011 at 4:06 PM, Matthias Felleisen >>> wrote: Yeap, I have live CS running all the time. Interesting effect. On Oct 19, 2011, at 5:02 PM, Robby Findler wrote: > Probably when you were running check syntax? (Or maybe when it was > being run for you?) > > Robby > > On Wed, Oct 19, 2011 at 4:01 PM, Matthias Felleisen > wrote: >> >> I am running the silly program below (no meaning), and on occasion I see >> the output of the *** line in the console from where I launched >> drracket. 5.2.0.1 from 10/16 >> >> >> #lang racket >> >> (require (for-syntax syntax/parse)) >> >> (define-for-syntax (postfix stx word stem) >> (datum->syntax stx (string->symbol (string-append word "-" >> (symbol->string stem) >> >> (define-syntax (define-un-serialize stx) >> (syntax-parse stx >>[(_ name:id (argument:id ...) unparser:expr parser:expr) >> (define serialize (postfix stx "serialize" (syntax-e #'name))) >> (define deserialize (postfix stx "deserialize" (syntax-e #'name))) >> (displayln `(,serialize ,deserialize)) ;; >> #`(define-values (#,serialize #,deserialize) >> (values (lambda (argument ...) unparser) >> (lambda (msg) parser)))])) >> >> (define-un-serialize f (x y) values values) >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev >> >> >> _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
With a REPL? That's a lot more than I had been thinking about. I'm not sure how to do it, either. Robby On Wed, Oct 19, 2011 at 4:12 PM, Matthias Felleisen wrote: > > May I propose a compile-time interaction window in drracket? -- Matthias > > > > On Oct 19, 2011, at 5:08 PM, Robby Findler wrote: > >> Well, when you do IO at compile time there isn't really a good place >> to put it (at least not at the moment) so instead of making a good >> place to put it, I just let it go to drracket's stdout. Probably >> reasonable to consider this a bug. >> >> Robby >> >> On Wed, Oct 19, 2011 at 4:06 PM, Matthias Felleisen >> wrote: >>> >>> Yeap, I have live CS running all the time. Interesting effect. >>> >>> >>> On Oct 19, 2011, at 5:02 PM, Robby Findler wrote: >>> Probably when you were running check syntax? (Or maybe when it was being run for you?) Robby On Wed, Oct 19, 2011 at 4:01 PM, Matthias Felleisen wrote: > > I am running the silly program below (no meaning), and on occasion I see > the output of the *** line in the console from where I launched drracket. > 5.2.0.1 from 10/16 > > > #lang racket > > (require (for-syntax syntax/parse)) > > (define-for-syntax (postfix stx word stem) > (datum->syntax stx (string->symbol (string-append word "-" > (symbol->string stem) > > (define-syntax (define-un-serialize stx) > (syntax-parse stx > [(_ name:id (argument:id ...) unparser:expr parser:expr) > (define serialize (postfix stx "serialize" (syntax-e #'name))) > (define deserialize (postfix stx "deserialize" (syntax-e #'name))) > (displayln `(,serialize ,deserialize)) ;; > #`(define-values (#,serialize #,deserialize) > (values (lambda (argument ...) unparser) > (lambda (msg) parser)))])) > > (define-un-serialize f (x y) values values) > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > >>> >>> > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
May I propose a compile-time interaction window in drracket? -- Matthias On Oct 19, 2011, at 5:08 PM, Robby Findler wrote: > Well, when you do IO at compile time there isn't really a good place > to put it (at least not at the moment) so instead of making a good > place to put it, I just let it go to drracket's stdout. Probably > reasonable to consider this a bug. > > Robby > > On Wed, Oct 19, 2011 at 4:06 PM, Matthias Felleisen > wrote: >> >> Yeap, I have live CS running all the time. Interesting effect. >> >> >> On Oct 19, 2011, at 5:02 PM, Robby Findler wrote: >> >>> Probably when you were running check syntax? (Or maybe when it was >>> being run for you?) >>> >>> Robby >>> >>> On Wed, Oct 19, 2011 at 4:01 PM, Matthias Felleisen >>> wrote: I am running the silly program below (no meaning), and on occasion I see the output of the *** line in the console from where I launched drracket. 5.2.0.1 from 10/16 #lang racket (require (for-syntax syntax/parse)) (define-for-syntax (postfix stx word stem) (datum->syntax stx (string->symbol (string-append word "-" (symbol->string stem) (define-syntax (define-un-serialize stx) (syntax-parse stx [(_ name:id (argument:id ...) unparser:expr parser:expr) (define serialize (postfix stx "serialize" (syntax-e #'name))) (define deserialize (postfix stx "deserialize" (syntax-e #'name))) (displayln `(,serialize ,deserialize)) ;; #`(define-values (#,serialize #,deserialize) (values (lambda (argument ...) unparser) (lambda (msg) parser)))])) (define-un-serialize f (x y) values values) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev >> >> _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
Well, when you do IO at compile time there isn't really a good place to put it (at least not at the moment) so instead of making a good place to put it, I just let it go to drracket's stdout. Probably reasonable to consider this a bug. Robby On Wed, Oct 19, 2011 at 4:06 PM, Matthias Felleisen wrote: > > Yeap, I have live CS running all the time. Interesting effect. > > > On Oct 19, 2011, at 5:02 PM, Robby Findler wrote: > >> Probably when you were running check syntax? (Or maybe when it was >> being run for you?) >> >> Robby >> >> On Wed, Oct 19, 2011 at 4:01 PM, Matthias Felleisen >> wrote: >>> >>> I am running the silly program below (no meaning), and on occasion I see >>> the output of the *** line in the console from where I launched drracket. >>> 5.2.0.1 from 10/16 >>> >>> >>> #lang racket >>> >>> (require (for-syntax syntax/parse)) >>> >>> (define-for-syntax (postfix stx word stem) >>> (datum->syntax stx (string->symbol (string-append word "-" (symbol->string >>> stem) >>> >>> (define-syntax (define-un-serialize stx) >>> (syntax-parse stx >>> [(_ name:id (argument:id ...) unparser:expr parser:expr) >>> (define serialize (postfix stx "serialize" (syntax-e #'name))) >>> (define deserialize (postfix stx "deserialize" (syntax-e #'name))) >>> (displayln `(,serialize ,deserialize)) ;; >>> #`(define-values (#,serialize #,deserialize) >>> (values (lambda (argument ...) unparser) >>> (lambda (msg) parser)))])) >>> >>> (define-un-serialize f (x y) values values) >>> _ >>> For list-related administrative tasks: >>> http://lists.racket-lang.org/listinfo/dev >>> > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
Yeap, I have live CS running all the time. Interesting effect. On Oct 19, 2011, at 5:02 PM, Robby Findler wrote: > Probably when you were running check syntax? (Or maybe when it was > being run for you?) > > Robby > > On Wed, Oct 19, 2011 at 4:01 PM, Matthias Felleisen > wrote: >> >> I am running the silly program below (no meaning), and on occasion I see the >> output of the *** line in the console from where I launched drracket. >> 5.2.0.1 from 10/16 >> >> >> #lang racket >> >> (require (for-syntax syntax/parse)) >> >> (define-for-syntax (postfix stx word stem) >> (datum->syntax stx (string->symbol (string-append word "-" (symbol->string >> stem) >> >> (define-syntax (define-un-serialize stx) >> (syntax-parse stx >>[(_ name:id (argument:id ...) unparser:expr parser:expr) >> (define serialize (postfix stx "serialize" (syntax-e #'name))) >> (define deserialize (postfix stx "deserialize" (syntax-e #'name))) >> (displayln `(,serialize ,deserialize)) ;; >> #`(define-values (#,serialize #,deserialize) >> (values (lambda (argument ...) unparser) >> (lambda (msg) parser)))])) >> >> (define-un-serialize f (x y) values values) >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev >> _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
Probably when you were running check syntax? (Or maybe when it was being run for you?) Robby On Wed, Oct 19, 2011 at 4:01 PM, Matthias Felleisen wrote: > > I am running the silly program below (no meaning), and on occasion I see the > output of the *** line in the console from where I launched drracket. 5.2.0.1 > from 10/16 > > > #lang racket > > (require (for-syntax syntax/parse)) > > (define-for-syntax (postfix stx word stem) > (datum->syntax stx (string->symbol (string-append word "-" (symbol->string > stem) > > (define-syntax (define-un-serialize stx) > (syntax-parse stx > [(_ name:id (argument:id ...) unparser:expr parser:expr) > (define serialize (postfix stx "serialize" (syntax-e #'name))) > (define deserialize (postfix stx "deserialize" (syntax-e #'name))) > (displayln `(,serialize ,deserialize)) ;; > #`(define-values (#,serialize #,deserialize) > (values (lambda (argument ...) unparser) > (lambda (msg) parser)))])) > > (define-un-serialize f (x y) values values) > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
I am running the silly program below (no meaning), and on occasion I see the output of the *** line in the console from where I launched drracket. 5.2.0.1 from 10/16 #lang racket (require (for-syntax syntax/parse)) (define-for-syntax (postfix stx word stem) (datum->syntax stx (string->symbol (string-append word "-" (symbol->string stem) (define-syntax (define-un-serialize stx) (syntax-parse stx [(_ name:id (argument:id ...) unparser:expr parser:expr) (define serialize (postfix stx "serialize" (syntax-e #'name))) (define deserialize (postfix stx "deserialize" (syntax-e #'name))) (displayln `(,serialize ,deserialize)) ;; #`(define-values (#,serialize #,deserialize) (values (lambda (argument ...) unparser) (lambda (msg) parser)))])) (define-un-serialize f (x y) values values) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev