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

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
>  ; 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?

Robby