Fw: Wrapup time

2000-09-13 Thread Jeremy Howard
Forwarded from perl6-meta Nathan Torkington wrote: Larry's going to release a draft of his langauge decisions on the 1st of October. My plan to prevent a flood of 100 new RFCs on September 30: - deadline for new RFCs of Sep 25. After that, only discussion of old ones. - send mail

reshape() (was Re: Fw: Wrapup time)

2000-09-13 Thread Jeremy Howard
Nathan Wiger wrote: Jeremy Howard wrote: 148: Change to Numeric Python semantics of reshape(), or write counter-RFC specifying these semantics (preferably renaming this RFC's 'reshape' to something else) There are a couple things that the NumPy one lacks that RFC 148 currently has:

Re: reshape() (was Re: Fw: Wrapup time)

2000-09-13 Thread Nathan Wiger
Jeremy Howard wrote: RFC 203 defines a :bounds attribute that defines the maximum index of each dimension of an array. RFC 206 provides the syntax @#array which returns these maximum indexes. For consistancy, the arguments to reshape() should be the maximum index of each dimension. A

Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch

2000-09-13 Thread Russ Allbery
Chaim Frenkel [EMAIL PROTECTED] writes: One other that might be useful is have strftime() (or something similar) built-in without having to use POSIX; and the default should be MMDDHHMMSS.fff, (the ISO format) The more commonly-used ISO format is the extended format rather than the

Re: RFC 181 (v1) Formats out of core / New format syntax

2000-09-13 Thread Glenn Linderman
I'm not on -io, so copy me on discussion. But this RFC was intriguing, so I read the discussion on the archive for it, and have the following comments. Perl6 RFC Librarian wrote: format FILE = @: @ $name, $ssn . =head2 New Syntax Under the new syntax, a format will be held in a

Re: Draft RFC: my Dog $spot is just an assertion

2000-09-13 Thread Hildo Biersma
Piers Cawley wrote: =head1 ABSTRACT The behaviour of the my Dog $spot syntax should simply be an assertion of the invariant: (!defined($spot) || (ref($spot) $spot-isa('Dog))) Apart from the buglet that Damian pointed out, agree. Instead of an implementation based on tie, I'd rather

Re: Draft RFC: new pragma: Cuse namespace

2000-09-13 Thread Hildo Biersma
Piers Cawley wrote: =head1 ABSTRACT Cmy Big::Long::Prefix::Class $object = Big::Long::Prefix::Class-Egtnew is a pain in the bum to type. We should replace this with use namespace 'Big::Long::Prefix'; my ::Class $object = ::Class-new; This is a bit dangerous, since we can get

Re: Draft RFC: my Dog $spot is just an assertion

2000-09-13 Thread Piers Cawley
Damian Conway [EMAIL PROTECTED] writes: Piers wrote: The behaviour of the my Dog $spot syntax should simply be an assertion of the invariant: (!defined($spot) || (ref($spot) $spot-isa('Dog))) (!defined($spot) || (ref($spot) $spot-isa('Dog')))

Re: RFC 101 (v2) Handlers and Pseudo-classes

2000-09-13 Thread John Porter
A module may remain the best implementation for this, the only problems are with speed (since the Perl 5 version requires AUTOLOAD) and also using this mechanism for core methods (like the new Copen from RFC 14). Just MHO, but I don't think this is the kind of thing that should go in the

Re: Draft RFC: new pragma: Cuse namespace

2000-09-13 Thread Piers Cawley
Hildo Biersma [EMAIL PROTECTED] writes: Piers Cawley wrote: =head1 ABSTRACT Cmy Big::Long::Prefix::Class $object = Big::Long::Prefix::Class-Egtnew is a pain in the bum to type. We should replace this with use namespace 'Big::Long::Prefix'; my ::Class $object =

Re: Draft RFC: new pragma: Cuse namespace

2000-09-13 Thread Hildo Biersma
Piers Cawley wrote: This is a bit dangerous, since we can get into ambiguities again. If I have A::B::C::Foo, A::B::C::Bar, X::Y::Z::Foo and X::Y::Z::Bar, I'd like to use shorthands for A::B::C's Foo and X::Y::Z's Bar at the same time. Well you can't. The patch that I pinched this

Re: Draft RFC: new pragma: Cuse namespace

2000-09-13 Thread Dave Storrs
On 13 Sep 2000, Piers Cawley wrote: Hildo Biersma [EMAIL PROTECTED] writes: Piers Cawley wrote: I'd like to use shorthands for A::B::C's Foo and X::Y::Z's Bar at the same time. Well you can't. The patch that I pinched this RFC from is a lexically How about if we added a

Re: Draft RFC: new pragma: Cuse namespace

2000-09-13 Thread Dave Storrs
Scuse me...I just realized that I missed an edit in my previous post. The [1] that you see was intended to be a footnote talking about the possibility of conflicting namespace aliases. When I expanded that into the final couple paragraphs, I forgot to take out the [1]. Sorry for the

Re: Draft RFC: new pragma: Cuse namespace

2000-09-13 Thread Nathan Wiger
use namespace 'Big::Long::Prefix'; my ::Class $object = ::Class-new; Anyone mentioned that this: $SHORT = 'Some::Huge::Obnoxious::Ridiculous::Term'; $SHORT-member; $stuff = new $SHORT; Already works? The only problem is that this: $SHORT::stuff(@args); Doesn't, but this

Re: RFC 218 (v1) Cmy Dog $spot is just an assertion

2000-09-13 Thread Damian Conway
I was hoping Damian would be able to suggest a Perlish way of handling typechecking and polymorphism. If you mean static typechecking, then it is the natural enemy of polymorphism. Either you give up interface polymorphism (a grievous loss) or you give up static type-checking.

Re: RFC 218 (v1) Cmy Dog $spot is just an assertion

2000-09-13 Thread Nathan Torkington
Damian Conway writes: Either you give up interface polymorphism (a grievous loss) or you give up static type-checking. Blech, you're right. Actually, it's inheritance polymorphism that proliferates pretend classes like Pet. I meant that. Sorry, you're so in tune with Perl that I'm

Re: RFC 101 (v2) Handlers and Pseudo-classes

2000-09-13 Thread Nathan Wiger
[added -io cross-post] John Porter wrote: Just MHO, but I don't think this is the kind of thing that should go in the core. Just MHO. I think I agree. Just to clarify, the only reason it's an RFC and not just a Perl 5 module is because RFC 14 (the one on a new open()) relies on a handler

Re: RFC 144 (v1) Behavior of empty regex should be simple

2000-09-13 Thread John Porter
John Porter wrote: Mark Dominus [EMAIL PROTECTED]: This behavior should be changed. If the PATTERN is empty, Perl should look for the empty string. (That is, if the PATTERN is empty, it should always match.) Except perhaps for undef loperands? (matchees? bindees?) What did you

Re: RFC 166 (v1) Additions to regexs

2000-09-13 Thread Richard Proctor
On Wed 13 Sep, Bart Lateur wrote: On Tue, 12 Sep 2000 19:01:35 -0400, Mark-Jason Dominus wrote: I don't know what you mean, but you're mistaken, because it means to interpolate @foo as in a double-quoted string. Which is precisely the meaning he wants for it, with $" set to '|'. I

Re: perl6-language-regex summary for 20000911

2000-09-13 Thread Paul Grzesina
On Mon, 11 Sep 2000, Mark-Jason Dominus wrote: perl6-language-regex Summary report 2911 RFC 164: Replace =~, !~, m//, s///, and tr// with match(), subst(), and trade() (Nathan Wiger) Surprisingly, there was no discussion about this RFC this week. I only read the

Re: RFC 72 (v3) Variable-length lookbehind: the regexp engine should also go backward.

2000-09-13 Thread Peter Heslin
On Tue, Sep 12, 2000 at 05:16:17AM +0100, Hugo wrote: :Simply put, I want variable-length lookbehind. The difficulty with variable-length lookbehind (let's call it VLLB) is this: suppose that we want to match "abcdef...xyz" =~ /(?=x+)y/. In theory, to check the possible /x+/ matches in the

Re: RFC 72 (v3) Variable-length lookbehind: the regexp engine should also go backward.

2000-09-13 Thread Robert Mathews
Hugo wrote: The difficulty with variable-length lookbehind (let's call it VLLB) is this: suppose that we want to match "abcdef...xyz" =~ /(?=x+)y/. In theory, to check the possible /x+/ matches in the right order [0] we need to check whether there we can match 0 characters at offset 0 (no),

Re: RFC 212 (v1) Make length(@array) work

2000-09-13 Thread Randal L. Schwartz
"Perl6" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: Perl6 Make length(@array) work Perl6 I propose to make length() return the number of elements in the array Perl6 it is passed, if its first argument begins with @. This proposal makes length() an un-prototypable (and therefore

Re: RFC 212 (v1) Make length(@array) work

2000-09-13 Thread Nathan Torkington
Randal L. Schwartz writes: This proposal makes length() an un-prototypable (and therefore unoverridable). Do you have a proposal for how to handle that? Do we really want everything in Perl to be overridable? What use is an overridden length()? Nat

Re: RFC 212 (v1) Make length(@array) work

2000-09-13 Thread Dave Storrs
On Wed, 13 Sep 2000, Hildo Biersma wrote: =head1 TITLE Make length(@array) work Counter-proposal: make length(@array) a syntax error. I don't feel like rewarding stupidity, I'd rather teach people how to do things properly. As a general rule, I agree with Hildo that we

Re: RFC 212 (v1) Make length(@array) work

2000-09-13 Thread Nathan Torkington
Nathan Wiger writes: Brainstorming off the top of my head: sub length (($|@)) { } That is, use a regex-like "(x|y)" - or maybe [$@%] ?? - for alternative context coercions. The only RFC on prototype extensions we have is Andy Wardley's #57. I suggest you ask him to add this

Re: RFC 212 (v1) Make length(@array) work

2000-09-13 Thread Nathan Torkington
Casey R. Tweten writes: Ok, consider allowing: $a = length @b; to DWIM, however, when running with warnings, warn the user that Cscalar is what they really want. Just thowing that out there. Good idea, but I think it's a bad move to turn warnings into style guides. Warnings should

Re: RFC 212 (v1) Make length(@array) work

2000-09-13 Thread Casey R. Tweten
Today around 12:19pm, Nathan Torkington hammered out this masterpiece: : Casey R. Tweten writes: : Ok, consider allowing: : :$a = length @b; : : to DWIM, however, when running with warnings, warn the user that Cscalar is : what they really want. : : Just thowing that out there. :

Re: RFC 212 (v1) Make length(@array) work

2000-09-13 Thread Randal L. Schwartz
"Casey" == Casey R Tweten [EMAIL PROTECTED] writes: Casey I agree with this line of thinking, however, I suppose I don't Casey agree with implementing length in this way since we already Casey have Cscalar. Casey In that light, if Clength is to replace scalar for, we'll Casey say, LISTs, then

Re: RFC 212 (v1) Make length(@array) work

2000-09-13 Thread Damian Conway
This proposal makes length() an un-prototypable (and therefore unoverridable). Do you have a proposal for how to handle that? Pray to Damian for a prototype that supports this? :-) If you'd been studying the holy writings properly, young Torkington, instead of those wicked

Re: RFC 212 (v1) Make length(@array) work

2000-09-13 Thread Damian Conway
The only RFC on prototype extensions we have is Andy Wardley's #57. Except, of course for #128, which already covers it. ;-) Damian

Re: RFC 212 (v1) Make length(@array) work

2000-09-13 Thread Damian Conway
Who has time to read all the crap you write, Damian? :-) Indeed. ;-) Sorry I missed that one. Thanks for pointing it out. I've just submitted an updated version which will probably hit the archive in the next few hours. For those who can't wait, the latest versions of all my RFCs are

Uninitialized value warnings should die (was Re: RFC 212 (v1) Make length(@array) work)

2000-09-13 Thread Nathan Wiger
Nathan Torkington wrote: Turning Perl into a nagging harpie means that the really important warnings will be ignored. This line of thinking brought to you by Mark-Jason's excellent talk on data typing. I agree, and just read MJD's paper the other day (nice job, BTW), but unfortunately

RFC 213 (v1) rindex and index should return undef on failure

2000-09-13 Thread Perl6 RFC Librarian
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:

Re: Please take RFC 179 discussion to -data

2000-09-13 Thread Gael Pegliasco
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 again the proposal with a

RFC 215 (v1) More defaulting to C$_.

2000-09-13 Thread Perl6 RFC Librarian
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

RFC 216 (v1) POD should tolerate white space.

2000-09-13 Thread Perl6 RFC Librarian
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:

RFC 217 (v1) POD needs comment command. POD needs a reorder command.

2000-09-13 Thread Perl6 RFC Librarian
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:

Don't require braces

2000-09-13 Thread raptor
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

Re: RFC 217 (v1) POD needs comment command. POD needs a reorder command.

2000-09-13 Thread Michael G Schwern
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

Re: RFC 216 (v1) POD should tolerate white space.

2000-09-13 Thread Michael G Schwern
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

Re: RFC 42 - Request For New Pragma: Shell

2000-09-13 Thread Michael G Schwern
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!

Re: RFC 216 (v1) POD should tolerate white space.

2000-09-13 Thread H . Merijn Brand
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. I

Re: RFC 215 (v1) More defaulting to C$_.

2000-09-13 Thread Philip Newton
On 13 Sep 2000, Perl6 RFC Librarian wrote: An inconsistency between "Cprint" and "" bugs me: "Cprint;" means "Cprint $_;" 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

Re: RFC 217 (v1) POD needs comment command. POD needs a reorder command.

2000-09-13 Thread Ken Rich
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

Re: RFC 216 (v1) POD should tolerate white space.

2000-09-13 Thread Ken Rich
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 agree!

Re: RFC 217 (v1) POD needs comment command. POD needs a reorder command.

2000-09-13 Thread Michael G Schwern
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).

Re: Don't require braces

2000-09-13 Thread Bart Lateur
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 consider

Re: RFC 42 - Request For New Pragma: Shell

2000-09-13 Thread Bryan C . Warnock
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

Re: Don't require braces

2000-09-13 Thread Walt Mankowski
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 10 print $i;

Re: RFC 42 - Request For New Pragma: Shell

2000-09-13 Thread Casey R. Tweten
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

Re: RFC 213 (v1) rindex and index should return undef on failure

2000-09-13 Thread Tom Christiansen
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

Re: RFC 216 (v1) POD should tolerate white space.

2000-09-13 Thread Tom Christiansen
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

Re: RFC 216 (v1) POD should tolerate white space.

2000-09-13 Thread Andy Dougherty
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

Re: RFC 215 (v1) More defaulting to C$_.

2000-09-13 Thread John Porter
$_ 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 "Cprint" and "" bugs me: "Cprint;" means "Cprint $_;" so it seems like "" should mean "C$_ =

Re: RFC 216 (v1) POD should tolerate white space.

2000-09-13 Thread John Porter
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, though I think I

Re: RFC 215 (v1) More defaulting to C$_.

2000-09-13 Thread Nathan Wiger
An inconsistency between "Cprint" and "" bugs me: "Cprint;" means "Cprint $_;" 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

RE: $a in @b (RFC 199)

2000-09-13 Thread Garrett Goebel
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 under Perl

Re: Don't require braces

2000-09-13 Thread Tad McClellan
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 $j; }

Re: RFC 216 (v1) POD should tolerate white space.

2000-09-13 Thread H . Merijn Brand
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 POD should

Re: RFC 216 (v1) POD should tolerate white space.

2000-09-13 Thread John Porter
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 *

Re: Don't require braces

2000-09-13 Thread raptor
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 this while ($i 10 )

Re: Don't require braces

2000-09-13 Thread Eric Roode
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} even if we ignore the

Re: RFC 216 (v1) POD should tolerate white space.

2000-09-13 Thread H . Merijn Brand
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 looked at

Re: RFC 42 - Request For New Pragma: Shell

2000-09-13 Thread Michael G Schwern
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 abiguity

Re: RFC 215 (v1) More defaulting to C$_.

2000-09-13 Thread Nathan Torkington
Perl6 RFC Librarian writes: An inconsistency between "Cprint" and "" bugs me: "Cprint;" means "Cprint $_;" 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

more yield tricks ((was Re: Cmap in RFC 31

2000-09-13 Thread David L. Nicol
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 after

RFC 208 (v2) crypt() default salt

2000-09-13 Thread Perl6 RFC Librarian
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:

RFC 215 (v2) More defaulting to $_

2000-09-13 Thread Perl6 RFC Librarian
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:

Re: RFC 42 - Request For New Pragma: Shell

2000-09-13 Thread Bryan C . Warnock
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

RFC 217 (v2) POD needs a reorder command.

2000-09-13 Thread Perl6 RFC Librarian
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:

RFC 220 (v1) wait() and waitpid() should return false on failure

2000-09-13 Thread Perl6 RFC Librarian
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

Conversion of undef() to string user overridable for easy debugging

2000-09-13 Thread Bart Lateur
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

Re: Conversion of undef() to string user overridable for easy debugging

2000-09-13 Thread Jarkko Hietaniemi
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 unitialized

Re: Conversion of undef() to string user overridable for easy debugging

2000-09-13 Thread Peter Scott
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 xxx

Re: Conversion of undef() to string user overridable for easy debugging

2000-09-13 Thread Mark-Jason Dominus
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 just

Re: Conversion of undef() to string user overridable for easy debugging

2000-09-13 Thread Bart Lateur
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.

Re: RFC 213 (v1) rindex and index should return undef on failure

2000-09-13 Thread Chaim Frenkel
"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 Cundef PRL on error. I propose changing index() and rindex() PRL to return Cundef if

Re: RFC 213 (v1) rindex and index should return undef on failure

2000-09-13 Thread Nathan Torkington
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

Re: Conversion of undef() to string user overridable for easy debugging

2000-09-13 Thread Brad Hughes
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 also,

Re: more yield tricks ((was Re: Cmap in RFC 31

2000-09-13 Thread Damian Conway
foreach @bigarray { yield (push @array1, $_); yield (push @array2, $_); yield (push @array3, $_); push @array4, $_; }; Except that Cyield is like Creturn and breaks out of the current *subroutine*, not the current block.

Re: more yield tricks ((was Re: Cmap in RFC 31

2000-09-13 Thread Randal L. Schwartz
"Damian" == Damian Conway [EMAIL PROTECTED] writes: foreach @bigarray { yield (push @array1, $_); yield (push @array2, $_); yield (push @array3, $_); push @array4, $_; }; Damian Except that Cyield is like Creturn and breaks out of the current Damian *subroutine*, not the current block.

Re: more yield tricks ((was Re: Cmap in RFC 31

2000-09-13 Thread Damian Conway
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 course, the

Re: Conversion of undef() to string user overridable for easy debugging

2000-09-13 Thread Eric Roode
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 HAVE

Re: RFC 215 (v2) More defaulting to $_

2000-09-13 Thread Michael G Schwern
On Wed, Sep 13, 2000 at 08:42:28PM -, Perl6 RFC Librarian wrote: Actually, some days I wish "Cprint;" meant "print nothing." I was tempted to title this RFC "Make Cprint and consistent." Color me stupid, but if you wanted to print nothing, shouldn't you just delete the print statement?

Re: RFC 213 (v1) rindex and index should return undef on failure

2000-09-13 Thread Chaim Frenkel
"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, I want the

Re: $a in @b (RFC 199)

2000-09-13 Thread David L. Nicol
"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

Re: RFC 213 (v1) rindex and index should return undef on failure

2000-09-13 Thread Nathan Torkington
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

Re: Conversion of undef() to string user overridable for easy debugging

2000-09-13 Thread Glenn Linderman
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 sentinel

Re: RFC 216 (v1) POD should tolerate white space.

2000-09-13 Thread John Porter
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 $/ (or

Re: RFC 216 (v1) POD should tolerate white space.

2000-09-13 Thread Peter Scott
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 probably be

Re: RFC 216 (v1) POD should tolerate white space.

2000-09-13 Thread Peter Scott
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.