Eliminate dynamic variables entirely?

2000-08-14 Thread J. David Blackstone

  Here's a radical thought:

  In most languages, dynamic scoping of variables offers no advantages
over lexical scoping, other than dynamic assignment.  Dynamic
assignment can be accomplished with the local() operator (soon to be
renamed, I hope).  The local() operator can be extended to operate on
lexical variables as well as (or instead of; read on ...) dynamic
variables.

  The package command was created in order to allow for different
namespaces that would not conflict, back 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:

*) Dynamic variables no longer exist.
*) Lexical variables belong to the package they are declared in.  (Or,
if not declared, the package to which they belong can be inferred.)
*) 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 if they belong to a different package, but lexicals
declared in another file cannot be accessed directly.
*) In nearly all cases (hopefully approaching the magic 80% translate
100% correctly, 95% translate 95% correctly), a package (dynamic)
variable can be translated into a lexical variable defined in a .pm
file along with a class accessor method (standard get/set
functionality).  I'm thinking cases where this wouldn't work, if there
are any, would be so esoteric that someone would want to port them by
hand, anyway.
*) Packages still continue to function in the same way to define
classes.
*) Packages still continue to provide a separate namespace for non-O-O
subroutines.

  This enforces the lexically-scoped variable paradigm even more, and
best of all, *the implementers only have to worry about one type of
variable!*  Perl could cease to look like lexical variables were
hacked onto the side to fix a problem.

  If people really want true dynamic variables, there could be a
pragma. ...  Results are left to the imagination.  (In this case, I
suppose Perl would look like lexical variables designed in with
dynamic variables hacked onto the side.  Still an improvement, I
think.)

Still trying to cause trouble,
J. David



Re: Eliminate dynamic variables entirely?

2000-08-14 Thread ___cliff rayman___

Nathan Wiger wrote:


 However, make lexicals the default so that MyPackage would have to look
 like this:

package MyPackage;

# my is redundant since lexicals are default
my($internal1, $internal2) = ('value1', 'value2');

# have to use your to give this variable to other packages
your $DEBUG = 0;  # $MyPackage::DEBUG now dynamic

how  is "your" different from "our"?

use MyPackage;
our $DEBUG=1;



 I think something like this is a good idea. It's more intuitive too -
 hide your variables in your package unless you *want* to give others
 access to them.

 If you're going to write an RFC on this, cool. Otherwise I will, just to
 keep it interesting. In particular I've "fallen in love" with the
 "your()" keyword. :-)

maybe i missed something.  is this really only "your" variable or do we have
access to it in "our" package when code is executing within it?



 -Nate

 Here's a great p5p message on Perl lexicals vs. globals/dynamics:
 http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-05/msg00839.html

--
___cliff [EMAIL PROTECTED]http://www.genwax.com/





Yet another lexical variable proposal

2000-08-14 Thread J. David Blackstone

=head1 TITLE

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

=head1 VERSION

  Maintainer: J. David Blackstone [EMAIL PROTECTED]
  Date: 14 Aug 2000
  Version: 1
  Mailing List: perl6-language-strict
  Number:

=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 Cmy

In all cases, the Cmy 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 Clocal 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 Clocal 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 Cmy.  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