This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
More direct syntax for hashes
=head1 VERSION
Maintainer: Nathan Torkington [EMAIL PROTECTED]
Date: 5 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 196
=head1 ABSTRACT
On Tue, 05 Sep 2000 18:37:11 -0600, Tom Christiansen wrote:
Those are not the semantics of print. It returns true (1) if successfSNIP
false (undef) otherwise. You cannot change that. If I write print "0", it
bloody well shan't be returning false.
Oh, why not? Does anybody actually *ever*
2000-08-28-18:47:06 Tom Christiansen:
It strikes me as a bit reminiscent of (one reason) why Larry
didn't make a+b work on strings, since then while with numbers,
a+b and b+a would be the same, with strings they would not be, and
we have these rather deeply held convictions about such
On Tue, 05 Sep 2000 19:08:18 -0600, Tom Christiansen wrote:
exists (sometimes causes autovivification, which affects Ckeys)
That's not technically accurate--exists never causes autovivification.
print exists $hash{foo}{bar}{baz};
use Data::Dumper;
print Dumper
print keys %hash, "\n";
exists $hash{key}{subkey};
print keys %hash, "\n";
Or did that get fixed when I wasn't looking?
No, the - operator has not been changed to do lazy evaluation.
That's not required. All that is necessary is for Cexists nodes
in the op
Why can't we just apply the same warnings on hashes as we do on
variables in Perl? Maybe a new lexical pragma:
no autoviv; # any autovivification carps (not just
# hashes)
no autoviv 'HASH'; # no new
On Tue, 05 Sep 2000 19:08:18 -0600, Tom Christiansen wrote:
exists (sometimes causes autovivification, which affects Ckeys)
That's not technically accurate--exists never causes autovivification.
print exists $hash{foo}{bar}{baz};
use Data::Dumper;
print Dumper
I'd suggest also, that (?[) (with no specified brackets) have the
default meaning
of the "four standard brackets" :
(?['('=')','{'='}','['=']',''='')
Note also the subtle syntax change. We are either dealing with strings
or with patterns. The consensus seems to be against patterns (I can
At 09:05 AM 9/6/00 -0400, David Corbin wrote:
I'd suggest also, that (?[) (with no specified brackets) have the
default meaning
of the "four standard brackets" :
(?['('=')','{'='}','['=']',''='')
Note also the subtle syntax change. We are either dealing with strings
or with patterns. The
It would be useful (and increasingly more common) to be able to match
qr|\s*(\w+)([^]*)| to qr|\s*/\1\s*|, and handle the case where those
can nest as well. Something like
listmatch this with
list
/list not this but
/list this.
I suspect this is going to need a ?[ and ?]
Nathan Wiger wrote:
It would be useful (and increasingly more common) to be able to match
qr|\s*(\w+)([^]*)| to qr|\s*/\1\s*|, and handle the case where those
can nest as well. Something like
listmatch this with
list
/list not this but
/list this.
I suspect
On Tue 05 Sep, Nathan Wiger wrote:
"normal" "reversed"
-- ---
103301
99aa99
(( ))
+ +
{{[!_ _!]}}
{__A1( )A1__}
That is, when a bracket is encountered, the "reverse" of
- Original Message -
From: "Jonathan Scott Duff" [EMAIL PROTECTED]
Subject: Re: XML/HTML-specific ? and ? operators? (was Re: RFC 145
(alternate approach))
On Wed, Sep 06, 2000 at 08:40:37AM -0700, Nathan Wiger wrote:
What if we added special XML/HTML-parsing ? and ? operators?
I am working on an RFC
to allow boolean logic ( and || and !) to apply a number of patterns to
the same substring to allow easier mining of information out of such
constructs.
What, you don't like: :-)
$pattern = $conjunction eq "AND"
? join('' = map { "(?=.*$_)" }
Jonathan Scott Duff wrote:
On Wed, Sep 06, 2000 at 08:40:37AM -0700, Nathan Wiger wrote:
What if we added special XML/HTML-parsing ? and ? operators?
What if we just provided deep enough hooks into the RE engine that
specialized parsing constructs like these could easily be added by
...My point is that I think we're approaching this
the wrong way. We're trying to apply more and more parser power into what
classically has been the lexer / tokenizer, namely our beloved
regular-expression engine.
I've been thinking the same thing. It seems to me that the attempts to
On Wed, Sep 06, 2000 at 03:47:57PM -0700, Randal L. Schwartz wrote:
"Mark-Jason" == Mark-Jason Dominus [EMAIL PROTECTED] writes:
Mark-Jason I have some ideas about how to do this, and I will try to
Mark-Jason write up an RFC this week.
"You want Icon, you know where to find it..." :)
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Numberic Value Ranges In Regular Expressions
=head1 VERSION
Maintainer: David Nicol [EMAIL PROTECTED]
Date: 5 september 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 197
Status:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
lvalue subs: parameters, explicit assignment, and wantarray() changes
=head1 VERSION
Maintainer: Nathan Torkington [EMAIL PROTECTED]
Date: Aug 16, 2000
Last Modified: Sep 6, 2000
Mailing List:
(I sent this to horos in the first RFC format, before the language
list. I haven't got any response, so I send this agian now. I don't
have time to read the list or maintain an RFC. I just wan't to give
this suggestion.)
Does any other RFC give the equivalent to an 'in' operator?
I have a
Jonas Liljegren wrote:
Does any other RFC give the equivalent to an 'in' operator?
I have a couple of times noticed that beginners in programming want to
write if( $a eq ($b or $c or $d)){...} and expects it to mean
if( $a eq $b or $a eq $c or $a eq $d ){...}.
I think it's a natural human
On 4 Sep 2000 21:32:00 -, Perl6 RFC Librarian [EMAIL PROTECTED] wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1TITLE
Here Docs Terminators (Was Whitespace and Here Docs)
[...]
=head1 IMPLENTATION
Intentional? It's either
On Wed, Sep 06, 2000 at 02:51:03PM +0200, Willy wrote:
Does anyone know how can i
[snip]
How can i do??
You cannot do this in perl6 because perl6 does not yet exist.
Please do not abuse this mailing list with off-topic questions.
Thank you.
--
Tad McClellan
From: Jonas Liljegren [mailto:[EMAIL PROTECTED]]
Does any other RFC give the equivalent to an 'in' operator?
I have a couple of times noticed that beginners in programming want to
write if( $a eq ($b or $c or $d)){...} and expects it to mean
if( $a eq $b or $a eq $c or $a eq $d ){...}.
On Wed, Sep 06, 2000 at 09:43:03AM -0500, Garrett Goebel wrote:
From: Jonas Liljegren [mailto:[EMAIL PROTECTED]]
Does any other RFC give the equivalent to an 'in' operator?
I have a couple of times noticed that beginners in programming want to
write if( $a eq ($b or $c or $d)){...}
The fact that something can be accomplished in Perl doesn't necessarily mean
its the best or most desirable way to do it. I respect the programming
abilities, but
grep { ref($a) eq ref($b) } @b)
is far less intuitive than the proposal. I could perhaps dig into my distant
memory and
grep { $_ == 1 } 1..1_000_000
grep doesn't short-circuit.
I never did figure out why "last" {w,sh,c}ouldn't be made to do
that very thing.
--tom
IMHO Perl should add a plethora of higher-order functions for arrays and
hashes, and from the chatter here I think a lot of people agree.
Make some modules, release them, and see how much they're used. Then
one can contemplate sucking them into the core based upon the success
of those
On Wed, Sep 06, 2000 at 09:46:13AM -0600, Tom Christiansen wrote:
grep { $_ == 1 } 1..1_000_000
grep doesn't short-circuit.
I never did figure out why "last" {w,sh,c}ouldn't be made to do
that very thing.
Agreed, that would be very natural.
--
$jhi++; # http://www.iki.fi/jhi/
I don't know exactly how this message got marked "unread" again,
No, here it is, the server at Sun has decided to send it again,
which is all right, since I don't think I responded before going
home last friday.
Received:
from mercury.Sun.COM
At 12:50 PM 9/6/00 -0500, David L. Nicol wrote:
I see barewords as being whatever the programmer wants them to be,
as long as he makes it clear what he expects the word to be before using
it.
So, Copen becomes a legacy constructor and the perl6 version of it would
be something like
my
Garrett Goebel wrote:
grep { ref($a) eq ref($b) } @b) # Same type?
grep { $a == $_ } @b)
grep { $a eq $_ } @b)
grep { $a $_ } @b)
Garrett
grep doesn't short-circuit; you can't return or exit or last out
of the thing.
Maybe we could add support for Clast to
"David L. Nicol" wrote:
s/x/5/; # this is still going to replace
# all the eckses in $_ with fives.
Why? This is an arbitrary decision if you've declared variables to be
barewords.
Anyways, I'm done harping on this issue. I think a single, simple syntax
is good. You
Buddha Buck wrote:
my filehandle fh; fh-new("/tmp/appendablelog");
Ugh... How about...
my filehandle fh;
fh-open("/tmp/appendablelog");
Has anyone read RFC 14?
$FILE = open "/etc/motd";
@doc = $FILE;
$WEB = open http "http://www.yahoo.com";
@html = $WEB;
The
Does any other RFC give the equivalent to an 'in' operator?
RFC 22 offers:
switch ($a) {
case (@b) { ... }
}
and my forthcoming superpositions RFC will offer:
if ($a == any(@b) ) { ... }
and:
if ($a eq any(@b) ) { ... }
and:
if ($a
Has anyone read RFC #11,112,006,825,558,016?
It's rather difficult to keep up with them all, or read them all
retroactively when you miss a few days. It's also hard to grep
them (HTML is the root of all evil). Is there an rsync server that
will dole out the pods for us as needed?
--tom
Tom Christiansen wrote:
The straightforward way to do that is quite simply:
open(FH, "|foocmd thisfoo thatfoo|")
or for shell avoidance:
open(FH, "|-|", "foocmd", "thisfoo", "thatfoo"))
Does this work now Or are you just suggesting this be added to Perl
6?
Quoth
s/x/5/; # this is still going to replace
# all the eckses in $_ with fives.
Why? This is an arbitrary decision if you've declared variables to
be
barewords.
I think it's a sane decision -- IMHO barewords shouldn't be allowed to
Damian Conway [EMAIL PROTECTED] writes:
Does any other RFC give the equivalent to an 'in' operator?
and my forthcoming superpositions RFC will offer:
if ($a == any(@b) ) { ... }
and:
if ($a eq any(@b) ) { ... }
and:
if ($a != any(@b) ) { ... }
and:
if
At 01:52 PM 9/6/00 -0600, Tom Christiansen wrote:
Has anyone read RFC #11,112,006,825,558,016?
It's rather difficult to keep up with them all, or read them all
retroactively when you miss a few days. It's also hard to grep
them (HTML is the root of all evil).
No HTML here:
$ telnet
Nathan Wiger wrote:
"David L. Nicol" wrote:
s/x/5/; # this is still going to replace
# all the eckses in $_ with fives.
Why? This is an arbitrary decision if you've declared variables to be
barewords.
Misstating my position, when I take one, is and will
From: Bart Lateur [mailto:[EMAIL PROTECTED]]
On Wed, 06 Sep 2000 13:04:51 -0500, David L. Nicol wrote:
grep { $a $_ and last } @b)
So "last" should return true, or what?
The last operator doesn't return anything does it? It immediately exits the
loop/block in question.
@passed =
"Myers, Dirk" wrote:
I still find this whole idea confusing, though. Just out of curiosity,
though, would:
#include a way for users to bail out gracefully
be a syntax error?
It is clear to us that that is a comment and not a preprocessor directive.
The #include preprocessor
Just to note that RFC 76 (Builtin: reduce) also proposes this
mechanism as a means of short-circuiting Creduce.
Damian
@passed = grep { 2 $_ and last } (1, 2, 3, 2, 1);
I believe that unless used with a label, if someone were to use
last within a grep or map block, then further processing for that
element of the list which grep is working on would be skipped, and
it would continue with
David L. Nicol wrote:
A bareword inside doublequotes is not interpreted, in Perl or C.
No; a "bareword" in quotes (any kind) is not a bareword.
--
John Porter
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Short-circuiting Cgrep and Cmap with Clast
=head1 VERSION
Maintainer: Garrett Goebel [EMAIL PROTECTED]
Date: 6 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 199
Status: Developing
I should have an RFC out on this by next week.
Damian
On Thu, Sep 07, 2000 at 06:28:25AM +1100, Damian Conway wrote:
I should have an RFC out on this by next week.
Feel free to hijack and/or infiltrate my RFC.
Damian
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'.
Feel free to hijack and/or infiltrate my RFC.
You Will Be Assimilated.
Damian
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Standardise Function Pre- and Post-Handling
=head1 VERSION
Maintainer: Jarkko Hietaniemi
Date: 05 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 194
Status: Developing
=head1
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Retire chop().
=head1 VERSION
Maintainer: Nathan Torkington [EMAIL PROTECTED]
Date: 5 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 195
Status: Developing
=head1 ABSTRACT
Remove
52 matches
Mail list logo
