Re: RFC 290 (v1) Remove -X
Uri Guttman [EMAIL PROTECTED] writes: "JSD" == Jonathan Scott Duff [EMAIL PROTECTED] writes: I'll revise the RFC to add 'readable()', 'writable()', and such synonyms for -r and -w that are more like 'use english' and less like 'use English'. i have a minor problem with the names readable and writeable. i am currently using them as method names in a major project i have created. they are callbacks (see my recent callback rfc) which mean the socket is readable/writeable. maybe put some sort of prefix on them to designate them as file test operators so we don't clutter up the namespace so much. also the common prefix will make it clear tha tthey are part of the family of file test ops. here are some ideas which you can shoot down: a minus prefix like the current -r -readable -tty or has_ as the file has read permission: has_readable has_executable or is_ if the file is a text file: is_text is_sticky is_writable I refer you to my previous message (archived in http://tmtowtdi.perl.org/archive?35:mss:4575). Basically, not have a prefix predicates should have! Another option is to stuff the long names into some namespace, and export them upon request (or maybe not export them, upon request). [...] -- Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED] Compugen Ltd. |Tel: +972-2-5713025 (Jerusalem) \ We recycle all our Hz 72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`- Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: RFC 290 (v1) Remove -X
On 27 Sep 2000 09:16:10 +0300, Ariel Scolnicov wrote: Another option is to stuff the long names into some namespace, and export them upon request (or maybe not export them, upon request). Can you say "method"? -- Bart.
Re: RFC 290 (v1) Remove -X
On Wed, Sep 27, 2000 at 08:50:28AM +0200, Bart Lateur wrote: On 27 Sep 2000 09:16:10 +0300, Ariel Scolnicov wrote: Another option is to stuff the long names into some namespace, and export them upon request (or maybe not export them, upon request). Can you say "method"? Doesn't work on scalars. Unless every scalar should have a 'readable()' method *just in case* it could contain a filename. Not sure I like that. I just drafted a set of methods. The basic problem is -e = exists(), and -S = socket(), which are already taken. I didn't like the idea of -e = present(), and I couldn't think of a synonym for exists that begins with 'e', nor a synonym for socket that begins with 's'. :-) If that isn't enough, I think we all forgot about thie difference between -r and -R, which *really confuses things. Is one of them more readable than the other? It's late, and I'm just going through another revision of 4 of my last 5, and I went with f*() and F*() for the -RWX. Not as bad as filetest::readable() filetest::really_readable() filetest::exists() filetest::socket() ... Update to be posted as soon as the left hand finds out what the right hand was doing... Z.
Better Security support (was: RFC 290 (v1) Remove -X)
The -wd syntax (writeable directory) is nicer than file($file, "wd"). But anyway, there's hardly anything wrong with -w -d. Don't understand the complaint. One thing I would really like to see is better security support. Look at the Camel-III's security chapter, File::Temp, and the is_safe stuff I've done lately. Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Re: RFC 290 (v1) Remove -X
On Tue, Sep 26, 2000 at 12:34:00AM -0400, Adam Turoff wrote: Making '@permissions = -rwx $filename;' work is an interesting new suggestion. Yep. Of course, I should say that I've been hanging out with some snake-hearders recently. Hey, we could learn a thing or two from some snake herders. (Watch how they get bit and don't do the same ;-) I'll revise the RFC to add 'readable()', 'writable()', and such synonyms for -r and -w that are more like 'use english' and less like 'use English'. Excellent. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 290 (v1) Remove -X
"JSD" == Jonathan Scott Duff [EMAIL PROTECTED] writes: I'll revise the RFC to add 'readable()', 'writable()', and such synonyms for -r and -w that are more like 'use english' and less like 'use English'. i have a minor problem with the names readable and writeable. i am currently using them as method names in a major project i have created. they are callbacks (see my recent callback rfc) which mean the socket is readable/writeable. maybe put some sort of prefix on them to designate them as file test operators so we don't clutter up the namespace so much. also the common prefix will make it clear tha tthey are part of the family of file test ops. here are some ideas which you can shoot down: a minus prefix like the current -r -readable -tty or has_ as the file has read permission: has_readable has_executable or is_ if the file is a text file: is_text is_sticky is_writable also you have to differentiate -R from -r. is_euid_readable is_ruid_writeable and then names for -M/A/C don't work with is/has: file_mod_time file_access_time i don't mind having the longer names as an option, but it should be a pragma/module and the namespace has to be clean. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 290 (v1) Remove -X
"John L. Allen" wrote: The use of a caret was to prevent decimation of the user's namespace, perl -e 'print -^rwx $_' syntax error at -e line 1, near "-^" Execution of -e aborted due to compilation errors. The only problem I have with a caret is that to me the proposal doesn't "jibe" with it's current use of negating a character class in a regexp and it's proposed use for currying. Clayton
Re: RFC 290 (v1) Remove -X
On Tue, Sep 26, 2000 at 02:13:41PM -0400, Uri Guttman wrote:
and if the file test names are only loaded via a pragma it should be
ok. it is not clear to me that you want that.
It's not clear that I want that either.
This is probably a plea for a subset of 'use english;', possibly
'use english "filetests";'
But I wouldn't want that pragma to override any other aspect of the
core library, such as async I/O.
also i think a common
prefix idea is still valid as it will make it more apparent that these
are from the file test family.
That's a stone's throw awaty from:
import english
from english import filetest
result = filetest.readable("/dev/null")
I think the common prefix idea is a nonstarter. There must be a way
to coming up with sensible names for all of -X that don't conflict
with the core library. Besides, AIO has a requirement on
'sub Foo::readable()', which means that main::readable is still
accessible and doesn't conflict. No, that's not desirable, but AIO
behavior looks more malleable to me.
i have not seen an attempt to name all of
the -X ops yet.
v2 fast approaching. ;-)
Z.
Re: RFC 290 (v1) Remove -X
Adam Turoff wrote:
That's a stone's throw awaty from:
import english
from english import filetest
result = filetest.readable("/dev/null")
I think the common prefix idea is a nonstarter. There must be a way
to coming up with sensible names for all of -X that don't conflict
with the core library.
I think perhaps that Uri was suggesting more a common letter prefix,
such as:
freadable($file);
fwritable($file);
fexecutable($file);
Than a piece of bastardized Pythonesque syntax. ;-)
-Nate
Re: RFC 290 (v1) Remove -X
On Tue, 26 Sep 2000, Nathan Wiger wrote:
I think perhaps that Uri was suggesting more a common letter prefix,
such as:
freadable($file);
fwritable($file);
fexecutable($file);
Than a piece of bastardized Pythonesque syntax. ;-)
Was that what the foo.bar("baz") syntax was? I thought that was in another
RFC I had to hunt down and read :-) But I think I like this anyway:
-f.r($file);# same as -r $file
-f.rwx($file); # same as -rwx $file
etc. Or leave off the -, or even the -f ... oh well, I guess there are
syntax possibilities ad nauseum, but none very satisfying.
John.
Re: RFC 290 (v1) Remove -X
"AT" == Adam Turoff [EMAIL PROTECTED] writes:
AT On Tue, Sep 26, 2000 at 02:13:41PM -0400, Uri Guttman wrote:
AT But I wouldn't want that pragma to override any other aspect of the
AT core library, such as async I/O.
agreed. but we can reconcile the name spaces then. or let larry do
it. :)
AT That's a stone's throw awaty from:
AT import english
AT from english import filetest
AT result = filetest.readable("/dev/null")
blecchh!
AT I think the common prefix idea is a nonstarter. There must be a way
AT to coming up with sensible names for all of -X that don't conflict
AT with the core library. Besides, AIO has a requirement on
AT 'sub Foo::readable()', which means that main::readable is still
AT accessible and doesn't conflict. No, that's not desirable, but AIO
AT behavior looks more malleable to me.
what about my idea for is_ or has_? actually that could be used for
callbacks as well. we need some semantic distance from the socket/handle
is readable right now (buffers have data) and the file can be read
if/when it is opened (you can test an open handle too IIRC).
i have not seen an attempt to name all of
the -X ops yet.
AT v2 fast approaching. ;-)
awaiting with my whip so i can shred your names. :)
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 290 (v1) Remove -X
"NW" == Nathan Wiger [EMAIL PROTECTED] writes:
NW I think perhaps that Uri was suggesting more a common letter prefix,
NW such as:
NW freadable($file);
NW fwritable($file);
NW fexecutable($file);
NW Than a piece of bastardized Pythonesque syntax. ;-)
basically correct. even a - as a prefix will be nicer and closer to the
original -X stuff. but that might conflict with the -rwx ideas (which i
am not fond of anyway).
if ( -readable( $filename ) ) {
not the best. would that be confused with a sub readable and a leading
unary negation? in fact how does perl parse -r now vs - r()?
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 290 (v1) Remove -X
Uri Guttman wrote:
not the best. would that be confused with a sub readable and a leading
unary negation? in fact how does perl parse -r now vs - r()?
Yes it would, here's how Perl parses these right now:
perl -w -e '
sub r { local $\; print "r(@_) : "; }
$\ = "\n";
print "-r" if -r "/etc/motd";
print "-r()" if -r("/etc/motd");
print "- r" if - r "/etc/motd";
print "- r()" if - r("/etc/motd");
'
Prints out:
-r
-r()
r(/etc/motd) : - r
r(/etc/motd) : - r()
Basically, the -r filetest always wins. Injecting a space makes the r
sub always win, as would be expected.
-Nate
Re: RFC 290 (v1) Remove -X
File tests (-r/-w/-x/...) made sense when Perl's shellness was an attribute. Most new Perl programmers are not coming from a shell programming background, and the -X syntax is opaque and bizarre. It should be removed. Perl programmers happy with the -X syntax will need to get used to the lengthier replacement. Blech. I certainly think that long functions are fine and dandy, but I'd loathe the day that I'd have to give up my -X stuff. I *love* it. I'm a shell-head! Many Perlers are. I would not classify giving this up as an improvement. Alternative functions are fine, but I think removing -X would definitely fit into the realm of causing existing Perl hackers to run away screaming. -Nate
Re: RFC 290 (v1) Remove -X
On 25 Sep 2000, Perl6 RFC Librarian wrote: =head1 TITLE Remove -X The prefered mechanism for file tests should be more legible, using terms like 'readable(FOO)' and 'writeable(FOO)' instead of the =head1 MIGRATION ISSUES Perl programmers happy with the -X syntax will need to get used to the lengthier replacement. Why can't both remain in place? Have the short forms so that those of us who are used to them and don't find them confusing can use them (and so p526 does not need to address this issue), and have the new readability-enhanced ( : ) versions as well, for them's as want those. This seems like an excellent place to TIMTOWTDI. Dave
Re: RFC 290 (v1) Remove -X
Perl6 RFC Librarian wrote:
=head1 ABSTRACT
File tests (-r/-w/-x/...) made sense when Perl's shellness was an
attribute. Most new Perl programmers are not coming from a shell
programming background, and the -X syntax is opaque and bizarre.
It should be removed.
is_readable(file) is really -r(file)
If you are proposing complete removal of -X tests (as the RFC title
suggests) then I think the syntax definately needs more discussion.
I liked Nathan's suggestion (quoted below) and I've listed why I
think it's the better syntax.
It:
+ stacks multiple tests quite cleanly without excess verbiage
(if (-e -T -s -x){...} gets a little tedious especially
if you don't use $_)
+ introduces only 1 new keyword ("file" seems bad, but maybe not)
+ does not break the brains of the -X loving crowd (as much)
+ introduce long names for -X haters
e.g. file($file, 'readable,writable,directory');
Nathan Wiger wrote:
In fact, I'd much rather still a more generic function like 'want' that
takes a list of things to check:
file($file); # does it exist?
file($file, 'r'); # is it readable?
file($file, 'w'); # is it writable?
file($file, 'd'); # is it a directory?
file($file, 'wd'); # is it a writable directory?
file($file, 'dw'); # same thing
Otherwise we run the risk of 200 builtins just to check file types and
modes on all the different platforms
Clayton
Re: RFC 290 (v1) Remove -X
On Sun, 24 Sep 2000 23:05:45 -0700, Nathan Wiger wrote: Perl programmers happy with the -X syntax will need to get used to the lengthier replacement. Blech. I certainly think that long functions are fine and dandy, but I'd loathe the day that I'd have to give up my -X stuff. I *love* it. I'm a shell-head! Many Perlers are. I would not classify giving this up as an improvement. I am not a shellhead. In fact, I never do any shell programming. But I do feel that readable() innstead of -r is not an improvement. What's next, replacing abs() with absolute()? -r takes a *bit* of getting used to, but not much. For the rest, -X stands out as "this is a file test", and it's short. I love short. -- Bart.
Re: RFC 290 (v1) Remove -X
On Mon, 25 Sep 2000, Clayton Scott wrote:
It:
+ stacks multiple tests quite cleanly without excess verbiage
(if (-e -T -s -x){...} gets a little tedious especially
if you don't use $_)
+ introduces only 1 new keyword ("file" seems bad, but maybe not)
+ does not break the brains of the -X loving crowd (as much)
+ introduce long names for -X haters
e.g. file($file, 'readable,writable,directory');
Nathan Wiger wrote:
In fact, I'd much rather still a more generic function like 'want' that
takes a list of things to check:
file($file); # does it exist?
file($file, 'r'); # is it readable?
file($file, 'w'); # is it writable?
file($file, 'd'); # is it a directory?
file($file, 'wd'); # is it a writable directory?
file($file, 'dw'); # same thing
I'd even go so far as to say that the current -X syntax should be
_extended_, to allow for multiple tests at once, maybe by way of a
leading caret (mnemonic "all"):
-^rwx; # $_ is readable, writable and executable
($size, $mod, $acc, $ichange) = -^sMAC;
And, as the filetest operators currently rely solely on the unix-ish mode
and uid/gid of the file, there should be a pragma that you can use to
force the interpretation to be "true", i.e., modulo ACLs, readonly
filesystems, etc., maybe
use filetest true;
John.
Re: RFC 290 (v1) Remove -X
I'd even go so far as to say that the current -X syntax should be
_extended_, to allow for multiple tests at once, maybe by way of a
leading caret (mnemonic "all"):
-^rwx; # $_ is readable, writable and executable
($size, $mod, $acc, $ichange) = -^sMAC;
In fact, you wouldn't even need a caret, since all file tests are a
single letter. Just like grouping s/// flags, we should make file tests
groupable as well:
if ( -drwx /usr/local and ! -h /usr/local ) {
# directory exists and has correct perms
}
And, as the filetest operators currently rely solely on the unix-ish mode
and uid/gid of the file, there should be a pragma that you can use to
force the interpretation to be "true", i.e., modulo ACLs, readonly
filesystems, etc., maybe
use filetest true;
This is a good idea, I think.
The more I look at the RFC, the less enamoured I am with the original
suggestion, which came from Tom's perl6storm email. "Learn Perl" comes
to mind. As Bart notes, short is good, and -r makes just as much/little
sense as s/// for non shell-people. We shouldn't be trying to make Perl
into Pascal - beginner-friendly but shitty.
-Nate
Re: RFC 290 (v1) Remove -X
"John L. Allen" wrote: The use of a caret was to prevent decimation of the user's namespace, vis: perl -e 'print -rwx $_' Can't call method "rwx" on an undefined value at -e line 1. Yeah, but read the error - Perl's parsing that as: [nwiger@matrix:~]$ perl -MO=Deparse -e 'print -rwx $_'; print -$_-rwx; -e syntax OK This is a really, really, really strange use of indirect object syntax. I doubt anyone is doing that currently (and if they are, they really shouldn't be! :). And, as Damian notes, ^ is already taken as a general-purpose prefix for Perl 6. -Nate
Re: RFC 290 (v1) Remove -X
On Mon, 25 Sep 2000, Nathan Wiger wrote:
perl -e 'print -rwx $_'
Can't call method "rwx" on an undefined value at -e line 1.
Yeah, but read the error - Perl's parsing that as:
[nwiger@matrix:~]$ perl -MO=Deparse -e 'print -rwx $_';
print -$_-rwx;
-e syntax OK
Ok, so that's pathological, but this isn't
perl -e 'print -rwx($_)'
Undefined subroutine main::rwx called at -e line 1.
Just think about all the possible subroutine names you can make out of
the set of chars [rwxoRWXOezsfdlpSbctugkTBMAC]. I don't think we want to
prevent the use of those names by allowing the -XXX syntax without some
special char used as a prefix. But as the ^ is already taken by the
cool RFC 23, my idea have hit a dead end:
-{rwx}
-~rwx
have ambiguity problems.
Hmmm, does
-^{rwx}
have a currying interpretation?
John.
Re: RFC 290 (v1) Remove -X
"John L. Allen" wrote:
Ok, so that's pathological, but this isn't
perl -e 'print -rwx($_)'
Undefined subroutine main::rwx called at -e line 1.
Well, it is still a little weird. You're still negating a subroutine
call. And remember, if you have a sub called "r" this doesn't work right
currently:
sub r {
return 41 + $_[0];
}
$file = '1';
unless ( -r $1 ) {
print 'our total was: ', -r $1, "\n";
}
If you want to do what you're proposing, why not just put parens around
it?
perl -e 'print -( rwx $_ )'
Or not even that, how about just a space?
perl -e 'print - rwx $_'
This is needed to fix the above 'r' example currently. And how often do
you have to directly negate sub calls??
I'm not trying to turn a deaf ear to your concerns, but I do think
they're not showstoppers. Negating sub calls with no space is weird, and
so is negating strings, which are the only two things making a leading -
special in the given context could conflict with. And there's already
plenty of places currently (as shown above) where this conflict exists
and doesn't seem to be causing any problems.
Hmmm, does
-^{rwx}
have a currying interpretation?
Yes, it does, see Damian's RFC on higher-order functions.
-Nate
Re: RFC 290 (v1) Remove -X
On Mon, 25 Sep 2000 10:22:46 -0400, Clayton Scott wrote:
It:
+ stacks multiple tests quite cleanly without excess verbiage
(if (-e -T -s -x){...} gets a little tedious especially
if you don't use $_)
Perhaps you want is to use $_. A "with" statement, or is it an
expression, sounds like it could do the job:
if(with($file){-e -T -s -x}) { ... }
Note that currently you can use for(SCALAR) BLOCK in a similar function,
except that it's a statement and not an expression, and it doesn't
return anything.
This works in perl5:
if(grep {-e -T -s -x} $file) { ... }
but the syntax doesn't match the purpose.
--
Bart.
RFC 290 (v1) Remove -X
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Remove -X =head1 VERSION Maintainer: Adam Turoff [EMAIL PROTECTED] Date: 24 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 290 Version: 1 Status: Developing =head1 ABSTRACT File tests (-r/-w/-x/...) made sense when Perl's shellness was an attribute. Most new Perl programmers are not coming from a shell programming background, and the -X syntax is opaque and bizarre. It should be removed. =head1 DESCRIPTION Tom Christiansen proposed this in his perl6storm message: =item perl6storm #0101 Just like the "use english" pragma (the modern not-yet-written version of "use English" module), make something for legible fileops. is_readable(file) is really -r(file) note that these are hard to write now due to -s(FH)/2 style parsing bugs and prototype issues on handles vs paths. Aside from providing parsing bugs and prototype issues, the -X syntax is strange and confusing to many Perl programmers who are completely unfamiliar with Bourne shell syntax. The prefered mechanism for file tests should be more legible, using terms like 'readable(FOO)' and 'writeable(FOO)' instead of the opaque '-r FOO' and '-x FOO'. Furthermore, these tests should remain useable where appropriate on any I/O mechanism, not just files. =head1 MIGRATION ISSUES p52p6 would convert instances of -X to the appropriate legible test. Perl programmers happy with the -X syntax will need to get used to the lengthier replacement. =head1 IMPLEMENTATION None required. =head1 REFERENCES perl6storm
