David L. Nicol wrote:
>
> A bareword inside doublequotes is not interpreted, in Perl or C.
No; a "bareword" in quotes (any kind) is not a bareword.
--
John Porter
> More direct syntax for hashes
>
> Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
> Date: 5 Sep 2000
> Mailing List: [EMAIL PROTECTED]
> Version: 1
> Number: 196
Nat, I was thinking of writing an RFC on a related issue...
but it could piggy-back on this one (196) if you like the id
> "TH" == Tom Hughes <[EMAIL PROTECTED]> writes:
TH> I wasn't just talking about the threaded case though - the point
TH> which I was making was that of what happens if a single threaded
TH> program alters a hash in the middle of iterating it.
TH> Currently keys and values are flattened when
> "UG" == Uri Guttman <[EMAIL PROTECTED]> writes:
UG> i don't see how you can do atomic ops easily. assuming interpreter
UG> threads as the model, an interpreter could run in the middle of another
UG> and corrupt it. most perl ops do too much work for any easy way to make
UG> them atomic with
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> Multithreaded programming is hard and for a given program the only
JH> person truly knowing how to keep the data consistent and threads not
JH> strangling each other is the programmer. Perl shouldn't try to be too
JH> helpful and ge
> what if i do $i++ and overflow into the float (or bigint) domain? that
> is enough work that you would need to have a lock around the ++. so then
> all ++ would have implied locks and their baggage. i say no atomic ops
> in perl.
>From RFC 178
[Atomic] operations typically lock their opera
> DS> Some things we can guarantee to be atomic.
> This is going to be tricky. A list of atomic guarentees by perl will be
> needed.
>From RFC 178
...we have to decide which operations are [atomic]. As a starting
point, we can take all the operators documented in C and
all the functions docume
> "Jarkko" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>> "You want Icon, you know where to find it..." :)
Jarkko> Hey, it's one of the few languages we haven't yet stolen a
Jarkko> neat feature or few from... (I don't really count the few
Jarkko> regex thingies as full-fledged stealin
> >In fact, I shall extend RFC 128 to allow subroutine parameter to specify
> >that they are non-autovivifying.
>
> I'm not sure why it matters to the subroutine. We've already got
> the hack so that
>
> fn( $a[$i] )
> or
> fn( $h{$k} )
>
> will onl
On Wed, Sep 06, 2000 at 03:47:57PM -0700, Randal L. Schwartz wrote:
> > "Mark-Jason" == Mark-Jason Dominus <[EMAIL PROTECTED]> writes:
>
> Mark-Jason> I have some ideas about how to do this, and I will try to
> Mark-Jason> write up an RFC this week.
>
> "You want Icon, you know where to find
> Are you satisfied with this? I think this is a good compromise, and
> still powerful :-)
Me satisfied? Well, kind of. I see the need, I just disagree with
the proposed interface and extent. I will not comment on the subject
much more because I sense that soon we'll be hip deep in database
> > "Mark-Jason" == Mark-Jason Dominus <[EMAIL PROTECTED]> writes:
>
> Mark-Jason> I have some ideas about how to do this, and I will try to
> Mark-Jason> write up an RFC this week.
>
> "You want Icon, you know where to find it..." :)
That's exactly my motivation. It seems to me that tryi
>I agree entirely.
>In fact, I shall extend RFC 128 to allow subroutine parameter to specify
>that they are non-autovivifying.
I'm not sure why it matters to the subroutine. We've already got the hack
so that
fn( $a[$i] )
or
fn( $h{$k} )
will only autoviv those puppies if you muddle
> >That seems reasonable--except that I don't believe exists() merits
> >any special treatment.
>
> More specifically, I think all non-lvalue context use of -> should be
> non-autoviv, whether exists or anything else.
I agree entirely.
In fact, I shall extend RFC 128 to allow
> > And how about:
> >
> > int length = 256 ;
> >
> > and, if that's legal, what does:
> >
> > print "I wonder what this is : " . length ;
> >
> > do?
> I imagine the first order of business for the C JIT team would be
> some conversion operators. Numeric types stringify int
>That seems reasonable--except that I don't believe exists() merits
>any special treatment.
More specifically, I think all non-lvalue context use of -> should be
non-autoviv, whether exists or anything else.
--tom
>That's not required. All that is necessary is for C nodes
>in the op tree to propagate a special non-autovivifying context to
>subordinate nodes.
That seems reasonable--except that I don't believe exists() merits
any special treatment.
--tom
> Why can't we just apply the same warnings on hashes as we do on
> variables in Perl? Maybe a new lexical pragma:
>
> no autoviv; # any autovivification carps (not just
> # hashes)
>
> no autoviv 'HASH'; # no
In message <[EMAIL PROTECTED]>
Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> Why not
> lock(%y);
> foreach my $x (keys %y) {
> $y{$x+1} = 1;
> }
> unlock(%y);
>
> Hmm, I just realized, perhaps we can just punt. Any p5 program that
> doesn't use Threads
> > print keys %hash, "\n";
> > exists $hash{key}{subkey};
> > print keys %hash, "\n";
>
> >Or did that get fixed when I wasn't looking?
>
> No, the -> operator has not been changed to do lazy evaluation.
That's not required. All that is necessary is for C nodes
in the o
> "Mark-Jason" == Mark-Jason Dominus <[EMAIL PROTECTED]> writes:
Mark-Jason> I have some ideas about how to do this, and I will try to
Mark-Jason> write up an RFC this week.
"You want Icon, you know where to find it..." :)
But yes, a way that allows programmatic backtracking sort of "inside
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL>%DataHash = unpack $mypic, $SomePackedCobolData;
Does it unpack it into the hash? Or does it keep a pointer into
the original structure?
What happens when a new key is added to the hash?
What happens if the underlying struc
/--- On Wed, Sep 06, 2000 at 05:16:03PM -0500, Jarkko Hietaniemi
wrote:
| Okay, I have read it now. Now I'm going to make suggestions :-)
| (Note
| that so far I've been commenting only on the aspects of making
| things
| 'thread-safe', not on the RFC itself. 'Threadsafing' Perl i
> @passed = grep { 2 > $_ and last } (1, 2, 3, 2, 1);
>
> I believe that unless used with a label, if someone were to use
> last within a grep or map block, then further processing for that
> element of the list which grep is working on would be skipped, and
> it would continue
Just to note that RFC 76 (Builtin: reduce) also proposes this
mechanism as a means of short-circuiting C.
Damian
> Please read the RFC and AFTER you can make suggestions. These _all_
> are mentioned in the rfc!
Okay, I have read it now. Now I'm going to make suggestions :-) (Note
that so far I've been commenting only on the aspects of making things
'thread-safe', not on the RFC itself. 'Threadsafing' P
/--- On Wed, Sep 06, 2000 at 11:23:37AM -0400, Dan Sugalski wrote:
| >Here's some high-level emulation of what it should do.
| >
| > eval {
| > my($_a, $_b, $c) = ($a, $b, $c);
| > ...
| > ($a, $b, $c) = ($_a, $_b, $_c);
| > }
|
| Nop
"Myers, Dirk" wrote:
> I still find this whole idea confusing, though. Just out of curiosity,
> though, would:
>
> #include a way for users to bail out gracefully
>
> be a syntax error?
It is clear to us that that is a comment and not a preprocessor directive.
The #include preprocesso
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Short-circuiting C and C with C
=head1 VERSION
Maintainer: Garrett Goebel <[EMAIL PROTECTED]>
Date: 6 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 199
Status: Developing
=head1 A
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Boolean Regexes
=head1 VERSION
Maintainer: Richard Proctor <[EMAIL PROTECTED]>
Date: 6 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 198
Status
From: Bart Lateur [mailto:[EMAIL PROTECTED]]
>
> On Wed, 06 Sep 2000 13:04:51 -0500, David L. Nicol wrote:
>
> > grep { $a > $_ and last } @b)
>
> So "last" should return true, or what?
The last operator doesn't return anything does it? It immediately exits the
loop/block in question.
@p
Nathan Wiger wrote:
>
> "David L. Nicol" wrote:
> >
> > s/x/5/; # this is still going to replace
> > # all the eckses in $_ with fives.
>
> Why? This is an arbitrary decision if you've declared variables to be
> barewords.
Misstating my position, when I take one, is and
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> Multithreaded programming is hard and for a given program the only
JH> person truly knowing how to keep the data consistent and threads not
JH> strangling each other is the programmer. Perl shouldn't try to be too
JH> helpfu
> "CF" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Well, there'll be safe access to individual variables when perl needs to
DS> access them, but that's about it.
DS> Some things we can guarantee to be atomic. The auto increme
At 01:52 PM 9/6/00 -0600, Tom Christiansen wrote:
> >Has anyone read RFC #11,112,006,825,558,016?
>
>It's rather difficult to keep up with them all, or read them all
>retroactively when you miss a few days. It's also hard to grep
>them (HTML is the root of all evil).
No HTML here:
$ telnet dev.
> But for a single 'statement', it may be possible to gather all the
> objects needing a lock and then grabbing them in order (say by address).
I still don't buy that. In Perl even simple assignments and
increments are not atomic which means that even 'single statements'
would require locking an
> "TH" == Tom Hughes <[EMAIL PROTECTED]> writes:
TH> I guess we can translate all uses of keys and values when doing
TH> the p52p6 conversion - so that this:
TH> foreach my $x (keys %y)
TH> {
TH> $y{$x+1} = 1;
TH> }
TH> becomes:
TH> foreach my $x (@temp = keys %y)
TH> {
TH>
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Well, there'll be safe access to individual variables when perl needs to
DS> access them, but that's about it.
DS> Some things we can guarantee to be atomic. The auto increment/decrement
DS> operators can be reasonably guaranteed atomi
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> The snag with attempting to automate such things is illustrated by :
NI> thread Athread B
NI> $a = $a + $b++; $b = $b + $a++;
NI> So we need to 'lock' both $a and $b both side
Today around 1:52pm, Tom Christiansen hammered out this masterpiece:
: >Has anyone read RFC #11,112,006,825,558,016?
:
: It's rather difficult to keep up with them all, or read them all
: retroactively when you miss a few days. It's also hard to grep
: them (HTML is the root of all evil). Is t
On Tue, 05 Sep 2000 19:08:18 -0600, Tom Christiansen wrote:
>> exists (sometimes causes autovivification, which affects C)
>
>That's not technically accurate--exists never causes autovivification.
print exists $hash{foo}{bar}{baz};
use Data::Dumper;
print Dumper \
Gregory S Hayes wrote:
>
> but it would look much nicer in the framework of this version of open(),
> perhaps something like ...
>
> ($readme, $writeme) = open doublehandle "/path/program -args";
> print $writeme "here's your input\n";
> $output = $readme;
> $writeme->close;
> $readme->close;
>
Damian Conway <[EMAIL PROTECTED]> writes:
>> Does any other RFC give the equivalent to an 'in' operator?
>
> and my forthcoming superpositions RFC will offer:
>
> if ($a == any(@b) ) { ... }
> and:
> if ($a eq any(@b) ) { ... }
> and:
> if ($a != any(@b) ) { ... }
> and:
>
> > s/x/5/; # this is still going to replace
> > # all the eckses in $_ with fives.
> Why? This is an arbitrary decision if you've declared variables to
be
> barewords.
I think it's a sane decision -- IMHO barewords shouldn't be allowed to
>Will this incarnation of open() be able to deal
>with bi directional process communication?
The straightforward way to do that is quite simply:
open(FH, "|foocmd thisfoo thatfoo|")
or for shell avoidance:
open(FH, "|-|", "foocmd", "thisfoo", "thatfoo"))
--tom
On Wed, 06 Sep 2000 13:04:51 -0500, David L. Nicol wrote:
> grep { $a > $_ and last } @b)
So "last" should return true, or what?
You do need a true value for grep() to claim success.
--
Bart.
>Tom Christiansen wrote:
>>
>> The straightforward way to do that is quite simply:
>>
>> open(FH, "|foocmd thisfoo thatfoo|")
>>
>> or for shell avoidance:
>>
>> open(FH, "|-|", "foocmd", "thisfoo", "thatfoo"))
>Does this work now
Not quite. Nearly, though.
>Or are you just su
Tom Christiansen wrote:
>
> The straightforward way to do that is quite simply:
>
> open(FH, "|foocmd thisfoo thatfoo|")
>
> or for shell avoidance:
>
> open(FH, "|-|", "foocmd", "thisfoo", "thatfoo"))
Does this work now Or are you just suggesting this be added to Perl
6?
Quoth
>On Tue, 05 Sep 2000 19:08:18 -0600, Tom Christiansen wrote:
>>> exists (sometimes causes autovivification, which affects C)
>>
>>That's not technically accurate--exists never causes autovivification.
> print exists $hash{foo}{bar}{baz};
> use Data::Dumper;
> print Dumpe
>On Tue, 05 Sep 2000 18:37:11 -0600, Tom Christiansen wrote:
>>Those are not the semantics of print. It returns true (1) if successf
>>false (undef) otherwise. You cannot change that. If I write print "0", it
>>bloody well shan't be returning false.
>Oh, why not? Does anybody actually *ever*
On Tue, 05 Sep 2000 18:37:11 -0600, Tom Christiansen wrote:
>Those are not the semantics of print. It returns true (1) if successful, and
>false (undef) otherwise. You cannot change that. If I write print "0", it
>bloody well shan't be returning false.
Oh, why not? Does anybody actually *eve
> Has anyone read RFC 14?
>
>$FILE = open "@doc = <$FILE>;
>
>$WEB = open http "http://www.yahoo.com";
>@html = <$WEB>;
>
> The next version (hopefully out this week) will clarify this syntax
> further.
>
> -Nate
This is a much friendlier looking approach to things. I also app
>Has anyone read RFC #11,112,006,825,558,016?
It's rather difficult to keep up with them all, or read them all
retroactively when you miss a few days. It's also hard to grep
them (HTML is the root of all evil). Is there an rsync server that
will dole out the pods for us as needed?
--tom
I've been tossing an idea around in my head, and I've not yet decided if
this is the most brilliant idea I've ever come up with:), or perhaps the
lamest. I'm sure it would be cool, but that doesn't mean it should be
pursued. I'm going to throw this one out in the open, and if it's not
shot full
> Feel free to hijack and/or infiltrate my RFC.
You Will Be Assimilated.
Damian
2000-08-28-18:47:06 Tom Christiansen:
> It strikes me as a bit reminiscent of (one reason) why Larry
> didn't make a+b work on strings, since then while with numbers,
> a+b and b+a would be the same, with strings they would not be, and
> we have these rather deeply held convictions about such matt
On Thu, Sep 07, 2000 at 06:28:25AM +1100, Damian Conway wrote:
> I should have an RFC out on this by next week.
Feel free to hijack and/or infiltrate my RFC.
> Damian
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'.
I should have an RFC out on this by next week.
Damian
> >...My point is that I think we're approaching this
> >the wrong way. We're trying to apply more and more parser power into what
> >classically has been the lexer / tokenizer, namely our beloved
> >regular-expression engine.
I've been thinking the same thing. It seems to me that the attempts
Jonathan Scott Duff wrote:
>
> On Wed, Sep 06, 2000 at 08:40:37AM -0700, Nathan Wiger wrote:
> > What if we added special XML/HTML-parsing ?< and ?> operators?
>
> What if we just provided deep enough hooks into the RE engine that
> specialized parsing constructs like these could easily be added
On Wed, Sep 06, 2000 at 12:14:17AM -0400, Bradley M. Kuhn wrote:
> Dan Sugalski wrote:
> > The decisions should be based on technical merit and general availability.
>
> I would include "available under a free software license" as part of the
> definition of "general availability".
Bradley, yo
> Does any other RFC give the equivalent to an 'in' operator?
RFC 22 offers:
switch ($a) {
case (@b) { ... }
}
and my forthcoming superpositions RFC will offer:
if ($a == any(@b) ) { ... }
and:
if ($a eq any(@b) ) { ... }
and:
if ($a
Buddha Buck wrote:
>
> > my filehandle fh; fh->new(">>/tmp/appendablelog");
>
> Ugh... How about...
>
> my filehandle fh;
> fh->open(">>/tmp/appendablelog");
Has anyone read RFC 14?
$FILE = open ";
$WEB = open http "http://www.yahoo.com";
@html = <$WEB>;
The next version (
- Original Message -
From: "Richard Proctor" <[EMAIL PROTECTED]>
Sent: Tuesday, September 05, 2000 1:49 PM
Subject: Re: RFC 145 (alternate approach)
> On Tue 05 Sep, David Corbin wrote:
> > Nathan Wiger wrote:
> > > But, how about a new ?m operator?
> > >/(?m<<|[).*?(?M>>|])/;
> The
"David L. Nicol" wrote:
>
> s/x/5/; # this is still going to replace
> # all the eckses in $_ with fives.
Why? This is an arbitrary decision if you've declared variables to be
barewords.
Anyways, I'm done harping on this issue. I think a single, simple syntax
is good. Yo
Nathan Wiger wrote:
> Intermingling it freely:
>
>my Dog $spot;
>int x;
>my int $y;
>#include
>char * name;
>#do some regexp matching
>s/x/5/;/* match the C value of x defined above */
>
> Is really confusing, even for us humans. :-)
>
> -Nate
Is it confusing?
Buddha Buck wrote:
> What advantage does this give
None whatsoever. I should have selected a less contentious
example that file handles to demonstrate my opinion that
tagged barewords should be allowed to do anything, not in exclusion
of, but in addition to, the syntactically tagged scalar
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Retire chop().
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: 5 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 195
Status: Developing
=head1 ABSTRACT
Remov
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Numberic Value Ranges In Regular Expressions
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 5 september 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 197
Status: Deve
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
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 196
=head1 ABSTRACT
C should re
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Standardise Function Pre- and Post-Handling
=head1 VERSION
Maintainer: Jarkko Hietaniemi
Date: 05 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 194
Status: Developing
=head1 ABSTR
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Thread Programming Model
=head1 VERSION
Maintainer: Steven McDougall <[EMAIL PROTECTED]>
Date: 31 Aug 2000
Last Modified: 05 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 185
St
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Allow multiple loop variables in foreach statements
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Last Modified: 6 Sep 2000
Mailing List: [EMAIL PROT
> sub callfritz{
> local STDIN < $InputData;
> local STDOUT > PREVIOUSLY_OPENED_HANDLE;
> eval `cat fritz.pl`;
> };
Unclear what you really mean there with the eval. But why not
simply allow
open(local *STDIN, "< $InputData");
open(local *STDOUT,
"Bryan C. Warnock" wrote:
>
> It's hitting a moving target :-(
I continue to explain myself until my mistakes become clear, that's
why I'm often wrong.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
This Is The Last Major Revision
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 5 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 141
Status: Frozen
=head1 ABSTRACT
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Merge C<$!>, C<$^E>, C<$@> and C<$?>
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 25 Aug 2000
Last-modified: 5 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
lvalue subs: parameters, explicit assignment, and wantarray() changes
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: Aug 16, 2000
Last Modified: Sep 6, 2000
Mailing List: [EM
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
structures and interface definitions
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last Modified: 5 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 75
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Shell Style Redirection
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last Modified: 5 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 66
Status: Deve
> I don't know exactly how this message got marked "unread" again,
> No, here it is, the server at Sun has decided to send it again,
No it didn't. :-) Those are cascading headers (read the "by" field),
Sun's internal mail system has 3-4 hops and 2 firewalls to go through.
Received:
from
>I am working on an RFC
>to allow boolean logic ( && and || and !) to apply a number of patterns to
>the same substring to allow easier mining of information out of such
>constructs.
What, you don't like: :-)
$pattern = $conjunction eq "AND"
? join('' => map { "(?=.*$_)" }
Garrett Goebel wrote:
> grep { ref($a) eq ref($b) } @b) # Same type?
> grep { $a == $_ } @b)
> grep { $a eq $_ } @b)
> grep { $a > $_ } @b)
>
> Garrett
grep doesn't short-circuit; you can't return or exit or last out
of the thing.
Maybe we could add support for C to C
On Wed 06 Sep, David Corbin wrote:
> Nathan Wiger wrote:
> >
> > > It would be useful (and increasingly more common) to be able to match
> > > qr|<\s*(\w+)([^>]*)>| to qr|<\s*/\1\s*>|, and handle the case where
> > > those can nest as well. Something like
> > >
> > > match this with
> > >
At 12:50 PM 9/6/00 -0500, David L. Nicol wrote:
>I see barewords as being whatever the programmer wants them to be,
>as long as he makes it clear what he expects the word to be before using
>it.
>
>So, C becomes a legacy constructor and the perl6 version of it would
>be something like
>
>
>
>I see barewords as being whatever the programmer wants them to be,
>as long as he makes it clear what he expects the word to be before using
>it.
I've been known to use:
sub opt(*); # imal quoting! :-)
So I could say if opt(a) sans quoting. But that
breaks for the pseudofuncs like m or s.
>...My point is that I think we're approaching this
>the wrong way. We're trying to apply more and more parser power into what
>classically has been the lexer / tokenizer, namely our beloved
>regular-expression engine.
>A great deal of string processing is possible with perls enhanced NFA
>engin
John Porter wrote:
>
> David L. Nicol wrote:
> >
> >
> > How about ALLOWING bareword everything-else? Start having
> > filehandles work the way everyone expects them to at first,
> > passing as arguments and so forth, without any special treatment?
>
> How about barewords are always interpreted
David Corbin wrote:
>
> m:(?['' => '').*(?]):
>
> or more generically
>
> m:(?['<\w+>' => '').*(?]):
I think these are good; but I do also like the idea of "automatic
reversing" by default, since that's a common operation.
Let's combine the ideas, as Richard suggests. How about:
1. When a
- Original Message -
From: "Jonathan Scott Duff" <[EMAIL PROTECTED]>
Subject: Re: XML/HTML-specific ?< and ?> operators? (was Re: RFC 145
(alternate approach))
> On Wed, Sep 06, 2000 at 08:40:37AM -0700, Nathan Wiger wrote:
> > What if we added special XML/HTML-parsing ?< and ?> operato
I don't know exactly how this message got marked "unread" again,
No, here it is, the server at Sun has decided to send it again,
which is all right, since I don't think I responded before going
home last friday.
Received:
from mercury.Sun.COM (mercur
On Tue 05 Sep, Nathan Wiger wrote:
>"normal" "reversed"
>-- ---
>103301
>99aa99
>(( ))
><+ +>
>{{[!<_ _>!]}}
>{__A1( )A1__}
>
> That is, when a bracket is encountered, the
On Wed, Sep 06, 2000 at 08:40:37AM -0700, Nathan Wiger wrote:
> What if we added special XML/HTML-parsing ?< and ?> operators?
What if we just provided deep enough hooks into the RE engine that
specialized parsing constructs like these could easily be added by
those who need them?
-Scott
--
Jon
Ed Mills wrote:
> The fact that something can be accomplished in Perl doesn't necessarily mean
> its the best or most desirable way to do it. I respect the programming
> abilities, but
>
>grep { ref($a) eq ref($b) } @b)
>
> is far less intuitive than the proposal.
...and is an example of
On Wed, Sep 06, 2000 at 09:46:13AM -0600, Tom Christiansen wrote:
> > grep { $_ == 1 } 1..1_000_000
>
> >grep doesn't short-circuit.
>
> I never did figure out why "last" {w,sh,c}ouldn't be made to do
> that very thing.
Agreed, that would be very natural.
--
$jhi++; # http://www.iki.fi/jh
Nathan Wiger wrote:
>
> > It would be useful (and increasingly more common) to be able to match
> > qr|<\s*(\w+)([^>]*)>| to qr|<\s*/\1\s*>|, and handle the case where those
> > can nest as well. Something like
> >
> > match this with
> >
> > not this but
> >this.
>
> I suspec
Tom Christiansen <[EMAIL PROTECTED]> writes:
> >IMHO Perl should add a plethora of higher-order functions for arrays and
> >hashes, and from the chatter here I think a lot of people agree.
>
> Make some modules, release them, and see how much they're used. Then
> one can contemplate sucking
> It would be useful (and increasingly more common) to be able to match
> qr|<\s*(\w+)([^>]*)>| to qr|<\s*/\1\s*>|, and handle the case where those
> can nest as well. Something like
>
> match this with
>
> not this but
>this.
I suspect this is going to need a ?[ and ?] of its
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>> I don't think we can do this immediately. Can you come up with the right
>> API and/or hooks that are needed so that it might be retrofited?
JH> I think language magic helping to do the user level data locking is
JH> a dead-in-the-wa
>IMHO Perl should add a plethora of higher-order functions for arrays and
>hashes, and from the chatter here I think a lot of people agree.
Make some modules, release them, and see how much they're used. Then
one can contemplate sucking them into the core based upon the success
of those modul
1 - 100 of 123 matches
Mail list logo
