[svn:perl6-synopsis] r9725 - doc/trunk/design/syn
la...@cvs.perl.org
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.
Aaron Crane
> - $+foo environmental variable
> + $+foo contextual variable
> - ENV
> + CONTEXT
> SUPER
> COMPILING
> -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
I realise this comment is a little late, but it occurred to me on seeing
Audrey's recent blog entry mentioning this change.
The motivation for s/environmental/contextual/ is clear: avoiding a term
that's already used for something else. But, on the same grounds, I'm not
sure that "contextual" is the right term, and especially not C<is context>
-- Perl already has contexts, and this isn't one.
How about "ambient variables" instead? I believe that captures the same
sense as "environmental". It's also an adjective, which I think reads more
naturally, especially in declarations:
my $foo is context;
say CONTEXT::<$foo>;
versus
my $foo is ambient;
say AMBIENT::<$foo>;
--
Aaron Crane
Audrey Tang
在 2006/7/28 上午 7:54 時，Aaron Crane 寫到：
> The motivation for s/environmental/contextual/ is clear: avoiding a
> term
> that's already used for something else. But, on the same grounds,
> I'm not
> sure that "contextual" is the right term, and especially not C<is
> context>
> -- Perl already has contexts, and this isn't one.
The idea is that context is something you pass along in each of your
calls. If your function body is a simple call, then it does not
affect the context; the callee gets the same context as you are getting.
So one can say that "want" is really one of the contextual variables
that gets reassigned every time a function is called when a
particular type is expected.
Thanks,
Audrey