Re: S05 question
On Wed, Dec 08, 2004 at 08:24:20PM -0800, Ashley Winters wrote:
: I'm still going to prefer using :=, simply as a good programming
: practice. My mind sees a big difference between building a parse-tree
: object and just grepping for some word I want in a string. Within a
: rule{} block, there is no place except the rule object to keep your
: data (hypothetically -- haha), so it makes sense to have everything
: capture unless otherwise specified. There's no such limitation in a
: regular code block, so I don't see the need.
Since regex results are lexically scoped in Perl 6, in a regular
code block we can do static analysis and determine whether there's
any possibility that $ is referenced at all, and optimize it
away in many cases, if it turns out to be high overhead. But as Patrick
points out, so far capture seems pretty cheap.
Larry
Re: S05 question
On Wed, Dec 08, 2004 at 08:24:20PM -0800, Ashley Winters wrote: > > I was working on the (possibly misguided) assumption that there's a > cost to capturing, and that perhaps agressive capturing isn't worth > having "on" in a one-liner. Some deep part of my mind remembers $` > being bad, I think. If there's no consequence to having capture being > on, then ignoring it is fine. I don't have a problem with that. As I > said before, reads fine to me. At least in the current implementation of PGE there's not a big cost to capturing of any sort. Each capture is held as a pair of (start,end) offsets into the target string, so there's no string copying or other overhead until the captured item is actually referred to. It's even easy to determine $` as being the start of the string up to the beginning offset of the $0 capture. (Yes, the perl 5 docs indicate there's a cost to $` that's incurred for all regexps in a program once $` is used, but I don't think that will translate over to PGE.) That might change, of course, especially as we add the ability to modify the target string in the middle of the match. But even then we may be able to keep the offset pairs as a useful optimization. At the moment the bigger cost is calling the subrule itself -- and even here it's basically the equivalent of a method or subroutine call (actually, coroutine calls), since a called rule maintains its own match state just like any other match. Pm
Re: S05 question
On Thu, Dec 09, 2004 at 10:52:54AM +, Matthew Walton wrote: > Of course, it then begs the question about > > > > if we're thinking of parallels with qw//-like constructs, which I > certainly am. I'm not quite sure what that would do, as it collides > slightly with the existing rule match syntax (which I quite like), and > thus it may already have a meaning. This already has a meaning, it calls the "word" assertion with the (rule) expression /ws $foo ws number/ as an argument. At least it's that way unless/until Larry changes (changed?) it. Pm
Re: S05 question
Larry Wall wrote:
I'm still thinking about what «...» might mean, if anything. Bonus points
for interpolative and/or word-splitty.
I'm perhaps not being entirely serious, but if you want something
word-splitty and interpolative, how about this (which may cause unwanted
physiological side effects, I disclaim all responsibility)
«word ws word ws number»
which would mean
but with less typing, depending on how many keystrokes it takes to
produce « and » on your keyboard, and how much you put in it.
As far as interpolation goes, it would have to treat
«word ws $foo ws number»
As
<$foo>
assuming, that is, that <$foo> would take the value of $foo and use it
as the name of the rule to match against, rather than taking the
contents of $foo and using it as the rule. Or perhaps that's the better
way round, if $foo is a regexp/rule object thingy (not quite sure how
they work for us in Perl 6, can I say my $foo = rule { \d+ }; and expect
something sane?). Perhaps it treats it as a name if it contains a string
and a rule if it contains a rule.
Of course, it then begs the question about
if we're thinking of parallels with qw//-like constructs, which I
certainly am. I'm not quite sure what that would do, as it collides
slightly with the existing rule match syntax (which I quite like), and
thus it may already have a meaning.
Perhaps I've gone completely barmy; I throw it open for your decision,
good p6lers.
