On Tue, May 17, 2005 at 03:02:12PM -0400, Mark Reed wrote:
>
>
>
> On 2005-05-17 14:14, "Peter Haworth" <[EMAIL PROTECTED]> wrote:\
> >
> > Does numbering of captures after an alternation continue as if the
> > alternative with the most captures matched?
> >
> > # $1$1 $2$3, eve
On 2005-05-17 14:14, "Peter Haworth" <[EMAIL PROTECTED]> wrote:\
>
> Does numbering of captures after an alternation continue as if the
> alternative with the most captures matched?
>
> # $1$1 $2$3, even if (a) matched
> rx/ [ (a) | (b) (c) ] (d) /;
I thought that was still l
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
Autrijus wrote:
/me eagerly awaits new revelation from Damian...
Be careful what you wish for. Here's draft zero. ;-)
Note that there may still be bugs in the examples, or even in the design.
@Larry has thrashed this through pretty carefully, and Patrick has implemented
it for PGE, but it's 10.30
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 (let) ( (\w+) \:= (\S+) )"
51 matches
Mail list logo
