in particular to add a note about implementation issues
in each case.
Enjoy,
Hugo
---
RFC 72: Variable-length lookbehind: the regexp engine should also go backward.
==
This is an interesting idea. However, it is not obvious to me that
there is any practical difference between the existing
, is that the compiler may not
yet have seen the $ we intend to use:
crypt% perl -wle '$_="foo"; /.*/; $_="bar"; print eval q{$}'
bar
crypt%
.. and I think coredumps may be possible from this. (Hmm, perlbug
upcoming.)
Hugo
In 085601c01cc8$2c94f390$[EMAIL PROTECTED], "mike mulligan" w
rites:
:From: Hugo [EMAIL PROTECTED]
:Sent: Monday, September 11, 2000 11:59 PM
:
:
: mike mulligan replied to Peter Heslin:
: : ... it is greedy in the sense of the forward matching "*" or "
it might be of interest nonetheless.
Hugo
mike mulligan writes:
:From: Hugo [EMAIL PROTECTED]
:Sent: Tuesday, September 12, 2000 2:54 PM
:
: 3. The regexp is matched left to right: first the lookbehind, then 'X',
: then '[yz]'.
:
:Thanks for the insight - I was stuck in my bad assumption that the optimized
:behavior was the only behavior
aning of $ only in such
cases and define it as $$ above in all other cases. I think this
would be more confusing, though.
We could also consider changing the base definition to (?=($/)?\z),
particularly if $/ is to be seen as a regexp.
I think I like $$ the best.
Hugo
shortly to
encourage them to work towards freezing them as soon as practical.
Hugo
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
eason qr{} currently doesn't behave like that is that
when we interpolate a compiled regexp into a context that requires it be
recompiled, we currently ignore the compiled form and act only on the
original string. Perhaps this is also an insufficiently intelligent thing
to do.
Hugo
simple
recursive regexps such as the above without resorting to a costly
eval. When I've tried to come up with an appropriate restriction,
however, I find it very difficult to pick a dividing line.
Hugo
In [EMAIL PROTECTED], Perl6 RFC Librarian writes:
:=head1 ABSTRACT
:
:Remove C?{ code }, C??{ code } and friends.
Whoops, I missed this bit - what 'friends' do you mean?
Hugo
you _want_ to restrict someone
from calling isKeyword($1) within the regexp, which will then read
the keyword patterns from a file and check $1 against those patterns
using regexps? It seems like an entirely reasonable and useful thing
to do.
Hugo
that, so
I'm glad I can save a bit of time. :)
Hugo
enough use that it would help to avoid the full deferred
eval infrastructure, even when it works properly.
:And clearly a non-regex approach could be more legible for
:recursive parsing.
Like any aspect of programming, if you use it regularly it will
become easier to read. And comments are a wonderful thing.
Hugo
r hash keys (RFC 150). I don't think switching to $1 is any
help for those, though.
Hugo
ck the top of perlre to be sure. I think
we've appreciated for some time that it was a mistake to name them
as if they were opposites, but if anything I'd like to reduce the
need for them rather than to increase it.
Hugo
last value set. Please can you make sure this is clearly
explained in the next version of the RFC?
Hugo
completely,
you need to address the utility and options for migration for all
the available uses of it, not just the one addressed by the new
handling of (?{...}).
Hugo
uncommonly liberating to me.
:You may have to completely rewrite your script. So much for code reuse.
I don't believe that it need be so painful to take advantage of it
in existing code. We can ease that by providing a selection of
helpful ready-rolled routines for common tasks.
Hugo
|no). This is rather harder to
emulate with other mechanisms without running to eval. OTTOMH it is
equivalent to (??{ defined($1) ? 'yes' : 'no' }).
Hugo
19 matches
Mail list logo
