|
View previous topic :: View next topic
|
| Author |
Message |
babuprashad
Warnings : 1
New User
Joined: 09 Aug 2007
Posts: 15
Location: mysore
|
|
|
|
Hi,
we have a requirement to change all the occurences of arithmetic operation in PL1 like var1+var2 or var1-var2 into ADD(var1,var2) or Substract(var1,var2)
we have around 500+ PL1 programs.....  and we should ignore the 1's commented .....
any i/p's to do this in rexx.... |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
the requirement is just laughable
go ahead... where is the issue ?
just curious ...
what about constructs like ... a + b*c ??? |
|
| Back to top |
|
|
babuprashad
Warnings : 1
New User
Joined: 09 Aug 2007
Posts: 15
Location: mysore
|
|
|
|
| Yes...I wanted to first find the number of occurances.......and then start with the conversion.....wanted to know if any one already have a rexx code to find the number of occurances.....or any input's of how to start with this in rexx....(Main set back would be eliminating the +,-,* in the comments as PLI is a freeflow lang.) |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
Yes, what...
result = ADD(a,MULTIPLY(b,c))
also ?
it can be easily done in REXX if You have the skills and the requirement is fully defined
You will simply have to write a small syntactical parser analyzer!
but... explain why?
an intelligent reply please, not the usual ... that' s the requirement  |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1314
Location: Vilnius, Lithuania
|
|
|
|
| babuprashad wrote: |
Hi,
we have a requirement to change all the occurences of arithmetic operation in PL1 like var1+var2 or var1-var2 into ADD(var1,var2) or Substract(var1,var2)
we have around 500+ PL1 programs..... and we should ignore the 1's commented .....
any i/p's to do this in rexx.... |
REXX has excellent parsing qualities, but...
ADD, SUBTRACT, MULTIPLY and DIVIDE all require two (or one for float) additional parameters, giving the precision and scale of the result, and finding these will require you to parse the full source and any possible %INCLUDE members for variable names.
Needlessly to say, the fact that PL/I allows unqualified variables for variables declared in structures and partially qualified names, will make this problem just a tiny bit harder.
However, as Enrico already asked, why would you do this? |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
The construct var1+var2 is very difficult to read for a lot of people.
ADD(var1,var2) or Substract(var1,var2) makes it a lot easier to understand what is happening.
 |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1049
Location: Richmond, Virginia
|
|
|
|
| This has to be way up on the list of stupidest standards in the history of the universe. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
I took a coffee break and here is a snippet that given a correct ( well formed ) expression will produce the asked for format
( that is just a polish notation equivalent)
at the next coffee break I' ll add parentheses and functions support
from a formal ( formal only )parsing point of view an array is parsed like a function call !
here is the snippet ( quick and dirty )
| Code: |
#! /opt/oorexx/bin/rexx
opers = " + - * / ^ "
isvar = 0
isopr = 1
vars.0 = 0
symb.0 = 0
prio.0 = 0
pri1.1 = 3
pri1.2 = 3
pri1.3 = 5
pri1.4 = 5
pri1.5 = 7
expr0 = "134 ** c + d / e + 77 + somevar"
expr = space(expr0,0)
prio = 0
do while expr \= ""
parse value getsym(expr) with type tokn pri1 pri2
select
when type = isvar then do
ivar = vars.0 + 1
vars.ivar = tokn
vars.0 = ivar
next = 1
iterate
end
when type = isopr then do
do while ( pri1 <= prio & symb.0 > 0 )
iop2 = vars.0
iop1 = iop2 - 1
select
when symb.isym = "+" then func = "ADD"
when symb.isym = "-" then func = "SUBTRACT"
when symb.isym = "*" then func = "MULTIPLY"
when symb.isym = "/" then func = "DIVIDE"
when symb.isym = "^" then func = "EXPONENT"
end
/* */
work = func"("vars.iop1","vars.iop2")"
vars.0 = iop1
vars.iop1 = work
isym = isym - 1
symb.0 = isym
indx = wordpos(symb.isym,opers)
prio = pri1.indx
end
isym = symb.0 + 1
symb.isym = tokn
prio.isym = pri1
symb.0 = isym
prio = pri1
next = 1
end
end
end
do while ( symb.0 > 0 )
isym = symb.0
iop2 = vars.0
iop1 = iop2 - 1
select
when symb.isym = "+" then func = "ADD"
when symb.isym = "-" then func = "SUBTRACT"
when symb.isym = "*" then func = "MULTIPLY"
when symb.isym = "/" then func = "DIVIDE"
when symb.isym = "^" then func = "EXPONENT"
end
/* */
work = func"("vars.iop1","vars.iop2")"
vars.0 = iop1
vars.iop1 = work
isym = isym - 1
symb.0 = isym
end
do i = 1 to vars.0
say i vars.i
end
say expr0
exit
getsym:
if left(expr,2) = "**" then do
expr ="^" || substr(expr,3)
end
_oper = left(expr,1)
_indx = wordpos(_oper,opers)
if _indx > 0 then do
expr = substr(expr,2)
_pri1 = pri1._indx
_pri2 = pri2._indx
return isopr _oper _pri1 _pri2
end
_next = verify(expr,"+-*/^","M")
if _next = 0 then do
_tokn = strip(expr)
expr = ""
end
else do
_tokn = left(expr,_next-1)
expr = substr(expr,_next)
end
return isvar _tokn 0 0
return ""
|
the result is
| Code: |
original expression
134 ** c + d / e + 77 + somevar
mangled one
ADD(ADD(ADD(EXPONENT(134,c),DIVIDE(d,e)),77),somevar)
|
we might discuss addition and multiplication associativity left/right ...
really nothing much sophysticated
the parsing has been done applying the simple rules of operator precedence |
|
| Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada
|
|
|
|
| PeterHolland wrote: |
The construct var1+var2 is very difficult to read for a lot of people.
ADD(var1,var2) or Substract(var1,var2) makes it a lot easier to understand what is happening.
|
Maybe what you need are some smarter people.  |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1049
Location: Richmond, Virginia
|
|
|
|
Somehow we lose the beauty of
as
| Code: |
| E = mult(m,square(c)) |
(How do we do superscripts here?) |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| Quote: |
( that is just a polish notation equivalent)
|
Enrico, why are you making life so miserable. Ages ago i had a calculator using polish notation. Sometimes i still have very very bad dreams about that.
By the way did your coffee break start at Wed Feb 16, 2011 6:46 am?
Isnt that a bit overdone? |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
| Quote: |
| Enrico, why are you making life so miserable. |
it wasn' t me... it wasn' t me
apart that real polish notation ( straight/reverse I keep forgetting which is which ) is less ugly
original
134 ** c + d / e + 77 + somevar
mangled one
ADD(ADD(ADD(EXPONENT(134,c),DIVIDE(d,e)),77),somevar)
polish
+++^134,c/d,e,77,somevar
for functions and arrays I will need two coffe breaks
the notation does not fall into the normal operator priority concept...
but I might tweak it considering the comma an operator as is done for the open and close parentheses |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
| Quote: |
| By the way did your coffee break start at Wed Feb 16, 2011 6:46 am? |
Noo!...
While waiting for the coffee to brew, since I had the pc powered on I replied...
after that I went for a 3 hrs walk into a snow blizzard with the snow shoes ..
I got back for lunch , the code was done during the after lunch coffee break  |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1314
Location: Vilnius, Lithuania
|
|
|
|
| enrico-sorichetti wrote: |
I took a coffee break and here is a snippet that given a correct ( well formed ) expression will produce the asked for format
( that is just a polish notation equivalent)
at the next coffee break I' ll add parentheses and functions support
from a formal ( formal only )parsing point of view an array is parsed like a function call !
here is the snippet ( quick and dirty )
the result is
| Code: |
original expression
134 ** c + d / e + 77 + somevar
mangled one
ADD(ADD(ADD(EXPONENT(134,c),DIVIDE(d,e)),77),somevar)
|
we might discuss addition and multiplication associativity left/right ...
really nothing much sophysticated
the parsing has been done applying the simple rules of operator precedence |
Except that the format for the builtins is
| Code: |
| OPER-builtin(var1, var2, precision[,scale]) |
Only two variables!
Precision must be included, scale can be omitted (defaulting to zero) for fixed, and must be omitted for float.
Your code is nice, but needs a lot of additional work to return PL/I syntax. Furthermore, PL/I does not have an EXPONENT builtin that does what you think it does, and the exponentiation operator is '**'... |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
never meant as a final solution... after all it took me just half an hour to do it 
just a proof of concept that it could be done!
( transforming binary operators in calls to functions )
the snippet is not adequate for a real job, I do not even know if it could be classified as a toy!
the parsing should be done properly according to a real representation of PLI grammar not a simple precedence one
all the PL1 source should be scanned
and... and... and
I am not that dumb not to know that the exponentiation operator is **
anyway it is recognized and handled correctly...
the ^ is just a place holder for the correct ** as can be seen in the getsym procedure
I know that the exponent builtin does not exist,
I just mapped some binary ( as opposed to unary ) operators to some arbitary function names
I added the ** to have three different operators priorities instead of just two
cheers
enrico |
|
| Back to top |
|
|
babuprashad
Warnings : 1
New User
Joined: 09 Aug 2007
Posts: 15
Location: mysore
|
|
|
|
@ enrico-sorichetti : Thanks for the code......the actual requirement came to us from a project dept saying they wanted to change the arithmetic operators to verbs and to start with they wanted to analyse the code base and generate a report of programs containing these arithmetic statements(they were checking with us if we had any rexx to do this)...and based on this report they would be getting a go ahead to change the operators....
I am not sure of the purpose behind the requirement(I assume it should be for precision of the o/p and to improve performance  ).
Or maybe like PeterHolland said for understanding purpose.
And regarding constructs like ... a + b*c ??? have not checked with the project team. 
Parsing a cobol is much easier coz of it's fixed column for comment.... |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
that departement approach is ... approximate ( even if a stronger adjective seems appropriate )
the correct approach should disregard the coding in the first instance...
RE-analyze the process, ( they should know what computations are being carried on )
determine it' s computational needs ( precision,, ... )
read carefully the manuals to see the characteristics of the basic math as implemented
read carefully the specs for the builtin functions to see if they satisfy the need
start planning the conversion
meditate also on the alternative of using a specialized high precision library
done as You say they want it done is just a waste of resources ( time, which means money)
anyway the code posted is a proof of concepts only done with a simple and almost useless algorithm
( instead of solving sudoko puzzles I write code snippets for various algorithm )
the approach for the real thing would/should be something very different
why the remark about the comments ?
since You will have to parse the whole program,skipping over comments is the simpler part
( scan for "/*" and start ignoring what follows until the next "*/"
keeping track of the stacking/nesting level )
added some more comments
what kind of computations are they carrying on that they are worried about losing precision on additions and subtractions
( and not on multiplication and division )
looks like there is something fishy going on |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1049
Location: Richmond, Virginia
|
|
|
|
Have you planned your QA processes?
For each program, I presume you have planned suitable unit testing on legitimate representative data. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hi Phil,
If it "clean compiles", is this not enough . . .
d |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
Dick, you're bringing back bad memories .... BAD memories!
I once worked with programmers from another country. One of them told me, in all seriousness, that if her program compiled without errors then it was tested and ready for production. |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1314
Location: Vilnius, Lithuania
|
|
|
|
| Robert Sample wrote: |
Dick, you're bringing back bad memories .... BAD memories!
I once worked with programmers from another country. One of them told me, in all seriousness, that if her program compiled without errors then it was tested and ready for production. |
Here in Belgium I worked at a site where they had no problems putting programs with 'E' errors in production, "because this error has been in the program for eons"... |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1787
Location: Bloomington, IL
|
|
|
|
| prino wrote: |
| Robert Sample wrote: |
Dick, you're bringing back bad memories .... BAD memories!
I once worked with programmers from another country. One of them told me, in all seriousness, that if her program compiled without errors then it was tested and ready for production. |
Here in Belgium I worked at a site where they had no problems putting programs with 'E' errors in production, "because this error has been in the program for eons"... |
And if you correct the error without being specifically told to, that's an unauthorized change to the business rules, and we simply can't have that...  |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1049
Location: Richmond, Virginia
|
|
|
|
I once turned a system over to someone who then proceeded to try to remove every instance of COBOL warnings (RC=4). I think he was OK with the info messages at least.
At another site (a brokerage) I had to repeatedly push to report an obvious COBOL error to the vendor because, since I could not substantiate the ramifications of the error, they would be unlikely to kindly receive the report. From the very nicely indented IF...THEN...ELSE, there was a stray period before the end of ELSE indenting. The compiler very kindly reported this because of the condition checking, the compiler detected dead code. They eventually relented, and the vendor confirmed the error. |
|
| Back to top |
|
|
|
|
