Re: Auto My?
On Mon, 20 Dec 2004, James Mastros wrote: 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 -- Cmy %foo = zip(@keys, @values); I think Cmy [EMAIL PROTECTED] = @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
Re: Auto My?
Luke Palmer wrote: James Mastros writes: Does this imply that it's now possible to type Cmy @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. Yes, that's the primary case I was thinking of. I was trying to find a 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 -- Cmy %foo = zip(@keys, @values); I think Cmy [EMAIL PROTECTED] = @values; reads better though, even though looking at it literally, you're attempting to lexicalize an element. -=- James Mastros, theorbtwo
Re: Auto My?
On 2004-12-19 at 21:35:46, Luke Palmer wrote:
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
Re: Auto My?
James Mastros skribis 2004-12-19 23:00 (+0100): Juerd wrote: 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. Does this imply that it's now possible to type Cmy @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. 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
Re: Auto My?
On Sun, Dec 19, 2004 at 08:25:58PM -0600, Rod Adams wrote: : 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? 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
Re: Auto My?
Juerd wrote: 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. Does this imply that it's now possible to type Cmy @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. -=- James Mastros
Re: Auto My?
James Mastros wrote: Juerd wrote: 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. Does this imply that it's now possible to type Cmy @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. 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 @[EMAIL PROTECTED] = @[EMAIL PROTECTED]; # ERROR! my %newhash; @[EMAIL PROTECTED] = @[EMAIL PROTECTED]; # 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
Re: Auto My?
On Sun, 2004-12-19 at 20:25 -0600, Rod Adams wrote: 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
Auto My?
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')? 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
Re: Auto My?
Rod Adams writes: 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
Re: Auto My?
Rod Adams skribis 2004-12-18 14:55 (-0600): 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
Re: Auto My?
- Original Message - From: Luke Palmer [EMAIL PROTECTED] 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
Re: Auto My?
JOSEPH RYAN writes: 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
