Changes by: Jason Hickey (jyh at cs.caltech.edu)
Date: 2006-04-14 21:14:33 -0700 (Fri, 14 Apr 2006)
Revision: 9087
Log message:
Updated a scoping issue. We had this:
public.x = 1
private.x = 2
echo $x
# Prints: 1
The problem was in Omake_ir_ast.check_var_def.
Also,
- changed the notation mutable. to export.
- export variables must _always_ include the modifier
The "auto-export" Aleksey and I have discussed is perhaps nicer,
if it were possible to indicate that existing variables can be
reclassified as auto-exports in some static scope.
This could be done, and it would replace the export variables.
However, the implementation would be fairly expensive. The cost
of leaving a scope would be linear in the number of auto-export
variables (plus some constant overhead, for adding extra export
directives).
The export. style has the same effect, but with (essentially) zero
overhead. This is because the export table is strictly statically
scoped; exports have no effect on it.
Export variables cannot escape their scope. In fact, they
simply can't escape at all. I had said that one way to create
a ref cell would be as follows.
Ref. =
export.x = 0
set(y) =
export.x = y
get() =
value $x
debug() =
set(1)
println(X is $(get))
However, the export directive is restrictive. Within the object Ref,
the variable will act the expected way, and the debug() method will
print "X is 1". The following code will result in an error.
Ref.set(1)
# x is undefined
Ref.get()
We might argue that x should revert to 0.
The summary is, the "export." variables have a strict auto-export
semantics, where their value disappears when leaving their static
scope. They are strictly temporary.
The disadvantage is minor, in that we can't auto-export existing
variables.