Auto My?
Rod Adams
dictates a heavy insistence on 'my'. I will thus assume that creation of
lexical variables with 'my' far out numbers the creation of package
space globals. Should we not then have it where it's the default
behavior, and creation of package ones take explicit declaration (via
'our')?
Well, at least when strictures are on. When they are off, the coder is
obviously playing fast and loose, and should get the easy 'everything
global' behavior.
What issues am I overlooking here?
-- Rod
Juerd
> Considering that "proper" and common usage, not to mention strictures,
> dictates a heavy insistence on 'my'. I will thus assume that creation of
> lexical variables with 'my' far out numbers the creation of package
> space globals. Should we not then have it where it's the default
> behavior, and creation of package ones take explicit declaration (via
> 'our')
No.
Some other languages, including Ruby, do this. I dislike it. The best
thing about strict is that it catches typos. With automatic declaration,
you loose typo checking, or solve it in an ugly manner by requiring
assignment (which is still declaration, just with different syntax).
Just typing "my " before the first use of a variable isn't hard, and it
makes things much clearer for both the programmer and the machine. For
the programmer, because you immediately see what some variable's scope
is, and for the machine because it no longer has to guess whether
something's a typo in order to warn you ("used only once" is not always
a typo).
Juerd
Luke Palmer
> Considering that "proper" and common usage, not to mention strictures,
> dictates a heavy insistence on 'my'. I will thus assume that creation
> of lexical variables with 'my' far out numbers the creation of package
> space globals. Should we not then have it where it's the default
> behavior, and creation of package ones take explicit declaration (via
> 'our')?
Larry has addressed this before, coining "I made 'my' short for a
reason". Python and Ruby both autodeclare in the lexical scope like
this, and some people like that. Sometimes you see bogus assignments
in those languages just to declare a variable in an outer scope.
Also, the idea is a bit brittle in the face of large subs. If you
change the control flow a little bit, you might accidentally change a
variable's scope, and then what you thought was one variable just became
two distinct lexicals.
There are pros and cons, and it basically ends up being a design choice.
> Well, at least when strictures are on. When they are off, the coder is
> obviously playing fast and loose, and should get the easy 'everything
> global' behavior.
When strictures are on, the compiler ought to die if you're tyring to
use a variable without declaration. This is another reason why Perl
doesn't like autodeclaration.
Luke
Joseph Ryan
From: Luke Palmer <lu...@luqui.org>
Date: Saturday, December 18, 2004 4:16 pm
Subject: Re: Auto My?
> Rod Adams writes:
> There are pros and cons, and it basically ends up being a design
> choice.
> > Well, at least when strictures are on. When they are off, the
> coder is
> > obviously playing fast and loose, and should get the easy
> 'everything
> > global' behavior.
>
> When strictures are on, the compiler ought to die if you're tyring to
> use a variable without declaration. This is another reason why Perl
> doesn't like autodeclaration.
As bad of an idea that I think this is, I wonder if
Perl6's reflection capabilities will be powerful
enough to where a module/pragma could be written
that would be able to do this? For instance, one
idea was: lexically change the current grammar to a
subclass of the grammar. In this subclass, there is
a hook on the "variable" deparsing rule that will
implictly declare a variable into its outer scope if
it has not yet been declared in the current scope.
Totally whacky, sure; but doable?
That brings up another idea that I had just now:
will it be possible to load 2 different grammars at
once if they don't conflict with each other? For
instance, say we have loaded a grammer,
Grammar::WhackyVars, that subclasses from the main
Perl6 grammar but modifies the "variable" rule
somehow. However, then say I want to use a grammar
that also subclasses from the main Perl6 grammar
that lets you use "happyfunactiontime" instead of
the word "class". Since the modified rules don't
conflict with each other, can I just "use
Grammar::HappyFunActionTime" and everything will
work? Or will Grammar::HappyFunActionTime overload
the changes done by the Grammar::WhackyVars?
- Joe
Luke Palmer
> As bad of an idea that I think this is, I wonder if Perl6's reflection
> capabilities will be powerful enough to where a module/pragma could be
> written that would be able to do this? For instance, one idea was:
> lexically change the current grammar to a subclass of the grammar. In
> this subclass, there is a hook on the "variable" deparsing rule that
> will implictly declare a variable into its outer scope if it has not
> yet been declared in the current scope. Totally whacky, sure; but
> doable?
I don't doubt it. I'd write it right now, but we don't know enough
about the compiler interface yet.
> That brings up another idea that I had just now: will it be possible
> to load 2 different grammars at once if they don't conflict with each
> other? For instance, say we have loaded a grammer,
> Grammar::WhackyVars, that subclasses from the main Perl6 grammar but
> modifies the "variable" rule somehow. However, then say I want to use
> a grammar that also subclasses from the main Perl6 grammar that lets
> you use "happyfunactiontime" instead of the word "class". Since the
> modified rules don't conflict with each other, can I just "use
> Grammar::HappyFunActionTime" and everything will work? Or will
> Grammar::HappyFunActionTime overload the changes done by the
> Grammar::WhackyVars?
This begs the use of a particular abstraction Perl 6 has introduced with
grammars. Maybe grammar munges aren't subclasses at all, but
grammatical roles.
The only problem I see with such roles is code generation. If we're
going to make it parse in such a modular way, we ought to generate code
in the same modular way. That will take some clever design (but I think
it can be done). This is important insight right about now, since we're
rethinking what the parse tree that rules spit out looks like.
Luke
James Mastros
> Just typing "my " before the first use of a variable isn't hard, and it
> makes things much clearer for both the programmer and the machine.
declare @foo? In the current perl, this doesn't work -- it's a syntax
error. It'd certainly make many constructs easier.
-=- James Mastros
Luke Palmer
That looks weird to me. But as Rod points out, it can be useful with
hashes.
In Perl 5 you can do the hackish:
(\my @foo)->[23] = 42;
Luke
Chromatic
> One of the other reasons in favor of the idea was aesthetic.
>
> # stuff which declares $x, $z, and $q
>
> $x = 4;
> my $y = 7;
> $z = 12;
> my $r = 4543;
> $q = 121;
>
> compared to:
>
> # stuff which declares $x, $z, and $q
>
> $x = 4;
> $y = 7;
> $z = 12;
> $r = 4543;
> $q = 121;
>
> With a fixed width font, like all code editors use, all the =' like up,
> and I can quickly scan the var names to get to the one I want to change
> at that moment.
If you align the equals signs yourself with spaces, you can use variable
names of different lengths (and possibly improved meaningfulness in
actual factual code) too.
I'm only half-joking. Vertical alignment makes a dramatic difference to
readability.
-- c
Rod Adams
I see why that's an error. It can be very confusing.... In literal
fashion you are attempting to make the 24th element of @foo lexical, and
having some elements of @foo have different scope from the rest is a bad
idea.
However, I have also been bitten by that rather frequently, though with
a different construct. Typically it's with hash slices:
my @newhash{@fields} = @oldhash{@fields}; # ERROR!
my %newhash;
@newhash{@fields} = @oldhash{@fields}; # Okay, but not as convienent.
This was part of the reason I spawned this thread. But it was also due
to being in the middle of trying to write some decent quality code under
a heavy time pressure, and noticed that >50% of my lines had a 'my' on
them. It's typically not that high of a percentage, but when you are
creating lots of small utility routines, declaring all your lexicals can
be a significant part of the task. I added to this the observation that
lexical variables are significantly more common than non-lexicals, and
thought out loud as to why I was doing more work for the common case
than the uncommon case, in a language that generally doesn't have that
problem.
One of the other reasons in favor of the idea was aesthetic.
# stuff which declares $x, $z, and $q
$x = 4;
my $y = 7;
$z = 12;
my $r = 4543;
$q = 121;
compared to:
# stuff which declares $x, $z, and $q
$x = 4;
$y = 7;
$z = 12;
$r = 4543;
$q = 121;
With a fixed width font, like all code editors use, all the =' like up,
and I can quickly scan the var names to get to the one I want to change
at that moment. Yes, I could have added a 'my ($y, $r);' to the front of
the list, but that's adding another statement to the mix, same as the
hash slice above, adding considerably more weight to 'my' than just
three keystrokes (m - y - space).
However, given the strong opposition (with merits) to this in other
responses, I am willing to live with it the P5 way. Just seemed like
autolexicals was rather DWIMish.
Another facet of this discussion comes into account when also specifying
type.
from S9:
my bit @bits;
my int @ints;
my num @nums;
my int4 @nybbles;
my str @buffers;
my ref[Array] @ragged2d;
my complex128 @longdoublecomplex;
Wouldn't this be much better as:
bit @bits;
int @ints;
num @nums;
int4 @nybbles;
str @buffers;
ref[Array] @ragged2d;
complex128 @longdoublecomplex;
Given that most of the stated reservations had to deal with explicit
declaration better defining scope, what is wrong with drooping the my in
this case?
-- Rod Adams
Mark J. Reed
> In Perl 5 you can do the hackish:
>
> (\my @foo)->[23] = 42;
Hm. My reaction to the above is, and I think I speak for the entire
assemblage when I say this, "Yuckbo."
:)
Now, (my @foo)[23] would be somewhat better, but of course, that's
attempting to assign to an element of a nonce list, not an array.
I think it would be reasonable for { my @foo[23] = 42; } to be legal
Perl 6 that declares @foo as lexical. Letting { my $foo[23] = 42; }
work in Perl 5 would be weirder, but Perl6's "arrays always have @"
means that it's pretty clear you're declaring an array rather than a single
element.
Just my 2c.
-Mark
James Mastros
> James Mastros writes:
>>Does this imply that it's now possible to type C<my @foo[23] = 42;>, and
>>declare @foo? In the current perl, this doesn't work -- it's a syntax
>>error. It'd certainly make many constructs easier.
>
> That looks weird to me. But as Rod points out, it can be useful with
> hashes.
smaller example.
OTOH, I realize now you can do that with zip in P6, in which case you do
have a mention of the whole variable to stick a my on -- C<my %foo =
zip(@keys, @values);> I think C<my %foo{@keys} = @values;> reads better
though, even though looking at it literally, you're attempting to
lexicalize an element.
-=- James Mastros,
theorbtwo
Luke Palmer
Know what's cool?
my %foo = @keys »=>« @values;
I think we have enough WTDI now.
Luke
Stéphane Payrard
> On Sun, 2004-12-19 at 20:25 -0600, Rod Adams wrote:
> >
> > $x = 4;
> > $y = 7;
> > $z = 12;
> > $r = 4543;
> > $q = 121;
> >
> > With a fixed width font, like all code editors use, all the =' like up,
> > and I can quickly scan the var names to get to the one I want to change
> > at that moment.
>
> If you align the equals signs yourself with spaces, you can use variable
> names of different lengths (and possibly improved meaningfulness in
> actual factual code) too.
>
> I'm only half-joking. Vertical alignment makes a dramatic difference to
> readability.
>
> -- c
>
Speaking of alignement, my understanding is that the .[] operator,
allows spacing while [] does not:
$a = @shortnm .[0 ];
$b = @longername .[42];
--
stef
Juerd
I didn't mean to imply that, but I sure think it's a great idea, even
though I can't think of useful examples (as everything I can come up
with is more elegantly done with vector ops or map anyway).
Juerd
Larry Wall
: Another facet of this discussion comes into account when also specifying
:
: from S9:
: my bit @bits;
: my int @ints;
: my num @nums;
: my int4 @nybbles;
: my str @buffers;
: my ref[Array] @ragged2d;
: my complex128 @longdoublecomplex;
:
: Wouldn't this be much better as:
: bit @bits;
: int @ints;
: num @nums;
: int4 @nybbles;
: str @buffers;
: ref[Array] @ragged2d;
: complex128 @longdoublecomplex;
:
: Given that most of the stated reservations had to deal with explicit
: declaration better defining scope, what is wrong with drooping the my in
: this case?
How 'bout ambiguity with unary ops like "int" and "ref", or any
other unaries anyone ever decides to have that might conflict with
type names. Plus it's just visually confusing. Making it hard to
tell declarations from statements is one of the areas where C made
a big mistake, and I am not at all tempted to repeat it.
Larry
Michele Dondi
> OTOH, I realize now you can do that with zip in P6, in which case you do have
> a mention of the whole variable to stick a my on -- C<my %foo = zip(@keys,
> @values);> I think C<my %foo{@keys} = @values;> reads better though, even
> though looking at it literally, you're attempting to lexicalize an element.
But dealing with a natural language, or with a programming language that
is so strongly inspired by natural languages it doesn't seem so mandatory
to have to "look at it literally". I don't know if it will be eventually
chosen so, but since (even intuitively speaking) you can't lexicalize an
element of an aggregate, an alleged attempt to do so could perfectly well
be Perl's lingo for what some people already think to be a logical way to
interpret it...
Michele
--
The trouble with engineers is that given the problem of knocking down
a stack of 100 bricks, they will start at the top, and work all
day removing them one at a time, while the mathematician will, after
a momemt's thought, remove the bottom brick and be done with it.
The "trouble" part, is having to brook the noise of the engineer
boasting about how much harder he worked while one is trying to
think about the next problem.
- Bart Goddard in sci.math