[plt-dev] new language dialog, iii

On Jan 31, Robby Findler wrote:
> On Sat, Jan 30, 2010 at 9:41 PM, Eli Barzilay <eli at barzilay.org> wrote:
> > On Jan 30, Robby Findler wrote:
> >> On Sat, Jan 30, 2010 at 6:15 PM, Eli Barzilay <eli at barzilay.org> wrote:
> >> > On Jan 30, Robby Findler wrote:
> >> >> And there are lots of other thigns that are observable if I do
> >> >> that: thread creation, possibly or who knows what. And who knows
> >> >> what strange state the user's program is in? Maybe the code
> >> >> doesn't work when some strange parameter setting is done or
> >> >> something like that.
> >> >
> >> > I still don't see your point.  There are already differences
> >> > between drscheme and mzscheme in that drscheme runs more syntax
> >> > expansions, and running the lang parser one more time sounds to me
> >> > much less noticeable than that.
> >>
> >> No, that's only because you've got the errortrace checkbox checked.
> >> You can uncheck it. That checkbox is just the same as setting up
> >> errortrace yourself in a mred program and running it there, also.
> >>
> >> But that aside, this is worse because it runs at unpredictable times
> >> (relative to the user program); DrScheme will need to get language
> >> info whenever you edit the lang line, for example.
> >
> > The bottom line is that the reader belongs in the user's context.
> 
> This is true when you're running the program, I agree. But I don't
> think that this is true when the PDE is examining the program and
> giving you feedback about it.

I don't see why not.  It should be similar to check-syntax.


> I don't see any connection between creating a second user area and
> allowing/disallowing file access. Its allowed in the first one, why
> not the second one?

If you allow it for the `#lang' stuff, then what's the point of using
a sandbox in the first place?  It will take some work to make it match
exactly what DrScheme is doing, while you already have a sandbox tool
that is exactly the user context.


> For example, imagine you had a program that started creating threads
> and killed itself after 20 threads were created. You don't want that
> program to die early just because the #lang line is being edited
> (which triggers a few extra threads to be created in the user's
> space).

Of course not -- every refresh of the data should start a new user
context.  (I thought that you meant it to be updated on each `Run'
only, and in that case a hook is better.)

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