[Oorexx-rfes] [ oorexx-Feature Requests-1667085 ] Add a true length operation to parse

[SourceForge.net <no...@so...>]

Feature Requests item #1667085, was opened at 2007-02-23 08:25
Message generated for change (Settings changed) made by bigrixx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684733&aid=1667085&group_id=119701

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interpreter
Group: v3.2.0
>Status: Pending
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Rick McGuire (bigrixx)
Assigned to: David Ashley (wdashley)
Summary: Add a true length operation to parse

Initial Comment:
A template can use a variable relative movement trigger to parse off a length of string within a template.  However, this usage breaks down when the length to extract is zero.  Because the definition of relative movement requires movement to or before the previous match pointer to match the rest of the string, a very unexpected result occurs.  It would be nice if there was a true length movements operation in parse that would function as expected with zero lengths.  For example, 

parse var x len +2 token >(len) 

Would extract the next "len" characters from the string, even if the length in question is zero.  It might also be useful for this operation to go relative to the end of string matches rather than the beginning like the + operation does.  Thus 

parse var x '<' tag >3 

would extract the 3 characters after the position matched by '<'.  As opposed to 

parse var x '<' tag +3 

which would extract 3 characters starting with the first character matched by the string search.  This again addresses a common expectation new parse users have.


A negative length movement might also be useful, if the result reset the position pointer back to the original.  For example, 

parse var x '>' tag <3 would extract 3 characters before the tag match position, and leave the match positions in the same state they were prior to the "<3" trigger. 


----------------------------------------------------------------------

Comment By: Rick McGuire (bigrixx)
Date: 2007-04-02 18:23

Message:
Logged In: YES 
user_id=1125291
Originator: YES

David, this also is going to require some documentation changes.  There
are two new trigger types introduced to parse:

>n (and >(expr)).  Matches the next "n" characters of the string.  The
movement value may be zero, which will result in a null string match.  If
"n" would extend beyond the end of the string, it will be truncated to the
remaining size.  The match position will be moved n characters as well. 

parse value "1234567890" with '3' a >3   -- equivalent to "... with '3' a
+3" 
parse value "1234567890" with '3' a >0   -- assigns a null string to A. 
Not the same as "... with '3' a +0"


<n (and n(expr)).  Matches "n" characters before the current match
position.  If "n" extends past the beginning of the string, the match
string will be truncated to the available size.  After the match, the
current match pointer remains in the same position, so all additional
searchs will proceed from the current match point. 

parse value "1234567890" with '4' a <2 b   -- a == '23', b == '45567890'



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684733&aid=1667085&group_id=119701