Re: RFC 234 (v1) Data: overloading via the SECOND operand if needed

2000-09-15 Thread Nathan Wiger
This RFC proposes a support of a situation when a more-knowledgable module may steal overloading from a less-knowledgable module or visa versa; What if both modules have this :override bit set at the same time? Does the second one still win? Or does the first one win again? Either way I'm not

Re: RFC 237 (v1) hashes should interpolate in double-quoted strings

2000-09-15 Thread Michael G Schwern
On Sat, Sep 16, 2000 at 03:37:33AM -, Perl6 RFC Librarian wrote: "%hash" should expand to: join( $/, map { qq($_$"$hash{$_}) } keys %hash ) So let me get this straight... %hash = (foo = 42, bar = 13); print "%hash"; should come out to: foo 42 bar 13 The idea of

RFC 196 (v2) More direct syntax for hashes

2000-09-15 Thread Perl6 RFC Librarian
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 Last Modified: 15 Sep 2000 Mailing List: [EMAIL PROTECTED] Version: 2 Number: 196

RFC 237 (v1) hashes should interpolate in double-quoted strings

2000-09-15 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE hashes should interpolate in double-quoted strings =head1 VERSION Maintainer: Nathan Torkington [EMAIL PROTECTED] Date: 15 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 237 Version: 1

Update: Wrapping up -data RFCs

2000-09-15 Thread Jeremy Howard
Adam Turoff wrote: I didn't use Date::Parse, but I did look for all RFCs still stting at v1 status. Since they're numbered chronologically, I cut off the bottom (anything submitted after 9/7). There are 100 RFCs in the list that follows. Code and data upon request. Thanks Ziggy--very

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

2000-09-15 Thread Chris Nandor
At 15:55 -0400 2000.09.15, Chaim Frenkel wrote: CN * We do not know if it will always be this simple for every platform Hard to see how the three variables wouldn't cover the spectrum. Very hard to see, until we know what the disparate platforms might require. :) CN * You might need to

Re: RFC 222 (v1) Interpolation of method calls

2000-09-15 Thread Bart Lateur
On Thu, 14 Sep 2000 18:37:22 -0500, David L. Nicol wrote: print "Today's weather will be ${weather-temp} degrees and sunny."; which would follow the "You want something funny in your interpolated scalar's name or reference, you put it in curlies" rule. I too feel that an approach like

Re: RFC 222 (v1) Interpolation of method calls

2000-09-15 Thread Michael G Schwern
On Thu, Sep 14, 2000 at 05:31:44PM -0500, David L. Nicol wrote: A possibility that does not appear in RFC222.1 is to put tho whole accessor expression inside curlies: print "Today's weather will be ${weather-temp} degrees and sunny."; which would follow the "You want something funny

Re: RFC 222 (v1) Interpolation of method calls

2000-09-15 Thread Michael Fowler
On Fri, Sep 15, 2000 at 10:58:26AM +0200, Bart Lateur wrote: MJD has a "silly module" which can tie a hash to a function: Interpolation.pm. I think I would like a special case, a specific hash that is *always* tied to a function that returns the arguments. Make it, for example, %$, %@ or %?.

Re: RFC 222 (v1) Interpolation of method calls

2000-09-15 Thread Bart Lateur
On Fri, 15 Sep 2000 01:36:50 -0800, Michael Fowler wrote: Or maybe an alternative, using : "foo foo(arg, arg, arg) bar" "foo { foo(arg, arg, arg) } bar" Ah, yes, {...}, I kinda like that. Unfortunately, in regexes, /{1,3}/ means matching 1 to three ampersands. There's a slight

Re: RFC 222 (v1) Interpolation of method calls

2000-09-15 Thread David L. Nicol
Michael Fowler wrote: Or maybe we need a more generic solution (as someone else suggested, I forget who). Something that allows the arbitrary execution of code, much like @{[ ]}, but cleaner. Unfortunately, I can't think of anything suitable. Whatever direction this discussion takes, I

Re: RFC - Interpolation of method calls

2000-09-15 Thread David L. Nicol
The only decision, then, is to decide which context to use; if it deparses to concatenation then it seems logical to use scalar context. This also makes sense in that you can force list context with @{[ $weather-temp ]} if you really wanted it. $ perl -le 'sub w{wantarray?"WA":"WS"};print

Re: RFC - Interpolation of method calls

2000-09-15 Thread Michael Fowler
On Fri, Sep 15, 2000 at 07:24:39PM -0500, David L. Nicol wrote: The only decision, then, is to decide which context to use; if it deparses to concatenation then it seems logical to use scalar context. This also makes sense in that you can force list context with @{[ $weather-temp ]} if

Fwd: [Re: [FWP] Comic goodness]

2000-09-15 Thread Michael G Schwern
I thought you people might need a little break. The first one is particularly... yeah. - Forwarded message from Jim Monty [EMAIL PROTECTED] - From: Jim Monty [EMAIL PROTECTED] Subject: Re: [FWP] Comic goodness To: [EMAIL PROTECTED] Date: Fri, 15 Sep 2000 09:53:48 -0700 (MST) See,

Re: RFC 166 (v2) Alternative lists and quoting of things

2000-09-15 Thread Mark-Jason Dominus
(?Q$foo) Quotes the contents of the scalar $foo - equivalent to (??{ quotemeta $foo }). How is this different from \Q$foo\E ?

RFC 166 (v2) Alternative lists and quoting of things

2000-09-15 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Alternative lists and quoting of things =head1 VERSION Maintainer: Richard Proctor [EMAIL PROTECTED] Date: 27 Aug 2000 Last Modified: 15 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 166

RFC 212 (v2) Make length(@array) work

2000-09-15 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Make length(@array) work =head1 VERSION Maintainer: Nathan Torkington [EMAIL PROTECTED] Date: Sep 12 2000 Last Modified: Sep 15 2000 Mailing List: [EMAIL PROTECTED] Number: 212 Version: 2

Re: RFC 238 (v1) length(@ary) deserves a warning

2000-09-15 Thread Michael G Schwern
On Sat, Sep 16, 2000 at 04:21:15PM +1100, Damian Conway wrote: I'm surprised there hasn't be a good overhaul of the prototyping system proposeed yet. What exactly didn't you like about RFC 128??? Ummm... the fact that its title doesn't match /proto/. My bad. Okay, its a proposal

Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)

2000-09-15 Thread Ariel Scolnicov
Dave Storrs [EMAIL PROTECTED] writes: [...] print FIRST_HERE_DOC; print SECOND_HERE_DOC; This is on the left margin. This is indented one char. FIRST_HERE_DOC This is indented one char. This is on the left margin. SECOND_HERE_DOC RFC 111

Re: RFC 223 (v1) Objects: Cuse invocant pragma

2000-09-15 Thread Hildo Biersma
Nathan Wiger wrote: and this may, indeed, be sufficient. Remember, this still won't solve the problem of a module whose functions can handle both OO and function-oriented calls - and yes, I have many that do this. :-) I think such modules are a bad idea, because their functionality is

Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)

2000-09-15 Thread Michael G Schwern
On Thu, Sep 14, 2000 at 03:36:10PM -0700, Nathan Wiger wrote: See, this is just too inflexible. The main complaint that I've heard has been "You can't have leading or trailing whitespace around your terminator". This is a very common error made by everyone, and *this* is where Perl should

Re: 'eval' odd thought

2000-09-15 Thread Bart Lateur
On Thu, 14 Sep 2000 18:14:49 -0400, Mark-Jason Dominus wrote: The perl 5 - perl 6 translator should replace calls to 'eval' with calls to 'perl5_eval', which will recursively call the 5-6 translator to translate the eval'ed string into perl 6, and will then eval the result. Blech, no. eval

Re: RFC 223 (v1) Objects: Cuse invocant pragma

2000-09-15 Thread Graham Barr
On Thu, Sep 14, 2000 at 08:10:54PM -, Perl6 RFC Librarian wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Objects: Cuse invocant pragma =head1 VERSION Maintainer: Damian Conway [EMAIL PROTECTED] Date: 14 September 2000

Re: RFC 226 (v2) Selective interpolation in single quotish context.

2000-09-15 Thread Philip Newton
On 15 Sep 2000, at 1:10, Perl6 RFC Librarian wrote: With this proposal, the scalar C$filename can be tagged to be interpolated by the C\I...\E pair and the double quotish context replaced by single quotish context resulting in the following: Definitely with this change, you should include a

Re: RFC 226 (v2) Selective interpolation in single quotish context.

2000-09-15 Thread Philip Newton
On 14 Sep 2000, at 21:06, Glenn Linderman wrote: I _like_ the conceptual idea, here. But I think we need a different kind of quoting, not extend single quote semantics. Single quote semantics are really, really, good for exact quoting. I'm sure you (since you mention VMS) find single

Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)

2000-09-15 Thread Eric Roode
Michael Schwern wrote: See, I never understood this. If you're indenting the terminator, it implies you're also indenting the here-doc text. I mean, this doesn't make any sense: { { { { print TAG; I don't know what their gripe is. A critic is simply someone paid to render opinions

Re: RFC 226 (v2) Selective interpolation in single quotish context.

2000-09-15 Thread Andy Dougherty
Perl6 should allow scalars and arrays to be tagged such that they are interpolated in single quotish context. How do you turn it off? I want to keep a way to specify stuff without any interpolation whatsoever. I see the usefulness of this sort of quoting, but I also see the usefulness of

Re: RFC 229 (v1) Variable interpolation on demand.

2000-09-15 Thread Simon Cozens
On Fri, Sep 15, 2000 at 05:56:36AM -, Perl6 RFC Librarian wrote: $foo = 'def'; $bar = 'ghi'; $x = "abc$foo$bar"; $y = 'abc$foo$bar'; There is no way to turn obtain the value of $x from the value of $y. In other words, while $foo and $bar were interpolated

Re: RFC 223 (v1) Objects: Cuse invocant pragma

2000-09-15 Thread John Porter
Graham Barr wrote: One of the benefits I was hoping to get from having a variable hold the invocant is the ability for the invocant to be undef if the sub was not called as a method. Um, functions can return undef too, ya know. :-) -- John Porter

Re: RFC 223 (v1) Objects: Cuse invocant pragma

2000-09-15 Thread Philip Newton
On 14 Sep 2000, at 14:18, Nathan Wiger wrote: Before you balk at #1 in favor of religious flexibility, please consider how unmaintainable Perl code would be if @ARGV, or $AUTOLOAD, or STDERR, or @INC, or chomp(), or split(), or any other widely-used variable or function was renameable. If

Re: RFC 223 (v1) Objects: Cuse invocant pragma

2000-09-15 Thread John Porter
Hildo Biersma wrote: I think such modules are a bad idea, because their functionality is typically restricted. Oh? Where do you get that idea? Altering the language to make that easier seems a bad idea to me. On the contrary: altering *anything* about Perl to make something easier is

Re: 'eval' odd thought

2000-09-15 Thread Dave Storrs
On Fri, 15 Sep 2000, Bart Lateur wrote: On Thu, 14 Sep 2000 18:14:49 -0400, Mark-Jason Dominus wrote: The perl 5 - perl 6 translator should [recursively handle eval] Blech, no. eval should stay eval. People are responsible for generating Perl6 compatible code, if they construct code as

Re: RFC 102 (v2) Inline Comments for Perl.

2000-09-15 Thread John Porter
Perl6 RFC Librarian wrote: =head1 TITLE Inline Comments for Perl. Why was this posted again? I see no CHANGES section. An idea that produces a paired feeling would be to use one of the paired character pairs, as in "#" and "#". #BOh Lord, What Have I Gotten Myself Into?/B

Forking multiple socket connections

2000-09-15 Thread webmaster UtopiaNet ISP
My question: using IO::SOCKET, i need to connect to multiple server at once. The server side works very well; it only waits for connections over a fixed IP,port. How can i write the client-side? Please help me!

an RFC for unbalanced parens/braces?

2000-09-15 Thread Ed Mills
Since there were no objections to cleaning up the error messages on unbalanced parens and braces, can we RFC that request? -Ed _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information

Re: RFC 226 (v2) Selective interpolation in single quotish context.

2000-09-15 Thread Nathan Wiger
Andy Dougherty wrote: How do you turn it off? I want to keep a way to specify stuff without any interpolation whatsoever. I see the usefulness of this sort of quoting, but I also see the usefulness of being absolutely able to turn all interpolation off. Yes, I agree with this point, also

Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)

2000-09-15 Thread Nathan Wiger
Michael G Schwern wrote: See, I never understood this. If you're indenting the terminator, it implies you're also indenting the here-doc text. I mean, this doesn't make any sense: { { { { print TAG; I don't know what their gripe is. A critic is simply someone paid to

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Michael G Schwern
On Fri, Sep 15, 2000 at 02:00:04PM -0400, Adam Turoff wrote: I'm kinda surfing the edge here. -T is definately an internals issue, but $TAINT? taint()? is_tainted()? I'm not sure if they should be exposed into the language from the internals, or if a superstudly taint.xs in stdlib is

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Dan Sugalski
At 03:43 PM 9/15/00 -0400, Michael G Schwern wrote: On Fri, Sep 15, 2000 at 02:00:04PM -0400, Adam Turoff wrote: I'm kinda surfing the edge here. -T is definately an internals issue, but $TAINT? taint()? is_tainted()? I'm not sure if they should be exposed into the language from the

Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)

2000-09-15 Thread Richard Proctor
On Fri 15 Sep, Michael G Schwern wrote: On Fri, Sep 15, 2000 at 06:38:37PM +0100, Richard Proctor wrote: 1) removes whitespace equivalent to the terminator (e) this is largely backward complatible as many existing heredocs are unlikely to have white space before the terminator. 2)

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Michael G Schwern
On Fri, Sep 15, 2000 at 04:01:11PM -0400, Dan Sugalski wrote: Anyhow, however these extra tainting functions are implemented is fine (as long as they work). The simplest thing would be to just merge and patch up Taint.pm and distribute it with perl6. Yup. I know Tom wanted an all-perl

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Nathan Wiger
Michael G Schwern wrote: perl6-internals is probably the wrong forum for this, it was just convenient. I think Dan's got the right idea, distribute a Taint module with Perl. I'm not sure what's happened on -internals, but early on in perl6-language I suggested something similar, and Larry

Re: RFC 232 (v1) Replace AUTOLOAD by a more flexible mechanism

2000-09-15 Thread Nathan Torkington
Perl6 RFC Librarian writes: This RFC proposes two-stage autoloading: one stage may be registered to act when the symbol is encountered at compile time, the other when the subroutine is called. Autoloading on the second stage does not Icall the subroutine, only Iloads it. You have a

Re: RFC 226 (v1) Selective interpolation in single quotish context.

2000-09-15 Thread Nathan Torkington
My first preference is for overriding constant strings. My second preference is to provide a user-defined quoting operator mechanism, possibly as part of a user-defined operator mechanism. My third preference is for a new operator. I personally do not want to see q() screwed with. Nat

RFC 199 (v3) Short-circuiting built-in functions and user-defined subroutines

2000-09-15 Thread Garrett Goebel
=head1 TITLE Short-circuiting built-in functions and user-defined subroutines =head1 VERSION Maintainer: Garrett Goebel [EMAIL PROTECTED] Date: 15 Sep 2000 Version: 3 Mailing List: perl6-language Number: 199 Status: Developing =head1 ABSTRACT Allow built-in functions and user

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

2000-09-15 Thread Nathan Torkington
Chaim Frenkel writes: I would like to have an undef returned. Ah, I see. You want subroutines to return undef if they're given it for any of their arguments. That'd break the lazy programmer practice of passing undef expecting it to become "" or 0. They don't have warnings on, of course.

Backtracing contexts with self($n) (was Re: RFC 223 (v1) Objects: Cuse invocant pragma)

2000-09-15 Thread Nathan Wiger
I think such modules are a bad idea, because their functionality is typically restricted. What, you mean like CGI.pm ?! :-) This is a benefit? Forcing multiple authors to use the same 'this' or 'self' name across modules is not the perl way Well, from this logically follows that "forcing"

Re: RFC 230 (v1) Replace Cformat built-in with pragmatically-induced Cformat function

2000-09-15 Thread Nathan Wiger
First off, nice proposal. :-) I haven't had a change to digest the entire thing (although I did read it all), but I would like to add a few things: returns the result as a single multi-line string (in a scalar context) returns the result as a list of single-line strings (in a

Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)

2000-09-15 Thread Nathan Wiger
I'm happy with this solution, it seems to address everyone's needs. -Nate Michael G Schwern wrote: I'd say: 1) does what it does now mod RFC 111 (ie. you can put whitespace in the terminator, but it doesn't effect anything) 2) does (e).

Re: RFC 229 (v1) Variable interpolation on demand.

2000-09-15 Thread Glenn Linderman
Simon Cozens wrote: sub interpolate {eval "\"@_\""} Never say "there is no way". There's *always* a way, and 99% of the time it doesn't need to go in core. Yes. Well, actually if you carefully read the thread about RFC 111 in which I got the inspired flash that interpolation of variables

Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)

2000-09-15 Thread Bart Lateur
On Thu, 14 Sep 2000 03:11:54 -0400, Michael G Schwern wrote: The current stumper, which involves problems 1, 2 and 3 is this: if( $is_fitting $is_just ) { die POEM; The old lie Dulce et decorum est Pro patria mori. POEM } I propose

Re: RFC 226 (v2) Selective interpolation in single quotish context.

2000-09-15 Thread Bart Lateur
On Thu, 14 Sep 2000 21:06:24 -0700, Glenn Linderman wrote: However, let's look at it the other way. How about instead of trying to _extend_ single quote semantics, that instead we find a way of _disabling_ double quote semantics? Let's say within double quotes that \D reverts to single-quote

Re: RFC 226 (v2) Selective interpolation in single quotish context.

2000-09-15 Thread Bart Lateur
On Fri, 15 Sep 2000 11:25:31 -0700, Steve Fink wrote: Does it strike anyone else as odd that 'foo\\bar' eq 'foo\bar'? It's an necessary evil. You need a way to escape the string delimiter, so that it can be included in the string, for which the backslash is used. Hence, you need to be a be to

Re: RFC 226 (v2) Selective interpolation in single quotish context.

2000-09-15 Thread Michael Fowler
On Fri, Sep 15, 2000 at 11:25:31AM -0700, Steve Fink wrote: I agree. I'd like q/.../ to stick as close to giving me ... as possible. I can live with the current 'foo\\bar' having only one backslash in it, but I'd rather not have to worry about anything else. I'd vote for Glenn's allowing the

Re: RFC 230 (v1) Replace Cformat built-in with pragmatically-induced Cformat function

2000-09-15 Thread Damian Conway
prints the result to the current filehandle (in a void context). The last one I think needs to be able to work on any filehandle via indirect object syntax, namely: format $FILE " [[[ [[", $title, $text1,

RFC 71 (v2) Legacy Perl $pkg'var should die

2000-09-15 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Legacy Perl $pkg'var should die =head1 VERSION Maintainer: Nathan Wiger [EMAIL PROTECTED] Date: 08 Aug 2000 Last Modified: 15 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 71 Version:

Re: RFC 230 (v1) Replace Cformat built-in with pragmatically-inducedCformat function

2000-09-15 Thread Nathan Wiger
I loathe the indirect object syntax. Well that makes one of us! ;-) Easy. Put them in a subroutine: sub format1 { format $template1, @data }; sub format2 { print STDERR format $template1, @data }; # etc. Gag! Cough! Ack! :-} Not trying to be mean, but this

Re: RFC 71 (v2) Legacy Perl $pkg'var should die

2000-09-15 Thread Michael G Schwern
On Sat, Sep 16, 2000 at 03:20:23AM -, Perl6 RFC Librarian wrote: Perl used to use $pkg'var instead of the modern $pkg::var. This is still in Perl 5. It's gotta go. Aside from "its old", is there any particular reason why $pkg'var should go? The only reason I saw was that $hash{a'b}

Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)

2000-09-15 Thread Glenn Linderman
Richard Proctor wrote: Maybe I'm being too simplistic, I don't use tabs anymore. Yes you are, the problem comes with mixing editors - some use tabs for indented material some dont, some reduce files using tabs etc etc. [I move between too many editors]. Perl should DWIM. I think that

Re: RFC 236 (v1) Change the way $SIG{__WARN__} and $SIG{__DIE__} are used

2000-09-15 Thread Uri Guttman
"MGS" == Michael G Schwern [EMAIL PROTECTED] writes: MGS On Sat, Sep 16, 2000 at 03:36:45AM -, Perl6 RFC Librarian wrote: Change the way $SIG{__WARN__} and $SIG{__DIE__} are used MGS I don't think this is enough to repair $SIG{__WARN__} and MGS $SIG{__DIE__}. I know some people

RFC 236 (v1) Change the way $SIG{__WARN__} and $SIG{__DIE__} are used

2000-09-15 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Change the way $SIG{__WARN__} and $SIG{__DIE__} are used =head1 VERSION Maintainer: Chris Hostetter [EMAIL PROTECTED] Date: 15 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 236 Version: 1

RFC 103 (v2) Fix C$pkg::$var precedence issues with parsing of C::

2000-09-15 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Fix C$pkg::$var precedence issues with parsing of C:: =head1 VERSION Maintainer: Nathan Wiger [EMAIL PROTECTED] Date: 14 Aug 2000 Last Modified: 15 Sep 2000 Mailing List: [EMAIL PROTECTED]

RFC 213 (v2) rindex and index should return true/false values

2000-09-15 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 true/false values =head1 VERSION Maintainer: Nathan Torkington [EMAIL PROTECTED] Date: Sep 12 2000 Last Modified: Sep 15 2000 Mailing List: [EMAIL PROTECTED]

RFC 135 (v3) Require explicit m on matches, even with ?? and // as delimiters.

2000-09-15 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Require explicit m on matches, even with ?? and // as delimiters. =head1 VERSION Maintainer: Nathan Torkington [EMAIL PROTECTED] Date: August 20, 2000 Last Modified: 15 Sep 2000 Mailing List:

RFC 199 (v3) Short-circuiting built-in functions and user-defined subroutines

2000-09-15 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Short-circuiting built-in functions and user-defined subroutines =head1 VERSION Maintainer: Garrett Goebel [EMAIL PROTECTED] Date: 6 Sep 2000 Last Modified: 15 Sep 2000 Mailing List: [EMAIL

RFC 232 (v1) Replace AUTOLOAD by a more flexible mechanism

2000-09-15 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Replace AUTOLOAD by a more flexible mechanism =head1 VERSION Maintainer: Ilya Zakharevich [EMAIL PROTECTED] Date: 15 September 2000 Mailing List: [EMAIL PROTECTED] Number: 232 Version: 1

RFC 230 (v1) Replace Cformat built-in with pragmatically-induced Cformat function

2000-09-15 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Replace Cformat built-in with pragmatically-induced Cformat function =head1 VERSION Maintainer: Damian Conway [EMAIL PROTECTED] Date: 15 September 2000 Mailing List: [EMAIL PROTECTED] Number: 230

Re: RFC 232 (v1) Replace AUTOLOAD by a more flexible mechanism

2000-09-15 Thread Glenn Linderman
Nathan Torkington wrote: Actually, I think I'd like to see this extended. I'd like to be able to hook into the parser so that when it sees a function call: foo() I can have it call my subroutine. foo_handler( $token_stream ) foo_handler can access the token stream that may or may

Re: RFC 236 (v1) Change the way $SIG{__WARN__} and $SIG{__DIE__} are used

2000-09-15 Thread Michael G Schwern
On Sat, Sep 16, 2000 at 03:36:45AM -, Perl6 RFC Librarian wrote: Change the way $SIG{__WARN__} and $SIG{__DIE__} are used I don't think this is enough to repair $SIG{__WARN__} and $SIG{__DIE__}. I know some people out there have some very strong feelings about these pseudo-signals. It may