Variable uninitialized variable values (or unexpected declarations)

[Bob Rasmussen]

David Vaughan <dvk at dvkconsult.com.au> 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