subpattern that appears in the rule; it
represents the capture made by the first subpattern of whichever
alternative actually matched.
Although last I heard, Larry had agreed to make the first captured paren
be $0 rather than $1 so that it could correspond to the indexing of the
match obje
] (d) /;
I thought that was still like Perl5:
> # $1$2 $3$4
> rx/ [ (a) | (b) (c) ] (d) /;
The *numbering* is based on the regex; the *values* are based on the actual
match.
What's changed in the Perl6 design, AIUI, is nested captures. Given this:
> rx/ (a (b (c d
On Mon, 09 May 2005 22:51:53 +1000, Damian Conway wrote:
> # Perl 6...
># $1 $2$3 $4$5 $6
> $tune_up6 = rx/ (don't) (ray) (me) (for) (solar tea), (d'oh!)
># $1 $2 $3$4$5
>| (every) (
> That's a very interesting generalization. There are plenty of *other*
cases
where one wants an ordinal, or some other kind of $n-1 value. If C
(and
C, C, C) was a "subtract one" operator, you could write:
my $n = prompt "How many elems? ";
print @array[1st.
Autrijus Tang wrote:
On Thu, May 12, 2005 at 12:37:06AM +0200, Fagyal Csongor wrote:
Damian Conway wrote:
print @array[1st..($n)th];
Sounds cool, but what about $n = 0; ?
Then it would be 0..-1, an empty range.
Yep, but I mean in general isn't it confusing that the 0th elem
On Thu, May 12, 2005 at 12:37:06AM +0200, Fagyal Csongor wrote:
> Damian Conway wrote:
>
> >print @array[1st..($n)th];
>
> Sounds cool, but what about $n = 0; ?
Then it would be 0..-1, an empty range.
/Autrijus/
pgpW4KeLIp7hR.pgp
Description: PGP signature
Damian Conway wrote:
print @array[1st..($n)th];
Sounds cool, but what about $n = 0; ?
- Fagzal
Larry mused:
I'm wondering if it's just a cardinal/ordinal thing, and we can just
translate $7 to $<7th>. Then we don't have to guess where to insert
a .flat or :flat.
That's a very interesting generalization. There are plenty of *other* cases
where one wants an ordinal, or some other kind of $n-
Larry decreed:
Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens.
Huzzah!
Our old $0 (P5's $&) could be $<> instead, short for $ or some
such.
According to the new capture semantics document posted earlier this week:
A successful match returns a C object whose ...
string
On Wed, May 11, 2005 at 06:35:36PM +0200, Juerd wrote:
: Larry Wall skribis 2005-05-11 8:30 (-0700):
: > It's already the case that p5-to-p6 is going to have a *wonderful*
: > time translating $7 to $1[2][0]...
:
: If I remember correctly, ** recursively flattens, and so (**$/)[7-1]
: should work
> On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote:
> : But that's only the opinion of one(@Larry), not of $Larry.
>
> Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens.
> Our old $0 (P5's $&) could be $<> instead, short for $ or some
> such.
Why can't bare $/ jus
On Wed, May 11, 2005 at 12:01:35PM -0500, Patrick R. Michaud wrote:
> Of course, this now begs the question -- where are things stored
> after doing ... ?
>
> rx :perl5 / (don't) (ray) (me) (for solar) /
>
> My guess is that within the rule they're $1, $2, $3, etc. as before,
Within the rule
On Wed, May 11, 2005 at 06:37:53PM +0200, Juerd wrote:
> Larry Wall skribis 2005-05-11 8:30 (-0700):
> > It's already the case that p5-to-p6 is going to have a *wonderful*
> > time translating $7 to $1[2][0]...
>
> Or maybe it just has to change "(" to "$1 := (", the second "(" to "$2
> := (", et
Larry Wall skribis 2005-05-11 8:30 (-0700):
> It's already the case that p5-to-p6 is going to have a *wonderful*
> time translating $7 to $1[2][0]...
Or maybe it just has to change "(" to "$1 := (", the second "(" to "$2
:= (", etc.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://co
Larry Wall skribis 2005-05-11 8:30 (-0700):
> It's already the case that p5-to-p6 is going to have a *wonderful*
> time translating $7 to $1[2][0]...
If I remember correctly, ** recursively flattens, and so (**$/)[7-1]
should work.
And otherwise a simple method can probably do the trick. I sugg
On Thu, May 12, 2005 at 12:06:57AM +0800, Autrijus Tang wrote:
> On Wed, May 11, 2005 at 08:30:42AM -0700, Larry Wall wrote:
> > On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote:
> > : But that's only the opinion of one(@Larry), not of $Larry.
> >
> > Let's go 0-based and make $0 =:=
H,
On Wed, May 11, 2005 at 08:30:42AM -0700, Larry Wall wrote:
On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote:
: But that's only the opinion of one(@Larry), not of $Larry.
Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens.
Our old $0 (P5's $&) could be $<> inst
On Wed, May 11, 2005 at 08:30:42AM -0700, Larry Wall wrote:
> On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote:
> : But that's only the opinion of one(@Larry), not of $Larry.
>
> Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens.
> Our old $0 (P5's $&) could be $<>
On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote:
: But that's only the opinion of one(@Larry), not of $Larry.
Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens.
Our old $0 (P5's $&) could be $<> instead, short for $ or some
such.
It's already the case that p5-to-
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Uri Guttman wrote:
DC> Sure. Just as $42 is a shorthand for $/[42], so too $ is a
DC> shorthand for $/.
>> but then what about the different index bases for $42 and $/[42]? i
>> don't think that has been resolved (nor has mixing
On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote:
> Uri Guttman wrote:
>
> > DC> Sure. Just as $42 is a shorthand for $/[42], so too $ is a
> > DC> shorthand for $/.
> >
> >but then what about the different index bases for $42 and $/[42]? i
> >don't think that has been resolved (nor
> > But it does raise an important point: the discrepancy between $42 and $/[41]
> > *is* a great opportunity for off-by-on errors. Previously, however, @Larry
> > have tossed back and forth the possibility of using $0 as the first capture
> > variable so that the indices of $/[0], $/[1], $/[2] mat
On Wed, 2005-05-11 at 17:48 +1000, Damian Conway wrote:
> But it does raise an important point: the discrepancy between $42 and $/[41]
> *is* a great opportunity for off-by-on errors. Previously, however, @Larry
> have tossed back and forth the possibility of using $0 as the first capture
> var
Damian Conway wrote:
I think this error--unintentional, I swear!--argues strongly that
internal consistency within Perl 6 is more important than historical
consistency with Perl 5's $1, $2, $3...
But that's only the opinion of one(@Larry), not of $Larry.
My opinion as none(@Larry), too. And corr
Uri Guttman wrote:
DC> Sure. Just as $42 is a shorthand for $/[42], so too $ is a
DC> shorthand for $/.
but then what about the different index bases for $42 and $/[42]? i
don't think that has been resolved (nor has mixing the $1.1 and $1[1]
syntaxes).
Bear in mind that that reply was posted i
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> rule mv { $lastcmd:=(mv) $:=[ ]+ $:= }
DC> rule cp { $lastcmd:=(cp) $:=[ ]+ $:= }
DC> sub lastcmd { return $lastcmd }
DC> }
DC> while shift ~~ m// {
DC> say "From: @{$}";
DC> say " To: $";
DC> }
>> since files and
On 5/10/05, Aaron Crane <[EMAIL PROTECTED]> wrote:
> Damian Conway writes:
> > Just as $42 is a shorthand for $/[42], so too $ is a
> > shorthand for $/.
>
> Isn't $42 a shorthand for $/[41] ?
>
> I think that having 1-based digit-variables but 0-based array indexes on
> $/ is really confusing; m
Damian Conway writes:
> Just as $42 is a shorthand for $/[42], so too $ is a
> shorthand for $/.
Isn't $42 a shorthand for $/[41] ?
I think that having 1-based digit-variables but 0-based array indexes on
$/ is really confusing; mistakes of this sort seem to confirm my view.
--
Aaron Crane
DC> rule mv { $lastcmd:=(mv) $:=[ ]+
$:= }
DC> rule cp { $lastcmd:=(cp) $:=[ ]+
$:= }
DC> sub lastcmd { return $lastcmd }
DC> }
DC> while shift ~~ m// {
DC> say "From: @{$}";
DC> say " To: $";
DC> }
since files and
Patrick R. Michaud wrote:
On Mon, May 09, 2005 at 09:14:02AM -0700, Larry Wall wrote:
: m/ (don't) (ray) (me) (for) (solar tea), (d'oh!)
: | (every) (green) (BEM) (devours) (faces)
: /;
This seems like a rather ugly syntax for what is essentially a label,
or a rule. I wonder
Larry Wall wrote:
On Mon, May 09, 2005 at 12:14:35PM -0700, Larry Wall wrote:
: On Mon, May 09, 2005 at 02:08:31PM -0500, Patrick R. Michaud wrote:
: : Hmmm, then would $x.$j.2 then be equivalent to $x[$j-1][1] ?
:
: Ouch.
Maybe that's a good reason to switch from 1-based to 0-based
$ vars. No
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> grammar Shell::Commands {
DC> my $lastcmd;
DC> rule cmd { $/:= | $/:= }
DC> rule mv { $lastcmd:=(mv) $:=[ ]+
$:= }
DC> rule cp { $lastcmd:=(cp) $:=[ ]+
$:= }
DC> s
On Mon, May 09, 2005 at 08:43:39PM +, [EMAIL PROTECTED] wrote:
> Can I say $*1, $*2, etc, to get perl5 flattened peren counting captures?
> We need something like that to make perl5->perl6 translation easier;
> otherwise we'd have to parse perl5 RE instead of just slapping on a ":p5".
> Unle
Can I say $*1, $*2, etc, to get perl5 flattened peren counting captures? We
need something like that to make perl5->perl6 translation easier; otherwise
we'd have to parse perl5 RE instead of just slapping on a ":p5". Unless ":p5"
also means that you get a single already fattened match objct.
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> On Mon, May 09, 2005 at 12:14:35PM -0700, Larry Wall wrote:
LW> : On Mon, May 09, 2005 at 02:08:31PM -0500, Patrick R. Michaud wrote:
LW> : : Hmmm, then would $x.$j.2 then be equivalent to $x[$j-1][1] ?
LW> :
LW> : Ouch.
LW>
On Mon, May 09, 2005 at 12:14:35PM -0700, Larry Wall wrote:
: On Mon, May 09, 2005 at 02:08:31PM -0500, Patrick R. Michaud wrote:
: : Hmmm, then would $x.$j.2 then be equivalent to $x[$j-1][1] ?
:
: Ouch.
Maybe that's a good reason to switch from 1-based to 0-based
$ vars. Not sure what that w
On Mon, May 09, 2005 at 02:08:31PM -0500, Patrick R. Michaud wrote:
: Hmmm, then would $x.$j.2 then be equivalent to $x[$j-1][1] ?
Ouch.
Larry
On Mon, May 09, 2005 at 11:34:10AM -0700, Larry Wall wrote:
> On Mon, May 09, 2005 at 10:33:33AM -0500, Patrick R. Michaud wrote:
> : After thinking on this a bit, I'm hoping we don't do this -- at least not
> : initially. I'm not sure there's a lot of advantage of C< $1.1 > over
> : C< $1[0] >,
On Mon, May 09, 2005 at 10:33:33AM -0500, Patrick R. Michaud wrote:
: After thinking on this a bit, I'm hoping we don't do this -- at least not
: initially. I'm not sure there's a lot of advantage of C< $1.1 > over
: C< $1[0] >, and one starts to wonder about things like $1.$j.2 and
: $1[$j].2 a
> "PRM" == Patrick R Michaud <[EMAIL PROTECTED]> writes:
PRM> After thinking on this a bit, I'm hoping we don't do this -- at least not
PRM> initially. I'm not sure there's a lot of advantage of C< $1.1 > over
PRM> C< $1[0] >, and one starts to wonder about things like $1.$j.2 and
P
On Mon, May 09, 2005 at 09:14:02AM -0700, Larry Wall wrote:
> : m/ (don't) (ray) (me) (for) (solar tea), (d'oh!)
> : | (every) (green) (BEM) (devours) (faces)
> : /;
>
> This seems like a rather ugly syntax for what is essentially a label,
> or a rule. I wonder if we can com
On Mon, May 09, 2005 at 11:02:58AM -0500, Patrick R. Michaud wrote:
> On Mon, May 09, 2005 at 09:47:14AM -0600, Paul Seamons wrote:
> > > =item *
> > >
> > > Quantifiers (except C and C) cause a matched subrule or subpattern
> > > to
> > > return an array of C objects, instead of just a single obj
On Mon, May 09, 2005 at 10:33:33AM -0500, Patrick R. Michaud wrote:
: > =head2 Subpattern numbering
: > [...]
: > Of course, the leading Cs that Perl 5 would produce do convey
: > (albeit awkwardly) which alternative actually matched. If that
: > information is important, Perl 6 has several far cle
On Mon, May 09, 2005 at 09:47:14AM -0600, Paul Seamons wrote:
: > =item *
: >
: > Quantifiers (except C and C) cause a matched subrule or subpattern to
: > return an array of C objects, instead of just a single object.
:
: What is the effect of the quantifiers C<**{0,1}> and C<**{0,1}?> ?
That wo
On Mon, May 09, 2005 at 09:47:14AM -0600, Paul Seamons wrote:
> > =item *
> >
> > Quantifiers (except C and C) cause a matched subrule or subpattern to
> > return an array of C objects, instead of just a single object.
>
> What is the effect of the quantifiers C<**{0,1}> and C<**{0,1}?> ? Will th
> =item *
>
> Quantifiers (except C and C) cause a matched subrule or subpattern to
> return an array of C objects, instead of just a single object.
What is the effect of the quantifiers C<**{0,1}> and C<**{0,1}?> ? Will they
behave like ? and ?? and return a single object - or will they cause t
Here's some more commentary to draft zero of the capturing semantics
(thanks, Damian!), based partially on PGE's current implementation.
On Mon, May 09, 2005 at 10:51:53PM +1000, Damian Conway wrote:
> [...]
> =head2 Nested subpattern captures
> [...]
> There may also be shortcuts for accessing ne
unding subpattern. This is quite
different to Perl 5 semantics:
# Perl 5...
#
# $1- $5- $6
# | $2-- $3--- | | | | $7-- $8-- |
# | | | | $4-- | | | | | | | | | |
# | | | | | | | | | | |
On Mon, May 09, 2005 at 12:15:30PM +0100, Carl Franks wrote:
> Are you subscribed to perl6-compiler?
Yes, of course I am. :-)
> Yesterday Patrick Michaud posted "PGE features update (corrections)"
> which describes the results you've got:
Ahh. I must've missed it. Thanks for the pointer.
/me
I will be releasing a full description of the new capturing semantics in the
next day or two. It will be appended to the appropriate Synopsis, but I'll
also post it here. It may be as soon as tomorrow, but I'm away teaching this
week, so my time is restricted.
Damian
Are you subscribed to perl6-compiler?
Yesterday Patrick Michaud posted "PGE features update (corrections)"
which describes the results you've got:
* Match objects for nested captures are nested into the surrounding
capture object. Thus, given
rulesub = p6rule(":w (
As Pugs now has Rule support via PGE (either with external parrot or a
faster, linked libparrot), I've been playing with the new capturing
semantics.
Currently, matching "123" against /(.(.(.)))/ produces this:
$0: 123
$1: 123
$1[0]: 23
$1[0][0]: 3
Instead of the Perl 5 behaviou
52 matches
Mail list logo
