On Thu, Sep 06, 2007 at 08:32:55PM -0400, Joe Gottman wrote:
: Do the results of andthen and orelse really bind to ANY arguments of
: the second block? If the second block has two parameters it makes more
: sense to me for the results to bind to the first parameter and nothing
: to bind to th
Author: larry
Date: Thu Sep 6 20:56:39 2007
New Revision: 14453
Modified:
doc/trunk/design/syn/S03.pod
Log:
fixed it right this time...
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod
Author: larry
Date: Thu Sep 6 20:50:04 2007
New Revision: 14452
Modified:
doc/trunk/design/syn/S03.pod
Log:
extra \ found by sunnavy++
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod
Author: larry
Date: Thu Sep 6 20:36:26 2007
New Revision: 14451
Modified:
doc/trunk/design/syn/S03.pod
Log:
typo spotted by sunnavy++
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod
Author: larry
Date: Thu Sep 6 19:29:21 2007
New Revision: 14450
Modified:
doc/trunk/design/syn/S05.pod
Log:
typo from [particle]++
Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn/S05.pod(o
On 9/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> @@ -1254,6 +1273,17 @@
>
> =item *
>
> +A leading C indicates a positive zero-width assertion, and like C
> +merely reparses the rest of the assertion recursively as if the C
> +were not there. In addition to forcing zero-width, it also su
[EMAIL PROTECTED] wrote:
Author: larry
Date: Thu Sep 6 09:31:16 2007
New Revision: 14447
+
+C<< infix: >>, proceed on success
+
+test1() andthen test2()
+
+Returns the left argument if the left argument indicates failure
+(that is, if the result is undefined). Otherwise it
+evaluates and r
Author: larry
Date: Thu Sep 6 17:12:02 2007
New Revision: 14449
Modified:
doc/trunk/design/syn/S05.pod
Log:
old is now <+foo> to suppress capture
new now is zero-width like
clarifications on backtracking and longest-token semantics
minimal quantifiers are now considered to terminate a long
Larry Wall wrote:
> Jonathan Lang wrote:
> : So 'orelse' is exactly like '//', except that the result of the left
> : side gets passed to the right side as an error message. Is there a
> : reason to make this exception, as opposed to altering '//' to behave
> : exactly like 'orelse' does?
>
> How
On Thu, Sep 06, 2007 at 03:49:42PM -0700, Larry Wall wrote:
: On Thu, Sep 06, 2007 at 04:02:19PM -0500, Patrick R. Michaud wrote:
: : I agree. One thought I had was that perhaps non-greedy matching
: : could also terminate the token prefix.
:
: Well, that's more or less arguing it the other way.
On Thu, Sep 06, 2007 at 04:02:19PM -0500, Patrick R. Michaud wrote:
: I agree. One thought I had was that perhaps non-greedy matching
: could also terminate the token prefix.
Well, that's more or less arguing it the other way. It kind of assumes
your fooba-ish arguments are smart enough to test
On Thu, Sep 06, 2007 at 01:40:20PM -0700, Jonathan Lang wrote:
: So 'orelse' is exactly like '//', except that the result of the left
: side gets passed to the right side as an error message. Is there a
: reason to make this exception, as opposed to altering '//' to behave
: exactly like 'orelse'
On Thu, Sep 06, 2007 at 12:37:37PM -0700, Larry Wall wrote:
> On Thu, Sep 06, 2007 at 01:25:12PM -0500, Patrick R. Michaud wrote:
> : On a somewhat similar question, what happens with a pattern
> : such as
> :
> : "foobar" ~~ / foo.+? | fooba /
> :
> : The LHS initially matches "foob", but wi
So 'orelse' is exactly like '//', except that the result of the left
side gets passed to the right side as an error message. Is there a
reason to make this exception, as opposed to altering '//' to behave
exactly like 'orelse' does?
--
Jonathan "Dataweaver" Lang
On Thu, 2007-09-06 at 12:37 -0700, Larry Wall wrote:
> Yow. ICATBW.
The what now?
-'f
On Thu, Sep 06, 2007 at 01:25:12PM -0500, Patrick R. Michaud wrote:
: > Were we using the procedural conjunction:
: >
: > "foobar" ~~ / <[a..z]>+ && [ ... ] /;
: >
: > I would guess that the LHS matches as much as it can ("foobar"), then
: > the RHS matches "foo" [...and then backtracks the L
On Wed, Sep 05, 2007 at 09:36:24PM -0500, Jonathan Scott Duff wrote:
> How do C<&> and C<&&> differ with respect to backtracking? For instance,
>
> "foobar" ~~ / <[a..z]>+ & [ ... ] /;
>
> Both sides of the C<&> happen in parallel, so I would guess that they
> both match "foo" then stop. Ple
Author: larry
Date: Thu Sep 6 09:51:18 2007
New Revision: 14448
Modified:
doc/trunk/design/syn/S03.pod
Log:
brainos
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ do
Author: larry
Date: Thu Sep 6 09:31:16 2007
New Revision: 14447
Modified:
doc/trunk/design/syn/S03.pod
Log:
Add logic programming primitives with decent binding of intermediate state
The much-despised "err" operator is gone; use "orelse" instead
Modified: doc/trunk/design/syn/S03.pod
==
Jonathan Scott Duff wrote:
> How do C<&> and C<&&> differ with respect to backtracking? For instance,
>
> "foobar" ~~ / <[a..z]>+ & [ ... ] /;
>
> Both sides of the C<&> happen in parallel, so I would guess that they
> both match "foo" then stop. Please correct me if that's wrong.
As written,
How do C<&> and C<&&> differ with respect to backtracking? For instance,
"foobar" ~~ / <[a..z]>+ & [ ... ] /;
Both sides of the C<&> happen in parallel, so I would guess that they
both match "foo" then stop. Please correct me if that's wrong.
Were we using the procedural conjunction:
"
21 matches
Mail list logo
