I think the proposal that Joe McMahon and I are finishing up now will
make these obsolete anyway.
On Mon, Sep 25, 2000 at 08:56:47PM +, Mark-Jason Dominus wrote:
I think the proposal that Joe McMahon and I are finishing up now will
make these obsolete anyway.
Good! The less I have to maintain the better...
Sorry, I meant that it would make (??...) and (?{...}) obsolete
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 should
be treated as subroutine calls. Unfortunately, this requires a
(?Q$foo) Quotes the contents of the scalar $foo - equivalent to
(??{ quotemeta $foo }).
How is this different from
\Q$foo\E
?
Simply put, I want variable-length lookbehind.
Why didn't you simply propose that the (?...) operator be fixed to
support variable-length expressions? Why so much additional machinery?
in any case, i think we have a fair agreement on rfc 158 and i will
freeze it if there is no further comments on it.
I think you should remove the parts of your propsal about making $ be
autolocalized.
If you're not planning to revise your RFC, let me know so that I can
ask the
: it looks worse and dumps core.
That's because the first non-paren forces it to recurse into the
second branch until you hit REG_INFTY or overflow the stack. Swap
second and third branches and you have a better chance:
I think something else goes wrong there too.
$re = qr{...}
(I
:Anyway, Snobol has a nice heuristic to prevent infinite recursion in
:cases like this, but I'm not sure it's applicable to the way the Perl
:regex engine works. I will think about it.
It is probably worth adding the heuristic above: anytime you recurse
into the same re at the same
2. Many people - including Larry - have voiced their desire
to see =~ die a horrible death
Please provide a look-up-able reference to Larry's saying that he
wanted to =~ to die horrible death.
Larry said:
# Well, the fact is, I've been thinking about possible ways to get rid
#
...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 to
(mystery: how
can filling in $ be a lot slower than filling in $1?)
It isn't. It's the same. $1 might even be more expensive than $.
It appears that many people don't understand the problem with $. I
will try to explain.
Maintaining the information required by $1 or $ slows down the
/ to get what you wanted. This
is almost identical to what Richard proposed anyway.
It is really not clear to me that this problem needs to be solved any
better than it is already.
I suggest that this section be removed from the RFC.
Mark-Jason Dominus
On Mon, 28 Aug 2000, Mark-Jason Dominus wrote:
But there is no convenient way to run the loop once for each date and
split the dates into pieces:
# WRONG
while (($mo, $dy, $yr) = ($string =~ /(\d\d)-(\d\d)-(\d\d)/g)) {
...
}
What I use
On Tue, 29 Aug 2000 08:47:25 -0400, Mark-Jason Dominus wrote:
m/.../Count,Insensitive (instead of m/.../ti)
That would escape the problem that we are running out of letters and
also the problem that the current letters are hard to remember.
Yes, but wouldn't this give us
raised by all three existing RFCs, should investigate several
solutions in parallel, and should compare them with one another and
contrast the benefits and drawbacks of each one.
Mark-Jason Dominus [EMAIL PROTECTED]
I am boycotting Amazon. See http
Please correct me if I'm mistaken, but I believe that that's the way
they are implemented now. A regex match populates the -startp and
-endp parts of the regex structure, and the elements of these items
are byte offsets into the original string.
I haven't looked at it at all, and
16 matches
Mail list logo
