[plt-dev] new language dialog, iii

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.


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

That seem pretty bad (in terms of dependencies and distribution) as
long as it has its current role.

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