Motivation for /<alpha>+/ set Array not Match?
Audrey Tang
If a subrule appears two (or more) times in any branch of a lexical
scope (i.e. twice within the same subpattern and alternation), or if the
subrule is quantified anywhere within a given scope, then its
corresponding hash entry is always assigned an array of
C<Match> objects rather than a single C<Match> object.
However, fglock and I both find the "quantified" clause very surprising.
Intuitively:
/<foo> bar bar <foo>/
should set $<foo> to an Array with two Match elements. However:
/<foo>+/
should set $<foo> to a single Match, with multiple positional Match
elements, each
one representing one match in the quantified match. Moreover:
/<foo> bar bar <foo>+/
should set $<foo> to an Array with two Match elements, the first being a
simple match, and the second has multiple positional submatches.
The thinking behind the separate treatment is that in a contiguous
quantified
match, it does make sense to ask the .from and .to for the entire
range, which
is very hard to do if it's an Array (which can have 0 elements,
rendering $<foo>[-1].to
dangerous). Also stringification for $<foo> on a /<foo>+/ match
should perhaps
not be space-separated, i.e. it should follow Match semantics not
Array semantics.
To recap: Is it possible to amend the quantified clause to have it
produce Match
objects, and reserve Array only for noncontiguous same-named subrules?
Thanks,
Audrey
Patrick R. Michaud
> Moreover:
>
> /<foo> bar bar <foo>+/
>
> should set $<foo> to an Array with two Match elements, the first being a
> simple match, and the second has multiple positional submatches.
>
> The thinking behind the separate treatment is that in a contiguous
> quantified
> match, it does make sense to ask the .from and .to for the entire
> range, which
> is very hard to do if it's an Array (which can have 0 elements,
> rendering $<foo>[-1].to
> dangerous).
Out of curiosity, why not:
/<foo> bar bar $<xyz>:=(<foo>+)/
and then one can easily look at $<xyz>.from and $<xyz>.to, as well
as get to the arrayed elements? (There are other possibilities as
well.)
I'm not arguing in favor of or against the proposal, just pointing
out that there are ways in the existing scheme to get at what is
wanted.
Pm
Flavio S. Glock
>
> Out of curiosity, why not:
>
> /<foo> bar bar $<xyz>:=(<foo>+)/
>
> and then one can easily look at $<xyz>.from and $<xyz>.to, as well
> as get to the arrayed elements? (There are other possibilities as
> well.)
>
> I'm not arguing in favor of or against the proposal, just pointing
> out that there are ways in the existing scheme to get at what is
> wanted.
This aliasing would still work:
/<foo> bar bar $<xyz>:=(<foo>+)/
$<foo>[0] - match
$<xyz>[] - array of match
$<xyz>[0] - match
~$<xyz> - stringified capture
I've been using aliasing a few times, and mostly exactly in this situation,
so I thought it would be nice to have a way to express this idea with
fewer words:
/<foo> bar bar <foo>+/
$<foo>[0] - match
$<foo>[1;*] - array of match
$<foo>[1;0] - match
~$<foo>[1] - stringified capture
OTOH, you lose ' @all_foo = $<foo> ', but maybe ' @all_foo = $<foo>[]
' could be overloaded to the old behaviour.
Anyway, it's just a thought.
thanks!
- Flavio S. Glock
Audrey Tang
在 Sep 22, 2006 10:36 PM 時，Patrick R. Michaud 寫到：
> Out of curiosity, why not:
>
> /<foo> bar bar $<xyz>:=(<foo>+)/
>
> and then one can easily look at $<xyz>.from and $<xyz>.to, as well
> as get to the arrayed elements? (There are other possibilities as
> well.)
>
> I'm not arguing in favor of or against the proposal, just pointing
> out that there are ways in the existing scheme to get at what is
> wanted.
Indeed... Though what I'm wondering is, is there a hidden implementation
cost or design cost of making /<foo>+/ always behave such that
$<foo>.from
returns something, compared to the current treatment with the workaround
you suggested?
Thanks,
Audrey
cma...@gmail.com
> Indeed... Though what I'm wondering is, is there a hidden implementation
> cost or design cost of making /<foo>+/ always behave such that
> $<foo>.from
> returns something, compared to the current treatment with the workaround
> you suggested?
Has this been settled or addressed off-list? Because from my
perspective as one who has never used P6 rules for anything in
particular, but who in the future most likely will, the proposed
semantics seems a lot saner and more useful. It'd be sad to let pass
this opportunity to fix (what from my perspective appears to be) a
shortcoming of the rule semantics.
Kindly,
--
masak
Audrey Tang
在 Sep 28, 2006 3:03 AM 時，Carl Mäsak 寫到：
> Audrey (>):
>> Indeed... Though what I'm wondering is, is there a hidden
>> implementation
>> cost or design cost of making /<foo>+/ always behave such that
>> $<foo>.from
>> returns something, compared to the current treatment with the
>> workaround
>> you suggested?
>
> Has this been settled or addressed off-list?
'fraid not yet...
> Because from my perspective as one who has never used P6 rules for
> anything
> in particular, but who in the future most likely will, the proposed
> semantics seems a lot saner and more useful. It'd be sad to let pass
> this opportunity to fix (what from my perspective appears to be) a
> shortcoming of the rule semantics.
*nod* The lack of .from/.to is merely an annoyance, but the spaced-out
stringification is really, really surprising with /<foo>+/.
Thanks,
Audrey
cma...@gmail.com
> > Has this been settled or addressed off-list?
>
> 'fraid not yet...
Ah. So Warnock applies.
(Side note: when I first read "Warnock applies" on things in p6
summaries a year or so ago, I thought it was some really energetic
programmer who went around and applied patches as soon as people posed
a question. Turned out that wasn't the case...)
<http://en.wikipedia.org/wiki/Warnock%27s_Dilemma>
> > Because from my perspective as one who has never used P6 rules for
> > anything
> > in particular, but who in the future most likely will, the proposed
> > semantics seems a lot saner and more useful. It'd be sad to let pass
> > this opportunity to fix (what from my perspective appears to be) a
> > shortcoming of the rule semantics.
>
> *nod* The lack of .from/.to is merely an annoyance, but the spaced-out
> stringification is really, really surprising with /<foo>+/.
Do you have a short snippet to illustrate this?
--
masak