On Fri, Sep 07, 2007 at 04:05:55PM -0600, Paul Seamons wrote:
> I'd vote for <:ws> which is vaguely reminiscent of the former non-capturing
> parens (?:).
>
> It (<:ws>) also bears little similarity to any other regex construct -
> although it looks a bit like a Perl 6 pair.
For completeness it
On Fri, Sep 07, 2007, Larry Wall writes:
> If we stick with +, one approach might be to simply disallow whitespace
> in composite character classes.
Of the choices presented thus far, I like this one the best.
Although I did like being able to stick whitespace in the
character classes for readabil
On Sat, Sep 08, 2007 at 12:12:10AM +0100, Nicholas Clark wrote:
: On Fri, Sep 07, 2007 at 03:50:09PM -0700, Larry Wall wrote:
: > I dunno, maybe <\ws> isn't so bad...
:
: But as soon as I saw it I thought the same as you say in the paragraph above -
: in the context of a regexp (or string) \ makes
On Fri, Sep 07, 2007 at 03:50:09PM -0700, Larry Wall wrote:
> The first list is the ones I'm really considering, and of those, <.ws>
> is the easiest to type and gets out of the way of identifier visually.
> It also looks like a method call, which in fact it is. <~ws> is hard
> to type, and <\ws>
On Fri, Sep 07, 2007 at 04:05:55PM -0600, Paul Seamons wrote:
: > Other available chars:
: >
: > <`ws>
: > <^ws>
: > <&ws>
: > <*ws>
: > <-ws>
I forgot we're using - already, so scratch that one...
: > <|ws>
: > <:ws>
: > <;ws>
: >
:
: I'd vote for <:ws> whic
> Other available chars:
>
> <`ws>
> <^ws>
> <&ws>
> <*ws>
> <-ws>
> <|ws>
> <:ws>
> <;ws>
>
I'd vote for <:ws> which is vaguely reminiscent of the former non-capturing
parens (?:).
It (<:ws>) also bears little similarity to any other regex construct -
altho
On Fri, Sep 07, 2007 at 02:45:52AM -0500, Patrick R. Michaud wrote:
: On Thu, Sep 06, 2007 at 05:12:03PM -0700, [EMAIL PROTECTED] wrote:
: > Log:
: > old is now <+foo> to suppress capture
: > new now is zero-width like
:
: I really like the change from to <+foo>, but I think there's
: a confli
[EMAIL PROTECTED] writes:
> -A leading C<[> or C<+> indicates an enumerated character class. Ranges
> +A leading C<[> indicates an enumerated character class. Ranges
> in enumerated character classes are indicated with "C<..>" rather than
> "C<->".
>
> / <[a..z_]>* /
> - / <+[a..z_
Some other minor notes about the S05.pod update:
> +In particular, also matches the null string, and always fails.
Perhaps these should be quoted with "C<< ... >>" so that it's
clear that "" and "" are the tokens? When looking at the
.pod file I had to think about it a couple of times to make
On Thu, Sep 06, 2007 at 05:12:03PM -0700, [EMAIL PROTECTED] wrote:
> Log:
> old is now <+foo> to suppress capture
> new now is zero-width like
I really like the change from to <+foo>, but I think there's
a conflict (or at least some confusion) in the way the new spec is
worded, especially as i
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
11 matches
Mail list logo
