The "do" Command

Date:    Tue, 17 Oct 1995 11:15:11 -0500
From:    "Glenn M. Picher" <gpicher@maine.com>
Subject: Re: How does one "do" ?

> So what is the advantage or the intended use of "do"?

The "do" command is actually very powerful. You can write a handler that writes new Lingo code to execute at run time. For instance, you can access different variables:

global var1, var2, var3, var4, var4a, var5, x
--these globals, since they are defined outside a specific handler,
--are visible to every handler in the same script as global variables

on fixX category additions
  if not integerP(category) then return
  put "set x to var" into dostring
  put string(category) after dostring
  if stringP(additions) then put additions after dostring
  do dostring --updates the global x based on the inputs
end

This is a relatively trivial example, and could certainly be implemeted with lists or arrays without using "do". But the technique is powerful. See the point?

One important limitation is that you can't declare new variables (whether local or global) with "do". They have to be explicitly declared in the handler (or, for globals, in the same script, outside the handler) in order to be getable or setable.

This general technique is called "self-modifying code". Another way of doing the same thing in Lingo is to set the scriptText of a cast member to a string of lines of valid Lingo (which can be created on the fly by another Lingo handler). This technique is trickier but more powerful, because you *can* declare new globals this way, and because you can get a whole script to run faster than multiple "do" commands, since Lingo is pseudo-compiled (reduced to smaller, faster command codes) when setting the scriptText. It works in projectors and protected movies as long as you don't try to build a handler based on reading the scripttext of some other cast member (the scripttext is writable but not readable, since the scripts are stripped out of projectorized/protected movies). You can store scripts to modify in text cast members, if necessary, to get around this.

> Is there a "C" equiv.?

Yes, sort of. You can write C code that writes machine language opcodes into memory, then executes the opcodes. This can be used for runtime cryptography (it's harder to crack code that never appears in the executable file), for optimizing execution speed (for instance, time-critical operations like updating palettes can be done without repeat loops, which is actually *necessary* on older VGA cards to avoid schmutz on the screen), and, most commonly, for writing viruses that hang around in memory and continue to wreak havok after the launching program quits.

This isn't really a C equivalent to "do", though, because the language you're do-ing in C is machine language, not C.