atomicness and \n
Is C<\n> going to be a rule (e.g. C<< >>) or is it implicitly
translated to:
<[\x0a\x0d...]>+
If it's the latter, then what does this do?
\n?
Do I get
[<[\x0a\x0d...]>+]?
Or do I get
<[\x0a\x0d...]>+?
If the former (which I assume is the case), how do I get the latter
without having to know what the C<...> is, above?
Along those lines, will
<[\n]>
work, or should I expect that to be an error because C<\n> is no longer
an actual character class.
Hmm... this is a slippery slope. That gets me thinking about
rule roundascii { <[a-hjm-uB-DGJO-SU23568-0]> }
$roundor7 = rx /<[17]>/;
or do I have to
$roundor7 = rx /|<[17]>/;
Which seems somewhat clunky and less efficient.
Re: atomicness and \n
Aaron Sherman wrote:
> Is C<\n> going to be a rule (e.g. C<< >>)
There might be an named rule like that. But C<\n> will certainly
still be available.
> or is it implicitly translated to:
>
> <[\x0a\x0d...]>+
No. It will be equivalent to:
<[\x0a\x0d...]>
(no repetition)
> Along those lines, will
>
> <[\n]>
>
> work
Yes.
> Hmm... this is a slippery slope. That gets me thinking about
>
> rule roundascii { <[a-hjm-uB-DGJO-SU23568-0]> }
> $roundor7 = rx /<[17]>/;
>
> or do I have to
>
> $roundor7 = rx /|<[17]>/;
Neither. You need:
$roundor7 = rx /<+[17]>/
That is: the union of the two character classes.
Damian
Re: atomicness and \n
[EMAIL PROTECTED] (Damian Conway) writes: > Neither. You need: > $roundor7 = rx /<+[17]>/ > That is: the union of the two character classes. Thank you; that wasn't in A5, E5 or S5. Will there be <-> as well? -- I wish my keyboard had a SMITE key -- J-P Stacey
Re: atomicness and \n
> > $roundor7 = rx /<+[17]>/ > > That is: the union of the two character classes. > > Thank you; that wasn't in A5, E5 or S5. Will there be <-> as > well? >From A5: The outer <...> also naturally serves as a container for any extra syntax we decide to come up with for character set manipulation: <[_]++-> -- ralph
Re: atomicness and \n
On Sat, 2002-08-31 at 07:07, Damian Conway wrote: > Aaron Sherman wrote: > > > Is C<\n> going to be a rule (e.g. C<< >>) > > There might be an named rule like that. But C<\n> will certainly > still be available. > > > or is it implicitly translated to: > > > > <[\x0a\x0d...]>+ > > No. It will be equivalent to: > > <[\x0a\x0d...]> > > (no repetition) Didn't A5 or E5 say that C<\n> was going to match sequences like C<\x0d\x0a> so that file formats that treat this as EOL would be supported natively? Was this a mistake? If it's not a mistake, then is there a way to minimally match "the first end-of-line character, regardless of what follows it (even if it's another end-of-line character)? That was the crux of my question. On the union operator stuff, thanks; I'd forgotten about that.
Re: atomicness and \n
Damian Conway wrote:
> No. It will be equivalent to:
>
> <[\x0a\x0d...]>
I don't think \n can be a character class because it
is a two character sequence on some systems. Apoc 5
said \n will be the same everywhere, so won't it be
something like
rule \n { \x0d \x0a | \x0d | \x0a }
Hmm. Now that I read that, I'm thinking some characters
will be multi-byte sequences. Is there going to be
multi-byte magic for line endings? Even in ASCII data
streams?
- Ken
Re: atomicness and \n
At 9:24 PM -0400 8/31/02, Ken Fox wrote:
>Damian Conway wrote:
>>No. It will be equivalent to:
>>
>> <[\x0a\x0d...]>
>
>I don't think \n can be a character class because it
>is a two character sequence on some systems. Apoc 5
>said \n will be the same everywhere, so won't it be
>something like
>
> rule \n { \x0d \x0a | \x0d | \x0a }
That should be
rule ASCII::\n
or something of the sort. That particular rule will only be valid for
ASCII data. Unicode will have a superset of that, and the other
character sets will have a different line ending rule.
This, like the other shortcut characters, will be character-set
specific. (And overridable, in case someone feels like making \b work
properly (FSVO "properly") for asian data that doesn't use word
delimiters)
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
RE: atomicness and \n
Damian Conway:
# Neither. You need:
#
# $roundor7 = rx /<+[17]>/
#
# That is: the union of the two character classes.
How can you be sure that is implemented as a character
class, as opposed to (say) an alternation?
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"In other words, it's the 'Blow up this Entire Planet and Possibly One
or Two Others We Noticed on our Way Out Here' operator."
--Damian Conway
RE: atomicness and \n
On Tue, 3 Sep 2002, Brent Dax wrote: > Damian Conway: > # Neither. You need: > # > # $roundor7 = rx /<+[17]>/ > # > # That is: the union of the two character classes. > > How can you be sure that is implemented as a character > class, as opposed to (say) an alternation? What's the difference? :) Neglecting internals, semantically what I the difference? Luke
RE: atomicness and \n
On Tue, 3 Sep 2002, Luke Palmer wrote: > On Tue, 3 Sep 2002, Brent Dax wrote: > > > Damian Conway: > > # Neither. You need: > > # > > # $roundor7 = rx /<+[17]>/ > > # > > # That is: the union of the two character classes. > > > > How can you be sure that is implemented as a character > > class, as opposed to (say) an alternation? > > What's the difference? :) > > Neglecting internals, semantically what I the difference? None, I think. Of course, if we ignore internals, there's no difference bewteen that and "rx / | 1 | 7/". /s
Re: atomicness and \n
On Tue, Sep 03, 2002 at 09:57:31PM -0600, Luke Palmer wrote: > On Tue, 3 Sep 2002, Brent Dax wrote: > > > Damian Conway: > > # Neither. You need: > > # > > # $roundor7 = rx /<+[17]>/ > > # > > # That is: the union of the two character classes. > > > > How can you be sure that is implemented as a character > > class, as opposed to (say) an alternation? > > What's the difference? :) > > Neglecting internals, semantically what I the difference? I think the point still stands. How can you be sure that is implemented as a character class instead of being some other arbitrary rule? An answer is that perl should know how these things are implemented and if you try arithmetic on something that's not a character class, it should carp appropriately. Another answer might be that <+[17]> is actually syntactically illegal and you MUST perform character class arithmetic as <[abc]+[def]>. Somehow I prefer the former to the latter. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
RE: atomicness and \n
On Wed, 2002-09-04 at 00:01, Sean O'Rourke wrote: > On Tue, 3 Sep 2002, Luke Palmer wrote: > > > On Tue, 3 Sep 2002, Brent Dax wrote: > > > > > Damian Conway: > > > # $roundor7 = rx /<+[17]>/ > > > # > > > # That is: the union of the two character classes. > > > > > > How can you be sure that is implemented as a character > > > class, as opposed to (say) an alternation? > > > > What's the difference? :) > None, I think. Of course, if we ignore internals, there's no difference > bewteen that and "rx / | 1 | 7/". Then, why is there a C<+>? Why not make it C<|>? $foo = rx/ <||[cde]>|f /
RE: atomicness and \n
On Tue, 2002-09-03 at 23:57, Luke Palmer wrote: > On Tue, 3 Sep 2002, Brent Dax wrote: > > > > How can you be sure that is implemented as a character > > class, as opposed to (say) an alternation? > > What's the difference? :) > > Neglecting internals, semantically what I the difference? > One *possible* semantic difference is a guaranteed matching order. Nothing (historically) has ever really dictated that character classes must match left-to-right, as alternation does. That's mainly because character classes have always been of a uniform width, in which case it is only going to match one thing and one thing only. Whether that will be an issue with variable-width characters in a class is largely going to rely on the semantics that are dictated. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
RE: atomicness and \n
On 4 Sep 2002 at 0:22, Aaron Sherman wrote: > On Wed, 2002-09-04 at 00:01, Sean O'Rourke wrote: > > > None, I think. Of course, if we ignore internals, there's no > > difference bewteen that and "rx / | 1 | 7/". > > Then, why is there a C<+>? Why not make it C<|>? > > $foo = rx/ <||[cde]>|f / Because it's good to have MTOWTDI. (= More than one way to do it) -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
RE: atomicness and \n
On Wed, 2002-09-04 at 09:55, Markus Laire wrote: > On 4 Sep 2002 at 0:22, Aaron Sherman wrote: > > > On Wed, 2002-09-04 at 00:01, Sean O'Rourke wrote: > > > > > None, I think. Of course, if we ignore internals, there's no > > > difference bewteen that and "rx / | 1 | 7/". > > > > Then, why is there a C<+>? Why not make it C<|>? > > > > $foo = rx/ <||[cde]>|f / > > Because it's good to have MTOWTDI. (= More than one way to do it) But, there isn't. There's only one way to indicate character-class unions, and that's C<+>. If we had C<+> and C<|> as synonyms, I'd be ok with that, though I'd only tell people about C<|> to avoid the confusion (mind if we call you Bruce?)
Re: atomicness and \n
Jonathan Scott Duff wrote: > How can you be sure that is > implemented as a character class instead of being some other arbitrary > rule? An answer is that perl should know how these things are > implemented and if you try arithmetic on something that's not a > character class, it should carp appropriately. Another answer might be > that <+[17]> is actually syntactically illegal and you MUST > perform character class arithmetic as <[abc]+[def]>. > > Somehow I prefer the former to the latter. It will definitely be the former, since we have to support named character classes like , , , etc. Damian
