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)
:
# $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) e) f) /
In Perl5, $1 is abcdef, $2 is bcde, and $3 is cd
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 object when used as an array.
What's changed in the Perl6 design, AIUI, is nested captures. Given this:
rx/ (a (b (c d) e) f) /
In Perl5, $1 is abcdef, $2
Uri Guttman wrote:
DC Sure. Just as $42 is a shorthand for $/[42], so too $whatever is a
DC shorthand for $/whatever.
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
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
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] match up
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 $whatever is a
DC shorthand for $/whatever.
but then what about the different index bases for $42 and $/[42]? i
don't think that has been resolved
DC == Damian Conway [EMAIL PROTECTED] writes:
DC Uri Guttman wrote:
DC Sure. Just as $42 is a shorthand for $/[42], so too $whatever is a
DC shorthand for $/whatever.
but then what about the different index bases for $42 and $/[42]? i
don't think that has been resolved (nor has
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 $MATCH or some
such.
It's already the case that
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 $
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 $
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 =:= $/[0] so
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
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
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
:= (, etc.
More likely
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, $1
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 $MATCH or some
such.
Why can't bare $/ just
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.
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 $MATCH or some
such.
According to the new capture semantics document posted earlier this week:
A successful match returns a CMatch object whose ...
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-1
Damian Conway wrote:
print @array[1st..($n)th];
Sounds cool, but what about $n = 0; ?
- Fagzal
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
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
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 Cth
(and
Cst, Cnd, Crd) was a subtract one operator, you could write:
my $n = prompt How many elems? ;
print
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
$digit
Patrick R. Michaud wrote:
On Mon, May 09, 2005 at 09:14:02AM -0700, Larry Wall wrote:
: m/ alt: tea (don't) (ray) (me) (for) (solar tea), (d'oh!)
: | alt: BEM (every) (green) (BEM) (devours) (faces)
: /;
This seems like a rather ugly syntax for what is essentially a label,
or a
DC rule mv { $lastcmd:=(mv) $files:=[ ident ]+
$dir:=ident }
DC rule cp { $lastcmd:=(cp) $files:=[ ident ]+
$dir:=ident }
DC sub lastcmd { return $lastcmd }
DC }
DC while shift ~~ m/Shell::Commands.cmd/ {
DC say From: @{$files};
DC
Damian Conway writes:
Just as $42 is a shorthand for $/[42], so too $whatever is a
shorthand for $/whatever.
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.
--
On 5/10/05, Aaron Crane [EMAIL PROTECTED] wrote:
Damian Conway writes:
Just as $42 is a shorthand for $/[42], so too $whatever is a
shorthand for $/whatever.
Isn't $42 a shorthand for $/[41] ?
I think that having 1-based digit-variables but 0-based array indexes on
$/ is really
DC == Damian Conway [EMAIL PROTECTED] writes:
DC rule mv { $lastcmd:=(mv) $files:=[ ident ]+ $dir:=ident }
DC rule cp { $lastcmd:=(cp) $files:=[ ident ]+ $dir:=ident }
DC sub lastcmd { return $lastcmd }
DC }
DC while shift ~~ m/Shell::Commands.cmd/ {
DC say From: @{$files};
DC
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
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 (let) ( (\w+) \:= (\S
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
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
into the outer array...
for @{$pairs} = $key, $val {
say Key: $key;
say Val: $val;
}
}
In other words, an array alias is useful to flatten into a single array
any nested captures that might occur within a repeated subpattern or subrule.
Whereas a scalar
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
=item *
Quantifiers (except C? and C??) cause a matched subrule or subpattern to
return an array of CMatch 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
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 CMatch objects, instead of just a single object.
What is the effect of the quantifiers C**{0,1} and C**{0,1}? ? Will they
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 CMatch objects, instead of just a single object.
:
: What is the effect of the quantifiers C**{0,1} and C**{0,1}? ?
That
On Mon, May 09, 2005 at 10:33:33AM -0500, Patrick R. Michaud wrote:
: =head2 Subpattern numbering
: [...]
: Of course, the leading Cundefs that Perl 5 would produce do convey
: (albeit awkwardly) which alternative actually matched. If that
: information is important, Perl 6 has several far
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 CMatch objects, instead of just a single object.
On Mon, May 09, 2005 at 09:14:02AM -0700, Larry Wall wrote:
: m/ alt: tea (don't) (ray) (me) (for) (solar tea), (d'oh!)
: | alt: BEM (every) (green) (BEM) (devours) (faces)
: /;
This seems like a rather ugly syntax for what is essentially a label,
or a null rule. I
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
PRM $1[$j].2 and
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 and
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] , and
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 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
$digit vars. Not sure what
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 Maybe that's a
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.
--
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.
Unless :p5
DC == Damian Conway [EMAIL PROTECTED] writes:
DC grammar Shell::Commands {
DC my $lastcmd;
DC rule cmd { $/:=mv | $/:=cp }
DC rule mv { $lastcmd:=(mv) $files:=[ ident ]+
$dir:=ident }
DC rule cp { $lastcmd:=(cp) $files:=[ ident ]+
51 matches
Mail list logo
