Author: larry Date: Fri Jun 30 11:57:00 2006 New Revision: 9725 Modified: doc/trunk/design/syn/S02.pod doc/trunk/design/syn/S03.pod doc/trunk/design/syn/S04.pod doc/trunk/design/syn/S05.pod doc/trunk/design/syn/S06.pod
Log: Change "env" variables to "context" variables. Modified: doc/trunk/design/syn/S02.pod ============================================================================== --- doc/trunk/design/syn/S02.pod (original) +++ doc/trunk/design/syn/S02.pod Fri Jun 30 11:57:00 2006 @@ -570,7 +570,7 @@ $.foo object attribute accessor $^foo self-declared formal parameter $*foo global variable - $+foo environmental variable + $+foo contextual variable $?foo compiler hint variable $=foo pod variable $<foo> match variable, short for $/{'foo'} @@ -578,9 +578,7 @@ Most variables with twigils are implicitly declared or assumed to be declared in some other scope, and don't need a "my" or "our". -Attribute variables are declared with C<has>, though, and environment -variables are declared somewhere in the dynamic scope with the C<env> -declarator. +Attribute variables are declared with C<has>, though. =item * @@ -839,7 +837,7 @@ GLOBAL OUTER CALLER - ENV + CONTEXT SUPER COMPILING @@ -960,43 +958,48 @@ The C<CALLER> package refers to the lexical scope of the (dynamically scoped) caller. The caller's lexical scope is allowed to hide any variable except C<$_> from you. In fact, that's the default, and a -lexical variable must be declared using "C<env>" rather than C<my> to be +lexical variable must have the trait "C<is context>" to be visible via C<CALLER>. (C<$_>, C<$!> and C<$/> are always -environmental.) If the variable is not visible in the caller, it returns +contextual.) If the variable is not visible in the caller, it returns failure. -An explicit C<env> declaration is implicitly readonly. You may add -C<is rw> to allow subroutines from modifying your value. C<$_> is -C<rw> by default. In any event, your lexical scope can access the -variable as if it were an ordinary C<my>; the restriction on writing -applies only to subroutines. +Any lexical declared with the C<is context> trait is by default +considered readonly outside the current lexical scope. You may add +C<is rw> to allow called routines to modify your value. C<$_>, +C<$!> and C<$/> are C<rw> by default. In any event, your lexical +scope can always access the variable as if it were an ordinary C<my>; +the restriction on writing applies only to called subroutines. =item * -The C<ENV> pseudo-package is just like C<CALLER> except that it scans -outward through all dynamic scopes until it finds an environmental -variable of that name in that caller's lexical scope. (Use of C<$+FOO> -is equivalent to ENV::<$FOO> or $ENV::FOO.) If after scanning all -the lexical scopes of each dynamic scope, there is no variable of -that name, it looks in the C<*> package. If there is no variable in -the C<*> package, it looks in C<%*ENV> for the name, that is, in the -environment variables passed to program. If the value is not found -there, it returns failure. Note that C<$+_> is always the same as -CALLER::<$_> since all callers have a C<$_> that is automatically -considered environmental. Note also that C<ENV> and C<$+> always -skip the current scope, since you can always name the variable -directly without the C<ENV> or C<+> if it's been declared C<env> -in the current lexical scope. - -Subprocesses are passed only the global C<%*ENV> values. They do not -see any lexical variables or their values. The C<ENV> package is only -for internal overriding of environmental parameters. Change C<%*ENV> -to change what subprocesses see. [Conjecture: This might be suboptimal -in the abstract, but it would be difficult to track the current set of -environment variable names unless we actually passed around a list. -The alternative seems to be to walk the entire dynamic scope and -reconstruct %*ENV for each subprogram call, and then we only slow -down subprogram calls.] +The C<CONTEXT> pseudo-package is just like C<CALLER> except that +it scans outward through all dynamic scopes until it finds a +contextual variable of that name in that caller's lexical scope. +(Use of C<$+FOO> is equivalent to CONTEXT::<$FOO> or $CONTEXT::FOO.) +If after scanning all the lexical scopes of each dynamic scope, +there is no variable of that name, it looks in the C<*> package. +If there is no variable in the C<*> package and the variable is +a scalar, it then looks in C<%*ENV> for the identifier of the variable, +that is, in the environment variables passed to program. If the +value is not found there, it returns failure. Note that C<$+_> is +always the same as CALLER::<$_> since all callers have a C<$_> that +is automatically considered environmental. Note also that C<CONTEXT> +and C<$+> always skip the current scope, since you can always name +the variable directly without the C<CONTEXT> or C<+> if it's been +declared in the current lexical scope. + +The C<CONTEXT> package is only for internal overriding of contextual +information, modelled on how environmental variables work among +processes. Despite the fact that the C<CONTEXT> package reflects the +current process's environment variables, at least where those are not +hidden by lower-level declarations, the C<CONTEXT> package should not +be considered isomorphic to the current set of environment variables. +Subprocesses are passed only the global C<%*ENV> values. They do +not see any lexical variables or their values, unless you copy those +values into C<%*ENV> to change what subprocesses see: + + temp %*ENV{LANG} = $+LANG; # may be modifed by parent + system "greet"; =item * Modified: doc/trunk/design/syn/S03.pod ============================================================================== --- doc/trunk/design/syn/S03.pod (original) +++ doc/trunk/design/syn/S03.pod Fri Jun 30 11:57:00 2006 @@ -889,7 +889,6 @@ my $foo # ordinary lexically scoped variable our $foo # lexically scoped alias to package variable has $foo # object attribute - env $foo # environmental lexical state $foo # persistent lexical (cloned with closures) constant $foo # lexically scoped compile-time constant Modified: doc/trunk/design/syn/S04.pod ============================================================================== --- doc/trunk/design/syn/S04.pod (original) +++ doc/trunk/design/syn/S04.pod Fri Jun 30 11:57:00 2006 @@ -529,7 +529,7 @@ value thereafter. Any other use of the C<Failure> will throw its associated exception immediately. -Because the C<env> variable C<$!> contains all exceptions collected in the +Because the contextual variable C<$!> contains all exceptions collected in the current lexical scope, saying C<die $!> will throw all exceptions, whether they were handled or not. A bare C<die>/C<fail> takes C<$!> as the default argument. Modified: doc/trunk/design/syn/S05.pod ============================================================================== --- doc/trunk/design/syn/S05.pod (original) +++ doc/trunk/design/syn/S05.pod Fri Jun 30 11:57:00 2006 @@ -1340,7 +1340,7 @@ =item * A match always returns a Match object, which is also available -as C<$/>, which is an environmental lexical declared in the outer +as C<$/>, which is a contextual lexical declared in the outer subroutine that is calling the regex. (A closure lexically embedded in a regex does not redeclare C<$/>, so C<$/> always refers to the current match, not any prior submatch done within the closure). Modified: doc/trunk/design/syn/S06.pod ============================================================================== --- doc/trunk/design/syn/S06.pod (original) +++ doc/trunk/design/syn/S06.pod Fri Jun 30 11:57:00 2006 @@ -1991,7 +1991,7 @@ Hypothetical variables use the same mechanism, except that the restoring closure is called only on failure. -Note that "env" variables may be a better solution than temporized +Note that contextual variables may be a better solution than temporized globals in the face of multithreading. =head2 Wrapping @@ -2348,13 +2348,13 @@ C<< CALLER::<$varname> >> specifies the C<$varname> visible in the dynamic scope from which the current block/closure/subroutine -was called, provided that variable is declared with the "C<env>" -declarator. (Implicit lexicals such as C<$_> are automatically -assumed to be environmental.) - -C<< ENV::<$varname> >> specifies the C<$varname> visible in the -innermost dynamic scope that declares the variable with the "C<env>" -declarator. +was called, provided that variable is declared with the "C<is context>" +trait. (Implicit lexicals such as C<$_> are automatically +assumed to be contextual.) + +C<< CONTEXT::<$varname> >> specifies the C<$varname> visible in the +innermost dynamic scope that declares the variable with the "C<is context>" +trait. C<< MY::<$varname> >> specifies the lexical C<$varname> declared in the current lexical scope.