[plt-dev] new language dialog, iii

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.

> Pushing it to some new sandbox is not going to make things right: it
> will be difficult to do, it will make language readers very restricted
> (for example, they won't be able to consult random files), and the
> reader would *still* need to be completely side-effect-free.  For
> example of the last point, if the reader consults some external
> resource to decide on some unique id, then it will make two decisions
> for the two cases.

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?

No, my point is that the user area created for running the program
should only be running the program.

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).

> If you really want to avoid running it twice, and if you want it to
> run in the user context (which IMO is a requirement), then the only
> other way I can think of is setting up some event listener --
> something like a parameter that holds a function that will be invoked
> as soon as the language is parsed.  DrScheme could then hook on to
> that and display the text with the exact information.

Something like that would be fine for figuring out the "Language:
<what goes here?>" line in the interactions window, but won't work
well when figuring out the tabbing mode or the syntax coloring mode,
etc, sine the program is not even run to figure that out.

Robby