Author: larry
Date: Thu Apr 20 02:07:51 2006
New Revision: 8883
Modified:
doc/trunk/design/syn/S05.pod
Log:
Various clarifications.
Documented that null first alternative is ignored.
Removed colon separator after last modifier, now just use space.
Deleted the :once modifier. (A state variable
> +but rather easier to read. The bare C<*>, C<+> and C quantifiers
> +never backtrack in a C unless some outer rule has specified a
> +C<:panic> option that applies. If you want to prevent even that, use
> +C<*:>, C<+:> or C to prevent any backtracking into the quantifier.
> +If you want to expl
On Wed, Apr 19, 2006 at 07:22:33AM +0200, demerphq wrote:
> On 4/19/06, Andy Lester <[EMAIL PROTECTED]> wrote:
> > > BTW, the patch only shows TODO pass status when no failures occur.
> > >
> > > Oh and obviously all of Test::Harness'es tests pass. :-)
> >
> > This patch doesn't apply against my la
[EMAIL PROTECTED] wrote:
> +=item *
> +
> +Just as C has variants, so does the C declarator.
> +In particular, there are two special variants for use in grammars:
> +C and C.
After a brief discussion on #perl6 with pmichaud and Juerd, it seems
that a verb "parse" at the same space as "sub"/"method
First, let me say I really like the changes to S05. Good work
once again.
Here are my questions and comments.
On Thu, Apr 20, 2006 at 02:07:51AM -0700, [EMAIL PROTECTED] wrote:
> -(To get rule interpolation use an assertion - see below)
> +However, if C<$var> contains a rule object, rather attem
On Thu, Apr 20, 2006 at 09:24:09AM -0500, Patrick R. Michaud wrote:
> First, let me say I really like the changes to S05. Good work
> once again.
>
> Here are my questions and comments.
>
> On Thu, Apr 20, 2006 at 02:07:51AM -0700, [EMAIL PROTECTED] wrote:
> > -(To get rule interpolation use an
On 4/20/06, Steve Peters <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 19, 2006 at 07:22:33AM +0200, demerphq wrote:
> > On 4/19/06, Andy Lester <[EMAIL PROTECTED]> wrote:
> > > > BTW, the patch only shows TODO pass status when no failures occur.
> > > >
> > > > Oh and obviously all of Test::Harness'es
On 19 Apr 2006, at 09:02, Ovid wrote:
[snip]
From a parser standpoint, there's no clean way of distinguishing that
from what the test functions are going to output. As a result, I
really think that "diag" and normal test failure information should be
marked differently (instead of the /^# / tha
Ovid wrote:
> --- Adrian Howard <[EMAIL PROTECTED]> wrote:
>> I've thought in the past about about using /^## / for non-test
>> related diagnostics
>>
>> ## Start the fribble tests
>> ok 1 - fribble foo
>> not ok 2 - fribble bar
>> # Failed test 'fribble bar'
>> # in untitled text 2 at line
On 19 Apr 2006, at 17:12, Andrew Gianni wrote:
[snip]
We'd like to be a bit more programmatic about writing our mech
tests to test
use-case driven test-cases. I'm wondering if there are any tools or
ideas
out there to ease the process so we don't have to manually write the
numerous mech tests
--- Adrian Howard <[EMAIL PROTECTED]> wrote:
> I've thought in the past about about using /^## / for non-test
> related diagnostics
>
> ## Start the fribble tests
> ok 1 - fribble foo
> not ok 2 - fribble bar
> # Failed test 'fribble bar'
> # in untitled text 2 at line 5.
> # got: '
On 20 Apr 2006, at 16:55, Michael Peters wrote:
[snip]
I'm not sure I agree that there is a difference between them. They are
both comments output by the tests. Just because one comes from the
testing routine used by the test and the other from the test itself
doesn't mean they aren't both just
(Oops. Accidentally sent this to Michael directly rather than to the
list.)
--- Michael Peters <[EMAIL PROTECTED]> wrote:
> I'm not sure I agree that there is a difference between them. They
> are
> both comments output by the tests. Just because one comes from the
> testing routine used by the t
On Thu, Apr 20, 2006 at 09:24:09AM -0500, Patrick R. Michaud wrote:
: First, let me say I really like the changes to S05. Good work
: once again.
:
: Here are my questions and comments.
:
: On Thu, Apr 20, 2006 at 02:07:51AM -0700, [EMAIL PROTECTED] wrote:
: > -(To get rule interpolation use an
On Thu, Apr 20, 2006 at 09:19:48AM -0700, Larry Wall wrote:
> : > +Any other value causes the match to fail. In particular, shorter keys
> : > +are not tried if a longer one matches and fails.
> :
> : Is there a way to say to continue with the next shortest key?
>
> Yeah, use <@rules> rather tha
Patrick R. Michaud wrote:
> Two other ideas (from a short walk)... how about something along
> the lines of "phrase" or "sequence"?
Parsec use the word "lexeme" to mean exactly the same thing...
Audrey
signature.asc
Description: OpenPGP digital signature
Author: pmichaud
Date: Thu Apr 20 11:48:29 2006
New Revision: 8886
Modified:
doc/trunk/design/syn/S12.pod
Log:
* Fixed "long dot" constructs to reflect new syntax.
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/tr
Larry wrote:
> : I agree with Audrey that C is probably too useful in other
> : contexts. C works fine for me.
>
> Aesthetically, I hate :w, actually...and the whole point of naming "token"
> is that it is *not* a normal parser rule, but a lexer rule.
>
> But I agree that "parse" is probably the
On Thu, Apr 20, 2006 at 10:36:08PM +0200, demerphq wrote:
> On 4/20/06, Steve Peters <[EMAIL PROTECTED]> wrote:
> > Maybe I'm thinking too hard, or maybe the results reported aren't
> > exactly as clear as they probably should be. Here's an example test and
> > its results as reported by Test::Har
On 4/20/06, Steve Peters <[EMAIL PROTECTED]> wrote:
> Maybe I'm thinking too hard, or maybe the results reported aren't
> exactly as clear as they probably should be. Here's an example test and
> its results as reported by Test::Harness with the TODO changes.
>
> #!perl -w
>
> use strict;
> use Te
Author: larry
Date: Thu Apr 20 17:01:01 2006
New Revision: 8891
Modified:
doc/trunk/design/syn/S05.pod
Log:
As per Damian++'s suggestion, regex is now base form and rule is specialized.
(Note: subrules are still called subrules, not subregexes.)
The .matches method has been unified with multid
[EMAIL PROTECTED] schreef:
> @@ -266,7 +266,7 @@
>
> =item *
>
> -The new C<:rw> modifier causes this rule to "claim" the current
> +The new C<:rw> modifier causes this regex to "claim" the current
> string for modification rather than assuming copy-on-write semantics.
There are about eight use
Author: autrijus
Date: Thu Apr 20 23:49:15 2006
New Revision: 8893
Modified:
doc/trunk/design/syn/S05.pod
Log:
Stylistic cleanup of S05; no functional changes.
* s/TimToady/Larry Wall/
* Consistently change "foo" to C or I to be consistent
with context.
* Fixed the "state $x ||= /.../" ex
23 matches
Mail list logo
