Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #16026

Re: regexp help

Followups directed to: comp.lang.javascript

Show all headers | View raw

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> (You want to do something about that encoding problem of your posting
>> agent.)
> 
> Sorry, with how terrible Google Groups has gotten, I've looked around
> for some other web-based solution I can use from work.  It looks like
> another one is failing.  I'll look from home to see what the symptoms
> are.  From within FastUsenet.org and Google Groups I'm not seeing
> whatever issue you're noting.

webnews.fastusenet.org used UTF-8, but replaced U+2013 EN DASH in the quoted 
text with U+0096, a control character.

> It's back to Google for now, though.

I would rather live with borken en-dashes.

>> [ ... ]
>> <http://PointedEars.de/scripts/test/regexp>
>>
>> I am working on the rest of \b (`\b' after `('s and `\b' with match(/…/g)
>> still need fixing), and other character class escapes, like \d and \s, in
>> Unicode mode.  Although Perl and PCRE do not support it, given the
>> current implementation of \w, \b, and \p{…}, it might be possible to
>> implement in ECMAScript (?u-u) for `u' (would anyone find this useful?). 
>> And then there's the greater challenge of implementing `(?im-im)'.
> 
> I'm glad to hear you're making progress.  I wish I had something to
> offer beyond encouragement, but at least you have my best wishes!

Thanks.  `\b' after `('s and `\b' with match(/…/g) have been implemented 
now.  More in the unit test and changelog.

>>>>> Obviously you could make whatever call you choose about
>>>>> what to include, but is there an obvious call to make?
>>>>
>>>> Yes, Perl already specifies it, so I followed perlrecharclass(1) (but I
>>>> forgot to include \p{N}; that has been fixed in the meantime).
>>>>
>>>> However, I can see now that it is wrong to call my implementation of \w
>>>> in Unicode mode *PCRE*-conforming, as pcrepattern(1) specifies it
>>>> differently: \w is equivalent to [\p{L}\p{N}_] there, while according
>>>> to perlrecharclass(1) it appears to be [\p{L}\p{M}\p{N}\p{Pc}] in Perl.
>>>>
>>>> I think that Perl's definition is better than PCRE's here [ ... ]
>>>
>>> So yes, there are obvious choices, but which of the obvious choices is
>>> best is still up for grabs?  :-)
>>
>> ^^^^^^^^^^^^^^^^^^
>> I am not sure I fully understand that idiom.
> 
> I apologize.  Approximately, "unclaimed, available to anyone."
> 
>     <http://idioms.thefreedictionary.com/up+for+grabs>

If you are implementing syntactical and semantical extensions through string 
values as I do, you are basically free to implement whatever you like.  But 
if the new feature should be used as a stand-in for an existing feature, it 
is a good idea if syntax and result do not conflict with user expectations.  
That would be those that could be expected from the ECMAScript Language 
Specification, 5.1 Edition, and other scripting languages that implement the 
same feature, at this point.
 
>> However, saying that I think Perl's definition is better with \w, \W, and
>> \b, already indicated that I intended to implement that instead of
>> PCRE's.  So I did.  But AISB, if you are not happy with that, you can
>> easily redefine the escape sequence, even during runtime (provided that
>> the UCD has been loaded before; I am working on that as well):
>>
>> var RegExp2 = jsx.regexp.RegExp;
>>
>> /* \p{L}\p{M}\p{N}\p{Pc} */
>> console.log(RegExp2.propertyClasses["Word"]);
>>
>> /* \w, \p{Word} à la PCRE */
>> RegExp2.definePropertyClasses({
>> Word: "\\p{L}\\p{N}_"
>> });
>>
>> /* see above */
>> var rx = new RegExp2("\\b(?<foo>\\w+\\b)", "u");
>>
>> var input = "-trärä-";
>>
>> var m = rx.exec(input);
>>
>> if (m)
>> {
>> /* "trärä" "trärä" "trärä"¹ */
>> console.log(m[0], m[1], m.groups["foo"]);
>> }
>>
>> /* trärä */
>> console.log((new jsx.regexp.String(input)).match(rx).groups["foo"]);
> 
> That's an excellent approach, but I would suggest you think very hard
> about your defaults, because that is likely how most users would use
> it, regardless of how configurable you make it.

From top to bottom, and left to right:

I think that Perl's definitions for \w, \d and \s provide the best defaults 
for Unicode mode, as by contrast to PCRE's it includes the widest range of 
suitable Unicode characters.  For example, when you want to match word 
characters in Unicode, you should not be restricted to uncomposed characters 
– IMHO what matters is the final shape of the character and the meaning 
associated with that (such as, letter), not the code sequences that led to 
that shape.  With the PCRE definition apparently you would.

I think that jsx.regexp.RegExp can be used as a stand-in for RegExp() and 
RegExp literals is a good idea.  In fact, I am intentionally supporting 
references to RegExp instances as first argument as RegExp does: If you are 
not using syntactical extensions like named capturing groups, you can simply 
use jsx.regexp.RegExp(/…/gimy, "u") instead of /…/gimy to make your 
expression fully Unicode-aware (and thereby avoid the extra escaping that 
string values require).

Because it is defined so in PCRE, the named groups syntaxes can be found in 
Perl, PHP, and Python, among other programming languages that use the PCRE 
library.

I have chosen the `groups' property for matches for named capturing groups 
because it is so in Python (although the attribute it is a method there and 
accepts numbers as well); the same applies to other additional properties.

I also cannot see a viable alternative to jsx.regexp.String() if you need 
features that require syntactical extensions.  That is, `new 
jsx.regexp.String(string)' can be used as a stand-in for string values then; 
otherwise you can keep the primitive string value.

So I would like to think that I have thought very hard about my design and 
property class defaults already.  Do you have any specific issue with my 
approach, particularly with any of these considerations?


PointedEars
-- 
When all you know is jQuery, every problem looks $(olvable).

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

regexp help Andrew Poulos <ap_prog@hotmail.com> - 2012-09-07 14:37 +1000
  Re: regexp help Jake Jarvis <pig_in_shoes@yahoo.com> - 2012-09-07 10:55 +0200
    Re: regexp help Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-07 15:36 +0200
      Re: regexp help Andrew Poulos <ap_prog@hotmail.com> - 2012-09-08 10:27 +1000
        Re: regexp help Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-08 09:34 +0200
      Re: regexp help "Scott Sauyet" <3103invalid@webnews.fastusenet.org> - 2012-09-11 16:51 +0000
        Re: regexp help Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-11 22:31 +0200
          Re: regexp help "Scott Sauyet" <3103invalid@webnews.fastusenet.org> - 2012-09-19 11:56 +0000
            Re: regexp help Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-19 18:51 +0200
              Re: regexp help Scott Sauyet <scott.sauyet@gmail.com> - 2012-09-19 12:52 -0700
                Re: regexp help Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-20 02:13 +0200
                Re: regexp help Scott Sauyet <scott.sauyet@gmail.com> - 2012-09-20 06:51 -0700
                Re: regexp help Dr J R Stockton <reply1237@merlyn.demon.co.uk.invalid> - 2012-09-20 20:23 +0100
      Re: regexp help "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-09-11 14:55 -0700

csiph-web