r31964 -[S05] saner defaults for :c and :p; without a previous match, $/.to blows up

2010-08-12 Thread pugs-commits
Author: moritz
Date: 2010-08-12 10:02:42 +0200 (Thu, 12 Aug 2010)
New Revision: 31964

Modified:
   docs/Perl6/Spec/S05-regex.pod
Log:
[S05] saner defaults for :c and :p; without a previous match, $/.to blows up

Modified: docs/Perl6/Spec/S05-regex.pod
===
--- docs/Perl6/Spec/S05-regex.pod   2010-08-12 06:47:06 UTC (rev 31963)
+++ docs/Perl6/Spec/S05-regex.pod   2010-08-12 08:02:42 UTC (rev 31964)
@@ -278,7 +278,7 @@
 =item *
 
 The C:c (or C:continue) modifier causes the pattern to continue
-scanning from the specified position (defaulting to C$/.to):
+scanning from the specified position (defaulting to C($/ ?? $/.to !! 0)):
 
  m:c($p)/ pattern / # start scanning at position $p
 
@@ -296,7 +296,7 @@
 
  m:pos($p)/ pattern /  # match at position $p
 
-If the argument is omitted, it defaults to C$/.to.  (Unlike in
+If the argument is omitted, it defaults to C($/ ?? $/.to !! 0).  (Unlike in
 Perl 5, the string itself has no clue where its last match ended.)
 All subrule matches are implicitly passed their starting position.
 Likewise, the pattern you supply to a Perl macro's Cis parsed



Re: Buf.pm: FIFO and grammar

2010-08-12 Thread Carl Mäsak
Oha ():
 after speaking with masak, i come up with some ideas about Buf
 i would like to share with you, maybe you can find them usefull

 http://register.oha.it/buf.pod

Just thought I'd weigh in here a bit. Oha's proposal consists of two
parts, each of which is interesting in its own right:

* The spec already has Buf as a Stringy, Array-ish thing. Perhaps one
could optimize for the ways Buf will actually be used, and think up an
API that combines the encoding/pushing and decoding/shifting into
single operations?

* Grammars define a hierarchical structure that seems to be perfect
for encoding the packing of larger pieces of data, for example when
serializing an object structure. Could one use grammars, or something
very much like it, as a modern pack template?

While I'm not convinced of the specifics of Oha's proposals, I think
the cores of both of these ideas have merit.

// Carl


Re: Buf.pm: FIFO and grammar

2010-08-12 Thread Aaron Sherman
On Thu, Aug 12, 2010 at 5:47 AM, Carl Mäsak cma...@gmail.com wrote:

 Oha ():


 * Grammars define a hierarchical structure that seems to be perfect
 for encoding the packing of larger pieces of data, for example when
 serializing an object structure. Could one use grammars, or something
 very much like it, as a modern pack template?


A while back we had a fairly productive conversation about matching regexes
on non-textual data:

http://groups.google.com/group/perl.perl6.language/msg/24f23fdfc0c5d459?hl=en

My proposal there is incomplete, but matching structured data (even if that
structure is just a sequence of non-textual bytes) using rules definitely
makes sense to me. The real question is: what is the least invasive way to
do it? Modifying nqp for this purpose would, I think, not make sense. I
think we'd need a pure Perl implementation of the rules engine that could
match either text or data, and that's a gigantic undertaking.

-- 
Aaron Sherman
Email or GTalk: a...@ajs.com
http://www.ajs.com/~ajs


Re: Buf.pm: FIFO and grammar

2010-08-12 Thread Carl Mäsak
Carl (), Aaron ():
 * Grammars define a hierarchical structure that seems to be perfect
 for encoding the packing of larger pieces of data, for example when
 serializing an object structure. Could one use grammars, or something
 very much like it, as a modern pack template?

 A while back we had a fairly productive conversation about matching regexes
 on non-textual data:
 http://groups.google.com/group/perl.perl6.language/msg/24f23fdfc0c5d459?hl=en

Interesting thread.

 My proposal there is incomplete, but matching structured data (even if that
 structure is just a sequence of non-textual bytes) using rules definitely
 makes sense to me. The real question is: what is the least invasive way to
 do it? Modifying nqp for this purpose would, I think, not make sense. I
 think we'd need a pure Perl implementation of the rules engine that could
 match either text or data, and that's a gigantic undertaking.

Crazy people have been known to implement the rules engine in Perl 6,
even... :-)

But I think we can get away much cheaper than that. If we contend
ourselves with keeping an early sublanguage inside strings, or with
some well-chosen subroutine names, we could experiment with
hierarchical matchers today in Rakudo. I'd love for someone to develop
a proof-of-concept module for something like this; both matching on
binary data, and the hierarchy matcher described in your thread.

In fact, jnthn++ had a talk at YAPC::EU the other week where he showed
how nested signatures can be used to make hierarchical matches. A
proof-of-concept module could simply be some sugar around this already
existing functionality.

// Carl


Re: Buf.pm: FIFO and grammar

2010-08-12 Thread Nicholas Clark
On Thu, Aug 12, 2010 at 03:38:31PM +0200, Carl Mäsak wrote:

 In fact, jnthn++ had a talk at YAPC::EU the other week where he showed
 how nested signatures can be used to make hierarchical matches. A
 proof-of-concept module could simply be some sugar around this already
 existing functionality.

That was a really good talk. I hope that it has been videoed, and will be
online soon.

Nicholas Clark


r31972 -[S05] specify what .keys, .values and .kv do on Match objects

2010-08-12 Thread pugs-commits
Author: moritz
Date: 2010-08-12 21:10:33 +0200 (Thu, 12 Aug 2010)
New Revision: 31972

Modified:
   docs/Perl6/Spec/S05-regex.pod
Log:
[S05] specify what .keys, .values and .kv do on Match objects

Modified: docs/Perl6/Spec/S05-regex.pod
===
--- docs/Perl6/Spec/S05-regex.pod   2010-08-12 13:53:57 UTC (rev 31971)
+++ docs/Perl6/Spec/S05-regex.pod   2010-08-12 19:10:33 UTC (rev 31972)
@@ -2710,6 +2710,11 @@
 
 =item *
 
+The C.keys, C.values and C.kv methods act both on the positional and the
+named captures, so the keys generally involved both numbers and indentifiers.
+
+=item *
+
 In ordinary code, variables C$0, C$1, etc. are just aliases into
 C$/[0], C$/[1], etc.  Hence they will all be undefined if the
 last match failed (unless they were explicitly bound in a closure without



r31973 -[S05] attempt to clarify wording, and add an example

2010-08-12 Thread pugs-commits
Author: moritz
Date: 2010-08-12 21:23:14 +0200 (Thu, 12 Aug 2010)
New Revision: 31973

Modified:
   docs/Perl6/Spec/S05-regex.pod
Log:
[S05] attempt to clarify wording, and add an example

Modified: docs/Perl6/Spec/S05-regex.pod
===
--- docs/Perl6/Spec/S05-regex.pod   2010-08-12 19:10:33 UTC (rev 31972)
+++ docs/Perl6/Spec/S05-regex.pod   2010-08-12 19:23:14 UTC (rev 31973)
@@ -2710,9 +2710,12 @@
 
 =item *
 
-The C.keys, C.values and C.kv methods act both on the positional and the
-named captures, so the keys generally involved both numbers and indentifiers.
+The C.keys, C.values and C.kv methods act both on the list and hash
+part, with the list part coming first.
 
+'abcd' ~~ /(.)(.)**2 alpha/;
+say ~$/.keys;   # 1 2 alpha
+
 =item *
 
 In ordinary code, variables C$0, C$1, etc. are just aliases into



Re: r31972 -[S05] specify what .keys, .values and .kv do on Match objects

2010-08-12 Thread Jon Lang
How does a Match compare to a Parcel?

-- 
Jonathan Dataweaver Lang