David Vaughan <[EMAIL PROTECTED]> wrote:
> You may have misapprehended what is happening here.
I suppose if I misapprehended anything it was thinking of "var" as having been
declared a local
variable by simply referring to it in any context whatsoever. By this thinking "var"
appears to
be an implicitly declared variable with its name as its value, as opposed to being a
literal
string that just happens to be missing some quotation marks. Given the sloppiness of
the
syntax, a little extra documentation would be helpful.
> A variable is
> "declared" in Rev (given no active declaration such as "local var")
> when you put information into it or get it out (basically).
Not "get it out", I think, or it would have been declared by "case 1" as well, and all
would
have been sublime.
Nevertheless, that's precisely the point. Nothing was put into or gotten out of "var"
by "case
2" because the statements in that case were never executed. It was the existence
alone of a
"put" statement referring to "var", not the execution of it, that was sufficient to
declare the
variable. I'm hard pressed to think of another language where the scoping rules are
so loosely
tied to execution structure. And when you combine these odd scoping rules with the
literal/variable confusion, the result is quite peculiar. Again, some extra
documentation would
help.
> If you otherwise refer to a text string then the compiler treats it as a
> literal text string until proven otherwise. Thus, your first case
> statement says "put var" where "var" is an unquoted string not already
> defined as a variable - it is the string "var". That is, it is _not_ an
> initial value of the variable var but is a literal string "var".
>
> Your second case tells the compiler to create the variable var and set
> its value to the string "whatever". When the second case is compiled
> before the first, then the variable var has already been created (and
> hence initialised to empty/zero) when your case 1 is executed. Thus,
> var is now interpreted as an empty variable (case 2 not having been
> executed yet), not a literal string, and displays accordingly.
>
> Walk through your code in the actual sequence of considering first the
> compiler's perspective and then a second time for the run-time
> perspective.
It seems to me that the compiler, in recognizing an implicit local variable, should
make its
scope the entire handler, just as it does when the variable is declared explicitly.
The
following script, for example, will not compile.
on mouseUp
put "var =" && quote & var & quote
local var
end mouseUp
Error description: local: name shadows another variable or constant
However, this script does compile.
on mouseUp
put "var =" && quote & var & quote
put "whatever" into var
end mouseUp
I guess not all declarations are created equal. In this latter example, the compiler
is
apparently willing to treat "var" as a literal in the first statement, and as a local
variable
in the second. In the first example it was not, even though that one was more
transparent in
its meaning. My mistake in thinking of "var" as always a variable was due, I think,
to hoping
the compiler was not so capricious.
I shall continue to puzzle about the rationale behind all of this. However, in self
defense I
plan from now on to "set the explicitVariables to true" (or should that now be ' ...
to "true"
'?) as an attempt to impose some order (if I can get it to work).
Thanks for your help.
RR
>
>
> Hope this clarifies things.
>
> cheers
> David
_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
