Re: Scripting

[Dan Helfman <witten@torsion.org>]

On Wed, 2002-04-17 at 09:54, Chris wrote:
> > Better by far to utterly limit the power of downloaded code to play only
> > in it's sandbox.  Think JAVA - not Active-X.
> 
> Think Java speed. The sort of things I'm doing simply aren't possible in
> Java, python or any other interpreted language in a responsive time - but
> that's no reason why these techniques aren't useful for othe rpeople of
> course.

Everyone seems to be very polarized in this debate between slow
scripting languages with all kinds of safety checks and speedy compiled
languages with no checks at all. Perhaps that's because most languages
available today fall easily into one or the other of these two
categories. But what about a hypothetical language that is natively
compiled for speed, but still does some safety checks at compile-time
and possibly even at run-time. For example, in C++ style syntax, you
might have:

int array[10];
for (int i = 0; i < 10; i++) {
  array[i] = some_value;
}

Now a smart enough compiler could look at this particular code and
figure out that there cannot possibly be any array bounds violations
going on, and thus no run-time bounds checks are needed to guarantee
safety. Sure, there are many ways to modify this code to make a run-time
bounds check required for safety purposes. (Just change the literal 10
to some variable.) Also, there's Steve's example of "array[-12345] =
54321;". But for those cases the compiler can determine that a run-time
bounds check is needed, and thus would insert such a check to guarantee
safety.

Now the trick here is that the programmer would keep this behavior in
mind when developing his or her psuedo-scripts. It would be beneficial,
speed-wise, to write code that the compiler can determine is safe at
compile-time. And I think that quite a lot of code can be written in
such a manner if both the programmer and the compiler are smart enough.
Of course, some code would still require run-time safety checks, but
that would be a trade-off that the programmer would have to consider
when writing the code, much in the same way that a C++ coder today must
decide whether it's worth making a particular function virtual and
thereby taking a slight speed hit.

So the point of all this is just to suggest that maybe it's possible to
get much of the speed of a natively compiled language, without having to
forego the safety of an interpreted language, at least with certain code
that can be deemed largely safe at compile-time.

Anyway, just some stuff to think about. My proposed "solution" isn't
much of a solution at all if one is looking for a game scripting
solution today. But maybe it'll be a real solution at some point in the
future. If anyone knows of an existing natively compiled language that
does this sort of thing, I'd be very interested to hear about it.

> Chris

-- 
Dan Helfman
Torsion OS: http://torsion.org