[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 <eli at barzilay.org> 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!