At 2:38 PM -0800 on 11/29/99, Alain Farmer wrote:
>> Alain: We would indeed lose the bypass-the-hierarchy
>> feature of HyperTalk functions called with the
>> "the" keyword. Couldn't the scripter merely "send"
>the
>> message to HyperCard explicitly when the bypass
>> feature is deemed necessary?
>
>Anthony: No. Send is an evil command (just like 'do'),
>IMO. It's evil because it can't be parsed, tokenized,
>bytecoded, or assembled with the rest of the script.
>Each time a send or a do is encountered, it must be
>parsed, then bytecoded, then compiled, and only then
>run.
>
>Alain: Is this an incontrovertible principle or merely
>a limitation of our current approach? Your answer is
>very important to me because I am in the process of
>inventing an agent-based architecture where SEND is
>used very very frequently.
In general, there is no way to precompile these:
send ("handler" & myVariable) to whatever
do (variable)
Why? Because they depend upon the value of 'variable'.
There are two approaches to handle this. The first can be used solely, or
both can be used. You can't just use the second:
1) Postpone interpretation of the send and do commands until runtime
2) Run a complete variable usage analysis attempting to discover
what the contents of 'variable' will be when run. If this succeeds,
parse with the rest of it. Otherwise, see #1.
#2 is part of an optimizer. I believe the name of this little trick is
known as constant propogation or something like that. Optimizers are a very
good thing for compiled code. But for on-the-fly interpretation, probably
not -- they can take anywhere from minutes to hours to run, depending on
code size and complexity and computer speed.
Note that a special exception could be made for things like 'send domenu
quit to hypercard' because they don't rely on a variable, and I might be
willing to do this in interpreter.
>Anthony: Perhaps:
>HyperCard's abs of <expr>
>
>Alain: I like yours better. I would merely add that
>the "HyperCard's" keyword is optional, like this :
>
>[HyperCard's] abs of <expr>
>
>1. abs of <expr> -- traverses the hierarchy
>2. HyperCard's abs of <expr> -- does not traverse
>
>Alain: That what you meant, right?
Yes. I guess there are some problems with informal syntax proposal :)
