Author: lwall
Date: 2009-11-10 19:07:56 +0100 (Tue, 10 Nov 2009)
New Revision: 29049
Modified:
docs/Perl6/Spec/S04-control.pod
Log:
[S04] define "lexotic"
Modified: docs/Perl6/Spec/S04-control.pod
===================================================================
--- docs/Perl6/Spec/S04-control.pod 2009-11-10 17:15:21 UTC (rev 29048)
+++ docs/Perl6/Spec/S04-control.pod 2009-11-10 18:07:56 UTC (rev 29049)
@@ -13,16 +13,78 @@
Created: 19 Aug 2004
- Last Modified: 06 Nov 2009
- Version: 85
+ Last Modified: 10 Nov 2009
+ Version: 86
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
+=head1 The Relationship of Lexical and Dynamic Scopes
+
+Control flow is a dynamic feature of all computer programming
+languages, but languages differ in the extent to which control flow is
+attached to declarative features of the language, which are often known
+as "static" or "lexical". We use the phrase "lexical scoping" in its
+industry-standard meaning to indicate those blocks that surround the
+current textual location. More abstractly, any declarations associated
+with those textual blocks are also considered to be part of the lexical
+scope, and this is where the term earns the "lexical" part of its name,
+in the sense that lexical scoping actually does define the "lexicon"
+for the current chunk of code, insofar as the definitions of variables
+and routines create a local domain-specific language.
+
+We also use the term "dynamic scoping" in the standard fashion to
+indicate the nested call frames that are created and destroyed every
+time a function or method is called. In most interesting programs the
+dynamic scopes are nested quite differently from the lexical scopes,
+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
+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
+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.
+
+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
+of labels and blocks and combine those with the dynamic nature of the
+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
+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
+dynamic operation with a lexical target in mind. Lexotic operators
+in Perl 6 include:
+
+ return
+ next
+ last
+ redo
+ goto
+
+Some of these operators also fall back to a purely dynamic interpretation
+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
+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
+the loop scope to be exited (since the label was already "used up" to
+discover that identity), but for the dynamic fallback, the exception
+will contain only the loop label to be matched dynamically. See
+L</Control Exceptions> below.
+
=head1 The Relationship of Blocks and Declarations
Every block is a closure. (That is, in the abstract, they're all
-anonymous subroutines that take a snapshot of their lexical scope.)
+anonymous subroutines that take a snapshot of their lexical environment.)
How a block is invoked and how its results are used are matters of
context, but closures all work the same on the inside.
