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'
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>> "RA" == Russ Allbery <[EMAIL PROTECTED]> writes:
> RA> This will be completely impossible to implement in some installation
> RA> environments, such as AFS or read-only remote NFS mounts. I really
> RA> don't like software that tries to play dynam
In this message, I go section-by-section of the original Artistic license,
and discuss my interpretation of the intent of the license, and discuss how
the "Artistic License, Version 2.0" attempts to address that spirit. From
here on, I refer to the original Artistic License, used as part of Perl5
> "RA" == Russ Allbery <[EMAIL PROTECTED]> writes:
RA> Michael Maraist <[EMAIL PROTECTED]> writes:
>> I suggested this a while ago, and the response was that automatically
>> writing files is a security risk. You should extend your RFC to
>> describe a caching directory or configuration.
RA
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 y
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 prece
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 tai
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
>
At 07:03 PM 9/27/00 -0700, Randal L. Schwartz wrote:
>So, I'd be happy to make everything an object under three conditions:
>
>1) it doesn't interfere with *optimized* language constructs for
>the most common tasks
If it goes in it won't.
>2) it isn't being put in just to satisfy some theory tha
> > So, I'd be happy to make everything an object under three conditions:
> >
> > 1) it doesn't interfere with *optimized* language constructs for
> > the most common tasks
> >
> > 2) it isn't being put in just to satisfy some theory that making
> > everything an object will make everything easier
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"... B
2000-09-27-22:03:19 Randal L. Schwartz:
> So, I'd be happy to make everything an object under three conditions:
>
> 1) it doesn't interfere with *optimized* language constructs for
> the most common tasks
>
> 2) it isn't being put in just to satisfy some theory that making
> everything an object
> "Michael" == Michael Fowler <[EMAIL PROTECTED]> writes:
Michael> If $str = "foo" and m/foo/ are somehow magical objects,
Michael> that's fine, as long as it doesn't impact my not wanting to
Michael> use them as objects. That'd be some feat, but if you can
Michael> manage it, more power to
2000-09-27-21:53:34 Michael Fowler:
> You can ask "why?" (or "why not?") until you're blue in the face,
> and the question would still be valid. He just doesn't want to,
> nor do I.
We may have a misunderstanding here about what "it" is.
> If $str = "foo" and m/foo/ are somehow magical objects,
On Wed, Sep 27, 2000 at 09:36:43PM -0400, Bennett Todd wrote:
> > I don't want text to become an object. I don't want numbers to become
> > an object. I don't want to create object regular expressions to call
> > a method on text objects to return back a success object to test with
> > the contr
RFC 254 "Class Collections" was presented on 17 Sept proposing a
mechanism to extend classes. To date, only three people have said
anything on the subject:
Schwern said, "The DBI has this very problem!" While agreeing that
the problem exists, Schwern didn't directly endorse or denounce the
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
2000-09-27-17:37:07 Randal L. Schwartz:
> f I want a language where everything is an object, I know
> where to find it.
If the only excuse for tossing this is some kind of gut revulsion
towards objects, I sure hope the RFC doesn't get withdrawn, and the
folks with that revulsion take some tummy m
2000-09-27-15:19:23 Simon Cozens:
> On Wed, Sep 27, 2000 at 03:17:01PM -0400, Bennett Todd wrote:
> > I'd cite ruby as an indication that it shouldn't have to inflict any
> > performance hit
>
> *boggle*. That's classic. Ruby *is* a performance hit.
How so? Seems to run straightforward comparabl
In writing the last commentary, I noted some typos in my proposed Artistic
License.
I have corrected them, and here is 2.0beta2 of the license.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
The Artistic License
Version 2.0beta2, October 2
In this message, I attempt to document how I have addressed all the issues
from Ben's proposed version of the AL. The easiest way to read this
commentary is have my proposed AL (based on 2.0beta2) along with Ben's open
in other windows/buffers. I use section numbers to make the commentary less
v
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 comma
At 02:37 PM 9/27/00 -0700, Randal L. Schwartz wrote:
>Seconded. If I want a language where everything is an object, I know
>where to find it. When I hack Perl, I want things to be optimized for
>those "90% text, 10% something else" problems that Perl so well fills.
>I don't want text to become
> "Simon" == Simon Cozens <[EMAIL PROTECTED]> writes:
Simon> On Wed, Sep 27, 2000 at 12:53:49PM -0700, Matt Youell wrote:
>> > It doesn't feel right to me. It doesn't feel Perlish.
>> That's it?
Simon> That isn't enough? Christ, man, this is Perl we're talking about. If Perl
Simon> isn't Per
On Wed, Sep 27, 2000 at 04:56:37PM -0400, Dan Sugalski wrote:
> My gut feel is that there'll be a "default encoding" for filehandles and we
> *won't* try and get clever.
Yup, that's what the Line Disciplines RFC proposes.
--
Chopping wood won't stop the rage // We need targets on war we wage /
At 04:49 PM 9/27/00 -0400, Andy Dougherty wrote:
>On Wed, 27 Sep 2000, Dan Sugalski wrote:
>
> > Perl will, presumably, know how to go from A to B, and deal with that. If
> > you do something that wants UTF8 and your scalar's got EBCDIC data in it,
> > then perl will do the conversion on the fly.
On Wed, Sep 27, 2000 at 10:34:32AM +0100, Piers Cawley wrote:
> Simon Cozens <[EMAIL PROTECTED]> writes:
> > Which is what I'm working on. You'll all be extremely pleased to know, I'm
> > sure, that I have notes here for another 12 RFCs. After that, I have to start
> > thinking.
>
> Three days to
On Wed, 27 Sep 2000, Dan Sugalski wrote:
> Perl will, presumably, know how to go from A to B, and deal with that. If
> you do something that wants UTF8 and your scalar's got EBCDIC data in it,
> then perl will do the conversion on the fly.
I'm more worried that perl might mistakenly *think* th
At 03:04 PM 9/27/00 -0400, Andy Dougherty wrote:
>On Wed, 27 Sep 2000, Dan Sugalski wrote:
>
> > Well, the impression I get from Larry is that he wants the internals to be
> > character-formatting neutral. Scalars should be able to provide their
> > contents in a number of different formats, but p
At 02:55 PM 9/27/00 -0400, Andy Dougherty wrote:
>On Wed, 27 Sep 2000, Dan Sugalski wrote:
>
> > Well, the impression I get from Larry is that he wants the internals to be
> > character-formatting neutral. Scalars should be able to provide their
> > contents in a number of different formats, but p
At 07:20 PM 9/27/00 +0100, Nicholas Clark wrote:
>On Wed, Sep 27, 2000 at 01:26:18PM -0400, Dan Sugalski wrote:
> > At 11:04 PM 9/26/00 +0100, Simon Cozens wrote:
> > >Well, let's go over here, then. I just submitted an RFC for internal
> string
> > >abstraction, which may or may not be the same
==
> 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 s
==
RFC 72: The regexp engine should go backward as well as
forward. (Peter Heslin)
Peter says (edited):
:If the regexp code is unlikely to be rewritten from the ground up,
then
:there may be little chance of this feature bein
On Wed, Sep 27, 2000 at 12:53:49PM -0700, Matt Youell wrote:
> > It doesn't feel right to me. It doesn't feel Perlish.
> That's it?
That isn't enough? Christ, man, this is Perl we're talking about. If Perl
isn't Perlish, something is wrong.
--
!07/11 PDP a ni deppart m'I !pleH
> 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
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 ri
> On Wed, Sep 27, 2000 at 12:31:25PM -0700, Matt Youell wrote:
> > Would something less esoteric like Javascript be a better comparison?
>
> Not really. Perl and JavaScript have very little in common, despite what
> members of this list would like to do.
>
I wasn't suggesting that Javascr
Simon Cozens wrote:
>
> Not really. Perl and JavaScript have very little in common, despite what
> members of this list would like to do.
One of the big problems with this current discussion is nobody on either
side (RFC included) is providing any specifics as to how this could
potentially work.
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.
--
It took the c
On Wed, Sep 27, 2000 at 12:31:25PM -0700, Matt Youell wrote:
> Would something less esoteric like Javascript be a better comparison?
Not really. Perl and JavaScript have very little in common, despite what
members of this list would like to do.
--
DEC diagnostics would run on a dead whale.
On Wed, Sep 27, 2000 at 03:17:01PM -0400, Bennett Todd wrote:
>> I'd cite ruby as an indication that it shouldn't have to inflict any
>> performance hit
>*boggle*. That's classic. Ruby *is* a performance hit.
Would something less esoteric like Javascript be a better comparison?
Matt
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;
getpri
On Wed, Sep 27, 2000 at 03:07:19PM -0400, Ken Fox wrote:
> Dan was right to think of this as a C enum equivalent. The only real
> differences being that you don't have a chance to define the integer
> mapping and that the printable identity of the symbol is remembered by
> the run-time.
I don't y
On Wed, Sep 27, 2000 at 03:17:01PM -0400, Bennett Todd wrote:
> I'd cite ruby as an indication that it shouldn't have to inflict any
> performance hit
*boggle*. That's classic. Ruby *is* a performance hit.
--
Within a computer, natural language is unnatural.
> 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.
I open to hearing your reasons.
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
Dave Storrs wrote:
> It isn't terribly clear to me either
Well, he does give a couple references that would clear it up.
X11 Atoms are well documented.
> saying is that you can qs() a method name, get a "thingie" out, store the
> thingine in a scalar, and then that scalar becomes a direct portal
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.
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 lik
On Wed, 27 Sep 2000, Dan Sugalski wrote:
> Well, the impression I get from Larry is that he wants the internals to be
> character-formatting neutral. Scalars should be able to provide their
> contents in a number of different formats, but perl would usually not have
> One True Format internall
On Wed, 27 Sep 2000, Dan Sugalski wrote:
> Well, the impression I get from Larry is that he wants the internals to be
> character-formatting neutral. Scalars should be able to provide their
> contents in a number of different formats, but perl would usually not have
> One True Format internall
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 separately?
Adding headers() to the core language (or a similar pragma that is
automagically invo
Piers Cawley wrote:
> Simon Cozens <[EMAIL PROTECTED]> writes:
> > "use less 'rolled_loops';" sounds really weird.
>
> We obviously need to introduce a synonymous
> C for when we want to be grammatically
> correct. Or am I just being silly now?
Or have perl enforce the correct grammar.
% perl -
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
>
On Wed, Sep 27, 2000 at 01:26:18PM -0400, Dan Sugalski wrote:
> At 11:04 PM 9/26/00 +0100, Simon Cozens wrote:
> >Well, let's go over here, then. I just submitted an RFC for internal string
> >abstraction, which may or may not be the same thing as what you were just
> >talking about.
>
> Well, th
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.
I have written a proposed version of the Artistic License, which is
attached.
It appears that there are three camps right now in this Working Group:
(A) Those who want the Artistic License to stay as it is.
(B) Those who want the Artistic License to be clarified to remove legal
confus
> So getpwnam/uid should probably return gecos, not gcos.
Yep. Already fixed in the next version.
Damian
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
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 ou
At 11:04 PM 9/26/00 +0100, Simon Cozens wrote:
>Well, let's go over here, then. I just submitted an RFC for internal string
>abstraction, which may or may not be the same thing as what you were just
>talking about.
Well, the impression I get from Larry is that he wants the internals to be
charac
Damian Conway wrote:
>
>> On the matter of gcos or gecos, and passwd or pw_passwd, and all
>> that noise, please consult the User::pwent manpage.
>> There's no reason for all those noisy bits.
>
> Since the standard function provides those noisy bits, this proposal
> names them.
Not
> On the matter of gcos or gecos, and passwd or pw_passwd, and all
> that noise, please consult the User::pwent manpage.
> There's no reason for all those noisy bits.
Since the standard function provides those noisy bits, this proposal
names them.
> In fact, there had jolly well
> 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 A
> Rename the C operator
> A list of other proposed replacement names includes (but is not
> limited to, since I certainly have forgotten some):
> C
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
descriptive
On Wed, Sep 27, 2000 at 05:29:22AM -, Perl6 RFC Librarian wrote:
> $ok = try $scalar;
> $ok = try @array
> $ok = try %hash;
> $ok = try ⊂
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 simpl
> > 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
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)};
> }
>
> where the $1 in the regex quote is refering to $1
> "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 u
Dave Storrs <[EMAIL PROTECTED]> writes:
> 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 o
> "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 t
On Wed, 27 Sep 2000, Dan Sugalski wrote:
> At 05:37 AM 9/27/00 +, Perl6 RFC Librarian wrote:
> >Perl should adopt scheme-like symbols, both at the language level
> >and at the internals level.
>
> The explanation of this isn't that clear for me. (I have no scheme
> experience at all)
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
C
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 the regex. Is
> > there any reason n
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?
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 in
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 -- C. Really, I don't see why we can't
just have a
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
On Wed, Sep 27, 2000 at 10:30:36AM -0500, David Grove wrote:
> Although I have no interest in saying anything supportive of this idea, I think
> it would be dreadfully funny if Python suddenly lost its primary point of
> advocacy against the Perl language just because we allowed (not required)
From: "Dave Storrs" <[EMAIL PROTECTED]>
> 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 standa
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 f
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
Dave,
> 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
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 r
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 language has tried this before.
It's a question of what the language allows vs. what
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 Lar
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
Tom Christiansen wrote:
>
> You suggested:
>
> file($file, 'w'); # is it writeable?
>
> That's really insane. The goal was to produce code that's legible.
I'd always use -w and would never use anything else. I was just
brainstorming.
And I personally don't understand your sugge
At 08:31 AM 9/27/00 +0100, Simon Cozens wrote:
>On Wed, Sep 27, 2000 at 02:40:27AM -0400, Dan Sugalski wrote:
> > I don't much care how its faked (if it is) as long as it works.
>
>Well, given that line disciplines means we have to write our own IO
>subsystem, can't we fake it ourselves?
If we w
At 08:59 AM 9/27/00 +0100, Tom Hughes wrote:
>In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > I don't much care how its faked (if it is) as long as it
> > works. Might not be as efficient as full kernel support for async
> > I/O, but it'll do. At least there'
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 you
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
> In <[EMAIL PROTECTED]/, Perl6 RFC
> Librarian writes:
> :Given that expansion of regexes could include (+...) and (*...) I
> :have been thinking about providing a general purpose way of adding
> :functionality. Hence I propose that the entire (+...) syntax is
> :kept free from formal specifi
> 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
In <[EMAIL PROTECTED]>, Perl6 RFC Librarian writes:
:Given that expansion of regexes could include (+...) and (*...) I have
:been thinking about providing a general purpose way of adding
:functionality. Hence I propose that the entire (+...) syntax is
:kept free from formal specification for this
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 you want to order the keys, you need to know the possibly keys
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 pa
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 iss
[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 in
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!
For example, /CAN/ && /ANAL/ can't be written
1 - 100 of 133 matches
Mail list logo
