Re: RFC 204 (v2) Arrays: Use list reference for multidimensional array access

2000-09-27 Thread Nathan Wiger
Bart Lateur wrote: The problem is that $name = "myarray"; @$name = (1,2,3); print @$name[0,1]; # 1,2 Is very consistent currently. Change one and you have to change the precedence and parsing of all symbolic refs. You are suggesting to keep a weird precedence rule, just

Re: RFC 185 (v3) Thread Programming Model

2000-09-27 Thread James Mastros
On Wed, Sep 27, 2000 at 05:29:22AM -, Perl6 RFC Librarian wrote: $ok = try $scalar; $ok = try @array $ok = try %hash; $ok = try sub; I'd like to see a more specific name for these. 'try' is too useful a word for core to gobble it up for everything (IMHO). attempt_lock? Or

Re: RFC 319 (v1) Transparently integrate Ctie

2000-09-27 Thread Piers Cawley
Nathan Wiger [EMAIL PROTECTED] writes: I'm kind of curious to know what you think would happen with the following. I've commented where I'm confident... interface Number; sub TIESCALAR; sub STORE; sub FETCH; package integer implements Number; # I really

Re: RFC 161 (v4) Everything in Perl becomes an object.

2000-09-27 Thread Piers Cawley
Simon Cozens [EMAIL PROTECTED] writes: On Wed, Sep 27, 2000 at 05:25:28AM -, Perl6 RFC Librarian wrote: Not an awful lot was said once this RFC was condensed down to "Everything becomes an object". I believe some implementation and conceptual hurdles exist which have discouraged more

Re: RFC 161 (v4) Everything in Perl becomes an object.

2000-09-27 Thread Bennett Todd
2000-09-27-05:28:01 Piers Cawley: Simon Cozens [EMAIL PROTECTED] writes: On Wed, Sep 27, 2000 at 05:25:28AM -, Perl6 RFC Librarian wrote: At the suggestion of others I've opted to freeze rather than withdraw. How might I persuade you to reconsider? I was kind of hoping that

Re: RFC 161 (v4) Everything in Perl becomes an object.

2000-09-27 Thread Matt Youell
On Wed, Sep 27, 2000 at 05:25:28AM -, Perl6 RFC Librarian wrote: Not an awful lot was said once this RFC was condensed down to "Everything becomes an object". I believe some implementation and conceptual hurdles exist which have discouraged more serious discussion. At the

Re: RFC 161 (v4) Everything in Perl becomes an object.

2000-09-27 Thread Simon Cozens
On Wed, Sep 27, 2000 at 09:53:03AM -0700, Matt Youell wrote: Ok, no fair sniping after a freeze. You were warned. It's called email, people! Use it. Jeez... Never too late to withdraw, sir. [1] The less crap we make Larry wade through, the better. [1] Well, up until the pregnancy, I guess.

Re: RFC 161 (v4) Everything in Perl becomes an object.

2000-09-27 Thread Bennett Todd
2000-09-27-15:08:10 Simon Cozens: Never too late to withdraw, sir. [1] The less crap we make Larry wade through, the better. Regarding the specific issue at hand, could you please offer something more specific than "you'd like it withdrawn"? Is there a reason why it's impossible to implement

Re: RFC 161 (v4) Everything in Perl becomes an object.

2000-09-27 Thread Simon Cozens
On Wed, Sep 27, 2000 at 12:43:45PM -0700, Nathan Wiger wrote: As list chair, I ask either: 1. The people discussing this clarify themselves 2. The people discussing this please drop it Ho hum. You've heard, I believe, my arguments now. I'm happy to drop the matter, since it seems a

Re: RFC 161 (v4) Everything in Perl becomes an object.

2000-09-27 Thread Matt Youell
On Wed, Sep 27, 2000 at 12:16:36PM -0700, Matt Youell wrote: I open to hearing your reasons. The biggest reason it wasn't withdrawn is because someone said "hey don't do that, here's why". So give me a "why" already... It doesn't feel right to me. It doesn't feel Perlish. That's it?

Re: RFC 198 (v2) Boolean Regexes

2000-09-27 Thread Richard Proctor
HI Tom, Welcome to England (I presume) This seems very complicated. Did you look at the Ram:6 recipe on expressing AND, OR, and NOT in a regex? For example, to do /FOO/ /BAR/ you need not write /FOO.*BAR|BAR.*FOO/ -- and in fact, should not, as it doesn't work properly on some pairs!

is \1 vs $1 a necessary distinction?

2000-09-27 Thread Dave Storrs
Both \1 and $1 refer to what is matched by the first set of parens in a regex. AFAIK, the only difference between these two notation is that \1 is used within the regex itself and $1 is used outside of the regex. Is there any reason not to standardize these down to one notation (i.e., eliminate

Re: is \1 vs $1 a necessary distinction?

2000-09-27 Thread Jonathan Scott Duff
On Wed, Sep 27, 2000 at 08:15:53AM -0700, Dave Storrs wrote: Both \1 and $1 refer to what is matched by the first set of parens in a regex. AFAIK, the only difference between these two notation is that \1 is used within the regex itself and $1 is used outside of the regex. Is there any

Re: is \1 vs $1 a necessary distinction?

2000-09-27 Thread Dave Storrs
On Wed, 27 Sep 2000, Jonathan Scott Duff wrote: If $1 could be made to work properly on the LHS of s///, I'd vote for that being The Way. That was pretty much my thought?

Re: is \1 vs $1 a necessary distinction?

2000-09-27 Thread Uri Guttman
"DS" == Dave Storrs [EMAIL PROTECTED] writes: DS Both \1 and $1 refer to what is matched by the first set of parens DS in a regex. AFAIK, the only difference between these two notation DS is that \1 is used within the regex itself and $1 is used outside DS of the regex. Is there any

Re: is \1 vs $1 a necessary distinction?

2000-09-27 Thread Randal L. Schwartz
"Jonathan" == Jonathan Scott Duff [EMAIL PROTECTED] writes: Jonathan On Wed, Sep 27, 2000 at 08:15:53AM -0700, Dave Storrs wrote: Both \1 and $1 refer to what is matched by the first set of parens in a regex. AFAIK, the only difference between these two notation is that \1 is used within

Re: is \1 vs $1 a necessary distinction?

2000-09-27 Thread Dave Storrs
On 27 Sep 2000, Piers Cawley wrote: Do we *want* to maintain \1? Why have two notations to do the I'm kind of curious about what happens when you want to do, say: if (m/(\S+)/) { $reg = qr{(em|i|b)($1)/\1}; } where the $1 in the regex quote is refering to $1 from the

Re: is \1 vs $1 a necessary distinction?

2000-09-27 Thread Richard Proctor
On Wed 27 Sep, Dave Storrs wrote: On Wed, 27 Sep 2000, Richard Proctor wrote: Both \1 and $1 refer to what is matched by the first set of parens in a regex. AFAIK, the only difference between these two notation is that \1 is used within the regex itself and $1 is used outside of

Re: Perlstorm #0040

2000-09-27 Thread Ilya Zakharevich
== I lie: the other reason qr{} currently doesn't behave like that is that when we interpolate a compiled regexp into a context that requires it be recompiled, Interpolated qr() items shouldn't be recompiled anyway. They

Re: RFC 106 (v2) Yet another lexical variable proposal: lexical variables made default

2000-09-27 Thread Daniel Chetlin
I know it's unfair to comment on a frozen RFC, but I think it's important to note a few things: On Wed, Sep 27, 2000 at 05:22:30AM -, Perl6 RFC Librarian wrote: Maintainer: J. David Blackstone [EMAIL PROTECTED] Status: Frozen [snip] Dubbed the "conservative" approach by Mark-Jason

Re: RFC 324 (v1) Extend AUTOLOAD functionality to AUTOGLOB

2000-09-27 Thread Nathan Wiger
The AUTOGLOB subroutine should expect to take two parameters, the invocant, and a second parameter specifying what type of item is being AUTOGLOBbed, followed by - in the case of a sub - the sub's arguments. We suggest that the second parameter should be a scalar value - 'scalar' for an

Re: RFC 290 (v1) Remove -X

2000-09-27 Thread Ariel Scolnicov
Uri Guttman [EMAIL PROTECTED] writes: "JSD" == Jonathan Scott Duff [EMAIL PROTECTED] writes: I'll revise the RFC to add 'readable()', 'writable()', and such synonyms for -r and -w that are more like 'use english' and less like 'use English'. i have a minor problem with the

Re: RFC 290 (v1) Remove -X

2000-09-27 Thread Bart Lateur
On 27 Sep 2000 09:16:10 +0300, Ariel Scolnicov wrote: Another option is to stuff the long names into some namespace, and export them upon request (or maybe not export them, upon request). Can you say "method"? -- Bart.

Re: RFC 290 (v1) Remove -X

2000-09-27 Thread Adam Turoff
On Wed, Sep 27, 2000 at 08:50:28AM +0200, Bart Lateur wrote: On 27 Sep 2000 09:16:10 +0300, Ariel Scolnicov wrote: Another option is to stuff the long names into some namespace, and export them upon request (or maybe not export them, upon request). Can you say "method"? Doesn't work on

Re: RFC 290 (v2) Better english names for -X

2000-09-27 Thread Uri Guttman
"PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: PRL -r freadable() PRL -w fwriteable() PRL -x fexecable() PRL -o fowned() PRL -R Freadable() PRL -W Fwriteable() PRL -X Fexecable() PRL -O Fowned() PRL -e fexists() PRL

Re: RFC 290 (v2) Better english names for -X

2000-09-27 Thread Adam Turoff
On Wed, Sep 27, 2000 at 03:48:33AM -0400, Uri Guttman wrote: "PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: PRL -r freadable() PRL -w fwriteable() PRL -x fexecable() PRL -o fowned() PRL -R Freadable() PRL -W Fwriteable() PRL -X

Re: RFC 290 (v2) Better english names for -X

2000-09-27 Thread Uri Guttman
"AT" == Adam Turoff [EMAIL PROTECTED] writes: AT I can't think of any builtins that use _, but it's going to be AT exposed by use english, so perhaps that qualifies it. I'm AT on the fence though. If it's going to be *_writeable, is_writable() AT looks better. It is tom's original

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

2000-09-27 Thread iain truskett
* Perl6 RFC Librarian ([EMAIL PROTECTED]) [27 Sep 2000 18:36]: [] [...] When this pragma is loaded, it should replace the print coderef with a function that will print out all headers in the @HEADERS queue, print out the desired output, and restore the print coderef. It should also

Re: perl6storm #0050

2000-09-27 Thread Philip Newton
On 26 Sep 2000, Johan Vromans wrote: Philip Newton [EMAIL PROTECTED] writes: so fewer "cluttering" parentheses are needed to make things readable while still being correct. By the same reasoning, you can reduce the use of curlies by using indentation to define block structure. What

Re: perl6storm #0050

2000-09-27 Thread Philip Newton
On 26 Sep 2000, Johan Vromans wrote: Philip Newton [EMAIL PROTECTED] writes: so fewer "cluttering" parentheses are needed to make things readable while still being correct. Since when do parentheses make things less readable? Each parenthesis is one "token". The more tokens you need

Re: perl6storm #0050

2000-09-27 Thread Piers Cawley
Robert Mathews [EMAIL PROTECTED] writes: Simon Cozens wrote: (defun Schwartzian (func list) (mapcar (lambda (x) (car x)) (sort (mapcar (lambda (x) (cons x (funcall func x))) list ) (lambda (x y) ( (cdr x) (cdr y))) ) ) ) Maybe

Re: perl6storm #0050

2000-09-27 Thread iain truskett
* Philip Newton ([EMAIL PROTECTED]) [27 Sep 2000 19:54]: On 26 Sep 2000, Johan Vromans wrote: [...] By the same reasoning, you can reduce the use of curlies by using indentation to define block structure. What an idea! I wonder why no language has tried this before. I realise you're being

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-27 Thread Tom Christiansen
This is screaming mad. I will become perl6's greatest detractor and anti-campaigner if this nullcrap happens. And I will never shut up about it, either. Mark my words. Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the

Re: Perl6Storm: Intent to RFC #0101

2000-09-27 Thread Tom Christiansen
./sun4-solaris/POSIX.pm:sub isatty { ./sun4-solaris/B/Deparse.pm:sub is_scope { ./sun4-solaris/B/Deparse.pm:sub is_state { ./sun4-solaris/B/Deparse.pm:sub is_miniwhile { # check for one-line loop (`foo() while $y--') ./sun4-solaris/B/Deparse.pm:sub is_scalar { ./sun4-solaris/B/Deparse.pm:sub

Re: perl6storm #0050

2000-09-27 Thread Simon Cozens
On Wed, Sep 27, 2000 at 09:52:57AM +0100, Piers Cawley wrote: You know, I'm trying to see what's annoying about all those parentheses in the lisp function and what do you know, I can't see anything wrong. Okay, so it's not Perl syntax, but it's still clear what's going on. I'd go further

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-27 Thread Simon Cozens
On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote: The concept of Cnull as opposed to Cundef is sometimes difficult for people to understand. "People" in this context being the people who are reading perl6-language and purporting to be able to know what Perl 6 needs. People

Re: perl6storm #0050

2000-09-27 Thread Piers Cawley
Simon Cozens [EMAIL PROTECTED] writes: Readability is a programmer feature, not a language feature. The most important optimization a programmer can make is to optimize for understanding. -- Piers

RE: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-27 Thread David Grove
On Wednesday, September 27, 2000 4:17 AM, Tom Christiansen [SMTP:[EMAIL PROTECTED]] wrote: This is screaming mad. I will become perl6's greatest detractor and anti-campaigner if this nullcrap happens. And I will never shut up about it, either. Mark my words. Quote from Larry: "I have a

Re: RFC 292 (v1) Extensions to the perl debugger

2000-09-27 Thread Johan Vromans
[Quoting Dave Storrs, on September 26 2000, 11:47, in "Re: RFC 292 (v1) Ext"] I'm confused...are you suggesting that the debugger should no longer be integrated into perl? Absolutely not! What I wanted to indicate is that the input and output handling of the debugger, currently line

Re: RFC 320 (v1) Allow grouping of -X file tests and add Cfiletest builtin

2000-09-27 Thread Philip Newton
On Tue, 26 Sep 2000, Nathan Wiger wrote: John Porter wrote: Yeah, not to mention the fact that many modules, notably CGI.pm, are arranged to allow to use unquoted strings of the form -name: print textfield( -name = 'description' ); Well, this one's not an issue, because =

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

2000-09-27 Thread iain truskett
* Philip Newton ([EMAIL PROTECTED]) [27 Sep 2000 22:51]: 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? In my opinion, no, for the reasons given before. Hashes are unordered, and if

Re: Perl6Storm: Intent to RFC #0101

2000-09-27 Thread Tom Christiansen
You suggested: file($file, 'w'); # is it writeable? That's really insane. The goal was to produce code that's legible. That is hardly better. It's much worse than is_writable or writable or whatnot. Just use -w if that's what you want. --tom Visit our website at

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

2000-09-27 Thread Tom Christiansen
grep -l Class::Struct */*.pm Class/Struct.pm File/stat.pm Net/hostent.pm Net/netent.pm Net/protoent.pm Net/servent.pm Time/gmtime.pm Time/localtime.pm Time/tm.pm User/grent.pm User/pwent.pm Please check those out for precedent and practice. Visit our website at http://www.ubswarburg.com This

Re: Perl6Storm: Intent to RFC #0101

2000-09-27 Thread Jerrad Pierce
You suggested: file($file, 'w'); # is it writeable? Not that I'm advocating it but you do something like: test($file, WRITEABLE); test($file, WRITEABLE READABLE); ... where constants are defined for various "attributes" to be tested for... Currently 23, or 3 bytes... (not that

Re: RFC 290 Remove -X

2000-09-27 Thread Tom Christiansen
One doesn't remove useful and intuitive syntax just because Mr Bill never put it into MS-BASIC! I merely passingly suggested that there be a use English style alias for these. They are, however, wholly natural to millions of people, and should not be harrassed. (NB: 10 million Linux weenies

Better Security support (was: RFC 290 (v1) Remove -X)

2000-09-27 Thread Tom Christiansen
The -wd syntax (writeable directory) is nicer than file($file, "wd"). But anyway, there's hardly anything wrong with -w -d. Don't understand the complaint. One thing I would really like to see is better security support. Look at the Camel-III's security chapter, File::Temp, and the is_safe

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

2000-09-27 Thread Tom Christiansen
Don't change "use less" to "use optimize". We don't need to ruin the cuteness. Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate,

RFC 307 (v1) PRAYER - what gets said when you Cbless something

2000-09-27 Thread Tom Christiansen
Goodness, no, don't call it "PRAYER". The blessing is one of corporate approval, not ecclesiastical deprecationem. Please don't piss people off. Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-27 Thread Nathan Wiger
David Grove wrote: On Wednesday, September 27, 2000 4:17 AM, Tom Christiansen wrote: This is screaming mad. I will become perl6's greatest detractor and anti-campaigner if this nullcrap happens. And I will never shut up about it, either. Mark my words. Quote from Larry: "I have

RE: perl6storm #0050

2000-09-27 Thread David Grove
On Wednesday, September 27, 2000 10:21 AM, John Porter [SMTP:[EMAIL PROTECTED]] wrote: Philip Newton wrote: On 26 Sep 2000, Johan Vromans wrote: By the same reasoning, you can reduce the use of curlies by using indentation to define block structure. What an idea! I wonder why no

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

2000-09-27 Thread Simon Cozens
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 weird. -- UNIX was not designed to stop you from doing stupid things, because that would also stop you

Re: RFC 290 (v2) Better english names for -X

2000-09-27 Thread Nathan Wiger
Adam Turoff wrote: PRL -r freadable() PRL -w fwriteable() PRL -x fexecable() PRL -o fowned() PRL -R Freadable() PRL -W Fwriteable() PRL -X Fexecable() PRL -O Fowned() this looks decent to me. I reserve the right to

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

2000-09-27 Thread James Mastros
On Wed, Sep 27, 2000 at 07:36:42AM -, Perl6 RFC Librarian wrote: Tainting should be able to be turned off, as Tom recommends, but only if the user turns on the "absolutely, positively, do NOT turn on taint mode" switch. I can see it now -- Cno taint 'really';. Really, I don't see why we

Re: RFC 292 (v1) Extensions to the perl debugger

2000-09-27 Thread Dave Storrs
On Wed, 27 Sep 2000, Johan Vromans wrote: What I wanted to indicate is that the input and output handling of the debugger, currently line input and line output, should not be turned into a sophisticated user interface with command line recall/editing and fancy output paging (e.g. two

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

2000-09-27 Thread Piers Cawley
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 weird. We obviously need to introduce a synonymous Cuse fewer

Re: RFC 19 (v2) Rename the Clocal operator

2000-09-27 Thread Nathan Wiger
Rename the Clocal operator A list of other proposed replacement names includes (but is not limited to, since I certainly have forgotten some): Cnow Unfortunately, I wish this RFC would have taken a stand on at least a first choice. :-( I always thought that "now" was by far the most

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

2000-09-27 Thread Adam Turoff
On Wed, Sep 27, 2000 at 12:09:20PM -0400, James Mastros wrote: Really, I don't see why we can't just have a 'use taint' and 'no taint' pargma. Because taint mode needs to be turned on REEELY early, like before pragmas are compiled. Z.

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

2000-09-27 Thread Nathan Wiger
Philip Newton wrote: Is order important for @HEADERS? Would it be better to have %HEADERS instead that does such auto-formatting? In my opinion, no, for the reasons given before. Hashes are unordered, and if you want to order the keys, you need to know the possibly keys and in which

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

2000-09-27 Thread John Porter
Piers Cawley wrote: Simon Cozens [EMAIL PROTECTED] writes: "use less 'rolled_loops';" sounds really weird. We obviously need to introduce a synonymous Cuse fewer 'rolled_loops' for when we want to be grammatically correct. Or am I just being silly now? Or have perl enforce the correct

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

2000-09-27 Thread Simon Cozens
On Wed, Sep 27, 2000 at 02:45:24PM -0400, John Porter wrote: But on a tangential note: has anyone proposed letting functions, perhaps by prototype, allow the autoquoting of arguments? I thought about it, but it's hard to know when to stop. use fewer sewers; would be fine, and I'd like

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

2000-09-27 Thread John Porter
Simon Cozens wrote: I thought about it, but it's hard to know when to stop. Yep. If you don't stop, pretty soon you have sh. :-P l((apply foo (mapcar bar (@wibble pragma time: use literal qw( apply mapcar http://www.perl.org/ ); use LWP::Simple; getprint

Re: perl6storm #0050

2000-09-27 Thread John Porter
Piers Cawley wrote: You know, I'm trying to see what's annoying about all those parentheses in the lisp function and what do you know, I can't see anything wrong. Okay, so it's not Perl syntax, but it's still clear what's going on. Yes, but it's hard to read. Lisp requires parens, because

Re: perl6storm #0050

2000-09-27 Thread John Porter
Simon Cozens wrote: Readability is a programmer feature, not a language feature. Right. Parens, and other devices for "readability", are there for the user to use, if she chooses. Perl is not about forcing a certain style. -- John Porter Aus des Weltalls ferne funken Radiosterne.

Re: perl6storm #0050

2000-09-27 Thread Simon Cozens
On Wed, Sep 27, 2000 at 03:35:39PM -0400, John Porter wrote: Yes, but it's hard to read. Lisp requires parens, because it has no precedence rules. (Well, hardly any). It has (almost) no other syntax. This is the situation we would like to avoid in perl. By letting every operator have

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-27 Thread Dan Sugalski
At 10:26 AM 9/27/00 +0100, Simon Cozens wrote: On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote: The concept of Cnull as opposed to Cundef is sometimes difficult for people to understand. "People" in this context being the people who are reading perl6-language and

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

2000-09-27 Thread Dan Sugalski
At 02:20 PM 9/27/00 -0400, Adam Turoff wrote: On Wed, Sep 27, 2000 at 12:09:20PM -0400, James Mastros wrote: Really, I don't see why we can't just have a 'use taint' and 'no taint' pargma. Because taint mode needs to be turned on REEELY early, like before pragmas are compiled. 'no taint'

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

2000-09-27 Thread Nathan Wiger
Sounds good. I'll start on my 39th :-{ RFC right now... ;-) -Nate Adam Turoff wrote: On Wed, Sep 27, 2000 at 11:33:13AM -0700, Nathan Wiger wrote: Ziggy, are you interested in this idea enough (at all?) to stick a note about the 'header' function into the RFC? Or should I RFC it

Re: perl6storm #0050

2000-09-27 Thread John Porter
Simon Cozens wrote: Perl is English-like. And sometimes in English parentheses *are* necessary to increase both meaning and readability, as your own message proves. That's rather disingenuous, since perl does not use parens for the same purpose English does. Parens are necessary in a

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

2000-09-27 Thread Nathan Wiger
Dan Sugalski wrote: Because taint mode needs to be turned on REEELY early, like before pragmas are compiled. 'no taint' does make sense, though 'use taint' might not except to locally undo 'no taint'. Actually, from my talks with Larry both on and off-list about this, he convinced me

Re: perl6storm #0050

2000-09-27 Thread Buddha Buck
At 03:35 PM 9/27/00 -0400, John Porter wrote: Piers Cawley wrote: You know, I'm trying to see what's annoying about all those parentheses in the lisp function and what do you know, I can't see anything wrong. Okay, so it's not Perl syntax, but it's still clear what's going on. Yes, but

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

2000-09-27 Thread Dan Sugalski
At 12:52 PM 9/27/00 -0700, Nathan Wiger wrote: Dan Sugalski wrote: Because taint mode needs to be turned on REEELY early, like before pragmas are compiled. 'no taint' does make sense, though 'use taint' might not except to locally undo 'no taint'. Actually, from my talks with Larry

Re: RFC 262 (v1) Index Attribute

2000-09-27 Thread David L. Nicol
Webmaster wrote: What would really be nice here is an Cindex function, similar to the scalar version, that returns the index of the matching entry in a list. For instance: my $n=0; foreach (@items){ print "Found It at position $n!\n" if /$seek/; $n++; } Could be replaced by:

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

2000-09-27 Thread Robert Mathews
Parse the CGI GET/POST request, returning CGI variables into %CGI (regardless of the source) in an un-HTTP escaped fashion How are you going to handle multiple values for the same parameter? With CGI.pm, you can say @values = $q-param("foo"); Are you going to make the values of %CGI

Re: Perl6Storm: Intent to RFC #0101

2000-09-27 Thread Russ Allbery
Robert Mathews [EMAIL PROTECTED] writes: Nathan Wiger wrote: How many people really "use English" other than beginners? I would use it, but I heard a nasty rumor that it incurs the same penalty as using $' and such. I try to avoid too much line noise in code that has to be maintained. I

Re: Perl6Storm: Intent to RFC #0101

2000-09-27 Thread Robert Mathews
Russ Allbery wrote: I have a very serious problem with use English, namely that it makes Perl code much more difficult to read and maintain for people who know Perl ... and don't know use English. Why can't they learn to use it? Are you saying that nothing is worth knowing unless the

Re: Perl6Storm: Intent to RFC #0101

2000-09-27 Thread Mike Pastore
Russ Allbery wrote: I have a very serious problem with use English, namely that it makes Perl code much more difficult to read and maintain for people who know Perl. Writing something that's marginally easier to understand for a beginner and harder to understand for an expert doesn't strike

Re: Perl6Storm: Intent to RFC #0101

2000-09-27 Thread Russ Allbery
Robert Mathews [EMAIL PROTECTED] writes: ... and don't know use English. Why can't they learn to use it? Why can't the new users of Perl learn the real variable names? I guess I don't buy the argument that the real names are harder to learn. Most of them have fairly useful mnemonics, you see

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

2000-09-27 Thread James Mastros
From: "Dan Sugalski" [EMAIL PROTECTED] To: "Nathan Wiger" [EMAIL PROTECTED] Sent: Wednesday, September 27, 2000 4:08 PM 'no taint' and 'use taint' shouldn't affect whether data is tainted--the rules for that should stay in effect. What they should alter instead is perl's response to tainted

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

2000-09-27 Thread iain truskett
* Nathan Wiger ([EMAIL PROTECTED]) [28 Sep 2000 05:33]: Philip Newton wrote: Is order important for @HEADERS? Would it be better to have %HEADERS instead that does such auto-formatting? In my opinion, no, for the reasons given before. Hashes are unordered, and if you want to order

Expunge use English from Perl? (was Re: Perl6Storm: Intent to RFC #0101)

2000-09-27 Thread Nathan Wiger
Russ Allbery wrote: I've found the use of use English in code I had to maintain to be annoying and unhelpful, and to actually degrade the maintainability of the code [snip] I've yet to understand why I'd *want* to use English regularly; so far as I can tell, it has essentially no benefit in

Re: Expunge use English from Perl? (was Re: Perl6Storm: Intent to RFC #0101)

2000-09-27 Thread Adam Turoff
On Wed, Sep 27, 2000 at 04:39:32PM -0700, Nathan Wiger wrote: My personal feeling is that I'd love "use English" to be expunged from the language altogether - it's unnecessary bloat that only increases the number of mistakes that people can make. But I'm not sure if I have the guts to write

Re: Expunge use English from Perl? (was Re: Perl6Storm: Intent to RFC #0101)

2000-09-27 Thread Robert Mathews
Adam Turoff wrote: On Wed, Sep 27, 2000 at 04:39:32PM -0700, Nathan Wiger wrote: My personal feeling is that I'd love "use English" to be expunged from the language altogether - it's unnecessary bloat that only increases the number of mistakes that people can make. But I'm not sure if

Re: Expunge use English from Perl?

2000-09-27 Thread Nathan Wiger
My personal feeling is that I'd love "use English" to be expunged from the language altogether - it's unnecessary bloat that only increases the number of mistakes that people can make. But I'm not sure if I have the guts to write that RFC just yet. ;-) Are you talking about the

Re: Expunge use English from Perl?

2000-09-27 Thread Adam Turoff
On Wed, Sep 27, 2000 at 05:11:30PM -0700, Nathan Wiger wrote: Yes, but perhaps a little bit of both. Truthfully, I've always seen long alternatives as useless bloat, not used widely over the long term. Once people learn the shortcuts, they use them. Expunging "use English" may will improve

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

2000-09-27 Thread Brad Hughes
The story so far: On September 13 Jarkko professed a desire for "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()." [1] Seeing this as being especially useful for those of us creating

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

2000-09-27 Thread Dan Sugalski
At 07:09 PM 9/27/00 -0400, James Mastros wrote: From: "Dan Sugalski" [EMAIL PROTECTED] To: "Nathan Wiger" [EMAIL PROTECTED] Sent: Wednesday, September 27, 2000 4:08 PM 'no taint' and 'use taint' shouldn't affect whether data is tainted--the rules for that should stay in effect. What they

Re: Expunge use English from Perl?

2000-09-27 Thread Nathan Wiger
Adam Turoff wrote: It has nothing to do with improving the syntax though, because everything in use English is a variable that serves as a reference to some other variable. Yes, and that's why I really think it's a waste of time. ;-) I'm not vehemently opposed to "use English"... But I

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

2000-09-27 Thread Nathan Wiger
Dan Sugalski wrote: It might be nice if the result of a calculation was never tainted when the calculation was in a 'no taint' block. Yerk. No, that's bad. The data is still tainted--the fact that it flowed through a "no taint" block doesn't make it any more trustworthy. Tainting really

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

2000-09-27 Thread Dan Sugalski
At 07:53 PM 9/27/00 -0700, Nathan Wiger wrote: Dan Sugalski wrote: It might be nice if the result of a calculation was never tainted when the calculation was in a 'no taint' block. Yerk. No, that's bad. The data is still tainted--the fact that it flowed through a "no taint" block

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

2000-09-27 Thread Nathan Wiger
Robert Mathews wrote: Parse the CGI GET/POST request, returning CGI variables into %CGI (regardless of the source) in an un-HTTP escaped fashion How are you going to handle multiple values for the same parameter? With CGI.pm, you can say @values = $q-param("foo"); Are you going to

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

2000-09-27 Thread H . Merijn Brand
On 27 Sep 2000 07:36:42 -, Perl6 RFC Librarian [EMAIL PROTECTED] wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE First-Class CGI Support Freezing within two days doesn't leave much space for comments and or objections does it? I'm not