Nathan Wiger wrote:
> I don't know about this. What if someone writes:
>
>print "You owe me $2, $name.\n";
>
> With -w it'll print out the "correct" version?
With a warning, because $2 isn't defined.
>You owe me $2, Nate.
>
> But without it it won't?
>
>You owe me , Nate.
You turn
> > This would HAVE to be a very optional feature. I rely on undef
> > converting to a null string in many, many programs.
>
> Surely in those programs you don't have -w turned on, because you wouldn't
> want to see all those warning messages. So here is another idea: -w causes
> string interpol
RFC 186 is another interesting -io RFC, even though I'm not on the -io
list. I couldn't find any discussion in the mail archive, so here's
some to
start it. Please copy me on the discussion. Sorry for cross posting,
but
this is attempting to unify RFCs from different lists; I've bcc'd two of
th
Amen to the below. So can we have an RFC 111 (v4) that gets rid of allowing
stuff after the terminator? Even the ";" afterward seems useless... the ";"
should be at the end of the statement, not the end of the here doc. The only
improvement to here docs I see in this RFC is to allow whitespace
Eric Roode wrote:
> >Imagine that you could easily override the conversion of undef() into a
> >string, so that when stringified it returns something like "#UNDEF#"
> >instead of just an empty string. That would make debugging far more
> >easy: take a look at the output, and search for this senti
Chaim Frenkel writes:
> Somehow I find
> if (40 == ($foo = substr($bar, index($bar, 'xyz' {
> }
I don't understand your hypothetical code. substr() returns the
substring of $bar from the position retutned by index, onward.
When would this be 40, if index is going to return the po
"Randal L. Schwartz" wrote:
>
> I think we need a distinction between "looping" blocks and
> "non-looping" blocks. And further, it still makes sense to
> distinguish "blocks that return values" (like subroutines and map/grep
> blocks) from either of those. But I'll need further time to process
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
>> Would it be reasonable to ask that passing undef into the offset
>> or start of substr have substr return an undef?
NT> Wouldn't you get a warning anyway, if you were treating undef like
NT> a number?
Aha, but I don't want a warning
On Wed, Sep 13, 2000 at 08:42:28PM -, Perl6 RFC Librarian wrote:
> Actually, some days I wish "C" meant "print nothing." I was tempted
> to title this RFC "Make C and <> consistent."
Color me stupid, but if you wanted to print nothing, shouldn't you
just delete the print statement? Unless y
>Imagine that you could easily override the conversion of undef() into a
>string, so that when stringified it returns something like "#UNDEF#"
>instead of just an empty string. That would make debugging far more
>easy: take a look at the output, and search for this sentinel string.
This would HAV
> foreach @bigarray {
> sub {
> yield (push @array1, $_);
> yield (push @array2, $_);
> yield (push @array3, $_);
> push @array4, $_;
> }->();
> };
>
> :-)
As I've said before, Randal, you're a bad, bad man.
Of co
> "Damian" == Damian Conway <[EMAIL PROTECTED]> writes:
>> foreach @bigarray {
>> yield (push @array1, $_);
>> yield (push @array2, $_);
>> yield (push @array3, $_);
>> push @array4, $_;
>> };
Damian> Except that C is like C and breaks out of the current
Damian> *subroutine*, not the current
>foreach @bigarray {
>yield (push @array1, $_);
>yield (push @array2, $_);
>yield (push @array3, $_);
>push @array4, $_;
>};
Except that C is like C and breaks out of the current
*subroutine*, not the current block.
Damian
Mark-Jason Dominus wrote:
>
> > This reminds me of a related but rather opposite desire I have had
> > more than once: a quotish context that would be otherwise like q() but
> > with some minimal extra typing I could mark a scalar or an array to be
> > expanded as in qq().
>
> I have wanted that
Chaim Frenkel writes:
> Removing -1 as a valid result, could be a breakage (if someone is
> doing something weird with a negative result)
I don't care, so long as the perl526 translator can wrap perl6's
index/rindex. And I gave sample code for it to do that.
> Would it be reasonable to ask that
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> In perl5, index() and rindex() return -1 if the
PRL> substring isn't found. This seems out of step with
PRL> the rest of Perl's functions, which return C
PRL> on error. I propose changing index() and rindex()
PRL> to return C i
On Wed, 13 Sep 2000 13:56:53 -0700, Peter Scott wrote:
>I would rather solve this by requiring that Perl identify the thing that
>was undef than what you propose below. Surely it can't be that hard.
Fine by me.
Only, AFAIK, Perl is only aware of "values", not of "variables".
--
Bart
> This reminds me of a related but rather opposite desire I have had
> more than once: a quotish context that would be otherwise like q() but
> with some minimal extra typing I could mark a scalar or an array to be
> expanded as in qq().
I have wanted that also, although I don't remember why ju
At 10:49 PM 9/13/00 +0200, Bart Lateur wrote:
>Imagine the following scenario: your script contains a doiuble-quotish
>40 line here-doc, with a bunch of variables in it. Unforetunately, you
>forgot to set one, and you get the not so helpful complaint:
>
> use of unitialized value at line x
On Wed, Sep 13, 2000 at 10:49:41PM +0200, Bart Lateur wrote:
> Imagine the following scenario: your script contains a doiuble-quotish
> 40 line here-doc, with a bunch of variables in it. Unforetunately, you
> forgot to set one, and you get the not so helpful complaint:
>
> use of unitialize
Imagine the following scenario: your script contains a doiuble-quotish
40 line here-doc, with a bunch of variables in it. Unforetunately, you
forgot to set one, and you get the not so helpful complaint:
use of unitialized value at line xxx
where xxx is the line number for the line that c
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
system() should return useful values
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: Sep 13 2000
Mailing List: [EMAIL PROTECTED]
Number: 221
Version: 1
Status: Developing
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
wait() and waitpid() should return false on failure
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: Sep 13 2000
Mailing List: [EMAIL PROTECTED]
Number: 220
Version: 1
Sta
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
POD needs a reorder command.
=head1 VERSION
Maintainer: Kenneth C. Rich <[EMAIL PROTECTED]>
Date: 12 Sep 2000
Last Modified: 13 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 217
Version: 2
Status:
On Wed, 13 Sep 2000, Michael G Schwern wrote:
...many good points, all of which I should have known. :-(
I will modify the RFC to reflect that /\bshell\b/i is a poor name, due
to the current Shell module.
Personally, I don't particularly care what it's called - after all, I
don't name things ve
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
More defaulting to $_
=head1 VERSION
Maintainer: Kenneth C. Rich <[EMAIL PROTECTED]>
Date: 10 Sep 2000
Last Modified: 13 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 215
Version:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
crypt() default salt
=head1 VERSION
Maintainer: Mark Dominus <[EMAIL PROTECTED]>
Date: 11 Sep 2000
Last Modified: 13 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 208
Version: 2
Status: Dev
Damian Conway wrote:
>
> What you want is:
>
> %newhash = map {yield $_; transform($_)} %oldhash;
>
> This flattens the %oldhash to a sequence of key/value pairs. Then the
> first time the map block is called (i.e. on a key) it immediately
> returns the key. The second time, it resumes
Perl6 RFC Librarian writes:
> An inconsistency between "C" and "<>" bugs me: "C" means
> "C" so it seems like "<>" should mean "C<$_ = > <>".
> I can't yet think of code that this extension would break.
I assume you mean that <> in void context should assign to $_?
Any code that has set $_, the
On Wed, Sep 13, 2000 at 07:48:23AM -0400, Bryan C . Warnock wrote:
> On Wed, 13 Sep 2000, Michael G Schwern wrote:
> > Sooo... what happens to the existing Shell.pm?
>
> The RFC title notwithstanding, the pragma would be, by convention,
> lowercase. (As reflected in the abstract.)
The nasty abi
At 09:19 AM 9/13/00 -0700, I wrote:
>At 10:38 AM 9/13/00 -0400, John Porter wrote:
>> > 2. Allowing $/ (or its successor, perhaps set on a per-filehandle
>> > basis) to be a regular expression, not a string. (Surely there's an RFC
>> > on that somewhere.)
>>
>>This is a good idea too, and should
At 10:38 AM 9/13/00 -0400, John Porter wrote:
> > 2. Allowing $/ (or its successor, perhaps set on a per-filehandle
> > basis) to be a regular expression, not a string. (Surely there's an RFC
> > on that somewhere.)
>
>This is a good idea too, and should probably be considered independently.
*A
On Wed, 13 Sep 2000 10:58:51 -0400, John Porter <[EMAIL PROTECTED]> wrote:
> H.Merijn Brand wrote:
> > Are we being clever again?
> > Rephrase: "No empty lines".
> > I know you understood, but ... (no, I won't say it)
>
> Frankly, I thought it was absurd when I first wrote it...
> but then I look
Raptor wrote:
>
>problem can be solved again in this way i.e. shell like syntax :
>
>while $i > 10 && $i++ && print $i;
>
>mean this
>
>while ($i > 10 ) {$i++; print $i};
But:
$i=-5; while ($i<=5) && $i++ && print $i;
doesn't mean the same as:
$i=-5; while ($i<=5) {$i++; print $i}
eve
> problem can be solved again in this way i.e. shell like syntax :
>
> while $i > 10 && $i++ && print $i;
>
> mean this
>
> while ($i > 10 ) {$i++; print $i};
These don't mean the same thing - even in shell. The && requires truth.
Hence the reason this:
tar cBpf - . | ( cd /dest/dir && ta
hi,
> so,
>
>while $i < 10 print $i; print $j;
>
> should become
>
>while ($i < 10) { print $i; print $j; }
>
> or
>
>while ($i < 10) { print $i; } print $j;
> ???
]- !!! ;")
problem can be solved again in this way i.e. shell like syntax :
while $i > 10 && $i++ && print $i;
mean thi
H.Merijn Brand wrote:
> Are we being clever again?
> Rephrase: "No empty lines".
> I know you understood, but ... (no, I won't say it)
Frankly, I thought it was absurd when I first wrote it...
but then I looked at again, and now I'm not so sure I dislike it!
=head1 CHANGES
=over 4
=item *
Tom Christiansen wrote:
>
> Speaking of failure-mode, all syscalls should return false on failure, not
> ever -1. Right now, wait and waitpid work the other way. They should
> go the undef vs "0 but true" route that ioctl, fcntl, and sysread take.
And system()!
But I'm pretty sure you meant t
On Wed, 13 Sep 2000 10:19:38 -0400, John Porter <[EMAIL PROTECTED]> wrote:
> H.Merijn Brand wrote:
> > On 13 Sep 2000 07:18:15 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> > > This and other RFCs are available on the web at
> > > http://dev.perl.org/rfc/
> > >
> > > =head1 TITLE
> >
> When you process POD, all POD material prints.
> Sometimes that is undesirable. Podders need to have the
> option of not printing their POD. Also, it would be
> nice to have the order of output differ from the order in the
> source, sometimes.
These are essentially pod processor implementatio
On Wed, Sep 13, 2000 at 12:00:49PM +0100, raptor wrote:
> I was thinking will it be good if the braces are used but not required for
> while $i < 10 print $i;
> mean
> while ($i < 10) { print $i };
so,
while $i < 10 print $i; print $j;
should become
while ($i < 10) { print $i; print
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
> Garrett Goebel <[EMAIL PROTECTED]> writes:
> >
> > I agree... why can't a block be a block? Or put another
> > way, instead of trying to shoehorn in something new, why
> > don't we take away something old and treat all the blocks
> > the same
Andy Dougherty wrote:
>
> 1. A standard library function to safely but forgivingly read in a
> "paragraph". I have cc'd perl6-stdlib since this strikes me as a sensible
> candidate for the standard library.
I like this idea a lot. It would work very well with my RFC 79.
> 2. Allowing $/ (o
> An inconsistency between "C" and "<>" bugs me: "C" means
> "C" so it seems like "<>" should mean "C<$_ = > <>".
> I can't yet think of code that this extension would break.
>
> Would this have an advantage in making the
>
> while( <> ) {
> }
>
> syntax less magical?
You should probably ch
H.Merijn Brand wrote:
> On 13 Sep 2000 07:18:15 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> > This and other RFCs are available on the web at
> > http://dev.perl.org/rfc/
> >
> > =head1 TITLE
> >
> > POD should tolerate white space.
>
> I don't want any newlines needed at all, tho
> $_ is the default variable for some operations.
> Some other operations might benefit from similar use of
> $_ to reduce clutter.
This, as a general principle, sounds good.
> An inconsistency between "C" and "<>" bugs me: "C" means
> "C" so it seems like "<>" should mean "C<$_ = > <>".
> I
> POD should tolerate white space where it now requires empty lines
[...]
> =head1 IMPLEMENTATION
>
> Seems like it should be just a regexp stuck in somewhere
I think this is a specific problem calling for a more general solution.
I can think of two possible ones:
1. A standard library func
>I can't think any reason why POD tags require "\n" instead of /^\s*$/.
Because then you can set $/ = "" and sail through a source file, of course!
--tom
Speaking of failure-mode, all syscalls should return false on failure, not
ever -1. Right now, wait and waitpid work the other way. They should
go the undef vs "0 but true" route that ioctl, fcntl, and sysread take.
--tom
Today around 6:25am, Michael G Schwern hammered out this masterpiece:
: Sooo... what happens to the existing Shell.pm?
Indeed. Especially since, as of 5.7.0, it has a beautiful OO Interface so name
space pollution is avoided*. ;-)
[*] Of course, the origional intention of Shell.pm, seemingly t
On Wed, Sep 13, 2000 at 12:00:49PM +0100, raptor wrote:
> hi,
>
> I was thinking will it be good if the braces are used but not required for
> ops like while, until, if, unless ...etc... what I have in mind :
>
> if $x > 10 print $x;
> work as
> if ($x > 10) {print $x};
>
> OR
>
> while $i <
On Wed, 13 Sep 2000, Michael G Schwern wrote:
> Sooo... what happens to the existing Shell.pm?
The RFC title notwithstanding, the pragma would be, by convention,
lowercase. (As reflected in the abstract.)
Of course, should language features be added to allow scoping to be
easily controlled, it
On Wed, 13 Sep 2000 12:00:49 +0100, raptor wrote:
>I was thinking will it be good if the braces are used but not required for
>ops like while, until, if, unless ...etc... what I have in mind :
>
>if $x > 10 print $x;
>work as
>if ($x > 10) {print $x};
Eek! No! This is one of the things that I c
On Wed, Sep 13, 2000 at 07:04:26AM -0400, Ken Rich wrote:
> On the further note, though, I dislike the idea of overloading the
> =for label for =print purposes. I will modify the RFC.
Well, its not like the =for label is used much anyway... (yes, that is
a troll for someone to tell me otherwise)
> On 13 Sep 2000 07:18:15 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> > POD should tolerate white space.
>
> I don't want any newlines needed at all, though I think I stand somewhat alone
> here.
> --
> H.Merijn Brand Amsterdam Perl Mongers (http://www.amsterdam.pm.org/)
I
> POD readers will currently ignore =for and =begin/=end blocks with a
> name they don't recognize.
Thanks, that is a good idea. RTM, Kenny. Guess I am so allergic to
the foreign formatter stuff that my eye slides right off that
paragraph. And the labelless =clip grew out of the =print rather
On 13 Sep 2000, Perl6 RFC Librarian wrote:
> An inconsistency between "C" and "<>" bugs me: "C" means
> "C" so it seems like "<>" should mean "C<$_ = > <>".
> I can't yet think of code that this extension would break.
Minor formatting nit: modern pod parsers accept not only C<> but also
C<<>>,
On 13 Sep 2000 07:18:15 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> POD should tolerate white space.
I don't want any newlines needed at all, though I think I stand somewhat alone
here.
Sooo... what happens to the existing Shell.pm?
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
MORONS!
On Wed, Sep 13, 2000 at 07:18:15AM -, Perl6 RFC Librarian wrote:
> POD should tolerate white space where it now requires empty lines
I used to trip over this problem alot in my code. In fact, patches
#5507 and #5493 to perl were just about stripping whitespace out of
POD, IIRC.
I can't thin
On Wed, Sep 13, 2000 at 07:18:56AM -, Perl6 RFC Librarian wrote:
> =item Comment out documentation
>
> Sometimes I want a chunk of documentation to stick around but not
> be visible to the casual user. It may be tentative, half-baked, plain
> wrong, still in development, a comment about the
hi,
I was thinking will it be good if the braces are used but not required for
ops like while, until, if, unless ...etc... what I have in mind :
if $x > 10 print $x;
work as
if ($x > 10) {print $x};
OR
while $i < 10 print $i;
mean
while ($i < 10) { print $i };
I know that some will tell that
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
POD needs comment command. POD needs a reorder command.
=head1 VERSION
Maintainer: Kenneth C. Rich <[EMAIL PROTECTED]>
Date: 12 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 217
Version: 1
Status:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
POD should tolerate white space.
=head1 VERSION
Maintainer: Kenneth C. Rich <[EMAIL PROTECTED]>
Date: 12 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 216
Version: 1
Status: Devel
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
More defaulting to C<$_>.
=head1 VERSION
Maintainer: Kenneth C. Rich <[EMAIL PROTECTED]>
Date: 12 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 215
Version: 1
Status: Developing
Jeremy Howard wrote:
>
> > [EMAIL PROTECTED] wrote:
> > >
> > > Could we please take discussion of 179 to -data? I think that's where
> > > it should be.
> > >
> > > K.
> >
> > Personnally, I don't see any objection to this.
> > If everybody is ok, why not ?
> >
> > How should I process ? Submit
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
rindex and index should return undef on failure
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: Sep 12 2000
Mailing List: [EMAIL PROTECTED]
Number: 213
Version: 1
Status:
67 matches
Mail list logo
