Author: lwall
Date: 2009-11-20 07:12:28 +0100 (Fri, 20 Nov 2009)
New Revision: 29142
Modified:
docs/Perl6/Spec/S02-bits.pod
docs/Perl6/Spec/S03-operators.pod
docs/Perl6/Spec/S04-control.pod
docs/Perl6/Spec/S05-regex.pod
docs/Perl6/Spec/S06-routines.pod
docs/Perl6/Spec/S10-packages.pod
docs/Perl6/Spec/S11-modules.pod
docs/Perl6/Spec/S16-io.pod
docs/Perl6/Spec/S17-concurrency.pod
docs/Perl6/Spec/S19-commandline.pod
docs/Perl6/Spec/S28-special-names.pod
docs/Perl6/Spec/S29-functions.pod
docs/Perl6/Spec/S32-setting-library/IO.pod
Log:
[Spec] slaughter various confusing overloadings of the term 'context'
contextual variables are now dynamic variables
specific dynamic contexts are now just call frames
(for now we've left alone 'context' used as in 'context switching')
Modified: docs/Perl6/Spec/S02-bits.pod
===================================================================
--- docs/Perl6/Spec/S02-bits.pod 2009-11-20 04:34:57 UTC (rev 29141)
+++ docs/Perl6/Spec/S02-bits.pod 2009-11-20 06:12:28 UTC (rev 29142)
@@ -13,8 +13,8 @@
Created: 10 Aug 2004
- Last Modified: 18 Nov 2009
- Version: 190
+ Last Modified: 19 Nov 2009
+ Version: 191
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -996,7 +996,7 @@
(However, C<@array[**]> means the same thing because (as with C<...>
above), the subscript operator will interpret bare C<**> as meaning
all the subscripts, not the list of dimension sizes. The meaning of
-C<Whatever> is always controlled by its immediate context.)
+C<Whatever> is always controlled by the first context it is bound into.)
Other uses for C<*> and C<**> will doubtless suggest themselves
over time. These can be given meaning via the MMD system, if not
@@ -1640,7 +1640,7 @@
$.foo object attribute public accessor
$^foo self-declared formal positional parameter
$:foo self-declared formal named parameter
- $*foo contextualizable global variable
+ $*foo dynamically overridable global variable
$?foo compiler hint variable
$=foo Pod variable
$<foo> match variable, short for $/{'foo'}
@@ -1740,9 +1740,7 @@
force context, so these also work:
@x[$(g())] # item context for g()
- @x[$ g()] # item context for g()
%x{$(g())} # item context for g()
- %x{$ g()} # item context for g()
But note that these don't do the same thing:
@@ -1779,17 +1777,26 @@
into a C<Capture> with 3 positionals and one named argument
in preparation for binding.
-=item *
+A parcel may be captured into an object with backslashed parens:
-An argument list may be captured into an object with backslashed parens:
-
$args = \(1,2,3,:mice<blind>)
-Values in a C<Capture> object are parsed as ordinary expressions, then marked
as
-positional or named. If the first positional is followed by a colon instead of
-a comma, it is marked as the invocant in case it finds itself in a context
-that cares.
+Values in the C<Parcel> object are parsed as ordinary expressions,
+and any functions mentioned are called, with their results placed
+as a single subparcel within the outer parcel. Whether they
+are subsequently flattened will depend on the eventual binding.
+=item *
+
+If a C<Parcel> is used as a list of arguments, it will be transformed
+into a C<Capture> objects, which is much like a C<Parcel> but has its
+arguments divvied up into positional and named subsets for faster
+binding. (Usually this transformation happens at compile time.)
+If the first positional is followed by a colon instead of a comma,
+it is marked as the invocant in case it finds itself in a context
+that cares. It's illegal to use the colon in place of the comma
+anywhere except after the first argument.
+
Like C<List> objects, C<Capture> objects are immutable in the abstract, but
evaluate their arguments lazily. Before everything inside a C<Capture> is
fully evaluated (which happens at compile time when all the arguments are
@@ -1816,7 +1823,7 @@
to operate on the current match object; similarly C<@()> and C<%()> can
extract positional and named submatches.
-C<Capture> objects fill the ecological niche of references in Perl 6.
+C<Parcel> and C<Capture> objects fill the ecological niche of references in
Perl 6.
You can think of them as "fat" references, that is, references that
can capture not only the current identity of a single object, but
also the relative identities of several related objects. Conversely,
@@ -2030,13 +2037,13 @@
print $( foo() ) # foo called in item context
print @@( foo() ) # foo called in slice context
-In declarative contexts bare sigils may be used as placeholders for
+In declarative constructs bare sigils may be used as placeholders for
anonymous variables:
my ($a, $, $c) = 1..3;
print unless (state $)++;
-Outside of declarative contexts you may use C<*> for a placeholder:
+Outside of declarative constructs you may use C<*> for a placeholder:
($a, *, $c) = 1..3;
@@ -2139,7 +2146,7 @@
The C<GLOBAL> package itself is accessible via C<UNIT::GLOBAL>.
The C<PROCESS> package is accessible via C<UNIT::PROCESS>.
The C<PROCESS> package is not the parent of C<GLOBAL>. However, searching
-up the dynamic stack for context variables will look in all nested
+up the dynamic stack for dynamic variables will look in all nested
dynamic scopes (mapped automatically to each call's lexical scope,
not package scope) out to the main dynamic scope; once all the dynamic scopes
are
exhausted, it also looks in the C<GLOBAL> package and then in the
@@ -2173,10 +2180,10 @@
re-examine the unit with the new type constraints to see if any issues are
certain to arise at run time, in which case the compiler is free to complain.)
-Any context variable declared with C<our> in the user's main program
+Any dynamic variable declared with C<our> in the user's main program
(specifically, the part compiled with C<GLOBAL> as the current package)
-is accessible (by virtue of being in C<GLOBAL>) as a context variable
-even if not directly in the dynamic call chain. Note that context
+is accessible (by virtue of being in C<GLOBAL>) as a dynamic variable
+even if not directly in the dynamic call chain. Note that dynamic
vars do *not* look in C<CORE> for anything. (They I<might> look in
C<SETTING> if you're running under a setting distinct from C<CORE>,
if that setting defines a dynamic scope outside your main program,
@@ -2304,19 +2311,19 @@
The C<CALLER> package refers to the lexical scope of the (dynamically
scoped) caller. The caller's lexical scope is allowed to hide any
user-defined variable from you. In fact, that's the default, and a
-lexical variable must have the trait "C<is context>" to be
+lexical variable must have the trait "C<is dynamic>" to be
visible via C<CALLER>. (C<$_>, C<$!> and C<$/> are always
-contextual, as are any variables whose declared names contain a C<*> twigil.)
+dynamic, as are any variables whose declared names contain a C<*> twigil.)
If the variable is not visible in the caller, it returns
failure. Variables whose names are visible at the point of the call but that
come from outside that lexical scope are controlled by the scope
-in which they were originally declared as contextual.
+in which they were originally declared as dynamic.
Hence the visibility of C<< CALLER::<$*foo> >> is determined where
C<$*foo> is actually declared, not by the caller's scope (unless that's where
it happens to be declared). Likewise C<< CALLER::CALLER::<$x> >>
depends only on the declaration of C<$x> visible in your caller's caller.
-User-defined contextual variables should generally be initialized with
+User-defined dynamic variables should generally be initialized with
C<::=> unless it is necessary for variable to be modified. (Marking
dynamic variables as readonly is very helpful in terms of sharing
the same value among competing threads, since a readonly variable
@@ -2326,8 +2333,8 @@
The C<DYNAMIC> pseudo-package is just like C<CALLER> except that
it starts in the current dynamic scope and from there scans outward
-through all dynamic scopes until it finds a contextual variable of that
-name in that dynamic context's associated lexical pad. (This search
+through all dynamic scopes (frames) until it finds a dynamic variable of that
+name in that dynamic frame's associated lexical pad. (This search
is implied for variables with the C<*> twigil; hence C<$*FOO> is
equivalent to C<< DYNAMIC::<$*FOO> >>.) If, after scanning outward
through all those dynamic scopes, there is no variable of that name
@@ -2335,22 +2342,22 @@
out of the name and looks in the C<GLOBAL> package followed by the
C<PROCESS> package. If the value is not found, it returns failure.
-Unlike C<CALLER>, C<DYNAMIC> will see a contextual variable that is
+Unlike C<CALLER>, C<DYNAMIC> will see a dynamic variable that is
declared in the current scope, since it starts search 0 scopes up the
stack rather than 1. You may, however, use C<< CALLER::<$*foo> >>
-to bypass a contextual definition of C<$*foo> in your current context,
-such as to initialize it with the outer contextual value:
+to bypass a dynamic definition of C<$*foo> in your current scope,
+such as to initialize it with the outer dynamic value:
my $*foo ::= CALLER::<$*foo>;
The C<temp> declarator may be used (without an initializer) on a
-contextual variable to perform a similar operation:
+dynamic variable to perform a similar operation:
temp $*foo;
The main difference is that by default it initializes the new
C<$*foo> with its current value, rather than the caller's value.
-Also, it is allowed only on read/write contextual variables, since
+Also, it is allowed only on read/write dynamic variables, since
the only reason to make a copy of the outer value would be
because you'd want to override it later and then forget the
changes at the end of the current dynamic scope.
@@ -2401,12 +2408,12 @@
C<PROCESS> namespace holds variables that properly belong to the actual
process as a whole. From the viewpoint of the program
there is little difference as long as all global variables are accessed
-as if they were context variables (by using the C<*> twigil).
+as if they were dynamic variables (by using the C<*> twigil).
The process as a whole may place restrictions on the
mutability of process variables as seen by the individual subprocesses.
Also, individual subprocesses may not create new process variables.
If the process wishes to grant subprocesses the ability to communicate
-via the C<PROCESS> namespace, it must supply a writeable context variable
+via the C<PROCESS> namespace, it must supply a writeable dynamic variable
to all the subprocesses granted that privilege.
=item *
@@ -2504,9 +2511,9 @@
talk about these compiler-dynamic values using the C<COMPILING> pseudopackage.
References to C<COMPILING> variables are automatically hoisted into the
-context currently being compiled. Setting or temporizing a C<COMPILING>
+lexical scope currently being compiled. Setting or temporizing a C<COMPILING>
variable sets or temporizes the incipient C<$?> variable in the
-surrounding lexical context that is being compiled. If nothing in
+surrounding lexical scope that is being compiled. If nothing in
the context is being compiled, an exception is thrown.
$?FOO // say "undefined"; # probably says undefined
@@ -2525,7 +2532,7 @@
COMPILING::<$?FOO> = 45; # an error unless we are compiling something
Note that C<< CALLER::<$?FOO> >> might discover the same variable
-as C<COMPILING::<$?FOO>>, but only if the compiling context is the
+as C<COMPILING::<$?FOO>>, but only if the compiling scope is the
immediate caller. Likewise C<< OUTER::<$?FOO> >> might or might not
get you to the right place. In the abstract, C<COMPILING::<$?FOO>>
goes outwards dynamically until it finds a compiling scope, and so is
@@ -3651,8 +3658,10 @@
C<&?ROUTINE.name>. The current block is C<&?BLOCK>. If the block has any
labels, those shows up in C<&?BLOCK.labels>. Within the lexical scope of
a statement with a label, the label is a pseudo-object representing
-the dynamic context of that statement. (If inside multiple dynamic
-instances of that statement, the label represents the innermost one.)
+the I<dynamically> visible instance of that statement. (If inside multiple
+dynamic instances of that statement, the label represents the innermost one.)
+This is known as I<lexotic> semantics.
+
When you say:
next LINE;
@@ -3805,18 +3814,18 @@
=item *
-Perl still has the three main contexts: sink (void), item (scalar), and list.
+Perl still has the three main contexts: sink (aka void), item (aka scalar),
and list.
=item *
In addition to undifferentiated items, we also have these item contexts:
- Context Type OOtype Operator
- ------- ---- ------ --------
- boolean bit Bit ?
- integer int Int int
- numeric num Num +
- string buf Str ~
+ Context Type OOtype Operator
+ ------- ---- ------ --------
+ boolean bit Bit ?
+ integer int Integral int
+ numeric num Num +
+ string buf Str ~
There are also various container contexts that require particular kinds of
containers (such as slice and hash context; see S03 for details).
@@ -3930,9 +3939,9 @@
However, function calls in the argument list can't know their eventual
context because the method hasn't been dispatched yet, so we don't
-know which signature to check against. As in Perl 5, list context
-is assumed unless you explicitly qualify the argument with an item
-context operator.
+know which signature to check against. Such return values are
+bundled up into a "parcel" for later delivery to a context that
+will determine its context lazily.
=item *
Modified: docs/Perl6/Spec/S03-operators.pod
===================================================================
--- docs/Perl6/Spec/S03-operators.pod 2009-11-20 04:34:57 UTC (rev 29141)
+++ docs/Perl6/Spec/S03-operators.pod 2009-11-20 06:12:28 UTC (rev 29142)
@@ -15,8 +15,8 @@
Created: 8 Mar 2004
- Last Modified: 5 Oct 2009
- Version: 175
+ Last Modified: 19 Nov 2009
+ Version: 176
=head1 Overview
@@ -1467,7 +1467,7 @@
This does the same as C<:=>, then marks any destination parameters as
readonly (unless the individual parameter overrides this with either
the C<rw> trait or the C<copy> trait). It's particularly useful
-for establishing readonly context variables for a dynamic scope:
+for establishing readonly dynamic variables for a dynamic scope:
{
my $*OUT ::= open($file, :w) || die $!;
@@ -1476,7 +1476,7 @@
doit(); # runs with original stdout
If C<doit> wants to change C<$*OUT>, it must declare its own
-contextual variable. It may not simply assign to C<$*OUT>.
+dynamic variable. It may not simply assign to C<$*OUT>.
Note that the semantics of C<::=> are virtually identical to
the normal binding of arguments to formal subroutine parameters
@@ -1939,7 +1939,7 @@
=back
-Many of these operators return a list of C<Capture>s, which depending on
+Many of these operators return a list of C<Parcel>s, which depending on
context may or may not flatten them all out into one flat list. The
default is to flatten, but see the contextualizers below.
@@ -2222,7 +2222,7 @@
Returns the first argument that evaluates to true, otherwise returns
the result of the last argument. In list context forces a false return
-to mean C<()>. See C<||> above for high-precedence version.
+to mean C<()>, or C<Nil>. See C<||> above for high-precedence version.
=item *
@@ -2232,7 +2232,7 @@
Returns the true argument if there is one (and only one). Returns
C<Bool::False> if all arguments are false or if more than one argument is true.
-In list context forces a false return to mean C<()>.
+In list context forces a false return to mean C<()>, or C<Nil>.
See C<^^> above for high-precedence version.
=item *
@@ -2283,7 +2283,7 @@
The context determines how the expressions terminated by semicolon
are interpreted. At statement level they are statements. Within a
-bracketing construct they are interpreted as lists of C<Capture>s,
+bracketing construct they are interpreted as lists of C<Parcel>s,
which in slice context will be treated as the multiple dimensions of a
multidimensional slice. (Other contexts may have other interpretations
or disallow semicolons entirely.)
@@ -2471,11 +2471,11 @@
=item *
-Unary C<~> now imposes a string (C<Str>) context on its
-argument, and C<+> imposes a numeric (C<Num>) context (as opposed
+Unary C<~> now imposes a string (C<Stringy>) context on its
+argument, and C<+> imposes a numeric (C<Numeric>) context (as opposed
to being a no-op in Perl 5). Along the same lines, C<?> imposes
a boolean (C<Bool>) context, and the C<|> unary operator imposes
-a function-arguments (C<Capture>) context on its argument.
+a function-arguments (C<Parcel> or C<Capture>) context on its argument.
Unary sigils are allowed when followed by a C<$> sigil on a scalar variable;
they impose the container context implied by their sigil.
As with Perl 5, however, C<$$foo[bar]> parses as C<( $($foo) )[bar]>,
@@ -2538,8 +2538,8 @@
=item *
-In item context comma C<,> now constructs a C<List> object from its
-operands. You have to use a C<[*-1]> subscript to get the last one.
+Comma C<,> now constructs a C<Parcel> object from its
+operands. In item context this turns into a C<List> object. You have to use
a C<[*-1]> subscript to get the last one.
(Note the C<*>. Negative subscripts no longer implicitly count from
the end; in fact, the compiler may complain if you use C<[-1]> on an
object known at compile time not to have negative subscripts.)
@@ -3192,7 +3192,7 @@
Since use of C<Range> objects in item context is usually
non-sensical, a C<Range> object used as an operand for scalar operators
will generally attempt to distribute the operator to its endpoints and
-return another suitably modified C<Range> instead. (Notable exceptions
+return another suitably modified C<Range> instead, much like a junction of two
items. (Notable exceptions
include C<< infix:<~~> >>, which does smart matching, and C<< prefix:<+> >>
which returns the length of the range.) Therefore if you wish to
write a slice using a length instead of an endpoint, you can say
Modified: docs/Perl6/Spec/S04-control.pod
===================================================================
--- docs/Perl6/Spec/S04-control.pod 2009-11-20 04:34:57 UTC (rev 29141)
+++ docs/Perl6/Spec/S04-control.pod 2009-11-20 06:12:28 UTC (rev 29142)
@@ -13,8 +13,8 @@
Created: 19 Aug 2004
- Last Modified: 17 Nov 2009
- Version: 88
+ Last Modified: 19 Nov 2009
+ Version: 89
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -40,14 +40,14 @@
so it's important to distinguish carefully which kind of scoping
we're talking about.
-Further compounding the difficulty is that every dynamic scope is
+Further compounding the difficulty is that every dynamic scope's outer call
frame is
associated with a lexical scope somewhere, so you can't just consider
one kind of scoping or the other in isolation. Many constructs define
a particular interplay of lexical and dynamic features. For instance,
-unlike normal lexically scope variables, contextual variables search
+unlike normal lexically scope variables, dynamic variables search
up the dynamic call stack for a variable of a particular name, but at
each "stop" along the way, they are actually looking in the lexical
-"pad" associated with that particular dynamic scope.
+"pad" associated with that particular dynamic scope's call frame.
In Perl 6, control flow is designed to do what the user expects most of
the time, but this implies that we must consider the declarative nature
@@ -55,7 +55,7 @@
call stack. For instance, a C<return> statement always returns from
the lexically scoped subroutine that surrounds it. But to do that,
it may eventually have to peel back any number of layers of dynamic
-scoping internal to the subroutine. The lexical scope supplies the
+call frames internal to the subroutine's current call frame. The lexical
scope supplies the
declared target for the dynamic operation. There does not seem to
be a prevailing term in the industry for this, so we've coined the
term I<lexotic> to refer to these strange operations that perform a
@@ -72,7 +72,7 @@
if the lexotic interpretation doesn't work. For instance, C<next>
will prefer to exit a loop lexotically, but if there is no loop with
an appropriate label in the lexical context, it will then scan upward
-dynamically for any loop with the appropriate label, even though that
+dynamically through the call frames for any loop with the appropriate label,
even though that
loop will not be lexically visible. Lexotic and dynamic control flow
is implemented by a system of control exceptions. For the lexotic
return of C<next>, the control exception will contain the identity of
@@ -733,19 +733,11 @@
A C<gather> is not considered a loop, but it is easy to combine with a loop
statement as in the examples above.
-If any function called as part of a C<take> list asks what its context
-is, it will be told it was called in list context regardless of the
-eventual binding of the returned C<Capture>. If that is not the
-desired behavior you must coerce the call to an appropriate context.
-In any event, such a function is called only once at the time the
-C<Capture> object is generated, not when it is bound (which could
-happen more than once).
-
=head2 The C<lift> statement prefix
X<lift>
When writing generic multi routines you often want to write a bit of
-code whose meaning is dependent on the context of the caller. It's
+code whose meaning is dependent on the linguistic context of the caller. It's
somewhat like virtual methods where the actual call depends on the type
of the invocant, but here the "invocant" is really the lexical scope of
the caller, and the virtual calls are name bindings. Within a lift,
@@ -775,7 +767,7 @@
Note that in each piece of lifted code there are references to
variables defined in the multi, such as C<$a>, C<$b>, and C<&f>.
These are taken at face value. Everything else within a lift is
-assumed to mean something in the caller's context. (This implies
+assumed to mean something in the caller's linguistic context. (This implies
that there are some errors that would ordinarily be found at
compile time that cannot be found until we know what the caller's
lexical scope looks like at run time. That's okay.)
@@ -886,9 +878,9 @@
block will be a C<given> or a C<for> statement, but any block that
sets the topic in its signature can be broken out of. At run time,
C<break> uses a control exception to scan up the dynamic chain to
-find the activation record belonging to that same outer block, and
-when it has found that scope, it does a C<.leave> on it to unwind
-the contexts. If any arguments are supplied to the C<break> function,
+find the call frame belonging to that same outer block, and
+when it has found that frame, it does a C<.leave> on it to unwind
+the call frames. If any arguments are supplied to the C<break> function,
they are passed out via the C<leave> method. Since leaving a block is
considered a successful return, breaking out of one is also considered
a successful return. (And in fact, the implicit break of a normal
@@ -992,8 +984,8 @@
statement still means C<&?ROUTINE.leave> from the C<Routine> that existed
in dynamic scope when the closure was cloned.
-It is illegal to return from the closure if that C<Routine> no longer exists
-in the current chain of contexts.
+It is illegal to return from the closure if that C<Routine> no longer owns
+a call frame in the current call stack.
To return a value (to the dynamical caller) from any pointy block or bare
closure, you either
just let the block return the value of its final expression, or you
@@ -1016,12 +1008,12 @@
caller.leave(1,2,3)
-Further contexts up the caller stack may be located by use of the
-C<context> function:
+Further call frames up the caller stack may be located by use of the
+C<callframe> function:
- context({ .labels.any eq 'LINE' }).leave(1,2,3);
+ callframe({ .labels.any eq 'LINE' }).leave(1,2,3);
-By default the innermost dynamic scope matching the selection criteria
+By default the innermost call frame matching the selection criteria
will be exited. This can be a bit cumbersome, so in the particular
case of labels, the label that is already visible in the current lexical
scope is considered a kind of pseudo object specifying a potential
@@ -1031,7 +1023,7 @@
it was always exit from your lexically scoped C<LINE> loop, even
if some inner dynamic scope you can't see happens to also have that
-label. If the C<LINE> label is visible but you aren't actually in
+label. (In other words, it's lexotic.) If the C<LINE> label is visible but
you aren't actually in
a dynamic scope controlled by that label, an exception is thrown.
(If the C<LINE> is not visible, it would have been caught earlier at
compile time since C<LINE> would likely be a bareword.)
@@ -1056,8 +1048,7 @@
control structures, hence the sub's lexical scope was I<always>
the innermost dynamic scope, so the preference to the lexical scope
in the current sub was implicit. For Perl 6 we have to make this
-preference explicit.) So this fallback is more like the C<context>
-form we saw earlier.
+preference for lexotic behavior explicit.)
Warnings are produced in Perl 6 by throwing a resumable control
exception to the outermost scope, which by default prints the
@@ -1082,7 +1073,7 @@
associated continuation) when the compiler or runtime can determine
that the semantics would be preserved by merely printing out the
error and going on. Since all exception handlers run in the dynamic
-context of the throw, that reduces to simply returning from the C<warn>
+scope of the throw, that reduces to simply returning from the C<warn>
function most of the time.
=head1 The goto statement
@@ -1141,7 +1132,7 @@
A bare C<die>/C<fail> takes C<$!> as the default argument specifying
the exception to be thrown or propagated outward to the caller's C<$!>.
-Because the contextual variable C<$!> contains all exceptions collected
+Because the dynamic variable C<$!> contains all exceptions collected
in the current lexical scope, saying C<die $!> will rethrow all those
exceptions as the new thrown exception, keeping the same structure of
main exception and list of unhandled exceptions. (The C<$!> seen in a
@@ -1228,7 +1219,9 @@
In fact, most of these phasers will take either a block or a statement
(known as a I<blast> in the vernacular). The statement form can be
particularly useful to expose a lexically scoped
-declaration to the surrounding context. Hence these declare the same
+declaration to the surrounding lexical scope without "trapping" it inside a
block.
+
+Hence these declare the same
variables with the same scope as the preceding example, but run the
statements as a whole at the indicated time:
Modified: docs/Perl6/Spec/S05-regex.pod
===================================================================
--- docs/Perl6/Spec/S05-regex.pod 2009-11-20 04:34:57 UTC (rev 29141)
+++ docs/Perl6/Spec/S05-regex.pod 2009-11-20 06:12:28 UTC (rev 29142)
@@ -16,8 +16,8 @@
Created: 24 Jun 2002
- Last Modified: 13 Nov 2009
- Version: 109
+ Last Modified: 19 Nov 2009
+ Version: 110
This document summarizes Apocalypse 5, which is about the new regex
syntax. We now try to call them I<regex> rather than "regular
@@ -2114,7 +2114,7 @@
These keyword-declared regexes are officially of type C<Method>,
which is derived from C<Routine>.
-In general, the anchoring of any subrule call is controlled by context.
+In general, the anchoring of any subrule call is controlled by its calling
context.
When a regex, token, or rule method is called as a subrule, the
front is anchored to the current position (as with C<:p>), while
the end is not anchored, since the calling context will likely wish
@@ -2377,12 +2377,12 @@
=item *
A match always returns a C<Match> object, which is also available
-as C<$/>, which is a contextual lexical declared in the outer
-subroutine that is calling the regex. (A regex declares its own
+as C<$/>, which is a dynamic lexical declared in the outer
+block that is calling the regex. (A regex declares its own
lexical C<$/> variable, which always refers to the most recent
submatch within the rule, if any.) The current match state is
kept in the regex's C<$¢> variable which will eventually get
-processed into the user's C<$/> variable when the match completes.
+bound to the user's C<$/> variable when the match completes.
=item *
Modified: docs/Perl6/Spec/S06-routines.pod
===================================================================
--- docs/Perl6/Spec/S06-routines.pod 2009-11-20 04:34:57 UTC (rev 29141)
+++ docs/Perl6/Spec/S06-routines.pod 2009-11-20 06:12:28 UTC (rev 29142)
@@ -17,7 +17,7 @@
Created: 21 Mar 2003
Last Modified: 19 Nov 2009
- Version: 124
+ Version: 125
This document summarizes Apocalypse 6, which covers subroutines and the
new type system.
@@ -285,7 +285,7 @@
dispatch only looks in lexical scopes.
Global subroutines and variables are normally referred to by prefixing
-their identifiers with the C<*> twigil, to allow contextual overrides.
+their identifiers with the C<*> twigil, to allow dynamically scoped overrides.
GLOBAL::<$next_id> = 0;
sub GLOBAL::saith($text) { say "Yea verily, $text" }
@@ -296,7 +296,7 @@
&*saith($*next_id); # print the dynamic $next_id;
}
-To disallow contextual overrides, you must access the globals directly:
+To disallow dynamic overrides, you must access the globals directly:
GLOBAL::saith($GLOBAL::next_id);
@@ -319,12 +319,12 @@
=head2 Dynamically scoped subroutines
-Similarly, you may define contextual subroutines:
+Similarly, you may define dynamically scoped subroutines:
my sub myfunc ($x) is context { ... }
my sub &*myfunc ($x) { ... } # same thing
-This may then be invoked via the syntax for contextual variables:
+This may then be invoked via the syntax for dynamic variables:
&*myfunc(42);
@@ -2030,12 +2030,11 @@
Binding to a copy parameter never triggers autovivification.
-=item C<is context(I<ACCESS>)>
+=item C<is dynamic>
Specifies that the parameter is to be treated as an "environmental"
variable, that is, a lexical that is accessible from the dynamic
-scope (see S02). If I<ACCESS> is omitted, defaults to readonly in
-any portions of the dynamic scope outside the current lexical scope.
+scope (see S02).
=back
@@ -2143,42 +2142,35 @@
caller may use C<< prefix:<|> >> to inline the returned values as part of the
new argument list. The caller may also bind the returned C<Capture> directly.
-If any function called as part of a return list asks what its context
-is, it will be told it was called in list context regardless of the
-eventual binding of the returned C<Capture>. (This is quite
-different from Perl 5, where a C<return> statement always propagates its
-caller's context to its own argument(s).) If that is not the
-desired behavior you must coerce the call to an appropriate context,
-(or declare the return type of the function to perform such a coercion).
-In any event, such a function is called only once at the time the
+A function is called only once at the time the
C<Capture> object is generated, not when it is later bound (which
could happen more than once).
-=head2 The C<dynamic> and C<caller> functions
+=head2 The C<callfram> and C<caller> functions
-The C<dynamic> function takes a list of matchers and interprets them
-as a navigation path from the current context to a location in the
-dynamic scope, either the current context itself or some context
-from which the current context was called. It returns an object
-that describes that particular dynamic scope, or a false value if
+The C<callframe> function takes a list of matchers and interprets them
+as a navigation path from the current call frame to a location in the
+call stack, either the current call frame itself or some frame
+from which the current frame was called. It returns an object
+that describes that particular call frame, or a false value if
there is no such scope. Numeric arguments are interpreted as number
-of contexts to skip, while non-numeric arguments scan outward for a
-context matching the argument as a smartmatch.
+of frames to skip, while non-numeric arguments scan outward for a
+frame matching the argument as a smartmatch.
-The current context is accessed with a null argument list.
+The current frame is accessed with a null argument list.
- say " file ", dynamic().file,
- " line ", dynamic().line;
+ say " file ", callframe().file,
+ " line ", callframe().line;
which is equivalent to:
say " file ", DYNAMIC::<$?FILE>,
" line ", DYNAMIC::<$?LINE>;
-The immediate caller of this context is accessed by skipping one level:
+The immediate caller of this frame is accessed by skipping one level:
- say " file ", dynamic(1).file,
- " line ", dynamic(1).line;
+ say " file ", callframe(1).file,
+ " line ", callframe(1).line;
You might think that that must be the current function's caller,
but that's not necessarily so. This might return an outer block in
@@ -2186,60 +2178,60 @@
control operator on behalf of our block. To get outside your current
routine, see C<caller> below.
-The C<dynamic> function may be given arguments
+The C<callframe> function may be given arguments
telling it which higher scope to look for. Each argument is processed
in order, left to right. Note that C<Any> and C<0> are no-ops:
- $ctx = dynamic(); # currently running context for &?BLOCK
- $ctx = dynamic(Any); # currently running context for &?BLOCK
- $ctx = dynamic(Any,Any); # currently running context for &?BLOCK
- $ctx = dynamic(1); # my context's context
- $ctx = dynamic(2); # my context's context's context
- $ctx = dynamic(3); # my context's context's context's context
- $ctx = dynamic(1,0,1,1); # my context's context's context's context
- $ctx = dynamic($i); # $i'th context
+ $ctx = callframe(); # currently running frame for &?BLOCK
+ $ctx = callframe(Any); # currently running frame for &?BLOCK
+ $ctx = callframe(Any,Any); # currently running frame for &?BLOCK
+ $ctx = callframe(1); # my frame's caller
+ $ctx = callframe(2); # my frame's caller's caller
+ $ctx = callframe(3); # my frame's caller's caller's caller
+ $ctx = callframe(1,0,1,1); # my frames's caller's caller's caller
+ $ctx = callframe($i); # $i'th caller
Note also that negative numbers are allowed as long as you stay within
-the existing context stack:
+the existing call stack:
- $ctx = dynamic(4,-1); # my context's context's context's context
+ $ctx = callframe(4,-1); # my frames's caller's caller's caller
-Repeating any smartmatch just matches the same context again unless you
+Repeating any smartmatch just matches the same frame again unless you
intersperse a 1 to skip the current level:
- $ctx = dynamic(Method); # nearest context that is method
- $ctx = dynamic(Method,Method); # nearest context that is method
- $ctx = dynamic(Method,1,Method); # 2nd nearest method context
- $ctx = dynamic(Method,1,Method,1) # caller of that 2nd nearest method
- $ctx = dynamic(1,Block); # nearest outer context that is block
- $ctx = dynamic(Sub,1,Sub,1,Sub); # 3rd nearest sub context
- $ctx = dynamic({ .labels.any eq 'Foo' }); # nearest context labeled 'Foo'
+ $ctx = callframe(Method); # nearest frame that is method
+ $ctx = callframe(Method,Method); # nearest frame that is method
+ $ctx = callframe(Method,1,Method); # 2nd nearest method frame
+ $ctx = callframe(Method,1,Method,1) # caller of that 2nd nearest method
+ $ctx = callframe(1,Block); # nearest outer frame that is block
+ $ctx = callframe(Sub,1,Sub,1,Sub); # 3rd nearest sub frame
+ $ctx = callframe({ .labels.any eq 'Foo' }); # nearest frame labeled 'Foo'
Note that this last potentially differs from the answer returned by
- Foo.dynamic
+ Foo.callframe
-which returns the context of the innermost C<Foo> block in the lexical scope
-rather than the dynamic scope. A context also responds to the C<.dynamic>
-method, so a given context may be used as the basis for further navigation:
+which returns the frame of the innermost C<Foo> block in the lexical scope
+rather than the dynamic scope. A call frame also responds to the C<.callframe>
+method, so a given frame may be used as the basis for further navigation:
- $ctx = dynamic(Method,1,Method);
- $ctx = dynamic(Method).dynamic(1).dynamic(Method); # same
+ $ctx = callframe(Method,1,Method);
+ $ctx = callframe(Method).callframe(1).callframe(Method); # same
-You must supply args to get anywhere else, since C<.dynamic> is
+You must supply args to get anywhere else, since C<.callframe> is
the identity operator when called on something that is already
a C<Context>:
- $ctx = dynamic;
- $ctx = dynamic.dynamic.dynamic.dynamic; # same
+ $ctx = callframe;
+ $ctx = callframe.callframe.callframe.callframe; # same
The C<caller> function is special-cased to go outward just far enough
to escape from the current routine scope, after first ignoring any
inner blocks that are embedded, or are otherwise pretending to be "inline":
- &caller ::= &dynamic.assuming({ !.inline }, 1);
+ &caller ::= &callframe.assuming({ !.inline }, 1);
-Note that this is usually the same as C<dynamic(&?ROUTINE,1)>,
+Note that this is usually the same as C<callframe(&?ROUTINE,1)>,
but not always. A call to a returned closure might not even have
C<&?ROUTINE> in its dynamic scope anymore, but it still has a caller.
@@ -2254,8 +2246,8 @@
" line ", CALLER::<$?LINE>;
Additional arguments to C<caller> are treated as navigational from the
-calling context. One context out from your current routine is I<not>
-guaranteed to be a C<Routine> context. You must say C<caller(Routine)>
+calling frame. One frame out from your current routine is I<not>
+guaranteed to be a C<Routine> frame. You must say C<caller(Routine)>
to get to the next-most-inner routine.
Note that C<caller(Routine).line> is not necessarily going to give you the
@@ -2264,10 +2256,10 @@
within that outer routine, where that block contains the call to
your routine.
-For either C<dynamic> or C<caller>,
-the returned context object supports at least the following methods:
+For either C<callframe> or C<caller>,
+the returned CallFrame object supports at least the following methods:
- .dynamic
+ .callframe
.caller
.leave
.inline
@@ -2277,10 +2269,10 @@
.my
.hints
-The C<.dynamic> and C<.caller> methods work the same as the functions
-except that they are relative to the context supplied as invocant.
+The C<.callframe> and C<.caller> methods work the same as the functions
+except that they are relative to the frame supplied as invocant.
The C<.leave> method can force an immediate return from the
-specified context.
+specified call frame.
The C<.inline> method says whether this block was entered implicitly
by some surrounding control structure. Any time you invoke a block or
@@ -2288,8 +2280,8 @@
to be true for any block entered using dispatcher-level primitives
such as C<.callwith>, C<.callsame>, C<.nextwith>, or C<.nextsame>.
-The C<.my> method provides access to the lexical namespace in effect at
-the given dynamic context's current position. It may be used to look
+The C<.my> method provides access to the lexical namespace associated with
+the given call frame's current position. It may be used to look
up ordinary lexical variables in that lexical scope. It must not be
used to change any lexical variable that is marked as readonly.
@@ -2315,6 +2307,7 @@
item => { @.list.join(', ') },
list => { ... },
;
+
or something similar.)
=head2 The C<leave> function
@@ -2340,18 +2333,18 @@
to your successor" as appropriate.) The object specifies the scope to exit,
and the method's arguments specify the return value. If the object
is omitted (by use of the function or listop forms), the innermost
-block is exited. Otherwise you must use something like C<context>
-or C<&?BLOCK> or a contextual variable to specify the scope you
+block is exited. Otherwise you must use something like C<callframe>
+or C<&?BLOCK> or a dynamic variable to specify the scope you
want to exit. A label (such as a loop label) previously seen in
-the lexical scope also works as a kind of singleton context object:
+the lexical scope also works as a kind of singleton dynamic object:
it names a statement that is serving both as an outer lexical scope
-and as a context in the current dynamic scope.
+and as a frame in the current dynamic scope.
As with C<return>, the arguments are taken to be a C<Capture> holding the
return values.
leave; # return from innermost block of any kind
- context(Method).leave; # return from innermost calling method
+ callframe(Method).leave; # return from innermost calling method
&?ROUTINE.leave(1,2,3); # Return from current sub. Same as: return
1,2,3
&?ROUTINE.leave <== 1,2,3; # same thing, force return as feed
OUTER.leave; # Return from OUTER label in lexical scope
@@ -2450,7 +2443,7 @@
Hypothetical variables use the same mechanism, except that the restoring
closure is called only on failure.
-Note that contextual variables may be a better solution than temporized
+Note that dynamic variables may be a better solution than temporized
globals in the face of multithreading.
=head2 Wrapping
@@ -2911,12 +2904,12 @@
C<< CALLER::<$varname> >> specifies the C<$varname> visible in
the dynamic scope from which the current block/closure/subroutine
-was called, provided that variable carries the "C<context>"
+was called, provided that variable carries the "C<dynamic>"
trait. (All variables with a C<*> twigil are automatically marked with the
trait.
Likewise certain implicit lexicals (C<$_>, C<$/>, and C<$!>) are so marked.)
C<< DYNAMIC::<$varname> >> specifies the C<$varname> visible in the
-innermost dynamic scope that declares the variable with the "C<is context>"
+innermost dynamic scope that declares the variable with the "C<is dynamic>"
trait or with a name that has the C<*> twigil.
C<< MY::<$varname> >> specifies the lexical C<$varname> declared in the current
Modified: docs/Perl6/Spec/S10-packages.pod
===================================================================
--- docs/Perl6/Spec/S10-packages.pod 2009-11-20 04:34:57 UTC (rev 29141)
+++ docs/Perl6/Spec/S10-packages.pod 2009-11-20 06:12:28 UTC (rev 29142)
@@ -13,8 +13,8 @@
Created: 27 Oct 2004
- Last Modified: 7 Sep 2009
- Version: 10
+ Last Modified: 19 Nov 2009
+ Version: 11
=head1 Overview
@@ -111,11 +111,11 @@
In any case, it is erroneous for any external module to depend
on any knowledge of its user with respect to compilation order or
-other contextual information, since other users may also depend on
+other dynamic information, since other users may also depend on
this single "first-use" execution and expect consistent semantics.
-(Really, all such contextual dependencies should be passed in at run
+(Really, all such dynamic dependencies should be passed in at run
time to the routines or methods of your module as normal parameters or
-contextual variables. For instance, you cannot know at module compile
+as dynamic variables. For instance, you cannot know at module compile
time whether your caller is going to be using 'fatal' semantics or not.
That is dynamically scoped info.)
@@ -147,7 +147,7 @@
The C<PROCESS::> namespace, shared by all interpreters within the process,
is notionally outside of C<GLOBAL::>, but package searches do not look
there for anything. (Contextual variable searches do; C<$*PID> will eventually
-locate C<$PROCESS::PID> if not hidden by an inner context's C<$PID>.)
+locate C<$PROCESS::PID> if not hidden by an inner callframe's C<$*PID>.)
=head1 Autoloading
Modified: docs/Perl6/Spec/S11-modules.pod
===================================================================
--- docs/Perl6/Spec/S11-modules.pod 2009-11-20 04:34:57 UTC (rev 29141)
+++ docs/Perl6/Spec/S11-modules.pod 2009-11-20 06:12:28 UTC (rev 29142)
@@ -13,8 +13,8 @@
Created: 27 Oct 2004
- Last Modified: 17 Nov 2009
- Version: 31
+ Last Modified: 19 Nov 2009
+ Version: 32
=head1 Overview
@@ -609,7 +609,7 @@
"Coolness, dude!";
it runs Perl 6 in "lax" mode, without strictures or warnings, since obviously
-a bare literal in a void context I<ought> to have produced a warning.
+a bare literal in a sink (void) context I<ought> to have produced a "Useless
use of..." warning.
(Invoking perl with C<-e '6;'> has the same effect.)
In the other direction, to inline Perl 5 code inside a Perl 6 program, put
@@ -713,7 +713,7 @@
indeterminacy in the language definition either directly or indirectly.
It must be possible for any official module to be separately compiled
-without knowledge of the context in which it will be embedded, and
+without knowledge of the lexical or dynamic context in which it will be
embedded, and
this separate compilation must be able to produce a deterministic
profile of the interface. It must be possible to extract out the
language tweaking part of this profile for use in tools that wish to
Modified: docs/Perl6/Spec/S16-io.pod
===================================================================
--- docs/Perl6/Spec/S16-io.pod 2009-11-20 04:34:57 UTC (rev 29141)
+++ docs/Perl6/Spec/S16-io.pod 2009-11-20 06:12:28 UTC (rev 29142)
@@ -17,8 +17,8 @@
Created: 12 Sep 2006
- Last Modified: 19 Apr 2009
- Version: 22
+ Last Modified: 19 Nov 2009
+ Version: 23
This is a draft document. Many of these functions will work as in Perl
5, except we're trying to rationalize everything into roles. For
@@ -45,7 +45,7 @@
namespace.
When no explicit filehandle is used, the standard IO operators are
-defined in terms of the contextual variables. So the C<print> function
+defined in terms of the dynamic variables. So the C<print> function
prints to C<$*OUT>, while C<warn> warns to C<$*ERR>. The C<< lines() >>
term inputs from C<$*ARGFILES> which defaults to C<$*IN> in the absence of any
filenames. So any given dynamic scope (interpreter,
Modified: docs/Perl6/Spec/S17-concurrency.pod
===================================================================
--- docs/Perl6/Spec/S17-concurrency.pod 2009-11-20 04:34:57 UTC (rev 29141)
+++ docs/Perl6/Spec/S17-concurrency.pod 2009-11-20 06:12:28 UTC (rev 29142)
@@ -198,7 +198,7 @@
for that concurrent context.
When an alarm object is garbage collected, the alarm is stopped automatically.
-Under void context, the implicit alarm object can only be stopped by querying
+Within sink (void) context, the implicit alarm object can only be stopped by
querying
C<.alarms> on the current process.
We are not sure what C<alarm(0)> would mean. Probably a deprecation warning?
Modified: docs/Perl6/Spec/S19-commandline.pod
===================================================================
--- docs/Perl6/Spec/S19-commandline.pod 2009-11-20 04:34:57 UTC (rev 29141)
+++ docs/Perl6/Spec/S19-commandline.pod 2009-11-20 06:12:28 UTC (rev 29142)
@@ -302,7 +302,7 @@
=back
-These options are made available in context variables matching their name,
+These options are made available in dynamic variables matching their name,
and are invisible to C<MAIN()> except as C<< %*OPTS<name> >>. For example:
++PARSER --setting=Perl6-autoloop-no-print ++/PARSER
@@ -516,7 +516,7 @@
Metasyntactic options are a subset of delimited options used to pass arguments
to an underlying component of Perl. Perl itself does not parse these options,
-but makes them available to run-time components via the C<%*META-ARGS> context
+but makes them available to run-time components via the C<%*META-ARGS> dynamic
variable.
Standard in Perl 6 are three underlying components, C<CMD>, C<PARSER>,
Modified: docs/Perl6/Spec/S28-special-names.pod
===================================================================
--- docs/Perl6/Spec/S28-special-names.pod 2009-11-20 04:34:57 UTC (rev
29141)
+++ docs/Perl6/Spec/S28-special-names.pod 2009-11-20 06:12:28 UTC (rev
29142)
@@ -13,8 +13,8 @@
Created: 23 Feb 2009, created by Tim Nelson from miscellaneous documents
lying around
- Last Modified: 19 Apr 2009
- Version: 6
+ Last Modified: 19 Nov 2009
+ Version: 7
=head1 Special Variables
@@ -123,9 +123,9 @@
$?VM S02 SoftwarePackage # Which virtual machine am I
compiling under
$?XVM S02 SoftwarePackage # Which virtual machine am I
cross-compiling for
-Note that contextual variables such as C<$*OUT> may have more than
+Note that dynamic variables such as C<$*OUT> may have more than
one current definition in the outer dynamic context, in which case
-the innermost dynamic scope determines the meaning. For instance,
+the innermost dynamic scope in which it is defined determines the meaning.
For instance,
C<$PROCESS::OUT> is the stdout for the entire process, but each
interpreter can set its own C<$GLOBAL::OUT> to make C<$*OUT> mean
whatever it wants independently of other interpreters. Any dynamic
Modified: docs/Perl6/Spec/S29-functions.pod
===================================================================
--- docs/Perl6/Spec/S29-functions.pod 2009-11-20 04:34:57 UTC (rev 29141)
+++ docs/Perl6/Spec/S29-functions.pod 2009-11-20 06:12:28 UTC (rev 29142)
@@ -20,8 +20,8 @@
Created: 12 Mar 2005
- Last Modified: 13 October 2009
- Version: 43
+ Last Modified: 19 Nov 2009
+ Version: 44
The document is a draft.
@@ -208,11 +208,11 @@
=item caller
-See L<S06/"The C<context> and C<caller> functions">.
+See L<S06/"The C<callframe> and C<caller> functions">.
-=item context
+=item callframe
-See L<S06/"The C<context> and C<caller> functions">.
+See L<S06/"The C<callframe> and C<caller> functions">.
=item eval
@@ -305,14 +305,14 @@
that represents a higher abstraction level than the current
lexical scope supports, that grapheme is converted to the
corresponding lower-level string of codepoints/bytes that would
-be appropriate to the current context, just as any other Str
+be appropriate to the current pragmatic context, just as any other Str
would be downgraded in context.
C<ord> goes the other direction; it takes a string value and returns
character values as integers. In a scalar context, the return value
is the just the integer value of the first character in the string. In
a list context, the return value is the list of integers representing
-the entire string. The definition of character is context dependent.
+the entire string. The definition of character is pragma dependent.
Normally it's a grapheme id, but under codepoints or bytes scopes,
the string is coerced to the appropriate low-level view and interpreted
as codepoints or bytes. Hence, under "use bytes" you will never see a
@@ -323,8 +323,8 @@
there is such a codepoint. Otherwise, the implementation is free to
return any unique id that larger than 0x10ffff. (The C<chr> function
will know how to backtranslate such ids properly to codepoints or
-bytes in any context. Note that we are assuming that every codepoints
-context knows its normalization preferences, and every bytes context
+bytes in any context. Note that we are assuming that every codepoint's
+context knows its normalization preferences, and every byte's context
also knows its encoding preferences. (These are knowable in the
lexical scope via the $?NF and $?ENC compile-time constants).)
@@ -437,7 +437,7 @@
our Bool multi chroot ( Str $path = CALLER::<$_> )
-On POSIX systems, changes the context of the current process such
+On POSIX systems, changes the process context of the current process such
that the "root" directory becomes C<$path> and all rooted paths
(those that begin with a leading path separator) are relative to
that path. For security reasons, many operating systems limit
Modified: docs/Perl6/Spec/S32-setting-library/IO.pod
===================================================================
--- docs/Perl6/Spec/S32-setting-library/IO.pod 2009-11-20 04:34:57 UTC (rev
29141)
+++ docs/Perl6/Spec/S32-setting-library/IO.pod 2009-11-20 06:12:28 UTC (rev
29142)
@@ -22,8 +22,8 @@
Created: 19 Feb 2009 extracted from S29-functions.pod; added stuff from
S16-IO later
- Last Modified: 5 Oct 2009
- Version: 8
+ Last Modified: 19 Nov 2009
+ Version: 9
The document is a draft.
@@ -124,7 +124,7 @@
These can naturally be overridden or added to by other modules.
-=item %*PROTOCOLS context variable
+=item %*PROTOCOLS dynamic variable
For each protocol, stores a type name that should be instantiated by calling
the C<uri>
constructor on that type, and passing in the appropriate uri.
