This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Shell Style Redirection
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last Modified: 5 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 66
Status: Deve
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
structures and interface definitions
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last Modified: 5 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 75
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: [EM
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
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
> sub callfritz{
> local STDIN < $InputData;
> local STDOUT > PREVIOUSLY_OPENED_HANDLE;
> eval `cat fritz.pl`;
> };
Unclear what you really mean there with the eval. But why not
simply allow
open(local *STDIN, "< $InputData");
open(local *STDOUT,
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Thread Programming Model
=head1 VERSION
Maintainer: Steven McDougall <[EMAIL PROTECTED]>
Date: 31 Aug 2000
Last Modified: 05 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 185
St
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
C should re
Just to note that RFC 76 (Builtin: reduce) also proposes this
mechanism as a means of short-circuiting C.
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 maili
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 sugg
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 patter
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 $
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 explain
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.)
>
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 ){...
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
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
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 (mercur
> 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 modul
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
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/jh
Ed Mills wrote:
> 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.
...and is an example of
> 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
>
> match this with
>
> not this but
>this.
I suspect this is going to need a ?[ and ?] of its
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
> >
> > match this with
> >
> > not this but
> >this.
>
> I suspec
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
those who need them?
-Scott
--
Jon
On Tue 05 Sep, Nathan Wiger wrote:
>"normal" "reversed"
>-- ---
>103301
>99aa99
>(( ))
><+ +>
>{{[!<_ _>!]}}
>{__A1( )A1__}
>
> That is, when a bracket is encountered, the
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 matt
>On Tue, 05 Sep 2000 19:08:18 -0600, Tom Christiansen wrote:
>>> exists (sometimes causes autovivification, which affects C)
>>
>>That's not technically accurate--exists never causes autovivification.
> print exists $hash{foo}{bar}{baz};
> use Data::Dumper;
> print Dumpe
I've been tossing an idea around in my head, and I've not yet decided if
this is the most brilliant idea I've ever come up with:), or perhaps the
lamest. I'm sure it would be cool, but that doesn't mean it should be
pursued. I'm going to throw this one out in the open, and if it's not
shot full
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 successful, and
>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 *eve
>On Tue, 05 Sep 2000 18:37:11 -0600, Tom Christiansen wrote:
>>Those are not the semantics of print. It returns true (1) if successf
>>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 struc
> "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
> > "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..." :)
That's exactly my motivation. It seems to me that tryi
> >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
> >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 onl
> > 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 C nodes
in the o
> 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
>That's not required. All that is necessary is for C 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
> "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 stealin
On Tue, 05 Sep 2000 19:08:18 -0600, Tom Christiansen wrote:
>> exists (sometimes causes autovivification, which affects C)
>
>That's not technically accurate--exists never causes autovivification.
print exists $hash{foo}{bar}{baz};
use Data::Dumper;
print Dumper \
>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;
>
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 'IMPL
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 c
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 natura
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 clo
> "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-wa
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 snaps
"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, yo
>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 dev.
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
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.
@p
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Short-circuiting C and C with C
=head1 VERSION
Maintainer: Garrett Goebel <[EMAIL PROTECTED]>
Date: 6 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 199
Status: Developing
=head1 A
"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 preprocesso
> Has anyone read RFC 14?
>
>$FILE = open "@doc = <$FILE>;
>
>$WEB = open http "http://www.yahoo.com";
>@html = <$WEB>;
>
> The next version (hopefully out this week) will clarify this syntax
> further.
>
> -Nate
This is a much friendlier looking approach to things. I also app
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 su
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
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:
>
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 t
> @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
> > 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 int
> Are you satisfied with this? I think this is a good compromise, and
> still powerful :-)
Me satisfied? Well, kind of. I see the need, I just disagree with
the proposed interface and extent. I will not comment on the subject
much more because I sense that soon we'll be hip deep in database
> what if i do $i++ and overflow into the float (or bigint) domain? that
> is enough work that you would need to have a lock around the ++. so then
> all ++ would have implied locks and their baggage. i say no atomic ops
> in perl.
>From RFC 178
[Atomic] operations typically lock their opera
> "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 ge
> "UG" == Uri Guttman <[EMAIL PROTECTED]> writes:
UG> i don't see how you can do atomic ops easily. assuming interpreter
UG> threads as the model, an interpreter could run in the middle of another
UG> and corrupt it. most perl ops do too much work for any easy way to make
UG> them atomic with
> "TH" == Tom Hughes <[EMAIL PROTECTED]> writes:
TH> I wasn't just talking about the threaded case though - the point
TH> which I was making was that of what happens if a single threaded
TH> program alters a hash in the middle of iterating it.
TH> Currently keys and values are flattened when
> DS> Some things we can guarantee to be atomic.
> This is going to be tricky. A list of atomic guarentees by perl will be
> needed.
>From RFC 178
...we have to decide which operations are [atomic]. As a starting
point, we can take all the operators documented in C and
all the functions docume
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 an
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 counterpar
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
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 mini
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
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
Remov
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 scalar
Nathan Wiger wrote:
> Intermingling it freely:
>
>my Dog $spot;
>int x;
>my int $y;
>#include
>char * name;
>#do some regexp matching
>s/x/5/;/* match the C value of x defined above */
>
> Is really confusing, even for us humans. :-)
>
> -Nate
Is it confusing?
"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. Yo
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 ";
$WEB = open http "http://www.yahoo.com";
@html = <$WEB>;
The next version (
> 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
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
>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.
I've been known to use:
sub opt(*); # imal quoting! :-)
So I could say if opt(a) sans quoting. But that
breaks for the pseudofuncs like m or s.
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, C becomes a legacy constructor and the perl6 version of it would
>be something like
>
>
>
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 C to C
> 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
1 - 100 of 123 matches
Mail list logo
