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
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
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
Jonathan Worthington wrote:
"Juerd" <[EMAIL PROTECTED]> wrote:
You both use "iff". What does that mean?
I believe it's to be read "if and only if".
Yes, but that doesn't explain what it means. Rather than me try to
explain it (poorly)...
http://en.wikipedia.org/wiki/If_and_only_if
David
What's really odd is that document links to
http://en.wikipedia.org/wiki/Exclusive_disjunction which ends up
stating that chained xors are associative and commutative, meaning
that instead of acting as one(), it counts parity.
Rob
On 5/9/05, David Landgren <[EMAIL PROTECTED]> wrote:
> Jonathan Wo
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
> =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
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
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 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 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 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 10:51:53PM +1000, Damian Conway wrote:
> Autrijus wrote:
>
> >/me eagerly awaits new revelation from Damian...
>
> Be careful what you wish for. Here's draft zero. ;-)
...and here is my status report of the Zero-Day exploit, err,
implementation, in Pugs. :-)
Note that th
> "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
Nothing makes you re-think your reply length like having your mailer
lose your message ;-)
A lot of your message revolves around this idea that there's a "normal
file open" semantic. What I've tried (but clearly failed) to articulate
previously is that this notion is becoming archaic in what is sh
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
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 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
$ vars. Not sure what that w
> "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>
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".
> Unle
> "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 Monday 09 May 2005 19:36, Autrijus Tang wrote:
> On Mon, May 09, 2005 at 10:51:53PM +1000, Damian Conway wrote:
> > Autrijus wrote:
> > >/me eagerly awaits new revelation from Damian...
> >
> > Be careful what you wish for. Here's draft zero. ;-)
>
> ...and here is my status report of the Zero-D
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
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
28 matches
Mail list logo
