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.
