This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Merge C$!, C$^E, C$@ and C$?
=head1 VERSION
Maintainer: Peter Scott [EMAIL PROTECTED]
Date: 25 Aug 2000
Last-modified: 5 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
This Is The Last Major Revision
=head1 VERSION
Maintainer: David Nicol [EMAIL PROTECTED]
Date: 5 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 141
Status: Frozen
=head1 ABSTRACT
Just to note that RFC 76 (Builtin: reduce) also proposes this
mechanism as a means of short-circuiting Creduce.
Damian
On Wed, 6 Sep 2000, Bradley M. Kuhn wrote:
[...]
Also, what if people want to learn how the source system works on their own,
and experiment with it? With only 100-user license, we are pretty tight as
to who can do that. There are probably more than 100 people on the various
perl6 mailing
Well in PDL we called them 'piddles' for precisely this reason!
The problem is they ARE arrays, which perl already has, just with a
more compact storage and nicer representation.
And we ARE proposing to make them look like plain perl arrays remember!
So let's keep CALLING them arrays!
I
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
On Wed, Sep 06, 2000 at 10:40:47AM +0200, Jonas Liljegren wrote:
(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.)
At 12:14 AM 9/6/00 -0400, Bradley M. Kuhn wrote:
Dan Sugalski wrote:
The decisions should be based on technical merit and general availability.
I would include "available under a free software license" as part of the
definition of "general availability".
You would, but in this case I don't.
On Wed, Sep 06, 2000 at 12:05:21PM +1100, Damian Conway wrote:
This bothers me. Name an operation in perl that, when applied to
a single element of an aggregate, affects all other elements of
the aggregate (especially future, as-yet-unborn elements).
There are remarkably few
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
Tom Christiansen [EMAIL PROTECTED] writes:
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
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/
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
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Boolean Regexes
=head1 VERSION
Maintainer: Richard Proctor [EMAIL PROTECTED]
Date: 6 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 198
Status:
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*
"PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes:
PRL%DataHash = unpack $mypic, $SomePackedCobolData;
Does it unpack it into the hash? Or does it keep a pointer into
the original structure?
What happens when a new key is added to the hash?
What happens if the underlying structure is
"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..." :)
But yes, a way that allows programmatic backtracking sort of "inside out"
That seems reasonable--except that I don't believe exists() merits
any special treatment.
More specifically, I think all non-lvalue context use of - should be
non-autoviv, whether exists or anything else.
I agree entirely.
In fact, I shall extend RFC 128 to allow
I agree entirely.
In fact, I shall extend RFC 128 to allow subroutine parameter to specify
that they are non-autovivifying.
I'm not sure why it matters to the subroutine. We've already got the hack
so that
fn( $a[$i] )
or
fn( $h{$k} )
will only autoviv those puppies if you muddle up
In fact, I shall extend RFC 128 to allow subroutine parameter to specify
that they are non-autovivifying.
I'm not sure why it matters to the subroutine. We've already got
the hack so that
fn( $a[$i] )
or
fn( $h{$k} )
will only autoviv
That's not required. All that is necessary is for Cexists nodes
in the op tree to propagate a special non-autovivifying context to
subordinate nodes.
That seems reasonable--except that I don't believe exists() merits
any special treatment.
--tom
That seems reasonable--except that I don't believe exists() merits
any special treatment.
More specifically, I think all non-lvalue context use of - should be
non-autoviv, whether exists or anything else.
--tom
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..." :)
"Jarkko" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
"You want Icon, you know where to find it..." :)
Jarkko Hey, it's one of the few languages we haven't yet stolen a
Jarkko neat feature or few from... (I don't really count the few
Jarkko regex thingies as full-fledged stealing, more
Will this incarnation of open() be able to deal
with bi directional process communication?
The straightforward way to do that is quite simply:
open(FH, "|foocmd thisfoo thatfoo|")
or for shell avoidance:
open(FH, "|-|", "foocmd", "thisfoo", "thatfoo"))
--tom
Gregory S Hayes wrote:
but it would look much nicer in the framework of this version of open(),
perhaps something like ...
($readme, $writeme) = open doublehandle "/path/program -args";
print $writeme "here's your input\n";
$output = $readme;
$writeme-close;
$readme-close;
Thoughts?
Does anyone know how can i use Net::Ping in a CGI without having security problems??
It tells me that "icmp ping requires root privileges". But if set the "uid" bit it
tells me "insecure $ENV". How can i do??
Willy
http://members.xoom.it/willy73
(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
At 06:49 PM 9/5/00 +0200, Bart Lateur wrote:
On Tue, 05 Sep 2000 11:48:38 -0400, Dan Sugalski wrote:
- two-phase commit handler, rollback coordinator (the above two is
connected to this: very simple algorhythm!)
Here's the killer. This is *not* simple. At all. Not even close.
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
I don't think we can do this immediately. Can you come up with the right
API and/or hooks that are needed so that it might be retrofited?
JH I think language magic helping to do the user level data locking is
JH a dead-in-the-water idea.
In message [EMAIL PROTECTED]
Dan Sugalski [EMAIL PROTECTED] wrote:
We punt. If the programmer wants consistent data in a multithreaded
program, he or she needs to lock the hash down. I'm all up for the
iterators looking at the hash as it exists--if the programmer wants
a snapshot of
"Bryan C. Warnock" wrote:
It's hitting a moving target :-(
I continue to explain myself until my mistakes become clear, that's
why I'm often wrong.
On Wed, Sep 06, 2000 at 12:14:17AM -0400, Bradley M. Kuhn wrote:
Dan Sugalski wrote:
The decisions should be based on technical merit and general availability.
I would include "available under a free software license" as part of the
definition of "general availability".
Bradley, your
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
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
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
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
Not quite. Nearly, though.
Or are you just suggesting this be
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?
You do need a true value for grep() to claim success.
--
Bart.
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
Today around 1:52pm, Tom Christiansen hammered out this masterpiece:
: 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
@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
And how about:
int length = 256 ;
and, if that's legal, what does:
print "I wonder what this is : " . length ;
do?
I imagine the first order of business for the C JIT team would be
some conversion operators. Numeric types stringify into decimal
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
JH Multithreaded programming is hard and for a given program the only
JH person truly knowing how to keep the data consistent and threads not
JH strangling each other is the programmer. Perl shouldn't try to be too
JH helpful and get in the
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
At 10:53 PM 9/5/00 -0400, Chaim Frenkel wrote:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS I'd definitely rather perl not do any sort of explicit user-level
locking.
DS That's not our job, and there be dragons.
Please explain how this is possible?
What, perl not make any locks
On Tue, Sep 05, 2000 at 10:57:30PM -0400, Chaim Frenkel wrote:
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
Now, "all" that needs to be taken care of, is make sure that the final
assignment from the localized and changed variables to their
outer-scoped counterparts happens in
Chaim Frenkel [EMAIL PROTECTED] writes:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS I'd definitely rather perl not do any sort of explicit user-level locking.
DS That's not our job, and there be dragons.
Please explain how this is possible?
Does this mean that without user specifying a
Benjamin Stuhl [EMAIL PROTECTED] writes:
All -
I fail to see the reason for imposing that all
variables
"know" how to perform ops upon themselves. An operation is
separate from the data it operates on. Therefore, I propose
the following vtbl scheme, with two goals:
1. that the minimal vtbl
At 05:17 PM 9/5/00 -0400, Chaim Frenkel wrote:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
This could be a lot more efficient than modifying the vtbl and filling
up the stack with the keys. I really am suspicious of replacing the
vtbl entry, there may be more than one thread working
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
Buddha Buck wrote:
What advantage does this give
None whatsoever. I should have selected a less contentious
example that file handles to demonstrate my opinion that
tagged barewords should be allowed to do anything, not in exclusion
of, but in addition to, the syntactically tagged
"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
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'.
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
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,
No it didn't. :-) Those are cascading headers (read the "by" field),
Sun's internal mail system has 3-4 hops and 2 firewalls to go through.
Received:
from
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
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 { "(?=.*$_)" }
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:
- Original Message -
From: "Richard Proctor" [EMAIL PROTECTED]
Sent: Tuesday, September 05, 2000 1:49 PM
Subject: Re: RFC 145 (alternate approach)
On Tue 05 Sep, David Corbin wrote:
Nathan Wiger wrote:
But, how about a new ?m operator?
/(?m|[).*?(?M|])/;
There already is a
...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
David Corbin wrote:
m:(?['list' = '/list').*(?]):
or more generically
m:(?['\w+' = '/\1').*(?]):
I think these are good; but I do also like the idea of "automatic
reversing" by default, since that's a common operation.
Let's combine the ideas, as Richard suggests. How about:
1. When
...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.
A great deal of string processing is possible with perls enhanced NFA
engine,
But for a single 'statement', it may be possible to gather all the
objects needing a lock and then grabbing them in order (say by address).
I still don't buy that. In Perl even simple assignments and
increments are not atomic which means that even 'single statements'
would require locking and
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
JH Multithreaded programming is hard and for a given program the only
JH person truly knowing how to keep the data consistent and threads not
JH strangling each other is the programmer. Perl shouldn't try to be too
JH helpful and get
"NI" == Nick Ing-Simmons [EMAIL PROTECTED] writes:
NI The snag with attempting to automate such things is illustrated by :
NI thread Athread B
NI $a = $a + $b++; $b = $b + $a++;
NI So we need to 'lock' both $a and $b both sides.
NI So
Please read the RFC and AFTER you can make suggestions. These _all_
are mentioned in the rfc!
Okay, I have read it now. Now I'm going to make suggestions :-) (Note
that so far I've been commenting only on the aspects of making things
'thread-safe', not on the RFC itself. 'Threadsafing'
/--- On Wed, Sep 06, 2000 at 05:16:03PM -0500, Jarkko Hietaniemi
wrote:
| Okay, I have read it now. Now I'm going to make suggestions :-)
| (Note
| that so far I've been commenting only on the aspects of making
| things
| 'thread-safe', not on the RFC itself. 'Threadsafing' Perl
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS Well, there'll be safe access to individual variables when perl needs to
DS access them, but that's about it.
DS Some things we can guarantee to be atomic. The auto increment/decrement
DS operators can be reasonably guaranteed atomic, for
"TH" == Tom Hughes [EMAIL PROTECTED] writes:
TH I guess we can translate all uses of keys and values when doing
TH the p52p6 conversion - so that this:
TH foreach my $x (keys %y)
TH {
TH $y{$x+1} = 1;
TH }
TH becomes:
TH foreach my $x (@temp = keys %y)
TH {
TH $y{$x+1} = 1;
More direct syntax for hashes
Maintainer: Nathan Torkington [EMAIL PROTECTED]
Date: 5 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 196
Nat, I was thinking of writing an RFC on a related issue...
but it could piggy-back on this one (196) if you like the idea.
To
74 matches
Mail list logo
