Regular expression built-in proposal
Locked
Regular expression built-in proposal
 
|
Hi all,
I'd like to propose a couple of additional builtin methods for NetRexx strings. These provide support for regular expression matching and substitution, allowing for more natural usage of the Pattern and Matcher classes. Here's the proposal: --( Appended to Rexx.nrx )---------------------------------------------- method matches(regex=String, strflags=String'') binary returns Rexx flags = pattern_flags(strflags) matcher = Pattern.compile(regex, flags).matcher(this) return Rexx matcher.find() /** * Replace regex matches with replacement string. Defaults to * replacing the first match. A string consisting of character * flags can also be supplied (see process_flags below). */ method replace(regex=String, replacement=String,- strglobal=Rexx'F', strflags=String'') binary returns Rexx global = boolean select case strglobal.optioncheck(Rexx 'FG') when 'F' then global = 0 -- "first match only" when 'G' then global = 1 -- "globally" end me = this.toString() flags = pattern_flags(strflags) matcher = Pattern.compile(regex, flags).matcher(me) buffer = StringBuffer() if global then return matcher.replaceAll(replacement) if \matcher.find() then return me matcher.appendReplacement(buffer, replacement) matcher.appendTail(buffer) return buffer.toString() method pattern_flags(str=String) binary static private returns int u = str.toUpperCase() acc = int 0 loop i=0 for u.length() c = u.charAt(i) select case c when '=' then f = Pattern.CANON_EQ when 'I' then f = Pattern.CASE_INSENSITIVE when 'C' then f = Pattern.COMMENTS when '.' then f = Pattern.DOTALL when 'L' then f = Pattern.LITERAL when 'M' then f = Pattern.MULTILINE when 'X' then f = Pattern.UNICODE_CASE when 'U' then f = Pattern.UNIX_LINES otherwise f = 0 end acc = acc | f end return acc --8<-------------------------------------------------------------------- While Java provides String#replaceAll, String#replaceFirst and String#matches, these methods don't allow for flag specification; the above therefore leverages Pattern explicitly. In keeping with Rexx style, a character flag is used to specify global replacement; the default is substitution for the first match. If this is deemed confusing, 'replaceFirst' and 'replaceAll' methods could be defined to set the flag explicitly. Simple example of usage, --( re.nrx: proposed regex methods for NetRexx strings )---------------- input1 = "A hello world" input2 = "qqqqqq" input3 = "AAA" rx1 = "(.*?)([aeiou])(.*?)" -- non-greedy rpl = "$1V$3" -- replacement string say say "Replacing all matches with the string '"rpl"'" say "input1:" input1 say "input2:" input2 say "input3:" input3 say i1a = input1.replace(rx1, rpl) -- first only i1b = input1.replace(rx1, rpl, 'G') -- global replacement i1c = input1.replace(rx1, rpl, 'F', 'I') -- first, ignore case i1d = input1.replace(rx1, rpl, 'G', 'i') -- global, ignore case i2a = input2.replace(rx1, rpl) i2b = input2.replace(rx1, rpl, 'G') say "input1 matches rx1?" y_or_n(input1.matches(rx1)) say say "input1: first only: " i1a say "input1: globally: " i1b say "input1: first only, ignore case: " i1c say "input1: globally, ignore case: " i1d say say "input2 matches rx1?" y_or_n(input2.matches(rx1)) say say "input2: first only: " i2a say "input2: globally: " i2b say say "input3 matches rx1?" y_or_n(input3.matches(rx1)) say "input3 matches rx1 (ignore case)?" y_or_n(input3.matches(rx1, 'I')) method y_or_n(flag) static if flag then return "yes" return "no" --( re.nrx END )-------------------------------------------------------- Output, --8<-------------------------------------------------------------------- # nrc -run re NetRexx portable processor, version NetRexx 3.01RC3, build 80-20120125-1019 Copyright (c) RexxLA, 2011. All rights reserved. Parts Copyright (c) IBM Corporation, 1995,2008. Program re.nrx function y_or_n(Rexx) Compilation of 're.nrx' successful Running re... Replacing all matches with the string '$1V$3' input1: A hello world input2: qqqqqq input3: AAA input1 matches rx1? yes input1: first only: A hVllo world input1: globally: A hVllV wVrld input1: first only, ignore case: V hello world input1: globally, ignore case: V hVllV wVrld input2 matches rx1? no input2: first only: qqqqqq input2: globally: qqqqqq input3 matches rx1? no input3 matches rx1 (ignore case)? yes --8<-------------------------------------------------------------------- Obviously this approach could also be implemented non-invasively (i.e., without modifying core translator classes) should the above be considered too dramatic a change. Best, M _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
I find regex to be one of the most inhuman of any computer interaction.
And it already exists in java so why repeat it in nrx ? Perhaps some more human type of substitution ? -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Marc Simpson Sent: Wednesday, January 25, 2012 4:28 AM To: IBM Netrexx Subject: [Ibm-netrexx] Regular expression built-in proposal Hi all, I'd like to propose a couple of additional builtin methods for NetRexx strings. These provide support for regular expression matching and substitution, allowing for more natural usage of the Pattern and Matcher classes. Here's the proposal: --( Appended to Rexx.nrx )---------------------------------------------- method matches(regex=String, strflags=String'') binary returns Rexx flags = pattern_flags(strflags) matcher = Pattern.compile(regex, flags).matcher(this) return Rexx matcher.find() /** * Replace regex matches with replacement string. Defaults to * replacing the first match. A string consisting of character * flags can also be supplied (see process_flags below). */ method replace(regex=String, replacement=String,- strglobal=Rexx'F', strflags=String'') binary returns Rexx global = boolean select case strglobal.optioncheck(Rexx 'FG') when 'F' then global = 0 -- "first match only" when 'G' then global = 1 -- "globally" end me = this.toString() flags = pattern_flags(strflags) matcher = Pattern.compile(regex, flags).matcher(me) buffer = StringBuffer() if global then return matcher.replaceAll(replacement) if \matcher.find() then return me matcher.appendReplacement(buffer, replacement) matcher.appendTail(buffer) return buffer.toString() method pattern_flags(str=String) binary static private returns int u = str.toUpperCase() acc = int 0 loop i=0 for u.length() c = u.charAt(i) select case c when '=' then f = Pattern.CANON_EQ when 'I' then f = Pattern.CASE_INSENSITIVE when 'C' then f = Pattern.COMMENTS when '.' then f = Pattern.DOTALL when 'L' then f = Pattern.LITERAL when 'M' then f = Pattern.MULTILINE when 'X' then f = Pattern.UNICODE_CASE when 'U' then f = Pattern.UNIX_LINES otherwise f = 0 end acc = acc | f end return acc --8<-------------------------------------------------------------------- While Java provides String#replaceAll, String#replaceFirst and String#matches, these methods don't allow for flag specification; the above therefore leverages Pattern explicitly. In keeping with Rexx style, a character flag is used to specify global replacement; the default is substitution for the first match. If this is deemed confusing, 'replaceFirst' and 'replaceAll' methods could be defined to set the flag explicitly. Simple example of usage, --( re.nrx: proposed regex methods for NetRexx strings )---------------- input1 = "A hello world" input2 = "qqqqqq" input3 = "AAA" rx1 = "(.*?)([aeiou])(.*?)" -- non-greedy rpl = "$1V$3" -- replacement string say say "Replacing all matches with the string '"rpl"'" say "input1:" input1 say "input2:" input2 say "input3:" input3 say i1a = input1.replace(rx1, rpl) -- first only i1b = input1.replace(rx1, rpl, 'G') -- global replacement i1c = input1.replace(rx1, rpl, 'F', 'I') -- first, ignore case i1d = input1.replace(rx1, rpl, 'G', 'i') -- global, ignore case i2a = input2.replace(rx1, rpl) i2b = input2.replace(rx1, rpl, 'G') say "input1 matches rx1?" y_or_n(input1.matches(rx1)) say say "input1: first only: " i1a say "input1: globally: " i1b say "input1: first only, ignore case: " i1c say "input1: globally, ignore case: " i1d say say "input2 matches rx1?" y_or_n(input2.matches(rx1)) say say "input2: first only: " i2a say "input2: globally: " i2b say say "input3 matches rx1?" y_or_n(input3.matches(rx1)) say "input3 matches rx1 (ignore case)?" y_or_n(input3.matches(rx1, 'I')) method y_or_n(flag) static if flag then return "yes" return "no" --( re.nrx END )-------------------------------------------------------- Output, --8<-------------------------------------------------------------------- # nrc -run re NetRexx portable processor, version NetRexx 3.01RC3, build 80-20120125-1019 Copyright (c) RexxLA, 2011. All rights reserved. Parts Copyright (c) IBM Corporation, 1995,2008. Program re.nrx function y_or_n(Rexx) Compilation of 're.nrx' successful Running re... Replacing all matches with the string '$1V$3' input1: A hello world input2: qqqqqq input3: AAA input1 matches rx1? yes input1: first only: A hVllo world input1: globally: A hVllV wVrld input1: first only, ignore case: V hello world input1: globally, ignore case: V hVllV wVrld input2 matches rx1? no input2: first only: qqqqqq input2: globally: qqqqqq input3 matches rx1? no input3 matches rx1 (ignore case)? yes --8<-------------------------------------------------------------------- Obviously this approach could also be implemented non-invasively (i.e., without modifying core translator classes) should the above be considered too dramatic a change. Best, M _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Marc Simpson
Hi Marc,
could you enter an issue containing this proposal to the Kenai issue tracker? In the Rexx world, it is customary (at least: our intention) to have such a proposal accompanied by proposed changes to the nrl (The NetRexx Language Definition document). I will then schedule it for discussion in the ARB (the Architecture Review Board) (where Mike C. has an important vote as our language architect). My personal view: it seems entirely sensible to have something like this. But I am only managing the process. Is it you intention/plan to do the implementation of this in the runtime package yourself? If so, we need to set up some authorities on the codebase repository. If you have an implementation, you can always check it in into the public 'contrib' repository for the time being. best regards, René Jansen. On 2012-01-25 11:27, Marc Simpson wrote: > Hi all, > > I'd like to propose a couple of additional builtin methods for > NetRexx > strings. These provide support for regular expression matching and > substitution, allowing for more natural usage of the Pattern and > Matcher classes. > > Here's the proposal: > > --( Appended to Rexx.nrx > )---------------------------------------------- > method matches(regex=String, strflags=String'') binary returns Rexx > flags = pattern_flags(strflags) > matcher = Pattern.compile(regex, flags).matcher(this) > return Rexx matcher.find() > > /** > * Replace regex matches with replacement string. Defaults to > * replacing the first match. A string consisting of character > * flags can also be supplied (see process_flags below). > */ > method replace(regex=String, replacement=String,- > strglobal=Rexx'F', strflags=String'') binary returns > Rexx > global = boolean > select case strglobal.optioncheck(Rexx 'FG') > when 'F' then global = 0 -- "first match only" > when 'G' then global = 1 -- "globally" > end > me = this.toString() > flags = pattern_flags(strflags) > matcher = Pattern.compile(regex, flags).matcher(me) > buffer = StringBuffer() > if global then return matcher.replaceAll(replacement) > if \matcher.find() then return me > matcher.appendReplacement(buffer, replacement) > matcher.appendTail(buffer) > return buffer.toString() > > method pattern_flags(str=String) binary static private returns int > u = str.toUpperCase() > acc = int 0 > loop i=0 for u.length() > c = u.charAt(i) > select case c > when '=' then f = Pattern.CANON_EQ > when 'I' then f = Pattern.CASE_INSENSITIVE > when 'C' then f = Pattern.COMMENTS > when '.' then f = Pattern.DOTALL > when 'L' then f = Pattern.LITERAL > when 'M' then f = Pattern.MULTILINE > when 'X' then f = Pattern.UNICODE_CASE > when 'U' then f = Pattern.UNIX_LINES > otherwise f = 0 > end > acc = acc | f > end > return acc > > --8<-------------------------------------------------------------------- > > While Java provides String#replaceAll, String#replaceFirst and > String#matches, these methods don't allow for flag specification; the > above therefore leverages Pattern explicitly. > > In keeping with Rexx style, a character flag is used to specify > global > replacement; the default is substitution for the first match. If > this > is deemed confusing, 'replaceFirst' and 'replaceAll' methods could be > defined to set the flag explicitly. > > Simple example of usage, > > --( re.nrx: proposed regex methods for NetRexx strings > )---------------- > input1 = "A hello world" > input2 = "qqqqqq" > input3 = "AAA" > rx1 = "(.*?)([aeiou])(.*?)" -- non-greedy > rpl = "$1V$3" -- replacement string > > say > say "Replacing all matches with the string '"rpl"'" > say "input1:" input1 > say "input2:" input2 > say "input3:" input3 > say > > i1a = input1.replace(rx1, rpl) -- first only > i1b = input1.replace(rx1, rpl, 'G') -- global replacement > i1c = input1.replace(rx1, rpl, 'F', 'I') -- first, ignore case > i1d = input1.replace(rx1, rpl, 'G', 'i') -- global, ignore case > i2a = input2.replace(rx1, rpl) > i2b = input2.replace(rx1, rpl, 'G') > > say "input1 matches rx1?" y_or_n(input1.matches(rx1)) > say > say "input1: first only: " i1a > say "input1: globally: " i1b > say "input1: first only, ignore case: " i1c > say "input1: globally, ignore case: " i1d > say > say "input2 matches rx1?" y_or_n(input2.matches(rx1)) > say > say "input2: first only: " i2a > say "input2: globally: " i2b > say > say "input3 matches rx1?" y_or_n(input3.matches(rx1)) > say "input3 matches rx1 (ignore case)?" y_or_n(input3.matches(rx1, > 'I')) > > method y_or_n(flag) static > if flag then return "yes" > return "no" > --( re.nrx END > )-------------------------------------------------------- > > Output, > > > --8<-------------------------------------------------------------------- > # nrc -run re > NetRexx portable processor, version NetRexx 3.01RC3, build > 80-20120125-1019 > Copyright (c) RexxLA, 2011. All rights reserved. > Parts Copyright (c) IBM Corporation, 1995,2008. > Program re.nrx > function y_or_n(Rexx) > Compilation of 're.nrx' successful > Running re... > > Replacing all matches with the string '$1V$3' > input1: A hello world > input2: qqqqqq > input3: AAA > > input1 matches rx1? yes > > input1: first only: A hVllo world > input1: globally: A hVllV wVrld > input1: first only, ignore case: V hello world > input1: globally, ignore case: V hVllV wVrld > > input2 matches rx1? no > > input2: first only: qqqqqq > input2: globally: qqqqqq > > input3 matches rx1? no > input3 matches rx1 (ignore case)? yes > > --8<-------------------------------------------------------------------- > > Obviously this approach could also be implemented non-invasively > (i.e., without modifying core translator classes) should the above be > considered too dramatic a change. > > Best, > M > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: Regular expression built-in proposal
|
|
Hi René,
On Wed, Jan 25, 2012 at 12:58 PM, rvjansen <[hidden email]> wrote: > Hi Marc, > > could you enter an issue containing this proposal to the Kenai issue > tracker? Sure thing. > In the Rexx world, it is customary (at least: our intention) to have such a > proposal accompanied by proposed changes to the nrl (The NetRexx Language > Definition document). I will then schedule it for discussion in the ARB (the > Architecture Review Board) (where Mike C. has an important vote as our > language architect). Understood, thanks for the information. > My personal view: it seems entirely sensible to have something like this. > But I am only managing the process. Is it you intention/plan to do the > implementation of this in the runtime package yourself? I don't really mind—the first code snippet, above, is what I added to my local copy of Rexx.nrx (netrexx.lang.Rexx); the proposal has already been implemented in my local runtime package (though of course I don't mind someone else rewriting it or modifying should the proposal be accepted). > If so, we need to > set up some authorities on the codebase repository. If you have an > implementation, you can always check it in into the public 'contrib' > repository for the time being. Sure, I can do that if it would help. Best, M _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: Regular expression built-in proposal
|
|
On Wed, Jan 25, 2012 at 1:05 PM, Marc Simpson <[hidden email]> wrote:
> On Wed, Jan 25, 2012 at 12:58 PM, rvjansen <[hidden email]> wrote: >> Hi Marc, >> >> could you enter an issue containing this proposal to the Kenai issue >> tracker? > > Sure thing. Here's it is: http://kenai.com/jira/browse/NETREXX-73 Unfortunately the the formatting is a little messed up -- could someone with edit permissions possibly add {noformat} tags around the code snippets? If not, I'll attach them to the issue. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: Regular expression built-in proposal
|
|
In reply to this post by measel
I think regex is not Rexx or NetRexx but more like Perl or APL. I am
also getting the feeling that some people on this list may not realize that RexxLA created a special RegRexx mailing list last year to discuss a Rexx version of regex: http://rice.safedataisp.net/mailman/listinfo/regrexx I suggest that any NetRexx efforts be coordinated with the general Rexx project or we will be answering the usual type of questions one day: "Why does NetRexx do this differently than Rexx?" -- KK On 1/25/2012 4:57 AM, Measel, Mike wrote: > I find regex to be one of the most inhuman of any computer interaction. > > And it already exists in java so why repeat it in nrx ? > > Perhaps some more human type of substitution ? > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Marc Simpson > Sent: Wednesday, January 25, 2012 4:28 AM > To: IBM Netrexx > Subject: [Ibm-netrexx] Regular expression built-in proposal > > Hi all, > > I'd like to propose a couple of additional builtin methods for NetRexx > strings. These provide support for regular expression matching and > substitution, allowing for more natural usage of the Pattern and > Matcher classes. > > Here's the proposal: > > --( Appended to Rexx.nrx )---------------------------------------------- > method matches(regex=String, strflags=String'') binary returns Rexx > flags = pattern_flags(strflags) > matcher = Pattern.compile(regex, flags).matcher(this) > return Rexx matcher.find() > > /** > * Replace regex matches with replacement string. Defaults to > * replacing the first match. A string consisting of character > * flags can also be supplied (see process_flags below). > */ > method replace(regex=String, replacement=String,- > strglobal=Rexx'F', strflags=String'') binary returns Rexx > global = boolean > select case strglobal.optioncheck(Rexx 'FG') > when 'F' then global = 0 -- "first match only" > when 'G' then global = 1 -- "globally" > end > me = this.toString() > flags = pattern_flags(strflags) > matcher = Pattern.compile(regex, flags).matcher(me) > buffer = StringBuffer() > if global then return matcher.replaceAll(replacement) > if \matcher.find() then return me > matcher.appendReplacement(buffer, replacement) > matcher.appendTail(buffer) > return buffer.toString() > > method pattern_flags(str=String) binary static private returns int > u = str.toUpperCase() > acc = int 0 > loop i=0 for u.length() > c = u.charAt(i) > select case c > when '=' then f = Pattern.CANON_EQ > when 'I' then f = Pattern.CASE_INSENSITIVE > when 'C' then f = Pattern.COMMENTS > when '.' then f = Pattern.DOTALL > when 'L' then f = Pattern.LITERAL > when 'M' then f = Pattern.MULTILINE > when 'X' then f = Pattern.UNICODE_CASE > when 'U' then f = Pattern.UNIX_LINES > otherwise f = 0 > end > acc = acc | f > end > return acc > --8<-------------------------------------------------------------------- > > While Java provides String#replaceAll, String#replaceFirst and > String#matches, these methods don't allow for flag specification; the > above therefore leverages Pattern explicitly. > > In keeping with Rexx style, a character flag is used to specify global > replacement; the default is substitution for the first match. If this > is deemed confusing, 'replaceFirst' and 'replaceAll' methods could be > defined to set the flag explicitly. > > Simple example of usage, > > --( re.nrx: proposed regex methods for NetRexx strings )---------------- > input1 = "A hello world" > input2 = "qqqqqq" > input3 = "AAA" > rx1 = "(.*?)([aeiou])(.*?)" -- non-greedy > rpl = "$1V$3" -- replacement string > > say > say "Replacing all matches with the string '"rpl"'" > say "input1:" input1 > say "input2:" input2 > say "input3:" input3 > say > > i1a = input1.replace(rx1, rpl) -- first only > i1b = input1.replace(rx1, rpl, 'G') -- global replacement > i1c = input1.replace(rx1, rpl, 'F', 'I') -- first, ignore case > i1d = input1.replace(rx1, rpl, 'G', 'i') -- global, ignore case > i2a = input2.replace(rx1, rpl) > i2b = input2.replace(rx1, rpl, 'G') > > say "input1 matches rx1?" y_or_n(input1.matches(rx1)) > say > say "input1: first only: " i1a > say "input1: globally: " i1b > say "input1: first only, ignore case: " i1c > say "input1: globally, ignore case: " i1d > say > say "input2 matches rx1?" y_or_n(input2.matches(rx1)) > say > say "input2: first only: " i2a > say "input2: globally: " i2b > say > say "input3 matches rx1?" y_or_n(input3.matches(rx1)) > say "input3 matches rx1 (ignore case)?" y_or_n(input3.matches(rx1, 'I')) > > method y_or_n(flag) static > if flag then return "yes" > return "no" > --( re.nrx END )-------------------------------------------------------- > > Output, > > --8<-------------------------------------------------------------------- > # nrc -run re > NetRexx portable processor, version NetRexx 3.01RC3, build 80-20120125-1019 > Copyright (c) RexxLA, 2011. All rights reserved. > Parts Copyright (c) IBM Corporation, 1995,2008. > Program re.nrx > function y_or_n(Rexx) > Compilation of 're.nrx' successful > Running re... > > Replacing all matches with the string '$1V$3' > input1: A hello world > input2: qqqqqq > input3: AAA > > input1 matches rx1? yes > > input1: first only: A hVllo world > input1: globally: A hVllV wVrld > input1: first only, ignore case: V hello world > input1: globally, ignore case: V hVllV wVrld > > input2 matches rx1? no > > input2: first only: qqqqqq > input2: globally: qqqqqq > > input3 matches rx1? no > input3 matches rx1 (ignore case)? yes > --8<-------------------------------------------------------------------- > > Obviously this approach could also be implemented non-invasively > (i.e., without modifying core translator classes) should the above be > considered too dramatic a change. > > Best, > M > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: Regular expression built-in proposal
|
|
On 1/25/2012 11:04 AM, Kermit Kiser wrote:
> > I suggest that any NetRexx efforts be coordinated with the general > Rexx project And, as someone has already pointed out, since Java 1.4 regular expressions have been part of the library (java.util.regex). It seems to me that this is yet another wheel that needs no reinventing. Tom. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: Regular expression built-in proposal
|
|
On Wed, Jan 25, 2012 at 8:12 PM, Tom Maynard <[hidden email]> wrote:
> On 1/25/2012 11:04 AM, Kermit Kiser wrote: >> I suggest that any NetRexx efforts be coordinated with the general Rexx >> project > > And, as someone has already pointed out, since Java 1.4 regular expressions > have been part of the library (java.util.regex). Â It seems to me that this > is yet another wheel that needs no reinventing. I didn't propose the 'reinvention' of regular expressions, rather that some convenience methods (builtins) be provided so that matching and substitution are cleaner when dealing with NetRexx strings. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Providing convenience methods to allow easy access to Java tools (as
fugly as some of them are) is a good thing, imho, which should not require coordination with the ooRexx RegEx effort. I'm not averse to enhancing Parse with a robust pattern recognition capability having the power of GRE's, but that's 'way down the priority list. However, one would be hard-pressed to identify a less Rexx-ish tool than grep, so designing a true "RexxGrep" ain't gonna be easy. -Chip- On 1/25/12 20:20 Marc Simpson said: > On Wed, Jan 25, 2012 at 8:12 PM, Tom Maynard <[hidden email]> wrote: >> On 1/25/2012 11:04 AM, Kermit Kiser wrote: >>> I suggest that any NetRexx efforts be coordinated with the general Rexx >>> project >> And, as someone has already pointed out, since Java 1.4 regular expressions >> have been part of the library (java.util.regex). It seems to me that this >> is yet another wheel that needs no reinventing. > > I didn't propose the 'reinvention' of regular expressions, rather that > some convenience methods (builtins) be provided so that matching and > substitution are cleaner when dealing with NetRexx strings. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Parse...yes, I had to code in java again today and I kept wishing for parse.
So what is the "word" that best describes what Marc suggests ? And is Negative Lookahead something from regex or the Obama administration. ________________________________________ From: [hidden email] [[hidden email]] on behalf of Chip Davis [[hidden email]] Sent: Wednesday, January 25, 2012 6:57 PM To: IBM Netrexx Subject: Re: [Ibm-netrexx] Regular expression built-in proposal Providing convenience methods to allow easy access to Java tools (as fugly as some of them are) is a good thing, imho, which should not require coordination with the ooRexx RegEx effort. I'm not averse to enhancing Parse with a robust pattern recognition capability having the power of GRE's, but that's 'way down the priority list. However, one would be hard-pressed to identify a less Rexx-ish tool than grep, so designing a true "RexxGrep" ain't gonna be easy. -Chip- On 1/25/12 20:20 Marc Simpson said: > On Wed, Jan 25, 2012 at 8:12 PM, Tom Maynard <[hidden email]> wrote: >> On 1/25/2012 11:04 AM, Kermit Kiser wrote: >>> I suggest that any NetRexx efforts be coordinated with the general Rexx >>> project >> And, as someone has already pointed out, since Java 1.4 regular expressions >> have been part of the library (java.util.regex). It seems to me that this >> is yet another wheel that needs no reinventing. > > I didn't propose the 'reinvention' of regular expressions, rather that > some convenience methods (builtins) be provided so that matching and > substitution are cleaner when dealing with NetRexx strings. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: Regular expression built-in proposal
|
|
Regular expressions strike me as profoundly anti-NetRexx. They cannot by any stretch be called 'human oriented' -- it is too easy to write patterns one cannot reliably fathom. They are not even 'regular expressions' in the sense of being the set of symbol strings recognized by Finite State Automata -- they contain that set but extend it with a mass of ad hoc encrustations. The result is the the kind of monstrous trickiness so beloved of the `nix axis.
I would like to see some extension of the thinking behind Parse that would achieve the same results possible with grep, but in a way comprehensible to mortals. On Wed, Jan 25, 2012 at 7:55 PM, Measel, Mike <[hidden email]> wrote: Parse...yes, I had to code in java again today and I kept wishing for parse. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by measel
Are you thinking of NetRexx "wrappers" for Java methods?
Given the preponderance of unintended consequences resulting from legislation these days, I submit that "negative lookahead" is the salient skill of our primary sausage factory, Congress. :-/ -Chip- On 1/26/12 00:55 Measel, Mike said: > Parse...yes, I had to code in java again today and I kept wishing for parse. > > So what is the "word" that best describes what Marc suggests ? > > And is Negative Lookahead something from regex or the Obama administration. > ________________________________________ > From: [hidden email] [[hidden email]] on behalf of Chip Davis [[hidden email]] > Sent: Wednesday, January 25, 2012 6:57 PM > To: IBM Netrexx > Subject: Re: [Ibm-netrexx] Regular expression built-in proposal > > Providing convenience methods to allow easy access to Java tools (as > fugly as some of them are) is a good thing, imho, which should not > require coordination with the ooRexx RegEx effort. > > I'm not averse to enhancing Parse with a robust pattern recognition > capability having the power of GRE's, but that's 'way down the > priority list. However, one would be hard-pressed to identify a less > Rexx-ish tool than grep, so designing a true "RexxGrep" ain't gonna be > easy. > > -Chip- > > On 1/25/12 20:20 Marc Simpson said: >> On Wed, Jan 25, 2012 at 8:12 PM, Tom Maynard <[hidden email]> wrote: >>> On 1/25/2012 11:04 AM, Kermit Kiser wrote: >>>> I suggest that any NetRexx efforts be coordinated with the general Rexx >>>> project >>> And, as someone has already pointed out, since Java 1.4 regular expressions >>> have been part of the library (java.util.regex). It seems to me that this >>> is yet another wheel that needs no reinventing. >> I didn't propose the 'reinvention' of regular expressions, rather that >> some convenience methods (builtins) be provided so that matching and >> substitution are cleaner when dealing with NetRexx strings. > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: Regular expression built-in proposal
|
|
In reply to this post by George Hovey-2
On Wed, Jan 25, 2012 at 22:56, George Hovey <[hidden email]> wrote:
> Regular expressions strike me as profoundly anti-NetRexx. They cannot by > any stretch be called 'human oriented' -- it is too easy to write patterns > one cannot reliably fathom. +1+1+1+1+1+1+1 :) FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act - George Orwell _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
RegRexx, call for feedback/input ! (Re: [Ibm-netrexx] Regular expression built-in proposal
|
|
On 26.01.2012 03:57, Fernando Cassia wrote: > On Wed, Jan 25, 2012 at 22:56, George Hovey <[hidden email]> wrote: >> Regular expressions strike me as profoundly anti-NetRexx. They cannot by >> any stretch be called 'human oriented' -- it is too easy to write patterns >> one cannot reliably fathom. > +1+1+1+1+1+1+1 :) Then, maybe, you should turn to the archives of the RegRexx-mailing lists, where a few initial information and sketches are given (read sequentially from oldest to newest). Here is once more the URL that Kermit gave: <http://rice.safedataisp.net/mailman/listinfo/regrexx>. You may also want to subscribe and add your POVs to what has been layed out so far (positive, negative, ideas for improvements etc.). If enough interest gets generated, we may arrive at least at a specification of what a human-centric pattern matching for searching and/or replacing should look like for the Rexx dialects of languages! (This could then serve as the basis for discussions in the ARB and for implementation.) ---rony _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
In reply to this post by measel
Hello Marc, Chip, and all,
I'm just in progress to upload my (written in NetRexx) Tokenizer (Scanner) and Parser to org.netrexx.thsitc.pp.in When some body's would help me to *document* that whole stuff (by open source available, NetRexx Source Code, deployed under the ICU Licence) ... You would be more than welcome. I'm running here in Vienna, personally, out of time, at this minute ... But I'm ready to ZIP my whole source, for an Alpha release of what's coming up: org.netrexx.thsitc.xxxxx.yyyyy Sorry to say, I did have *no time* the past to weeks to *work at all*, as my physical Father, Dr. Kurt Schneider, did die 2 weeks ago, and we did have much to do within the Family to prepare the funeral etc. Thomas Schneider. ======================================================================================== As my Father, Dr. Kurt Schneider, did also invest a lot of his money in my always so curious projects, he will be happy (in Heaven) to see that I'm NOT alone on this earth ;-) ======================================================================================== Am 26.01.2012 01:55, schrieb Measel, Mike: > Parse...yes, I had to code in java again today and I kept wishing for parse. > > So what is the "word" that best describes what Marc suggests ? > > And is Negative Lookahead something from regex or the Obama administration. > ________________________________________ > From: [hidden email] [[hidden email]] on behalf of Chip Davis [[hidden email]] > Sent: Wednesday, January 25, 2012 6:57 PM > To: IBM Netrexx > Subject: Re: [Ibm-netrexx] Regular expression built-in proposal > > Providing convenience methods to allow easy access to Java tools (as > fugly as some of them are) is a good thing, imho, which should not > require coordination with the ooRexx RegEx effort. > > I'm not averse to enhancing Parse with a robust pattern recognition > capability having the power of GRE's, but that's 'way down the > priority list. However, one would be hard-pressed to identify a less > Rexx-ish tool than grep, so designing a true "RexxGrep" ain't gonna be > easy. > > -Chip- > > On 1/25/12 20:20 Marc Simpson said: >> On Wed, Jan 25, 2012 at 8:12 PM, Tom Maynard<[hidden email]> wrote: >>> On 1/25/2012 11:04 AM, Kermit Kiser wrote: >>>> I suggest that any NetRexx efforts be coordinated with the general Rexx >>>> project >>> And, as someone has already pointed out, since Java 1.4 regular expressions >>> have been part of the library (java.util.regex). It seems to me that this >>> is yet another wheel that needs no reinventing. >> I didn't propose the 'reinvention' of regular expressions, rather that >> some convenience methods (builtins) be provided so that matching and >> substitution are cleaner when dealing with NetRexx strings. > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > -- Thomas Schneider (Founder of www.thsitc.com) Member of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx Developer's Team (www.netrexx.org) _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
|
|
In reply to this post by Aviatrexx
No, not wappers, a verb(s) that describe with parameters that are easy.
If I called you on the phone, I wouldn't say look?\under.*couch.*keys. ------------------------------------------------------------------------ Coincidentally, I had to write an addition to an existing nrx program last week to search directories using a regex supplied by the user. The hard part is explaining to the user how to specify with the regex. /* making fun of my code is verboten */ /* rxFilter.nrx */ import java.util.regex class rxFilter implements FilenameFilter rexpression = String method rxFilter(exp=String) this.rexpression = exp --say ' File filter :' exp method accept(logDir=File, name=String) public returns boolean if Pattern.matches(rexpression, name) then return 1 else return 0 ====================================================== /* then from the main program - this is actually a runnable class that can call itself to "dig deeper" */ method filedigger(gcwArg = GCW16M, logDirNameArg = Rexx) gcw = gcwArg logDirName = logDirNameArg method run ct = Thread.currentThread() --say 'digging ' logDirName logDir = File(logDirName) sepr = logDir.separator logFilter = rxFilter(gcw.logFilterArg) -- set the filter with an arugment like .*PN0[1,3].*stderr.* if (\logDir.isDirectory) then do if (\logDir.isFile) then do say '===================' say ' File/Directory not found : ' logDirName say '===================' return end end if logDir.isFile then do say ct ' Processing single file ======>' logDirName -- its a file not a directory so lets process it watcher = GCWatchIBM16(logDirName,logDirName,gcw.prtWrt) Thread(watcher).start() end -- oh must be a directory else do say ct ' Processing Directory ---' logDirName -- determine the names and feed to new threads dirList = logDir.list(logFilter) -- first check for filter match if dirList.length = 0 then do --say 'No files found matching filter in ' logDirName ' - digging deeper' dirList = logDir.list() if dirList.length = 0 then return -- bottom loop n = 0 to (dirList.length - 1) logFileName = dirList[n] --say logFileName logFileHandle = File(logDirName||sepr||logFileName) if (logFileHandle.isDirectory) then do --say 'Found directory - calling digit on ' logFileName logFileName = logDirName||sepr||logFileName digIt = filedigger(gcw,logFileName) Thread(digit).start() end end end else -- process filter match do loop n = 0 to (dirList.length -1) logFileName = dirList[n] watcher = GCWatchIBM16(logFileName,logDirName,gcw.prtWrt) Thread(watcher,n).start() end return end end -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Chip Davis Sent: Wednesday, January 25, 2012 8:30 PM To: IBM Netrexx Subject: Re: [Ibm-netrexx] Regular expression built-in proposal Are you thinking of NetRexx "wrappers" for Java methods? Given the preponderance of unintended consequences resulting from legislation these days, I submit that "negative lookahead" is the salient skill of our primary sausage factory, Congress. :-/ -Chip- On 1/26/12 00:55 Measel, Mike said: > Parse...yes, I had to code in java again today and I kept wishing for parse. > > So what is the "word" that best describes what Marc suggests ? > > And is Negative Lookahead something from regex or the Obama administration. > ________________________________________ > From: [hidden email] [[hidden email]] on behalf of Chip Davis [[hidden email]] > Sent: Wednesday, January 25, 2012 6:57 PM > To: IBM Netrexx > Subject: Re: [Ibm-netrexx] Regular expression built-in proposal > > Providing convenience methods to allow easy access to Java tools (as > fugly as some of them are) is a good thing, imho, which should not > require coordination with the ooRexx RegEx effort. > > I'm not averse to enhancing Parse with a robust pattern recognition > capability having the power of GRE's, but that's 'way down the > priority list. However, one would be hard-pressed to identify a less > Rexx-ish tool than grep, so designing a true "RexxGrep" ain't gonna be > easy. > > -Chip- > > On 1/25/12 20:20 Marc Simpson said: >> On Wed, Jan 25, 2012 at 8:12 PM, Tom Maynard <[hidden email]> wrote: >>> On 1/25/2012 11:04 AM, Kermit Kiser wrote: >>>> I suggest that any NetRexx efforts be coordinated with the general Rexx >>>> project >>> And, as someone has already pointed out, since Java 1.4 regular expressions >>> have been part of the library (java.util.regex). It seems to me that this >>> is yet another wheel that needs no reinventing. >> I didn't propose the 'reinvention' of regular expressions, rather that >> some convenience methods (builtins) be provided so that matching and >> substitution are cleaner when dealing with NetRexx strings. > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: Regular expression built-in proposal
|
|
In reply to this post by ThSITC
You have my condolences, Tom.
DR Robert L Hamilton, Engineer Richardson Texas USA On Thu, Jan 26, 2012 at 6:56 AM, Thomas Schneider <[hidden email]> wrote: Hello Marc, Chip, and all, _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by measel
Sucks, I thought that would be some executabe code, but apparently some of it is missing. Can you post the rest?
No, not wappers, a verb(s) that describe with parameters that are easy. If I called you on the phone, I wouldn't say look?\under.*couch.*keys. ------------------------------------------------------------------------ Coincidentally, I had to write an addition to an existing nrx program last week to search directories using a regex supplied by the user. The hard part is explaining to the user how to specify with the regex. /* making fun of my code is verboten */ /* rxFilter.nrx */ import java.util.regex class rxFilter implements FilenameFilter rexpression = String method rxFilter(exp=String) this.rexpression = exp --say ' File filter :' exp method accept(logDir=File, name=String) public returns boolean if Pattern.matches(rexpression, name) then return 1 else return 0 ====================================================== /* then from the main program - this is actually a runnable class that can call itself to "dig deeper" */ method filedigger(gcwArg = GCW16M, logDirNameArg = Rexx) gcw = gcwArg logDirName = logDirNameArg method run ct = Thread.currentThread() --say 'digging ' logDirName logDir = File(logDirName) sepr = logDir.separator logFilter = rxFilter(gcw.logFilterArg) -- set the filter with an arugment like .*PN0[1,3].*stderr.* if (\logDir.isDirectory) then do if (\logDir.isFile) then do say '===================' say ' File/Directory not found : ' logDirName say '===================' return end end if logDir.isFile then do say ct ' Processing single file ======>' logDirName -- its a file not a directory so lets process it watcher = GCWatchIBM16(logDirName,logDirName,gcw.prtWrt) Thread(watcher).start() end -- oh must be a directory else do say ct ' Processing Directory ---' logDirName -- determine the names and feed to new threads dirList = logDir.list(logFilter) -- first check for filter match if dirList.length = 0 then do --say 'No files found matching filter in ' logDirName ' - digging deeper' dirList = logDir.list() if dirList.length = 0 then return -- bottom loop n = 0 to (dirList.length - 1) logFileName = dirList[n] --say logFileName logFileHandle = File(logDirName||sepr||logFileName) if (logFileHandle.isDirectory) then do --say 'Found directory - calling digit on ' logFileName logFileName = logDirName||sepr||logFileName digIt = filedigger(gcw,logFileName) Thread(digit).start() end end end else -- process filter match do loop n = 0 to (dirList.length -1) logFileName = dirList[n] watcher = GCWatchIBM16(logFileName,logDirName,gcw.prtWrt) Thread(watcher,n).start() end return end end -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Chip Davis Sent: Wednesday, January 25, 2012 8:30 PM To: IBM Netrexx Subject: Re: [Ibm-netrexx] Regular expression built-in proposal Are you thinking of NetRexx "wrappers" for Java methods? Given the preponderance of unintended consequences resulting from legislation these days, I submit that "negative lookahead" is the salient skill of our primary sausage factory, Congress. :-/ -Chip- On 1/26/12 00:55 Measel, Mike said: > Parse...yes, I had to code in java again today and I kept wishing for parse. > > So what is the "word" that best describes what Marc suggests ? > > And is Negative Lookahead something from regex or the Obama administration. > ________________________________________ > From: [hidden email] [[hidden email]] on behalf of Chip Davis [[hidden email]] > Sent: Wednesday, January 25, 2012 6:57 PM > To: IBM Netrexx > Subject: Re: [Ibm-netrexx] Regular expression built-in proposal > > Providing convenience methods to allow easy access to Java tools (as > fugly as some of them are) is a good thing, imho, which should not > require coordination with the ooRexx RegEx effort. > > I'm not averse to enhancing Parse with a robust pattern recognition > capability having the power of GRE's, but that's 'way down the > priority list. However, one would be hard-pressed to identify a less > Rexx-ish tool than grep, so designing a true "RexxGrep" ain't gonna be > easy. > > -Chip- > > On 1/25/12 20:20 Marc Simpson said: >> On Wed, Jan 25, 2012 at 8:12 PM, Tom Maynard <[hidden email]> wrote: >>> On 1/25/2012 11:04 AM, Kermit Kiser wrote: >>>> I suggest that any NetRexx efforts be coordinated with the general Rexx >>>> project >>> And, as someone has already pointed out, since Java 1.4 regular expressions >>> have been part of the library (java.util.regex). It seems to me that this >>> is yet another wheel that needs no reinventing. >> I didn't propose the 'reinvention' of regular expressions, rather that >> some convenience methods (builtins) be provided so that matching and >> substitution are cleaner when dealing with NetRexx strings. > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
I didn't mean to sound so rude, sorry. I was going for a light-hearted aw-shucks. It would be nice to see a working example of that code.
Sucks, I thought that would be some executabe code, but apparently some of it is missing. Can you post the rest?
No, not wappers, a verb(s) that describe with parameters that are easy. If I called you on the phone, I wouldn't say look?\under.*couch.*keys. ------------------------------------------------------------------------ Coincidentally, I had to write an addition to an existing nrx program last week to search directories using a regex supplied by the user. The hard part is explaining to the user how to specify with the regex. /* making fun of my code is verboten */ /* rxFilter.nrx */ import java.util.regex class rxFilter implements FilenameFilter rexpression = String method rxFilter(exp=String) this.rexpression = exp --say ' File filter :' exp method accept(logDir=File, name=String) public returns boolean if Pattern.matches(rexpression, name) then return 1 else return 0 ====================================================== /* then from the main program - this is actually a runnable class that can call itself to "dig deeper" */ method filedigger(gcwArg = GCW16M, logDirNameArg = Rexx) gcw = gcwArg logDirName = logDirNameArg method run ct = Thread.currentThread() --say 'digging ' logDirName logDir = File(logDirName) sepr = logDir.separator logFilter = rxFilter(gcw.logFilterArg) -- set the filter with an arugment like .*PN0[1,3].*stderr.* if (\logDir.isDirectory) then do if (\logDir.isFile) then do say '===================' say ' File/Directory not found : ' logDirName say '===================' return end end if logDir.isFile then do say ct ' Processing single file ======>' logDirName -- its a file not a directory so lets process it watcher = GCWatchIBM16(logDirName,logDirName,gcw.prtWrt) Thread(watcher).start() end -- oh must be a directory else do say ct ' Processing Directory ---' logDirName -- determine the names and feed to new threads dirList = logDir.list(logFilter) -- first check for filter match if dirList.length = 0 then do --say 'No files found matching filter in ' logDirName ' - digging deeper' dirList = logDir.list() if dirList.length = 0 then return -- bottom loop n = 0 to (dirList.length - 1) logFileName = dirList[n] --say logFileName logFileHandle = File(logDirName||sepr||logFileName) if (logFileHandle.isDirectory) then do --say 'Found directory - calling digit on ' logFileName logFileName = logDirName||sepr||logFileName digIt = filedigger(gcw,logFileName) Thread(digit).start() end end end else -- process filter match do loop n = 0 to (dirList.length -1) logFileName = dirList[n] watcher = GCWatchIBM16(logFileName,logDirName,gcw.prtWrt) Thread(watcher,n).start() end return end end -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Chip Davis Sent: Wednesday, January 25, 2012 8:30 PM To: IBM Netrexx Subject: Re: [Ibm-netrexx] Regular expression built-in proposal Are you thinking of NetRexx "wrappers" for Java methods? Given the preponderance of unintended consequences resulting from legislation these days, I submit that "negative lookahead" is the salient skill of our primary sausage factory, Congress. :-/ -Chip- On 1/26/12 00:55 Measel, Mike said: > Parse...yes, I had to code in java again today and I kept wishing for parse. > > So what is the "word" that best describes what Marc suggests ? > > And is Negative Lookahead something from regex or the Obama administration. > ________________________________________ > From: [hidden email] [[hidden email]] on behalf of Chip Davis [[hidden email]] > Sent: Wednesday, January 25, 2012 6:57 PM > To: IBM Netrexx > Subject: Re: [Ibm-netrexx] Regular expression built-in proposal > > Providing convenience methods to allow easy access to Java tools (as > fugly as some of them are) is a good thing, imho, which should not > require coordination with the ooRexx RegEx effort. > > I'm not averse to enhancing Parse with a robust pattern recognition > capability having the power of GRE's, but that's 'way down the > priority list. However, one would be hard-pressed to identify a less > Rexx-ish tool than grep, so designing a true "RexxGrep" ain't gonna be > easy. > > -Chip- > > On 1/25/12 20:20 Marc Simpson said: >> On Wed, Jan 25, 2012 at 8:12 PM, Tom Maynard <[hidden email]> wrote: >>> On 1/25/2012 11:04 AM, Kermit Kiser wrote: >>>> I suggest that any NetRexx efforts be coordinated with the general Rexx >>>> project >>> And, as someone has already pointed out, since Java 1.4 regular expressions >>> have been part of the library (java.util.regex). It seems to me that this >>> is yet another wheel that needs no reinventing. >> I didn't propose the 'reinvention' of regular expressions, rather that >> some convenience methods (builtins) be provided so that matching and >> substitution are cleaner when dealing with NetRexx strings. > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |