Re: FOR op-code

[boldt@xxxxxxxxxx]

Tom wrote:
>Second the idea about %TRIM.

Your wish is my command!  Here's an RPG procedure that implements
an extended trim operation:

 //===============================================================//
 // Procedure:  trimx                                             //
 //---------------------------------------------------------------//
 // Trim specified characters from string.                        //
 //                                                               //
 // Parameters:                                                   //
 //    I: string   - string to trim                               //
 //    I: chars    - list of characters to trim                   //
 //                                                               //
 // Returns:  trimmed string                                      //
 //                                                               //
 //===============================================================//
P trimx           b
D trimx           pi          1000a   varying
D   string                    1000a   const varying
D   chars                      256a   const varying
D start           s             10i 0
 /free
    start = %check(chars:string);
    if start = 0;
       return '';
    endif;
    return %subst(string: start: %checkr(chars:string) - start + 1);
 /end-free
P trimx           e

Just put the prototype into a /copy member, compile the procedure,
and put in into a service program, and you've got your enhancement!
(I'll leave it to you to implement "trimxl()" and "trimxr()".)


>But since we're on the subject of
>wish-lists...

>I wish the FOR op-code did away with the TO/DOWNTO and instead looked at
the
>sign of the BY increment.  There would also have to be a change in the way
>the limit value and the index are compared.
>
>So that I can fill an array 'forwards' or 'backwards', for instance.
This
>seems more 'natural' to me.

Since that might cause existing FOR loops to behave differently,
this isn't going to happen.  With the current syntax, it is clear
exactly which direction the loop interates.

One problem with the proposal is what happens when the sign of
the increment variable changes during the looping?  The limit
test would also change sense, and would likely cause the loop
to exit earlier than expected since the index value would now
be on the other side of the limit value.

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com