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

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!