[plt-dev] new language dialog, iii

On Sat, Jan 30, 2010 at 6:15 PM, Eli Barzilay <eli at barzilay.org> wrote:
> On Jan 30, Robby Findler wrote:
>> On Sat, Jan 30, 2010 at 5:50 PM, Eli Barzilay <eli at barzilay.org> wrote:
>> > On Jan 30, Robby Findler wrote:
>> >>
>> >> I guess I have to implement a Scheme comment parser in drscheme now.
>> >>
>> >> Blecch. I'm going to leave it alone for a while in the hopes that
>> >> the specification gets simpler.
>> >
>> > No -- I think that I should be the one implementing that, since I
>> > should implement a proper function that does this whole thing.  But I
>> > hope that there's something quick that Matthew can expose instead of
>> > re-implementing that functionality.
>>
>> I've argued this before, but I'll say it again: why does it make sense
>> to have scheme-style comments before #lang? Isn't it supposed to be
>> for all languages? Esp. given how restrictive the text following #lang
>> is?
>
> And I agree -- see what I said earlier...  I agree that there's not
> much point in allowing scheme-style comments, but you need at least
> "#!/" and "#|...|#" so this
>
>  #!/bin/sh
>  #|
>  exec mzscheme "$0" "$@"
>  |#
>  #lang scheme
>
> still works.  In this view, the original scheme style ";" comments are
> almost not needed, but if the above are in then I worry that not
> having ";" is going to lead to some confusing surprises.
>
> "Almost" is because there were also the "string=?; exec ..."
> trampolines.  They don't work with #lang since `string=?' is the first
> token that the scheme reader will see, but breaking that seems
> redundant.
>
> Also, you could argue for some specific *new* syntax that will allow
> shell trampolines, but it seems redundant to intentionally have some
> new style -- and it also means that if you want to run a script with
> "mzscheme -r $0" then you need to use the old style trampoline.
>
> (Now that I went through that whole story, I think that I've convinced
> myself that using the complete set of sexpr comments is the right
> thing.  Even "#;"...)
>
>
>> >> > No, I don't think that a sandbox is right in this case.  The thing
>> >> > is that it might need to consult code anywhere in the filesystem,
>> >> > or do whatever it wants to do to come up with the language.  So if
>> >> > I were trying to use this in the context of some utility that uses
>> >> > a sandbox then I wouldn't use *another* sandbox to do the `#lang'
>> >> > -- instead, I'd arrange for that parsing to happen in the existing
>> >> > user sandbox.  Translating this to drscheme -- I think that it's
>> >> > best if you call this function from the user context, so it's
>> >> > subject to the usual restrictions that drscheme puts on user code.
>> >>
>> >> I can't call this from the user context (or at least I need to make
>> >> a new one). DrScheme should run your program just like running it in
>> >> mred-text (or whatever) would. It should also occasionally do extra
>> >> evaluation here and there.
>> >
>> > I don't follow why you can't run it from the user context.  The lang
>> > reader code *should* be side-effect-free, so there shouldn't be any
>> > visible changes if it's being used N times for any N.  If it's not
>> > side-effect-free, then the language is what's buggy.
>>
>> That's not an argument!
>>
>> 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.

Robby