Re: Murdering @ISA considered cruel and unusual

Simon Cozens <[EMAIL PROTECTED]> writes: > On Thu, Sep 28, 2000 at 02:40:04PM -0400, John Porter wrote: > > Tom Christiansen wrote: > > > Perl's use of @ISA is beautiful. > > > > > > use base is, or can be, pretty silly -- > > > think pseudohashes, just for one. > > > > I suppose you diddle @

Re: RFC 329 (v1) C

Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > C > [ ... ] > =head1 ABSTRACT > > A pragma to modify the syntax of Perl 6 at run time. Oh yes. > [...] > =head1 IMPLEMENTATION > > First, i

Re: RFC 325 (v1) POD and comments handling in perl

It really is not feasible to relax the pod requirement that pod diretives begin with an equals to allow them to begin with a pound sign as well, for to do so would expose an untold number of programs to unpredictable effects. I also don't really see any advantage. And yes, I'm sure I'm days be

Re: Cya dudes

On Fri, Sep 29, 2000 at 02:34:55AM +, Ed Mills wrote: > I tried to contribute on this list bu -- "He was a modest, good-humored boy. It was Oxford that made him insufferable."

Term::ReadKey inclusion

It is unreasonably complicated to do single-character input in a portable fashion. We should therefore include the Term::ReadKey module in the standard distribution. Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the indiv

Re: Cya dudes

On Fri, Sep 29, 2000 at 09:39:20AM +0100, Simon Cozens wrote: > On Fri, Sep 29, 2000 at 02:34:55AM +, Ed Mills wrote: > > I tried to contribute on this list bu [You know, I think something went wrong there. Let's try again.] The RFC process gets you a hotline to Larry on an equal footing wit

Re: RFC 333 (v1) Add C and C funtions to coredistribution

On 28 Sep 2000, Perl6 RFC Librarian wrote: > The C function would work very similarly to C's: > >@HEADERS = header(content_type => 'text/html', > author => 'Nathan Wiger', > last_modified => $date, > accept => [qw(text/html text/

RE: RFC 329 (v1) C

>I briefly considered > >{ >use syntax "python"; >} > >and nearly lost my lunch. And if you want to lose your breakfast too, consider: use "lisp"; use "apl"; (Although if the array-processing and currying RFCs are accepted, Perl will finally have powers beyond tho

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

On 29 Sep 2000, Perl6 RFC Librarian wrote: > Make Perl's powerful string interpolation facilities are available to > variables, in addition to literals. > > =head1 DESCRIPTION > > Given: > > $foo = 'def'; > $bar = 'ghi'; > $x = "abc$foo$bar"; > $y = 'abc$foo$bar'; > > There is no way to tu

Re: RFC 333 (v1) Add C and C funtions to coredistribution

> Hm. This makes it difficult to construct a header incrementally -- for > example, @HEADERS=(); push @HEADERS, header(content_type=>'a', > author=>'b'); # 75 lines later; push @HEADERS, header(last_modified=>'c', > accept=>'d'); > > Since in this case, there would be two "blank" head lines inste

goof - RFC 328 (v1) Single quotes don't interpolate \' and \\

I goofed. (EWRONGLIST) I realise now that I should have said that RFC 328 (and 327) should have been on this list, not perl-language-data I had what I thought was a good look at previous RFCs but managed to miss RFC226 (Selective interpolation in single quotish context.) What I wanted comments a

Re: RFC 333 (v1) Add C and C funtions to coredistribution

On Fri, 29 Sep 2000, Nathan Wiger wrote: > > > Should result in C<@out> being exactly equivalent to C<@in>. > > > > It cannot, of course, since the order of hash keys obtained by flattening > > the hash is not necessarily the same as when you built the hash. > > Actually, it does. Remember, a h

Re: RFC 337 (v1) Common attribute system to allow user-defined, extensible attributes

> > =head1 TITLE > > > > Common attribute system to allow user-defined, extensible attributes > > Err... have you read perldoc attributes? There's already a mechanism > for doing this (see my japh), though it is a complete PITA to use and > I'd like to see it tidied up (and possibly have attribut

IDEA: lexically scoped subs anyone

Did anyone suggest the following yet? package Foo; my sub _helper_function { ... } sub public_function { ... helper_function(...); ... } # Some other file: use Foo; Foo::public_function(@args); # Okay Foo::_helper_function(@args); # Th

Re: IDEA: lexically scoped subs anyone

On Fri, Sep 29, 2000 at 04:13:46PM +0100, Piers Cawley wrote: > Did anyone suggest the following yet? > package Foo; > my sub _helper_function { ... } Todo: lexically scoped functions: my sub foo { ... } the basic concept is easy and sound, the difficulties begin with

Re: RFC 288 (v2) First-Class CGI Support

On 28 Sep 2000, at 21:36, iain truskett wrote: > * Philip Newton ([EMAIL PROTECTED]) [28 Sep 2000 21:19]: > > On 27 Sep 2000, at 23:48, iain truskett wrote: > > > > So surely you'd want %HTTP (the input headers) to also be an array > > > rather than a hash, since they'd be required in order as w

Why -> cannot autoquote the LHS (was Re: RFC 244 (v1) Method calls should not suffer...)

> =head1 TITLE > > Method calls should not suffer from the action on a distance > Currently, > > foo->bar($baz) > > can be parsed either as C<<'foo'->bar($baz)>>, or as C> > depending on how the symbol C was used on other places. The proposal > is to always choose the first meani

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

"John L. Allen" wrote: > Um, what would your proposal gain you over > > $z = eval "qq{$y}"; > > other than conciseness, elegance and speed (which may be quite enough!) ? $y = '};system "rm -rf *";qq{'; -- Robert Mathews Software Engineer Excite@Home

Re: RFC 288 (v2) First-Class CGI Support

Alan Gutierrez wrote: > HTML::Embperl stuffs form input into a hash just as proposed here. For > multiple values it creates a tab-delimited string. This will not present > the above trouble with commas, since when the user, for some odd reason, > enters "Ann Arbor\tMI", in most browsers the input

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

On Fri, 29 Sep 2000, Robert Mathews wrote: > "John L. Allen" wrote: > > Um, what would your proposal gain you over > > > > $z = eval "qq{$y}"; > > > > other than conciseness, elegance and speed (which may be quite enough!) ? > > $y = '};system "rm -rf *";qq{'; Hmmm, hold on a second while

Re: Attribute access

From: "Nathan Wiger" <[EMAIL PROTECTED]> Sent: Friday, September 29, 2000 12:51 AM > James Mastros wrote: > > As far as setting|getting, I'd like to make a simple proposal. Consider it > > an idea for whoever writes the RFC (I'm looking at you, Nate) > Oh, jeez, as if I didn't have enough already

Accessing perl's command line switches

In a perl program I found the need to determine the command line swithches passed to perl to be used to invoke the program. But I couldn't find anything that gave this. There is $^X but that's limited. I needed to reinvoke perl with all the -S and -I etc. commands. (I needed a daemon that could

Re: RFC 288 (v2) First-Class CGI Support

* Philip Newton ([EMAIL PROTECTED]) [30 Sep 2000 02:47]: > On 28 Sep 2000, at 21:36, iain truskett wrote: [] > > It's a case of: if you're going to have the output order, then you > > should provide for the input to be ordered. *As well as* unordered. > Sorry, I don't follow your line of reas

Re: IDEA: lexically scoped subs anyone

On 29 Sep 2000, Piers Cawley wrote: > Is it possible? Advisable? I haven't seen it yet, but that doesn't mean it's not in there somewhere...there's a bunch of RFCs I haven't had time to read. If it isn't there, it should be. I think this is definitely a cool idea.

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

> > This is a new feature, so name conflict is the only issue. > > Thisseems compatiblewith otherextensionsto string > interpolation... whatever extensions get implemented should work here > too. it's not a new feature. It's amazing the subtle control you can get with

RFC 327 (v2) C<\v> for Vertical Tab

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE C<\v> for Vertical Tab =head1 VERSION Maintainer: Nicholas Clark <[EMAIL PROTECTED]> Date: 26 Sep 2000 Last Modified: 29 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 327 Version: 2 Status:

RFC 328 (v2) Single quotes don't interpolate \' and \\

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Single quotes don't interpolate \' and \\ =head1 VERSION Maintainer: Nicholas Clark <[EMAIL PROTECTED]> Date: 28 Sep 2000 Last Updated: 29 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 328 Ve

RFC 259 (v1) Builtins : Make use of hashref context for garrulous builtins

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Builtins : Make use of hashref context for garrulous builtins =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 19 Sep 2000 Last Modified: 29 Sep 2000 Mailing List: [EMAIL PROTECTED

RFC 264 (v3) Provide a standard module to simplify the creation of source filters

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Provide a standard module to simplify the creation of source filters =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 20 Sep 2000 Last Modified: 29 Sep 2000 Mailing List: [EMAIL PR

RFC 271 (v3) Subroutines : Pre- and post- handlers for subroutines

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Subroutines : Pre- and post- handlers for subroutines =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 20 Sep 2000 Last Modified: 29 Sep 2000 Mailing List: [EMAIL PROTECTED] Numb

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

"David L. Nicol" wrote: > it's not a new feature. It's amazing the subtle control you > can get with s/(\$...)/$1/ge depending on your You mean /gee, right? Hadn't thought of that. /ee makes my brain hurt. -- Robert Mathews Software Engineer Excite@Home

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

Robert Mathews wrote: > > "David L. Nicol" wrote: > > it's not a new feature. It's amazing the subtle control you > > can get with s/(\$...)/$1/ge depending on your > > You mean /gee, right? Hadn't thought of that. /ee makes my brain hurt. I actually usually do things like unde

Re: RFC 328 (v2) Single quotes don't interpolate \' and \\

> =head1 ABSTRACT > > Remove all interpolation within single quotes and the C operator, to > make single quotes 100% shell-like. C<\> rather than C<\\> gives a single > backslash; use double quotes or C if you need a single quote in your > string. Yes. If people really need single quotes inside

Re: RFC 328 (v2) Single quotes don't interpolate \' and \\

On Fri, Sep 29, 2000 at 09:20:23PM -, Perl6 RFC Librarian wrote: > Although consensus so far is against the change, views were from B > perl users [who do you expect as the majority on perl6 lists? :-)]. The > change would penalise existing perl users, but benefit new perl users (and > presuma

Re: RFC 351 (v1) Beyond the amnesic eval

On Fri, Sep 29, 2000 at 09:47:00PM -, Perl6 RFC Librarian wrote: > Classic eval: > > eval {} > eval "" > > Unscoped eval > > +eval {} > +eval "" I like the general idea of this RFC, but the proposed syntax is less than desirable. What happens with the following? $result = 20+eval

Re: RFC 328 (v2) Single quotes don't interpolate \' and \\

Perl6 RFC Librarian wrote : || =head1 TITLE || || Single quotes don't interpolate \' and \\ || || =head1 VERSION || || Maintainer: Nicholas Clark <[EMAIL PROTECTED]> || Date: 28 Sep 2000 || Last Updated: 29 Sep 2000 || Mailing List: [EMAIL PROTECTED] || Number: 328 || Version: 2 ||

Re: RFC 339 (v1) caller->eval BLOCK

> > caller->eval EXPRESSION; > > That's mad, bad, scary and dangerous. Let's do it. Yes, this is cool. In fact, I'm writing Regexp::Func right now as a prototype for RFC 164 and discovering I could really use this - in fact, need it. A couple things: 1. Implement this eval as UNIVERSA

Re: RFC 328 (v2) Single quotes don't interpolate \' and \\

On Fri, Sep 29, 2000 at 09:20:23PM -, Perl6 RFC Librarian wrote: > Single quotes don't interpolate \' and \\ I rather like the Python triple-quote mechanism used for this purpose: $foo = """Things like ', ", and \ have no special meaning in here."""; Of course, this doesn't help if you wa

Re: RFC 328 (v2) Single quotes don't interpolate \' and \\

At 04:22 PM 9/29/00 -0700, Damien Neil wrote: >On Fri, Sep 29, 2000 at 09:20:23PM -, Perl6 RFC Librarian wrote: > > Single quotes don't interpolate \' and \\ > >I rather like the Python triple-quote mechanism used for this >purpose: > > $foo = """Things like ', ", and \ have no special meani

Re: RFC 328 (v2) Single quotes don't interpolate \' and \\

On Fri, Sep 29, 2000 at 02:14:26PM -0800, Michael Fowler wrote: > On Fri, Sep 29, 2000 at 09:20:23PM -, Perl6 RFC Librarian wrote: > > Although consensus so far is against the change, views were from B > > perl users [who do you expect as the majority on perl6 lists? :-)]. The > > change would

Re: RFC 327 (v2) C<\v> for Vertical Tab

Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > However, lack of C<\v> represents a special case for a C programmer to > learn. C<\v> isn't used for anything else in double quoted strings, nor > is it used in regular expressions, so it won't require removal of an > existing feature to add it.

RE: RFC 327 (v2) C<\v> for Vertical Tab

-> -Original Message- -> From: Russ Allbery [mailto:[EMAIL PROTECTED]] -> -> Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: -> -> > However, lack of C<\v> represents a special case for a C programmer to -> > learn. C<\v> isn't used for anything else in double quoted -> strings, nor -> >

Re: RFC 327 (v2) C<\v> for Vertical Tab

David Olbersen <[EMAIL PROTECTED]> writes: >> From: Russ Allbery [mailto:[EMAIL PROTECTED]] >> Just out of curiosity, and I'm not objecting to this RFC, has anyone >> reading this mailing list actually intentionally used a vertical tab >> for something related to its supposed purpose in the past

Re: RFC 328 (v2) Single quotes don't interpolate \' and \\

On Sat, Sep 30, 2000 at 01:01:52AM +0100, Nicholas Clark wrote: > My opinion is that > The current system is slightly irregular in the way it works. > A less irregular system would be nicer (hindsight is a wonderful thing) > It would have been nice to have had a less irregular system to star

Re: RFC 259 (v1) Builtins : Make use of hashref context for garrulous builtins

> "Will" == Will Coleda <[EMAIL PROTECTED]> writes: Will> Perl6 RFC Librarian wrote: >> =head1 VERSION >> >> Maintainer: Damian Conway <[EMAIL PROTECTED]> >> Date: 19 Sep 2000 >> Last Modified: 29 Sep 2000 >> Mailing List: [EMAIL PROTECTED] >> Number: 259 >> Version: 1 >> Status: Frozen >> F

Re: RFC 288 (v2) First-Class CGI Support

On Wed, 27 Sep 2000, iain truskett wrote: > Is order important for @HEADERS? Would it be better to have %HEADERS > instead that does such auto-formatting? >From RFC 2068 HTTP/1.0 - 4.2 Message Headers: The order in which header fields with differing field names are received is not significant.

Non-RFC: Revisit (Un)signed Integer Bit Ops?

There have been several suggestions and RFCs to consider implementing stronger typing -- C -- and attributes -- C -- for Perl. Should we consider revisiting how current perl handles bit operations on numbers, ie, based on the C pragma? >From perlop: --- Used on numbers, the bitwise operators ("

Re: RFC 303 (v1) Keep C, but make it work.

On 27 Sep 2000, Piers Cawley wrote: > Simon Cozens <[EMAIL PROTECTED]> writes: > > > On Wed, Sep 27, 2000 at 03:49:10PM +0100, Tom Christiansen wrote: > > > Don't change "use less" to "use optimize". We don't > > > need to ruin the cuteness. > > > > "use less 'rolled_loops';" sounds really wei

Re: RFC 351 (v1) Beyond the amnesic eval

> =head1 ABSTRACT > > An unscoped eval is needed. It is part of the necessary steps to > make Perl palatable as an interactive shell. I agree with Michael that the syntax is not suitable. If it's a separate function, then it needs to be a \w+ name. You should check out RFC 339 - it talks about

Re: RFC 288 (v2) First-Class CGI Support

* Nathan Wiger ([EMAIL PROTECTED]) [29 Sep 2000 02:14]: > > A future protocol could well require things in order. Hence you're > > having the output headers in order. Therefore you should have the > > input ones available in order as well. > I don't see a reason why an @HTTP ordered and %HTTP uno

Re: RFC 288 (v2) First-Class CGI Support

On Fri, 29 Sep 2000, Robert Mathews wrote: > Alan Gutierrez wrote: > > HTML::Embperl stuffs form input into a hash just as proposed here. For > > multiple values it creates a tab-delimited string. This will not present > > the above trouble with commas, since when the user, for some odd reason, >

Re: RFC 303 (v1) Keep C, but make it work.

Alan Gutierrez wrote: > > C< use less 'recursion' > sounds just find to me. > > The negation of C< use less 'rolled_loops' >, > C< use more 'unrolled_loops' >, does not sound very weird at all. > Weren't we planning on haveing a use more as an opposite of use less? If > so, let cuteness prevail!

Re: RFC 288 (v2) First-Class CGI Support

* Alan Gutierrez ([EMAIL PROTECTED]) [30 Sep 2000 14:47]: [...] > Pity about Solaris. I wonder if Gerard Richter, HTML::Embperl mainter, > has ideas about this? Does it really matter since it's a textarea? Typically you know which fields are only going to have one value and can just not split th

Re: RFC 288 (v2) First-Class CGI Support

On Sat, 30 Sep 2000, iain truskett wrote: > Or someone could split CGI.pm up so that there's CGI::FormValues and > CGI::HTTPHeaders. By jove Mr. Truskett, that sounds like a smashing idea! Could we RFC this? Do you think Mr. Stien would think us pushy? IMHO this thread is discussing the impleme

Re: RFC 288 (v2) First-Class CGI Support

* Alan Gutierrez ([EMAIL PROTECTED]) [30 Sep 2000 14:55]: > On Sat, 30 Sep 2000, iain truskett wrote: > > Or someone could split CGI.pm up so that there's CGI::FormValues and > > CGI::HTTPHeaders. > By jove Mr. Truskett, that sounds like a smashing idea! Could we RFC > this? Do you think Mr. Sti

Re: RFC 288 (v2) First-Class CGI Support

On Sat, 30 Sep 2000, iain truskett wrote: > * Alan Gutierrez ([EMAIL PROTECTED]) [30 Sep 2000 14:47]: > > [...] > > Pity about Solaris. I wonder if Gerard Richter, HTML::Embperl mainter, > > has ideas about this? > > Does it really matter since it's a textarea? Typically you know which > fields

Re: RFC 333 (v1) Add C and C funtions to coredistribution

On 28 Sep 2000, Perl6 RFC Librarian wrote: > =head1 TITLE > > Add C and C funtions to core distribution > =head2 Location > > These are such lightweight functions that their impact on core would be > negligible. As such, they could potentially be put directly into it, > since they are just for

Re: RFC 333 (v1) Add C and C funtions to coredistribution

On 28 Sep 2000, Perl6 RFC Librarian wrote: > =head1 TITLE > > Add C and C funtions to core distribution > The C > function would simply: > >1. uc the first letter of each tag token and lc the > rest, also converting _'s to -'s auto

Re: RFC 333 (v1) Add C and C funtions to coredistribution

On 28 Sep 2000, Perl6 RFC Librarian wrote: > =head1 TITLE > > Add C and C funtions to core distribution > > The C > function would simply: > >1. uc the first letter of each tag token and lc the > rest, also converting _'s to -'s au

Re: RFC 339 (v1) caller->eval BLOCK

Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > caller->eval BLOCK > > =head1 VERSION > > Maintainer: David Nicol <[EMAIL PROTECTED]> > Date: 28 Sep 2000 > Mailing List: [EMAIL PROTECTED]

Re: Cya dudes

"Ed Mills" <[EMAIL PROTECTED]> writes: > I tried to contribute on this list but it seems we've coalesced downto Tom > and a handful of others. No one else has a voice. Hmm... not my experience. But then I've only seen your message here because of Simon's response to it, my spamfilter sees your

Re: Cya dudes

Piers Cawley <[EMAIL PROTECTED]> writes: > "Ed Mills" <[EMAIL PROTECTED]> writes: > > > I tried to contribute on this list but it seems we've coalesced downto Tom > > and a handful of others. No one else has a voice. > > Hmm... not my experience. But then I've only seen your message here > bec

Re: RFC 337 (v1) Common attribute system to allow user-defined, extensible attributes

Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Common attribute system to allow user-defined, extensible attributes > > =head1 VERSION > > Maintainer: Nathan Wiger <[EMAIL PROTECTED]> > Da

Re: IDEA: lexically scoped subs anyone

Dave Storrs wrote: > > On 29 Sep 2000, Piers Cawley wrote:[EMAIL PROTECTED] > > > Is it possible? Advisable? > > I haven't seen it yet, but that doesn't mean it's not in there > somewhere...there's a bunch of RFCs I haven't had time to read. If it > isn't there, it should be. I think