Re: Non-executed repeat loop robs variable of value/definition
Re: Non-executed repeat loop robs variable of value/definition
- Subject: Re: Non-executed repeat loop robs variable of value/definition
- From: kai <email@hidden>
- Date: Mon, 29 Aug 2005 01:51:05 +0100
On 28 Aug 2005, at 19:46, deivy petrescu wrote:
Now that you've done it, here is what ASLG has to say about it (p
255):
"You can use an existing variable as the loop variable in a Repeat
statement or
define a new one in the Repeat statement. In either case, the loop
variable is
defined outside the loop. You can change the value of the loop
variable inside..."
So technically either way you should get a value for "n".
That was my feeling, Deivy. Thanks also for your interesting
comparisons with the behaviour in Smile.
Just thinking aloud for a moment, I can appreciate the need to
distinguish between global and local variables - which is no doubt
why this won't compile at the top level of a script (and why a
similarly placed global declaration doesn't compile within a handler):
----------
set n to 1
local n
--> "Syntax Error: Can't declare n as both a local and global variable."
----------
In a sense, a repeat loop (which evidently *can* allow both) seems to
contradict this:
----------
set v to "global"
repeat with v in {"local"}
end repeat
{v's contents, my v}
--> {"local", "global"}
----------
However, I don't have a problem with any of that - nor with the fact
that, following execution of such a repeat loop, any unqualified
reference to a variable will point to the local version (which can be
pretty useful).
The gotcha for me was the "undefining" effect on the initial (global)
variable, caused by the presence of a non-executing repeat loop. OK,
so this apparently takes place at compile time - whether or not the
loop will be entered at runtime (which is obviously something the
compiler can't predetermine).
Sure, an explicit declaration can avoid the issue - although, in
situations where a loop is leapfrogged, I still can't help thinking
the behaviour somewhat counterintuitive. Given Matt's helpful
'backstage' analysis, the reasons for this are understandable - and I
don't imagine changing it would be a trivial matter, either...
So, did I just talk myself out of filing?
Almost, perhaps. But - on the basis that AppleScript often does a
fair old job of taking care of things on our behalf - not entirely. ;-)
---
kai
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden