Re: Strings vs Numbers (Re: Tying Overloading)
On Tue, 24 Apr 2001, Graham Barr wrote: On Mon, Apr 23, 2001 at 05:19:22PM -0700, Larry Wall wrote: At the moment I'm leaning toward ^ for concat, and ~ for xor. That I think that would lead to confusion too. In many languages ^ is xor and ~ is a bitwise invert. It is that way in perl now too, so perl is already quite standard in that area. Changing these just to get . for - so that we are more standard seems very strange as you are loosing two standards to gain one. To be honest though I don't think it is possible to get a single char concat operator with loosing something else, which is a shame. It would be good if we could somehow overload + to be both string and numeric, but I not sure that is possible. I think someone may have mentioned this already, but why not just say that if you want '.' to mean concatenation, you have to surround it on either side with white space? If there's no white space around it, then it is forced to mean method invokation, or whatever else. Sure, some japhs will break, but that's just too bad :-) Perl already has other cases where white space matters, why not one more. That way, perhaps we can all get what we want, namely that '.' means both concatenation _and_ method invokation. John.
Re: RFC 229 (v2) Variable interpolation on demand.
On 29 Sep 2000, Perl6 RFC Librarian wrote:
Make Perl's powerful string interpolation facilities are available to
variables, in addition to literals.
=head1 DESCRIPTION
Given:
$foo = 'def';
$bar = 'ghi';
$x = "abc$foo$bar";
$y = 'abc$foo$bar';
There is no way to turn obtain the value of $x from the value of $y.
In other words, while $foo and $bar were interpolated into $x, they
were not interpolated into $y. It would be nice to get Success! from:
Um, what would your proposal gain you over
$z = eval "qq{$y}";
other than conciseness, elegance and speed (which may be quite enough!) ?
John.
Re: RFC 229 (v2) Variable interpolation on demand.
On Fri, 29 Sep 2000, Robert Mathews wrote:
"John L. Allen" wrote:
Um, what would your proposal gain you over
$z = eval "qq{$y}";
other than conciseness, elegance and speed (which may be quite enough!) ?
$y = '};system "rm -rf *";qq{';
Hmmm, hold on a second while I test that... NOT! :-)
John.
Re: RFC 320 (v1) Allow grouping of -X file tests and add Cfiletest builtin
On 26 Sep 2000, Perl6 RFC Librarian wrote:
=head1 TITLE
Allow grouping of -X file tests and add Cfiletest builtin
Nice summary. Thanks.
=head1 IMPLEMENTATION
This would involve making C-[a-zA-Z]+ a special token in all contexts,
serving as a shortcut for the Cfiletest builtin.
=head1 MIGRATION
There is a subtle trap if you are negating subroutines:
$result = -drwx $file;
And expect this to be parsed like this:
$result = - drwx($file);
However, usage such as this is exceedingly unlikely, and can simply be
resolved by the p52p6 translator looking for C-([a-zA-Z]{2,}) and
replacing it with C- $1, since injecting a single space will break up
the token.
I can't believe that special-casing the token -[rwxoRWXOezsfdlpSbctugkTBMAC]+
is an acceptble solution. I mean think of all the existing perl keywords
that that already matches: -pos, -cos, -lc, -uc, -fork, -use, -pop, -exp,
-oct, -log, -ord + others!. A lot of these already have a legitimate
not-filetest meaning, others not :-) So it still seems to me that some
sort of disambiguating syntax is needed, if not actually findable, to
save this filetest grouping idea of mine from the scrap heap. I guess
the p5-to-p6 converter could still resolve this as you stated, but I just
don't like it...
John.
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
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
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.
