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 var1var2 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 




enricosorichetti
Global Moderator
Joined: 14 Mar 2007 Posts: 10169 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 


enricosorichetti
Global Moderator
Joined: 14 Mar 2007 Posts: 10169 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
Active Member
Joined: 07 Feb 2009 Posts: 974 Location: Oostende, Belgium




babuprashad wrote: 
Hi,
we have a requirement to change all the occurences of arithmetic operation in PL1 like var1+var2 or var1var2 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: 2418 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
Active Member
Joined: 31 Oct 2006 Posts: 959 Location: Richmond, Virginia




This has to be way up on the list of stupidest standards in the history of the universe. 

Back to top 


enricosorichetti
Global Moderator
Joined: 14 Mar 2007 Posts: 10169 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,_next1)
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: 640 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
Active Member
Joined: 31 Oct 2006 Posts: 959 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: 2418 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 


enricosorichetti
Global Moderator
Joined: 14 Mar 2007 Posts: 10169 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 


enricosorichetti
Global Moderator
Joined: 14 Mar 2007 Posts: 10169 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
Active Member
Joined: 07 Feb 2009 Posts: 974 Location: Oostende, Belgium




enricosorichetti 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: 
OPERbuiltin(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 


enricosorichetti
Global Moderator
Joined: 14 Mar 2007 Posts: 10169 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




@ enricosorichetti : 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 


enricosorichetti
Global Moderator
Joined: 14 Mar 2007 Posts: 10169 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...
REanalyze 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
Active Member
Joined: 31 Oct 2006 Posts: 959 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
Site Director
Joined: 23 Nov 2006 Posts: 19270 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: 7869 Location: Bellevue, IA




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 



