FAQ

RFC 106 (v1) Yet another lexical variable proposal: lexical variables made default

Perl6 RFC Librarian
Aug 15, 2000 at 8:02 pm
without requiring strict 'vars'
Reply-To: perl6-language-strict@perl.org

This and other RFCs are available on the web at
http://dev.perl.org/rfc/

=head1 TITLE

Yet another lexical variable proposal: lexical variables made default
without requiring strict 'vars'

=head1 VERSION

Maintainer: J. David Blackstone <jdavidb@dfw.net>
Date: 15 Aug 2000
Version: 1
Mailing List: perl6-language-strict@perl.org
Number: 106

=head1 ABSTRACT

Perl was originally designed around dynamically-scoped variables.
Many users would like to see this design flaw fixed, but are disagreed
about how to go about it. This proposal suggests making undeclared
variables be lexical by default in Perl6 and deals with the possible
ambiguities this could bring about. An optional suggestion is made as
to how one might go even further and eliminate dynamic variables
entirely from the language.

=head1 DESCRIPTION

Lexically-scoped variables are easy to use and intuitive, in that any
lexical variable refers to a variable declared within the current
scope or the enclosing scope. The variable can be located by
lexically scanning the source code. Dynamic variables, on the other
hand, refer to a variable from within the current scope or from within
the current subroutines _caller_, which could be anywhere! It is
impossible to tell exactly what else might be happening to a dynamic
variable, resulting in various action at a distance problems, variable
suicide problems, and other difficulties.

Under this proposal, lexical variables are considered to be the norm
for Perl6. Any undeclared variable is considered to be a lexical
variable.

=head2 Scopes

An undeclared variable is lexical and visible only within the scope
where it is first used and any scopes contained within that one. The
notion of "scope" is the same as Perl has had almost since the
beginning: a block (including a subroutine block) begins a new scope;
a file is also a scope.

Thus, in the following code segment,

$x = 15;
$y = $x;
while ($y) {
$z = $y;
...
$x += $z;
}

$x and $y are lexicals contained in the outermost scope (probably a
file), while $z is a lexical available only in the while loop. When
used within the while loop, $x and $y refer to the same scalars
referred to outside of the while loop.

=head2 Use of C<my>

In all cases, the C<my> operator behaves as it does in Perl5, allowing
local variables that will not interfere with other variables, etc.

=head2 Dynamic Assignment

Dynamic assignment is the technical term given to the action performed
by C<local> in Perl5 and earlier versions. The value of a variable is
saved upon execution of the operator and restored when the current
scope ends.

There is no actual reason why dynamic assignment needs to be limited
to dynamic variables. This RFC strongly suggests that dynamic
assignment be enabled for lexical variables, as well. Programming
with all lexicals and occasional use of dynamic assignment can cover
many of the cases where dynamically-scoped variables are useful.

Note that C<local> will probably be renamed in Perl6.

=head2 Ambiguity

Several people have raised issues about possible ambiguities with this
idea, but they have all been instances of the same problem: the case
where an undeclared variable is used first within a block, then within
that block's containing scope. For example,

$cond = ...;
if ($cond) {
...
$color = "blue";
...
}
print "The color is $color\n";

The programmer expects the value of $color to be "blue" for the print
statement, but in fact $color is a brand-new, undefined, lexical
variable.

Translating this block from Perl5 to get the same behavior in Perl6 if
this RFC is adopted is straightforward and discussed in the
IMPLEMENTATION section.

There are two options for dealing with this construct in new Perl6
code:

=over 4

=item 1

Dubbed the "conservative" approach by Mark-Jason Dominus, this option
requires that the programmer disambiguate the situation by declaring
the variable with C<my>. Perl would produce a warning in this case to
the effect that, "A variable used within a block was used after that
block, but never declared or used before it. The enclosing scope
cannot see the same variable that exists within the enclosed block."

Alternatively, if this RFC is adopted, but nothing is done to alert
new Perl6 programmers about these possibly ambiguous cases, the
programmer would receive a "Use of undefined value" warning which
might suffice.

=item 2

In the "liberal" approach, perl can do what amounts to "inferring
declarations." To actually refer to it this way would be a
contradiction in terms, since a declaration is explicit, not inferred.

To implement the liberal approach, perl would detect all of the
undeclared variables used within a scope when it compiles that scope.
These variables would become available for use from the minute that
scope is entered. Thus, in the example above, $color is detected as
being a part of the enclosing scope before the interpreter ever enters
the if statement, and $color therefore refers to the same scalar in
both places.

=back

=head2 Variable declarations

This proposal does not require variable declarations, like the strict
'vars' pragma does, except if the conservative approach is taken to
resolving the ambiguity noted above. Even then, declarations are only
required in a very few cases.

Some programmers will want a mechanism to require declarations,
similar to Perl5's strict 'vars' pragma. This is beyond the scope of
this RFC.

=head2 Possible elimination of dynamic variables

This subsection suggests a radical change for Perl6. Everything else
in this RFC can be implemented without implementing this idea, if
desired. This subsection should be considered "optional."

In most languages, dynamic scoping of variables offers no advantages
over lexical scoping, other than dynamic assignment. As noted above,
dynamic assignment can be accomplished with the C<local> operator,
which can be extended to operate on lexical variables as well as (or
even instead of) dynamic variables.

The chief instance where Perl5 requires dynamic variables is in the
case of package globals. The package command was created in order to
allow for different namespaces that would not conflict, when lexical
variables were not available at all in Perl. Now it has been extended
for O-O classes.

The following changes could be made involving lexical variables and
packages in order to eliminate dynamic variables from the language
entirely:

=over 4

=item *

Dynamic variables are removed from the language.

=item *

Lexical variables belong to the package they are declared in. (Or, if
not declared, the package to which they belong can be inferred from
the scope in which they are used.)

=item *

Lexical variables can only be accessed from within the same scope or a
lower scope. This means lexicals declared in the same file can be
accessed even if they belong to a different package, but lexicals
declared in another file cannot be accessed directly.

=item *

In nearly all cases the functionality of a package (dynamic) variable
that is intended for access from a different scope/file can be
provided by a lexical variable defined in a .pm file along with a
class accessor method (standard get/set functionality). This should
provide the ability to automate the translation of Perl5 code into
Perl6, should this RFC and this optional subsection be adopted.

=item *

Packages still continue to function in the same way to define classes.

=item *

Packages still continue to provide a separate namespace for non-O-O
subroutines.

=back

Under the proposal of this optional subsection, it might be desired to
implement a pragma to allow the use of dynamic variables.

=head1 IMPLEMENTATION

Very little will have to be done to translate Perl5 to Perl6 under
this proposal. The ambiguous case mentioned above where a variable is
used after a block, but not before it, can be disambiguated in all
cases with a declaration before the block (100% translation). This
works whether the "conservative" or "liberal" approach is adopted.

It is suggested that Perl6 be designed with lexicals in mind first,
followed by dynamic variables, if appropriate.

If the optional subsection on eliminating dynamic variables entirely
is adopted, Perl will completely shed the heritage of dynamic
variables. Whatever the case, the language should be designed and
implemented in such a way that lexical variables are in the design
with dynamic assignment/dynamic variables added in later, rather than
the other way around.

=head1 REFERENCES

There have been many alternative and conflicting proposals. This RFC
does not necessarily attempt to be consistent with any of them, but
they are listed here for convenience.

RFC 6: Lexical variables made default by means of strict 'vars'

RFC 16: Keep default Perl free of constraints such as warnings and strict

RFC 64: New pragma 'scope' to change Perl's default scoping
reply

Search Discussions

12 responses

  • Jonathan Scott Duff at Aug 15, 2000 at 8:24 pm

    On Tue, Aug 15, 2000 at 08:02:46PM -0000, Perl6 RFC Librarian wrote:
    =head1 TITLE

    Yet another lexical variable proposal: lexical variables made default
    without requiring strict 'vars'
    Am I correct that the only significant difference between this and RFC 6
    is that RFC says we should have to C<use strict 'vars';> to get lexicals
    by default and this one says we shouldn't have to?

    -Scott
    --
    Jonathan Scott Duff
    duff@cbi.tamucc.edu
  • Nathan Wiger at Aug 15, 2000 at 9:55 pm

    =item 2

    In the "liberal" approach, perl can do what amounts to "inferring
    declarations."
    This is the way it has to work if I'm going to agree with it. However, I
    don't think the implementation needs to be nearly as complicated as this
    RFC proposes. Consider this code:

    $x = 15;
    $y = $x;
    while ($y) {
    $z = $y;
    $x += $z;
    }

    As you state, "$z is a lexical available only in the while loop".
    However, you also state that Perl will automatically scope outwards to
    the outermost one it find, so if I add a

    print "z = $z\n";

    At the bottom, now $z is available outside as well.

    Ok, but then why bother going to the trouble of scoping it so tightly to
    begin with? If you're just going to automatically scope it to the
    outermost one, then this is equivalent to no scoping at all (do you
    see?). The only reason you'd want to scope something tightly is to:

    1. Make it inaccessible to other routines

    2. Hide another lexical variable

    However, automatic scoping can't address either of these concerns. You
    have to do this explicitly with my(). As such, there's no benefit to
    liberal lexical scoping over package-wide scoping by default. As soon as
    you access a variable outside a block, that variable is rescoped
    outwards automatically.

    I propose the following modifications to this RFC. You'll wind up with a
    much more stable and faster implementation, I think:

    1. All variables are lexically scoped at the package
    level by default, like our().

    2. You can explicitly scope variables to a block with my().

    3. We introduce a new keyword, say "your()", that makes
    variables true dynamic variables.

    The #3 one might not be necessary if we eliminate dynamics altogether
    and make now() (or local or whatever) work on the lexicals correctly.

    Note that the net effect is the same. Lexicals are still the default.
    But the needless auto-scoping is eliminated.

    -Nate
  • J. David Blackstone at Aug 16, 2000 at 12:17 am

    On Tue, Aug 15, 2000 at 08:02:46PM -0000, Perl6 RFC Librarian wrote:
    =head1 TITLE

    Yet another lexical variable proposal: lexical variables made default
    without requiring strict 'vars'
    Am I correct that the only significant difference between this and RFC 6
    is that RFC says we should have to C<use strict 'vars';> to get lexicals
    by default and this one says we shouldn't have to?

    -Scott
    No. There are many significant differences. The proposals are very,
    very different. The mechanism for making lexicals the default in RFC
    106 is quite involved. RFC 6 takes a shortcut and just makes strict
    'vars' the default. RFC 6 would require next to no code translation
    or modifications to the language.

    J. David
  • Nathan Torkington at Aug 16, 2000 at 1:31 am

    Perl6 RFC Librarian writes:
    The chief instance where Perl5 requires dynamic variables is in the
    case of package globals.
    I think this is a bad idea (so I'm glad you made it optional).

    Global variables are important. They provide a mechanism for a
    separate module to add new behaviour to Perl: global variables
    function as configuration information that can be accessed by other
    packages (e.g., Exporter), and is used in the more general case of
    subclasses needing access to superclasses' innards. They're an
    escape hatch for programmers: language didn't build something in?
    Add it on! Grafting your own stuff into another module's package
    is how Class::Struct works, and I'm still unconvinced there should
    be a difference between subs and data in this respect.

    Any suggestion to make lexical variables accessible from outside
    their scope to solve this is also extremely dangerous (IMHO).
    Very little will have to be done to translate Perl5 to Perl6 under
    this proposal.
    Except if global variables are eliminated.

    Nat
  • J. David Blackstone at Aug 17, 2000 at 11:30 pm

    Perl6 RFC Librarian writes:
    The chief instance where Perl5 requires dynamic variables is in the
    case of package globals.
    I think this is a bad idea (so I'm glad you made it optional).
    Thanks for the feedback, Nat.

    I figured the idea would meet with resistance. Really, since the
    whole RFC is optional, I guess we shouldn't have to specify part of it
    as "optional", but I didn't want to jeopardize acceptance of the idea
    by tying an extra issue to it. (A gigantic leap would be great, but a
    moderate gain sure beats nothing.)
    Global variables are important. They provide a mechanism for a
    separate module to add new behaviour to Perl: global variables
    function as configuration information that can be accessed by other
    packages (e.g., Exporter), and is used in the more general case of
    subclasses needing access to superclasses' innards. They're an
    escape hatch for programmers: language didn't build something in?
    Add it on! Grafting your own stuff into another module's package
    is how Class::Struct works, and I'm still unconvinced there should
    be a difference between subs and data in this respect.
    I agree with you. However, I am unable to find a case in which a
    package global could not be replaced with a lexical defined in the
    module's .pm file and an accessor method for it. Even if you are
    extending a class, you can still provide this.

    I'm willing to listen to reason, however, if I'm nuts. :)
    Any suggestion to make lexical variables accessible from outside
    their scope to solve this is also extremely dangerous (IMHO).
    Right. If you did that, they wouldn't be lexical variables. Now, I
    mentioned in the radical optional section about eliminating dynamic
    variables that lexical variables could be made package variables,
    though still only accessible from within the same file or block. I'm
    thinking that's a bad idea, though, because it doesn't gain much.
    Packages were created as a means of hiding dynamic variable namespaces
    from each other -- this isn't needed if dynamic variables are
    eliminated. The only thing packages would really be needed for if
    such a radical course of action were taken would be the use they've
    been extended to cover: defining classes. (Of course, they would
    still be wanted for separating _functions_ into separate namespaces,
    but that's a separate issue from variables.)
    Very little will have to be done to translate Perl5 to Perl6 under
    this proposal.
    Except if global variables are eliminated.
    Depends on what you mean by very little. :) If they aren't
    eliminated, almost nothing will be required. If they are, you'll have
    to translate each package variable that is intended to be accessed
    from outside the file where it is defined into a lexical variable with
    an accessor method. Still mostly mechanical, though, I think.

    J. David
  • Ariel Scolnicov at Aug 18, 2000 at 2:26 pm
    "J. David Blackstone" <jdavidb@dfw.net> writes:

    [...]
    I agree with you. However, I am unable to find a case in which a
    package global could not be replaced with a lexical defined in the
    module's .pm file and an accessor method for it. Even if you are
    extending a class, you can still provide this.
    Modes. Emacs Lisp uses this (I'm not convinced that's a
    recommendation). Suppose I have a flag $PKG::verbose which prints
    descriptive messages to LOG if 1 (but if 2 does something else, since
    bits are significant). If it's a global, I can do this:

    {
    local $PKG::verbose = 1;
    PKG::frobnicate;
    }
    # Back to previous verbosity level

    Lacking true dynamic variables, this doesn't work (although
    unwind-protect, if we had that, could also provide for restoring
    variables).

    The best we can do is:

    {
    my $old_verbosity = PKG::get_verbose;
    PKG::set_verbose(1);
    PKG::frobnicate;
    PKG::set_verbose($old_verbosity);
    }

    but that doesn't work in the presence of eval{}/die. So you also need
    unwind-protect.

    [...]

    --
    Ariel Scolnicov |"GCAAGAATTGAACTGTAG" | ariels@compugen.co.il
    Compugen Ltd. |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz
    72 Pinhas Rosen St. |Tel: +972-3-7658514 (Main office)`---------------------
    Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555 http://3w.compugen.co.il/~ariels
  • Nathan Torkington at Aug 18, 2000 at 10:17 pm

    J. David Blackstone writes:
    I agree with you. However, I am unable to find a case in which a
    package global could not be replaced with a lexical defined in the
    module's .pm file and an accessor method for it. Even if you are
    extending a class, you can still provide this.
    A lexical plus an accessor method, when the accessor method does
    nothing more than get or set the value with no checks or anything,
    is just a slow and cumbersome global variable.

    I don't understand the rush to remove global variables. Why are they
    such a blight? If you don't like 'em, don't use 'em. But don't make
    me give them up. They make things easy for me.

    Nat
  • J. David Blackstone at Aug 18, 2000 at 12:14 am
    I've been wanting to respond to these issues for the past two days,
    but I've stopped short while I tried to consider everything.

    This email dealt with making lexical variables default to being
    available at the outermost scope (file). I'm not sure that's what
    people usually mean when they think of lexical scoping. I'm also not
    sure if there's a language visible difference. (There is a difference
    at the implementation level, though, to be sure.)

    I wrote (RFC 106):
    =item 2

    In the "liberal" approach, perl can do what amounts to "inferring
    declarations."
    Nate Wiger wrote:
    This is the way it has to work if I'm going to agree with it. However, I
    don't think the implementation needs to be nearly as complicated as this
    RFC proposes. Consider this code:

    $x = 15;
    $y = $x;
    while ($y) {
    $z = $y;
    $x += $z;
    }

    As you state, "$z is a lexical available only in the while loop".
    However, you also state that Perl will automatically scope outwards to
    the outermost one it find, so if I add a

    print "z = $z\n";

    At the bottom, now $z is available outside as well.
    Yes, it almost seems like there is no language visible difference
    between having the variable exist in the outer scope (file) and having
    it exist in the outermost scope in which it is referred to. Please
    correct me if you are thinking of one.
    Ok, but then why bother going to the trouble of scoping it so tightly to
    begin with? If you're just going to automatically scope it to the
    outermost one, then this is equivalent to no scoping at all (do you
    see?). The only reason you'd want to scope something tightly is to:

    1. Make it inaccessible to other routines
    That would be the whole point of lexical variables.
    2. Hide another lexical variable
    Really, though, the idea in mind (especially if you're writing a
    module for the rest of the world, or even just part of a big
    multi-developer project) is that your variables should be lexical not
    to "hide" another variable (since you usually won't know what other
    variables people are using), but to avoid intruding into someone
    else's namespace. Same thing, but thinking from the other direction.

    It just seems safer to tie everything down to the lowest block you
    can get it into.
    However, automatic scoping can't address either of these concerns. You
    have to do this explicitly with my(). As such, there's no benefit to
    liberal lexical scoping over package-wide scoping by default. As soon as
    you access a variable outside a block, that variable is rescoped
    outwards automatically.
    I may be making a bad assumption here, but since a package is
    usually (but not always) defined one per file, I'm assuming that in
    several of these places where you said "package" we should perhaps
    think "file."
    I propose the following modifications to this RFC. You'll wind up with a
    much more stable and faster implementation, I think:

    1. All variables are lexically scoped at the package
    level by default, like our().

    2. You can explicitly scope variables to a block with my().
    If I'm correct in asserting that there are no language-level
    differences, then I think we should recommend whichever is easiest to
    the implementers. I'm still unclear on which of these two approaches
    sounds easiest to implement, and I have zilch knowledge of the Perl5
    internals folks will have in mind when they start implementing Perl6.

    Like I said, I just feel that keeping everything restricted only to
    the block in which it exists is least likely to have an unexpected
    side-effect.


    Note that with debuggers and "eval," all bets may be off. This
    actually does show a difference in the language, I think. I'm not
    sure how anyone would want this to go.
    3. We introduce a new keyword, say "your()", that makes
    variables true dynamic variables.
    :) Yes, I know you're pretty happy about your(). All I really have
    in mind is just the same effect the vars pragma has right now. I'm
    not sure if or how people will want to rename it. our() doesn't do
    the exact same think, I don't think, although I've been alternately
    led to believe it does and that it doesn't. (That email in the p5p
    archives you referred to sure helped; thanks.)
    The #3 one might not be necessary if we eliminate dynamics altogether
    and make now() (or local or whatever) work on the lexicals correctly.
    Sounds good to me. :)

    J. David
  • Nathan Wiger at Aug 18, 2000 at 1:14 am

    Yes, it almost seems like there is no language visible difference
    between having the variable exist in the outer scope (file) and having
    it exist in the outermost scope in which it is referred to. Please
    correct me if you are thinking of one.
    No, I can't see one. Not if you're auto-scoping, that's my point.
    It just seems safer to tie everything down to the lowest block you
    can get it into.

    If I'm correct in asserting that there are no language-level
    differences, then I think we should recommend whichever is easiest to
    the implementers.
    I think that's true for the most part. I don't mind tying things down
    tightly as long as they're auto-scoped liberally. But it does seem like
    excess and unnecessary work if there's no language difference.
    3. We introduce a new keyword, say "your()", that makes
    variables true dynamic variables.
    :) Yes, I know you're pretty happy about your(). All I really have
    in mind is just the same effect the vars pragma has right now.
    Actually, this might be better. If you have a 'use vars' pragma, then
    this can be the only method for declaring global dynamics. Indeed, it
    should be the only method you need, since global dynamics are bad in
    most cases. However, having them available as global switches *is*
    valuable.

    I don't think suggesting that we eliminate globals altogether is a good
    or feasible idea. It's an unnecessary crutch. They are useful in many
    circumstances.

    I think this is shaping up to be a really good proposal. Here's what I
    hear:

    1. All variables are liberally lexically scoped by
    default. Either scope them package-wide or do the
    nearest block idea.

    2. You can explicitly scope variables with my or our.

    3. Global variables can still be declared with 'use vars'.

    4. Dynamic keywords (like local) still only work on
    global variables.

    Sound accurate? Exactly how point #1 is implemented can be left till
    later, just as long as this:

    $x = 1;
    {
    $y = $x + 1;
    }
    print "$y";

    Works without any predeclarations.

    -Nate

    P.S. I meant "package-wide" in the previous email. The package should
    always be the outermost logical container, I think.
  • Nick Ing-Simmons at Aug 22, 2000 at 8:42 pm

    J . David Blackstone writes:

    I may be making a bad assumption here, but since a package is
    usually (but not always) defined one per file, I'm assuming that in
    several of these places where you said "package" we should perhaps
    think "file."
    It is common practice in perl5 to do both of these:

    A. Multiple packages in one file, using lexicals at file scope
    to communicate bewteen them.

    B. Package split accross multiple files (classic case being AUTOLOADed subs)
    with package variables to communicate between the parts.

    You need to be able to represent both schemes to tanslate perl5 code
    (but it can be "moderately awkward" to discourage new weirdnesses).

    --
    Nick Ing-Simmons
  • J. David Blackstone at Aug 18, 2000 at 1:32 am

    Nate the prolific Perl6 RFC producer and commentator wrote:
    I don't think suggesting that we eliminate globals altogether is a good
    or feasible idea. It's an unnecessary crutch. They are useful in many
    circumstances.
    So here's my order of preference:

    1) Eliminate dynamic variables entirely.

    2) Eliminate dynamic variables from default Perl, but allow their use
    with a pragma.

    3) Provide a new strict pragma to disable dynamic variables. (Note
    that I have an ulterior motive, here; strict is the de-facto standard
    for module writing. If I get this into strict, then everybody will
    feel obligated to write their modules in this style. :) Of course,
    module writers are supposed to be good enough to not use unnecessary
    crutches, right?)

    CONTEXT ALERT: All of this is still optional to RFC 106, which can
    provide for making lexical variables the default without having to do
    anything to dynamic variables. Don't have a cow if you were worried
    about that.
    I think this is shaping up to be a really good proposal. Here's what I
    hear:

    1. All variables are liberally lexically scoped by
    default. Either scope them package-wide or do the
    nearest block idea.

    2. You can explicitly scope variables with my or our.

    3. Global variables can still be declared with 'use vars'.

    4. Dynamic keywords (like local) still only work on
    global variables.

    Sound accurate?
    Everything except #4. I explicitly believe in allowing dynamic
    assignment on lexical variables. Way back before this list, when the
    first version of RFC 6 came out, Tom Christiansen commented, "One
    could even make Chip happy and allow one to C<scopetemp> [one of many
    proposed new names for local()] a lexical." I'm not saying Tom was
    behind the idea, but it is a possibility, and I'm behind it.
    Apparently, Chip (the same one who started Topaz, I presume?) was,
    too, at some earlier point in Perl history.
    Exactly how point #1 is implemented can be left till
    later, just as long as this:

    $x = 1;
    {
    $y = $x + 1;
    }
    print "$y";

    Works without any predeclarations.
    Agreed. Implementation suggestions (both of them) will be relegated
    to the implementation section.
    P.S. I meant "package-wide" in the previous email. The package should
    always be the outermost logical container, I think.
    But packages can span multiple files. This boogers up lexical
    scoping. Two different files should both be able to plop
    subroutines/methods (and, yes, dynamic variables if they still exist)
    into a package, but they need to depend upon their _lexical_ variables
    not clashing. Otherwise, some of the more esoteric Perl modules might
    not be able to function (those that deliberately tweak the contents of
    other packages).


    J. David
  • Nathan Wiger at Aug 18, 2000 at 4:35 am

    "J. David Blackstone" wrote:
    1) Eliminate dynamic variables entirely.
    Don't think there's a win. You'll need something identically like it,
    which means you'll have to put lexicals in the symbol table, which means
    they're just dynamics again...

    Dynamic variables aren't evil, they're just misused because they're the
    default. If you make people have to use them explicitly, I think you'll
    see some really great, thoughtful uses of them in Perl 6.
    2) Eliminate dynamic variables from default Perl, but allow their use
    with a pragma.
    Good, I like. 'use vars' should work fine.
    3) Provide a new strict pragma to disable dynamic variables.
    Naw, take a stand. #2 is already loose enough. :-)

    -Nate

Related Discussions