"Greg Rollins" <[EMAIL PROTECTED]> writes:
> Would the rc support module loading? In other words, a sysadmin might want
> to give access to certain Perl modules to his/her users, and not to other
> users. That's the only use I can think of for dynamic Perl config. BTW,
> it's not something I'm
I know I just promised to be quiet... but I realized something really
important.
If the first arg returned from want() isn't the context, then this:
> In Perl 6 we switch with Ces, mister! ("Muro volente", of course ;-)
>
> switch (want) {
> case 'LIST' { do_list_stu
> If I said that, I was mistaken. It will always return false because
> the first return value from C is an expectation count, so:
Ok, here's your email cut-and-pasted, because I can't find it in the
frikkin' archives and I think it's worth re-visiting:
Damian Conway wrote:
>
>> Nathan Wige
Michael G Schwern wrote:
>
> >print <
> This still leaves the problem of having to count whitespace and having
> to change your regex if you reindent your code. In effect, it causes
> whitespace to become significant. Bleh.
How is this different from having to count the number of spaces y
>This still leaves the problem of having to count whitespace and having
>to change your regex if you reindent your code. In effect, it causes
>whitespace to become significant. Bleh.
It's much better to use the Cookbook method: it stands out better.
Please observe.
--tom
> > The LIST/SCALAR/VOID distinction is always the second value returned
> > (see the examples in the RFC). So your dispatcher is:
> >
> > my $func = lc (want)[1] . "_func";
> > return &$func(@_);
>
> I think I'd much rather it be the first. This seems to jiv
On Mon, Sep 04, 2000 at 05:36:32PM -0700, Nathan Wiger wrote:
> Actually, the two started merged. :-) They were split up after there
> were too many people for RFC 111 but against RFC 162. Personally, I'd
> rather see the recipe method of:
>
>print < > I can't think of much else I'd want to c
Michael G Schwern wrote:
>
> The RFC proposes a <<< operator which would strip whitespace off the
> front of the here-doc. Problem is preserving indentation. We can
> merge the two.
Actually, the two started merged. :-) They were split up after there
were too many people for RFC 111 but agains
Damian Conway wrote:
>
> The LIST/SCALAR/VOID distinction is always the second value returned
> (see the examples in the RFC). So your dispatcher is:
>
> my $func = lc (want)[1] . "_func";
> return &$func(@_);
I think I'd much rather it be the first. This seems to jive much more
Will perl monitor the commit and rollback actions of transactions?
- Original Message -
From: "Perl6 RFC Librarian" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, September 04, 2000 4:35 PM
Subject: RFC 130 (v5) Transaction-enabled variables for Perl6
>
> By RFC 21, it looks like the call would be
>
>if ( want 'LIST' ) {
> $num_to_return = want;
> # do stuff
>}
or, more efficiently:
if ( ($num_to_return) = want 'LIST' ) {
# do stuff
}
> However, at one time the discussion ha
On Mon, Sep 04, 2000 at 09:32:00PM -, Perl6 RFC Librarian wrote:
> Perl6 should ignore any whitespace before the terminator of a heredoc on any
> line.
Good. I don't see anything wrong with this.
***BRAIN STORM!***
RFC 162 (http://dev.perl.org/rfc/162.html) wanted to allow indented
here-d
Steve Fink uddered:
> Can't quite run perl yet.
Not for lack of trying.
ftp://cpan.valueclick.com/CPAN/authors/id/D/DC/DCONWAY/Quantum-Superpositions-1.03.tar.gz
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant
On Mon, Sep 04, 2000 at 09:52:19PM -, Perl6 RFC Librarian wrote:
> Perl winges if you compare an undefined value. This is silly and one often
> has to test for the undefined case (and the empty case for == and !=), then
> the equality that the programs logic calls for. If you leave warnings
Damian Conway wrote:
>
> That's indeed precisely what I meant. In fact, all list-returning built-ins
> ought to be optimized this way.
I think we're pretty much agreed on this point, but I have a tangential
question about want().
By RFC 21, it looks like the call would be
if ( want 'LIST' )
> >Should be part of the want() context.
>
> It is. I interpreted Damian's remark to mean that it would be good if
> readline() took advantage of it, and that should be RFC'ed.
That's indeed precisely what I meant. In fact, all list-returning built-ins
ought to be optimized this wa
Would the rc support module loading? In other words, a sysadmin might want
to give access to certain Perl modules to his/her users, and not to other
users. That's the only use I can think of for dynamic Perl config. BTW,
it's not something I'm against, I'm just trying to find a way I could use
In message <[EMAIL PROTECTED]>
Nathan Torkington <[EMAIL PROTECTED]> wrote:
> Peter Scott writes:
> > >> ($a, $b, $c) = ;
> > >> or
> > >> @a[4,1,5] = ;
> > >> only read three lines?
> > >
> > >I think this is a superb idea, and look forward to someone's RFC'ing
Jeremy Howard wrote:
>
> The problem with making these builtins respect the number of return values
> context in want() is that, as Nate mentions, the expressions may have
> side-effects that are desired for the whole list.
>
> An alternative approach is to make these builtins respect lazy(), as
Nathan Wiger wrote:
> Tom Christiansen wrote:
> >
> > Ever consider then having
> >
> > ($a, $b, $c) = ;
> > or
> > @a[4,1,5] = ;
> >
> > only read three lines? I mean, how many if any builtins would it
> > make sense to make aware of this, and do something "different"?
>
> Personally, I
>If you compare a variable that is undefined with something, perl winges.
Perl never whinges unless you turn on warnings.
>An undefined value is not equal to a string, it should do the right thing.
Comparing the undefined value against something else--that is, using
undef as though it were real
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Undef values ne value
=head1 VERSION
Maintainer: Richard Proctor <[EMAIL PROTECTED]>
Date: 4 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 192
Status: Developing
=head1 ABSTRACT
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl should support an interactive mode.
=head1 VERSION
Maintainer: Ariel Scolnicov <[EMAIL PROTECTED]>
Date: 31 Aug 2000
Last Modified: 3 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Num
I think it should be made explicit what happens if the here doc
terminator itself contains comment characters or semicolons. This is
my suggestion:
The here doc terminator must match as a string (that is,
C should match the line, where $term is
the desired terminator.
Otherwise the behaviour o
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Here Docs Terminators (Was Whitespace and Here Docs)
=head1 VERSION
Maintainer: Richard Proctor <[EMAIL PROTECTED]>
Date: 16 Aug 2000
Last Modified: 2 Sep 2000
Mailing List:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
List context return from filesystem functions
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 6 Aug 2000
Last Modified: 3 Sep 2000
Mailing List: [EMAIL PROTECTED
At 11:54 AM 9/4/00 -0700, Nathan Wiger wrote:
> > Seems a bit rare and unimportant -- until one observes how this
> > would also solve the problem of people being confused by this
> > gobbling up their handle:
> >
> > my($line) = ;
>
>And a nice side effect too. As Peter says, the only problem
Tom Christiansen wrote:
>
> Ever consider then having
>
> ($a, $b, $c) = ;
> or
> @a[4,1,5] = ;
>
> only read three lines? I mean, how many if any builtins would it
> make sense to make aware of this, and do something "different"?
Personally, I think this would be really cool; stuff l
At 10:52 AM 9/4/00 -0600, Nathan Torkington wrote:
>Peter Scott writes:
> > >> ($a, $b, $c) = ;
> > >> or
> > >> @a[4,1,5] = ;
> > >> only read three lines?
> > >
> > >I think this is a superb idea, and look forward to someone's RFC'ing it.
>
>Should be part of the want() c
Peter Scott writes:
> >> ($a, $b, $c) = ;
> >> or
> >> @a[4,1,5] = ;
> >> only read three lines?
> >
> >I think this is a superb idea, and look forward to someone's RFC'ing it.
Should be part of the want() context. Permit operations to discover
(as does split) how many el
At 11:48 AM 9/3/00 +1100, Damian Conway wrote:
>> Ever consider then having
>>
>> ($a, $b, $c) = ;
>> or
>> @a[4,1,5] = ;
>>
>> only read three lines?
>
>I think this is a superb idea, and look forward to someone's RFC'ing it.
I like it too. Anyone working on
Peter Scott <[EMAIL PROTECTED]> writes:
> Have you seen http://search.cpan.org/doc/GREGOR/psh-0.008/doc/psh.pod and
> the other tools it references? I haven't used it/them myself - what you
> propose has never itched enough for me to scratch it with anything more
> than a one-liner - but it a
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Casey R. Tweten writes:
>> Wow. Now that, that, is lame. You're saying that keys() expects
>> it's first argument to begin with a %? Why should it care what it's
>> argumen begins with?
NT> The keys function changes its arguments
Raptor <[EMAIL PROTECTED]> writes:
>What is interesting to me :
>
>1. "push" is used more than any of the other array ops, even than "shift"
>2. "use" is very good candidate for speedup
>3. We still use very much "goto" :")
>4. "each" is used more than "values" and "keys"
>5. Things like "hex,chr,
hi,
here is one simple script (Requires Parse::RecDescent) that count operators
in scripts.(and my fisrt grammar ;") )
OK. I started this against my current perl installation.
(it is not pure RH6.2 install, but many things are added)
i.e.
find /perl_dir -name *.pm | ./count.pl | tee allops.txt
i
35 matches
Mail list logo
