quoting all names, the mystery (was Re: [ANN] News Reader Stack Available)

[Alex Rice]

On Thursday, July 3, 2003, at 01:17  PM, Dar Scott wrote:

>
> On Thursday, July 3, 2003, at 12:15 PM, Alex Rice wrote:
>
>> _HyperTalk 2.2 The Book_
>>
>> Says on p. 45. "Enclosing literals in quotation marks can result in 
>> considerable time savings-- up to 20% for loops with several hundred 
>> or thousand repetitions."
>
> I think this means "--up to 20% which can be significant for loops 
> with several hundred or thousand repetitions."  The loops shouldn't 
> affect the percentage.

A loop will amplify the difference which is why I stuck it into a long 
loop.

>> In this test you are accessing a UI object. I suspect that access is 
>> going to skew things. We know accessing fields is much slower than 
>> accessing variables... maybe the same with for buttons?
>
> Uh.  I thought the question was related to UI objects.

Maybe, but I think the issue is relating the engine parsing ambiguous 
words. Here is the context of that quote

Chapter- Style Memory and Performance
Section- Use Quoted Literals Instead of Unquoted Literals

	When HyperTalk comes across an ambiguous word-- one that might be a 
literal, function call, variable, or whatever-- it must check all the 
possibilities to discover what the word really is. The first 
possibility that HyperTalk considers is that the word is a quoted 
literal; the last thing it considers is that the word is an unquoted 
literal. Enclosing literals in quotation marks can result in 
considerable time savings-- up to 20% for loops with several hundred or 
thousand repetitions.

> Here is where I see a mystery--
> Suppose I insert this line at the start of the the minimal unquoted 
> test:
>   if 0 = 1 then put "cow" into dummy
> The report at the end shows that 'get dummy' got empty.  If I put that 
> at the end, then 'get dummy' got "dummy".

So this line
if 0 = 1 then put "cow" into dummy
although it is never executed, the compiler creates a local variable 
named dummy?

> The method used seems to depend on whether a variable was created by 
> that line in compiling.  If that is the case, why aren't the times the 
> same?

I agree that's what it looks like.

> I suspect there might be some decisions that have to wait until 
> execution time related to this but don't come into play in this case.

Hmm... this is getting mind bending now :-) I hope Scott or Tuviah will 
set us straight.



Alex Rice, Software Developer
Architectural Research Consultants, Inc.
http://ARCplanning.com