Are the -X functions still going to be there? I definitely hope so! However, to come to the actual question, it has happened to me to have to do, in perl5 that is:
perl -lne 's/^"//;s/"$//;print if -e'
or (less often)
perl -lne '$o=$_;s/^"//;s/"$//;print $o if -e'
Ok: no much harm done (to my fingertips). But then, talking about huffmanization, could a standard adverb be provided for -X's to the effect of specifying that the passed filename is quoted, say in double (or if sensible in single) quotes: for I find that to be a common filelist "format". Ideally, what I'd like to do is
perl -lne 'print if -e :q'
Michele -- Mary had a little lamb;/Its fleece was green as limes. And every even number greater than two/Is the sum of two primes. - Robert Israel in sci.math, "Re: all math problems reduce to linguistics"
On Thu, Apr 21, 2005 at 10:18:17AM +0200, Michele Dondi wrote:
: Are the -X functions still going to be there? I definitely hope so!
Certainly. They're useful, and one of the things people love about Perl. In fact, we're enhancing them to be stackable, so you can say
if -r -w -x $filename {...}
to "and" the conditions. Or maybe there's a better solution to that now that we have junctions, on the order of
if $filename ~~ -r & -w & -x {...}
Then we also get our "or" for free. We'd just say that ~~ binds the default of -X just as it does m// or s///.
The only fly in the ointment is that this is awfully ambiguous because -X is a unary operator looking for an argument, and you're not giving it one. But it might think the next thing is a sub ref starting with '&'. Ouch. Not sure where to go with that, other than require space or parens when ambiguous.
: However, to come to the actual question, it has happened to me to have to : do, in perl5 that is: : : perl -lne 's/^"//;s/"$//;print if -e' : : or (less often) : : perl -lne '$o=$_;s/^"//;s/"$//;print $o if -e' : : : Ok: no much harm done (to my fingertips). But then, talking about : huffmanization, could a standard adverb be provided for -X's to the effect : of specifying that the passed filename is quoted, say in double (or if : sensible in single) quotes: for I find that to be a common filelist : "format". Ideally, what I'd like to do is : : perl -lne 'print if -e :q'
It seems to me that -e «$_» would handle most of these cases, as long as whitespace always comes in quoted so that you always end up with one word. That seems more general than a special option to -X ops.
if (&prefix:<-r> & &prefix:<-w> & &prefix:<-x>)($filename) { ... }
> It seems to me that -e «$_» would handle most of these cases, as long as > whitespace always comes in quoted so that you always end up with one word. > That seems more general than a special option to -X ops.
Wouldn't it be a good option to combine the filetest operators into one operator? It'd even be historically correct to call that test:
test(:r & :w, $fn);
I still like -r -w $fn much better than the binding and the ~~ things.
On Thu, Apr 21, 2005 at 06:40:54PM +0200, Juerd wrote:
: Larry Wall skribis 2005-04-21 8:54 (-0700): : > if $filename ~~ -r & -w & -x {...} : : Just curious - would the following dwym? : : if (&prefix:<-r> & &prefix:<-w> & &prefix:<-x>)($filename) { ... }
It might do what you mean. Personally, I would never mean that if I could help it. :-)
: > It seems to me that -e «$_» would handle most of these cases, as long as : > whitespace always comes in quoted so that you always end up with one word. : > That seems more general than a special option to -X ops. : : Wouldn't it be a good option to combine the filetest operators into one : operator? It'd even be historically correct to call that test: : : test(:r & :w, $fn);
Hmm. I think this works syntactically:
$file ~~ all(:r:w)
: I still like -r -w $fn much better than the binding and the ~~ things.
There's one minor problem with -r -w $file, which is that it evaluates right-to-left, which is going to surprise some people who think they want to say
-e -r $file
when they really mean
-r -e $file
But that doesn't really matter much unless you're so much into speed that you think about falsifying the test without doing a stat().
Now the interesting thing about the ~~ approach is that it naturally lends itself to
given $file { when :x {...} when :r:w {...} when :r(0) {...} when :u | :g {...} default: }
I suppose it's a little bit rude to grab all the pairs for testing against all the strings, so maybe we have to say
given $file.test {...} $file.test ~~ :r&:w
or maybe
given $file.stat {...} $file.stat ~~ :r&:w
which leaves room for lstat if we need it, though I can't say I'm fond of the Unix naming scheme here. If we borrow from IO::All maybe it's just:
given io($file) {...} io($file) ~~ :r&:w
BTW, I'm assuming the $file is either $filename or $filehandle there.
On Thu, 21 Apr 2005, Larry Wall wrote: > : perl -lne 'print if -e :q'
> It seems to me that -e «$_» would handle most of these cases, as long as > whitespace always comes in quoted so that you always end up with one word.
I would say this is hardly the case for the kind of file lists I was referring to. Not that this is terribly relevant from a world wide perspective, I guess...
> That seems more general than a special option to -X ops.
Speaking of which, I like to think of (some) adverbs in terms of cmd line switches, and maybe it's just me, but I think it would be extremely useful to have a full set of tricky ones providing reasonable defaults (user-overridable, of course), short enough to be easy to type; e.g:
unlink :warn; # roughly equivalent to Perl5's # unlink or warn "Could not remove `$_':$!\n";
Michele -- Whoa! That is too weird! I asked around among the math faculty here and it turns out that _every one's_ wife is married to a mathematician! - Dave Rusin in sci.math, "Re: Genetics and Math-Ability"
On Fri, Apr 22, 2005 at 09:24:51AM +0200, Michele Dondi wrote:
: Speaking of which, I like to think of (some) adverbs in terms of cmd line : switches, and maybe it's just me, but I think it would be extremely useful : to have a full set of tricky ones providing reasonable defaults : (user-overridable, of course), short enough to be easy to type; e.g: : : unlink :warn; # roughly equivalent to Perl5's : # unlink or warn "Could not remove `$_':$!\n";
The problem with that approach is also evident in Unix culture. How many different ways are there to ask for help, or to get verbose output, or to specify the output filename? How many different ways are there to specify input and output delimiters? -e means something very different to Perl than to rpm. Does this version of chown use -r or -R for recursion?
Admittedly, some of these problems would have been reduced if Unix had gone with long option names to begin with. But a lot of these problems come from too many people in too many places inventing too many similar things without the benefit of a culture that encourages a common standard without forcing one. In Perl culture we must guard against the extremes of central control vs anarchy, and choose a middle path.
And some of these things can be headed off by designing the interface differently. We wouldn't need a recursion option on chmod/chown/cp etc. if Unix had a notation for "all the files under this one". Similarly, if Perl has consistent warning and exception mechanisms that are easy to use and properly scoped, people are less tempted to make up one of their own.
All that being said, we did design named parameters into Perl 6 so that an interface could have options. But people are quick to add options without thinking about the global consequences of name choice. I feel like there's a cultural solution there somewhere, but I don't know what it is, because that's the sort of thing cultures are better at inventing than I am. :-)
> There's one minor problem with -r -w $file, which is that it evaluates > right-to-left, which is going to surprise some people who think they > want to say > -e -r $file > when they really mean > -r -e $file
It doesn't have to, of course. The test can be postponed and delegated to the lexical first -X operator. A matter of letting -X behave differently in -X context than in any other context, I guess.
> Now the interesting thing about the ~~ approach is that it naturally > lends itself to > given $file { > when :x {...} > when :r:w {...} > when :r(0) {...} > when :u | :g {...} > default: > } > I suppose it's a little bit rude to grab all the pairs for testing > against all the strings, so maybe we have to say > given $file.test {...} > $file.test ~~ :r&:w > or maybe > given $file.stat {...} > $file.stat ~~ :r&:w
Perfect!
> BTW, I'm assuming the $file is either $filename or $filehandle there.
Which brings me to the following: can open please use the same kind of $file, so that open $filehandle just checks $filehandle's mode and returns $filehandle again? That way, every library function that accepts a filename automatically also accepts an open filehandle, which has a thousand and one benefits.
On Fri, Apr 22, 2005 at 11:28:06AM +0200, Juerd wrote:
: Which brings me to the following: can open please use the same kind of : $file, so that open $filehandle just checks $filehandle's mode and : returns $filehandle again? That way, every library function that accepts : a filename automatically also accepts an open filehandle, which has a : thousand and one benefits.
You speak of "open" as if it must be a single function. We're now living in the age of MMD, so what you're asking for is a no-brainer. If we decided to we could even do MMD with constraints:
multi sub open ($u of Str where /^file:/, *@opts) returns Handle {...} multi sub open ($u of Str where /^http:/, *@opts) returns Handle {...} multi sub open ($u of Str where /^ftp:/, *@opts) returns Handle {...} multi sub open ($u of Str where /^mailto:/, *@opts) returns Handle {...} ...
Though that would potentially be problematic if you wanted to open a file whose name started with "http:", so we'd probably want to give that suite of multis a different name. Call it io() maybe, if we can unify the Handle and IO abstractions. As I've said before, I kinda like the IO::All module, except for how it overloads < and >. But Perl 6 has ==> and <== that can do that instead, which just happen to be called "pipes", strange coincidence. :-)
> multi sub open ($u of Str where /^http:/, *@opts) returns Handle {...} > Though that would potentially be problematic if you wanted to open > a file whose name started with "http:"
open "./http://..."; open "file://$CWD/http://...";
:)
In fact, I'm a big proponent of using URIs instead of filenames where possible. It can even provide a more portable way of saying \\sambaserver\share, in smb://sambaserver/share, which can be translated to whatever the system supports, possibly failing because it's just not supported.
> I kinda like the IO::All module, except for how it overloads < and >. > my $page <== io("http://www.wall.org/~larry");
"IO" used in this way denies that there's non-stream-based IO too. Waiting for a certain wire to get shorted is input too, as is writing directly to graphic memory a form of output.
On Fri, Apr 22, 2005 at 05:53:48PM +0200, Juerd wrote:
: > I kinda like the IO::All module, except for how it overloads < and >. : > my $page <== io("http://www.wall.org/~larry"); : : "IO" used in this way denies that there's non-stream-based IO too.
How so? Where's the xor?
: Waiting for a certain wire to get shorted is input too, as is writing : directly to graphic memory a form of output.
I don't see how an IO is prevented from being used like any other handle. The handle type is there so MMD can pick out particular behaviors for <== and syswrite(). And different subtypes of handles can pick out different behaviors. Even the OS can keep track of the types of file descriptors that are just integers as far as the user is concerned.
On Fri, 22 Apr 2005 14:24:25 -0400, Juerd <ju...@convolution.nl> wrote:
> Because a URI scheme ends in :. It http: followed by anything other than > // should fail because it is invalid, not fall back to file handling. > IFF you're handling URIs.
>> multi sub open ($u of Str where /^mailto:\/\//, *@opts) returns >> Handle {...}
> Well, it's mailto:exam...@example.com, not mailto://exam...@example.com.
True, I did not think of that. But it can at least be defined for most URI schemes to check for ://, in the case of HTTP, FTP, etc.
We're talking about the *built-in* functions here, right?
Anyway, is there any other URI scheme besides for mailto: that doesn't use <://>? mailto isn't something you can "open" really, for read at least. If it's for built-in, then only the most common protocols would be defined I imagine. The ones I can think of that you can read from/stream in use <://>, so I don't see why the methods for those protocols can't be defined with <://>. Maybe I'm missing something here though.. which does happen a lot ;)
>> Also, I don't know much about rules with regex yet, but could you do >> something like... >> multi sub open ($u of Str where /<protocol(file)>/, *@opts) returns >> Handle {...} >> Where < <protocol(file)> > expands to < file:// >
> Yes, but it's probably easier to just use a hash: %protocol<file>.
On Fri, 22 Apr 2005 11:42:10 -0400, Larry Wall <la...@wall.org> wrote:
> You speak of "open" as if it must be a single function. We're now > living in the age of MMD, so what you're asking for is a no-brainer. > If we decided to we could even do MMD with constraints:
> multi sub open ($u of Str where /^file:/, *@opts) returns Handle > {...} > multi sub open ($u of Str where /^http:/, *@opts) returns Handle > {...} > multi sub open ($u of Str where /^ftp:/, *@opts) returns Handle {...} > multi sub open ($u of Str where /^mailto:/, *@opts) returns Handle > {...} > ...
> Though that would potentially be problematic if you wanted to open > a file whose name started with "http:", so we'd probably want to > give that suite of multis a different name. Call it io() maybe, if > we can unify the Handle and IO abstractions. As I've said before, > I kinda like the IO::All module, except for how it overloads < and >. > But Perl 6 has ==> and <== that can do that instead, which just happen > to be called "pipes", strange coincidence. :-)
Well why can't you define the functions like so:
multi sub open ($u of Str where /^file:\/\//, *@opts) returns Handle {...} multi sub open ($u of Str where /^http:\/\//, *@opts) returns Handle {...} multi sub open ($u of Str where /^ftp:\/\//, *@opts) returns Handle {...} multi sub open ($u of Str where /^mailto:\/\//, *@opts) returns Handle {...}
Also, I don't know much about rules with regex yet, but could you do something like...
multi sub open ($u of Str where /<protocol(file)>/, *@opts) returns Handle {...}
> Well why can't you define the functions like so:
Because a URI scheme ends in :. It http: followed by anything other than // should fail because it is invalid, not fall back to file handling. IFF you're handling URIs.
> multi sub open ($u of Str where /^mailto:\/\//, *@opts) returns > Handle {...}
Well, it's mailto:exam...@example.com, not mailto://exam...@example.com.
> Also, I don't know much about rules with regex yet, but could you do > something like... > multi sub open ($u of Str where /<protocol(file)>/, *@opts) returns > Handle {...} > Where < <protocol(file)> > expands to < file:// >
Yes, but it's probably easier to just use a hash: %protocol<file>.
> mailto isn't something you can "open" really, for read at least.
No, but writing to it ought to simplify things :)
given open 'mailto:m...@weakmind.org' { .say(q0:to<.> Subject: Useful mailto open User-Agent: Perl 6 In-Reply-To: <op.spnc0sii8hsiyb@codeslut>
Hello, world! . ); .close or fail; }
> If it's for built-in, then only the most common protocols would be defined > I imagine.
No, if it's built in, we should stick to the spec and interpret every ^\w+: (roughly - see RFCs for syntax specifics) as a scheme.
> >>Also, I don't know much about rules with regex yet, but could you do > >>something like... > >> multi sub open ($u of Str where /<protocol(file)>/, *@opts) returns > >>Handle {...} > >>Where < <protocol(file)> > expands to < file:// > > >Yes, but it's probably easier to just use a hash: %protocol<file>. > Easier or more efficient?
> Anyway, is there any other URI scheme besides for mailto: that doesn't use > <://>?
> It¹s optional for news:; news:comp.lang.perl is a valid URI for accessing that > Usenet newsgroup via whatever your default news server is.
> There aren¹t any slashes in the aim: scheme (not part of the IANA standard, > but widely supported for accessing AOL-compatible IM clients from web > browsers).
> There are no slashes in tel: (telephone numbers), though I don¹t know what you > could do with those from Perl. :)
> And I¹m sure there are others. The syntax after the colon is pretty much > arbitrarily determined by the scheme prefix, so a global constraint on it is a > bad idea.
On Fri, 22 Apr 2005 15:09:21 -0400, Juerd <ju...@convolution.nl> wrote: > Matt skribis 2005-04-22 14:44 (-0400): >> mailto isn't something you can "open" really, for read at least.
> No, but writing to it ought to simplify things :)
> given open 'mailto:m...@weakmind.org' { > .say(q0:to<.> > Subject: Useful mailto open > User-Agent: Perl 6 > In-Reply-To: <op.spnc0sii8hsiyb@codeslut> > Hello, world! > . > ); > .close or fail; > }
Good point, I didn't think of that :) That would be awesome if you could do that in perl6 without needing any extra libraries.
On Fri, Apr 22, 2005 at 09:09:21PM +0200, Juerd wrote:
: Matt skribis 2005-04-22 14:44 (-0400): : > We're talking about the *built-in* functions here, right? : : I don't know. : : > Anyway, is there any other URI scheme besides for mailto: that doesn't use : > <://>? : : I don't know, but if you want to find this out, : http://www.iana.org/assignments/uri-schemes is probably a good starting : point. : : > mailto isn't something you can "open" really, for read at least. : : No, but writing to it ought to simplify things :) : : given open 'mailto:m...@weakmind.org' { : .say(q0:to<.> : Subject: Useful mailto open : User-Agent: Perl 6 : In-Reply-To: <op.spnc0sii8hsiyb@codeslut> : : Hello, world! : . : ); : .close or fail; : }
I should point out that we're still contemplating breaking .foo() so it no longer means $_.foo(). I wish there were more keys on my keyboard...
I know it's a bit counter-cultural, but at the moment I'm wondering if we can make this work instead:
given open 'mailto:m...@weakmind.org' { _say(...); _close or fail; }
We do, after all, have better ways of declaring private methods and functions now. so maybe we don't need to reserve _ for that anymore. And it would save two characters over $_.foo(). But recovering C programmers will scream, and probably prefer _.foo(), even if it only saves one character. Maybe it's time to raid Latin-1 for the next closest thing to a dot, "middle dot":
given open 'mailto:m...@weakmind.org' { ·say(...); ·close or fail; }
But I'm sure some will argue that's too subtle. (Hi, @Larry<Damian>.)
Well, hey, as long as we're looking at Latin-1, we could use superscripts to indicate nested topic defaults.
given open 'mailto:m...@weakmind.org' { say¹(...); close¹ or fail; }
Then foo² would be $OUTER::_.foo(), foo³ would be $OUTER::OUTER::_.foo().
Or we go back to .foo always meaning $_.foo and use ¹.foo to call the first invocant, ².foo to call the second, ³.foo to call the third. Interestingly, 1.foo, 2.foo, 3.foo etc. would work as ASCII workarounds if we didn't autobox literal numbers. Though that would put a crimp in the Rubyish
3.times:{ say "It's true!" }
Okay, that's kinda nuts. How 'bout we change ! to ¬ and then we can say:
given open 'mailto:m...@weakmind.org' { !say(...); !close or fail; }
Sigh. We could also take ` away from user-defined literals and say
given open 'mailto:m...@weakmind.org' { `say(...); `close or fail; }
But I rather like ` for user-defined literals. I suppose bare ^ is also available:
given open 'mailto:m...@weakmind.org' { ^say(...); ^close or fail; }
That almost makes sense, given that $^a is like $_. It also points vaguely upward toward some antecedent. I could maybe get used to that, if I tried real hard for a long time. Almost makes we wish we could rename $_ to $^ though. Hmm...
: > If it's for built-in, then only the most common protocols would be defined : > I imagine. : : No, if it's built in, we should stick to the spec and interpret every : ^\w+: (roughly - see RFCs for syntax specifics) as a scheme.
On Fri, 22 Apr 2005 21:31:03 -0400, Larry Wall <la...@wall.org> wrote:
> given open 'mailto:m...@weakmind.org' { > ^say(...); > ^close or fail; > }
> That almost makes sense, given that $^a is like $_. It also points > vaguely > upward toward some antecedent. I could maybe get used to that, if I > tried real hard for a long time. Almost makes we wish we could rename > $_ to $^ though. Hmm...
I think ^ makes the most sense. I like how it points up. Like it's saying "HEY! THE TOPIC IS UP THERE!"
Though, it IS still a bit odd. It seems more like a modifier on the function, than a reference to the topic.
What about . for each level up you want to go?
instead of 1.say, 2.say, 3.say you use .say, ..say, ...say
Larry Wall wrote: > I should point out that we're still contemplating breaking .foo() so it > no longer means $_.foo(). I wish there were more keys on my keyboard...
> I know it's a bit counter-cultural, but at the moment I'm wondering > if we can make this work instead:
> given open 'mailto:m...@weakmind.org' { > _say(...); > _close or fail; > }
> We do, after all, have better ways of declaring private methods and > functions now. so maybe we don't need to reserve _ for that anymore. > And it would save two characters over $_.foo(). But recovering C
I kind of like that, but see below.
> programmers will scream, and probably prefer _.foo(), even if it only > saves one character. Maybe it's time to raid Latin-1 for the next > closest thing to a dot, "middle dot":
> given open 'mailto:m...@weakmind.org' { > ·say(...); > ·close or fail; > }
> But I'm sure some will argue that's too subtle. (Hi, @Larry<Damian>.)
I agree, too subtle.
> Well, hey, as long as we're looking at Latin-1, we could use superscripts > to indicate nested topic defaults.
> given open 'mailto:m...@weakmind.org' { > say¹(...); > close¹ or fail; > }
> Then foo² would be $OUTER::_.foo(), foo³ would be $OUTER::OUTER::_.foo().
> Or we go back to .foo always meaning $_.foo and use ¹.foo to call the > first invocant, ².foo to call the second, ³.foo to call the third. > Interestingly, 1.foo, 2.foo, 3.foo etc. would work as ASCII workarounds > if we didn't autobox literal numbers.
Given I like _.foo(), we can get around the autobox problem by using _2.foo(), _3.foo, etc. Even though those are legal(?) variable names I've never seen them used in code anywhere.
> But I rather like ` for user-defined literals. I suppose bare ^ > is also available:
> given open 'mailto:m...@weakmind.org' { > ^say(...); > ^close or fail; > }
This kind of works also. And it would allow ^2.foo(), ^3.foo(), etc. or even ^^.foo(), ^^^.foo(), etc (nah!).
> That almost makes sense, given that $^a is like $_. It also points vaguely > upward toward some antecedent. I could maybe get used to that, if I > tried real hard for a long time. Almost makes we wish we could rename > $_ to $^ though. Hmm...
> I should point out that we're still contemplating breaking .foo() so it > no longer means $_.foo(). I wish there were more keys on my keyboard...
Which I think would be a very bad idea, so while I can (as long as no other decision has been made), I'm using the current syntax :)
I even consider breaking compatibility with bare Perl 6, for my grammar, if that's necessary to get .foo to use the same implicit LHS as .[5].
Subs and loops are related, and aliasing the invocant as $_ the same way a loop aliases the loop variable as $_ makes sense to me. when you use a loop within a sub, do the same thing as when you use a loop within another loop: explicitly use the full name, or use OUTER::.
> We do, after all, have better ways of declaring private methods and > functions now. so maybe we don't need to reserve _ for that anymore.
I was planning on using prefixed underscore for macros that slurp up till the end of a line, so syntax highlighting could be adjusted for those things that would otherwise break. With non-underscore, I'd have to use a litter, or make my macro a prefix operator, which is more work.
> And it would save two characters over $_.foo(). But recovering C > programmers will scream, and probably prefer _.foo(), even if it only > saves one character.
_ on my keyboards is two keys, shift and -, while . is only one.
In fact, I find $_.foo even easier to type than _.foo, and better looking. Especially because the $ sigil is part of the name now, _ without sigil should not be used.
> Maybe it's time to raid Latin-1 for the next closest thing to a dot, > "middle dot": > ·say(...); > ·close or fail;
Please, no.
> But I'm sure some will argue that's too subtle. (Hi, @Larry<Damian>.)
String index for an array?
> say¹(...); > close¹ or fail; > Then foo² would be $OUTER::_.foo(), foo³ would be $OUTER::OUTER::_.foo().
For that matter, I think repeating prefixed dots works just as well:
>> What about . for each level up you want to go? >> instead of 1.say, 2.say, 3.say >> you use .say, ..say, ...say >> (Ok, I'm just kidding.. really!)
> I read your message after I suggested the same thing (I'm too impatient > to read all new messages before sending replies).
> Why were you just kidding? I think it's a great idea.
I like it too.
In normal writing ... acts as a kind of 'think back' operator. Even though the writer uses it to signal an afterthought - it also makes the reader 'think back' to what preceded the afterthought.
Syntax like .say ..say ...say enables the writer to add an afterthought and the reader to 'think back' to precisely the right scope. It allows you to have N scopes too .....say, that would be cool.
I hope this doesn't cause trouble for yada yada because I really like that operator too.
On Sat, 23 Apr 2005 07:25:10 -0400, Juerd <ju...@convolution.nl> wrote: > Matt skribis 2005-04-22 21:55 (-0400): >> What about . for each level up you want to go? >> instead of 1.say, 2.say, 3.say >> you use .say, ..say, ...say >> (Ok, I'm just kidding.. really!)
> I read your message after I suggested the same thing (I'm too impatient > to read all new messages before sending replies).
> Why were you just kidding? I think it's a great idea.
> Juerd
Well I like it too. I just didn't think anyone would actually go for it. I guess I underestimated how crazy you guys are ;)
Matt wrote: > On Sat, 23 Apr 2005 07:25:10 -0400, Juerd <ju...@convolution.nl> wrote:
>> Matt skribis 2005-04-22 21:55 (-0400):
>>> What about . for each level up you want to go? >>> instead of 1.say, 2.say, 3.say >>> you use .say, ..say, ...say >>> (Ok, I'm just kidding.. really!) >> I read your message after I suggested the same thing (I'm too impatient >> to read all new messages before sending replies).
>> Why were you just kidding? I think it's a great idea. > Well I like it too. I just didn't think anyone would actually go for > it. I guess I underestimated how crazy you guys are ;)
After some further thought (and a phone talk with Larry), I now think that all of these counted-level solutions (even my proposal of _2.foo(), etc.) are a bad idea. They have a similar problems to constructs like "next 5;" meaning jump to the next iteration of the loop 5 level out. Any time you refactor you code and change levels, they break in a subtle and very hard to debug way, causing mysterious errors. Just like the current Perl construct of "labeled loops" so that you can talk about the target loop explicitly, the proper solution for up-level access to $OUTER::OUTER::...::OUTER::_ is to create a named binding like "$uplevel_topic := $_;" at that upper level and then use that to refer to it at lower levels. Beside is ".......foo();" seven of eight levels up? Any other way than explicit naming is madness; leading to unreadable and unmaintainable code.
