On Thu, Oct 20, 2011 at 9:29 AM, Robby Findler <ro...@eecs.northwestern.edu> wrote: > On Thu, Oct 20, 2011 at 8:25 AM, Sam Tobin-Hochstadt <sa...@ccs.neu.edu> > 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
