The collection of objects that another object can "see" is called the scope of that object (by see, it is meant that some aspect of the object can be accessed, but does not assume that it can be modified). Scoping in GraalScript (as of the advent of new GraalScript) is similar to that seen in ECMAScript, that is, that a temporary variable is visible from any part of a function's body.
Serverside versus Clientside
GraalScript is divided amongst code that is run by the server (the aptly named serverside) and code that is run by the client (the also-aptly named clientside). For the most part, these two halves are distinct (and separated by the unique identifier, in that code (and its variables) on the clientside is inaccessible by code on the serverside, and vice-versa. The exceptions to this rule are serverr, clientr, client, and attribute variables. The former two exceptions are read-only on the clientside, whereas the latter are also modifiable on the clientside. In a sense, these variables have a super-global scope, and are accessible from anywhere.
Global scope in GraalScript is a sort of misnomer, in that a variable with global scope is only accessible to objects in the player's vicinity. An example might be i=0; where i has not been defined previously. This variable is now available to any weapon on the player, or any level NPC (granted that the codes accessing them are also on the same side [ie., server- or clientside] as the variable definition), and can be modified by any of them. For this reason, global variables of this type are used infrequenctly, and instead this variables and public functions are used, both of which also have global scope.
Any function that is not qualified by public is accessible only by the script to which it belongs except in the case of classes. The public keyword grants a function global scope.
A very special type of "global" scope comes in the form of public functions inherited from a class, which are accessible via namespace::function as well as by object.function. Use of the former should conform to the principle of function purity. The operator :: is called the namespace operator.
Each function in GraalScript, be it a formal function definition or an inline definition, has its own separate scope. That is, temporary variables in one function cannot be accessed from another function, regardless of where the function is defined, without accessing the callstack. This is one of the biggest differences between ECMAScript and GraalScript.
Many variables can be referenced without use of their prefix. This includes temp and this, as well as global variables and GS1-style events. The following summarizes the rank of these variables in the mapping from unprefixed to prefixed variable.