[plt-dev] new language dialog, iii

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?

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

>> > Re packaging -- given the amount of subtleties that need to be
>> > addressed, it definitely should go in some library.  But what I
>> > don't know exactly where to put it.  Is `syntax/lang-utils' too
>> > lame?
>>
>> syntax/ seems wrong, but I don't have any good ideas.
>
> ...and `lang/utils' is bad too...

lang/something seems slightly better to me.

Robby