Reserved Words in REXX/Object REXX/NetRexx.

Reserved Words in REXX/Object REXX/NetRexx.

Post by Thomas.Sch » Thu, 13 Nov 2003 01:14:03


Hello there,
I do wonder more and more about the underlying concepts of 'NO
reserved Verbs' in the various REXX dialects:

Example 1: (Object REXX)
==========

::class xx
::method yy
call abc(13)
abc:
parse arg v
return(v)

::method return
use arg p
return p

In the example avove, is 'return(v)' a reference to the method
'return'
defined below ar an execition of the RETURN verb with the expression
parameter (v). Note that 'return(v)' has NO BLANK verfore the opening
parenthesis, and as such would be a function reference (or what ?).

Example 2: NetRexx/Object Rexx:
===============================
class abcdef
method init

xx='ABC'
xx[1] = 2
xx[2] = 3
xx[3] = 4

display_range(3,4) /* invokes (calls) method display_range */
exit

method display_range(from,to)

loop ii=from to to
display xx[ii]
end

Example 3: All REXX languages:
==============================

if abc='def' do /* note the missing THEN */
x=3
end

Shouldn't be the first line recognized as an error ?? (missing 'THEN'
?)

Example 4:
==========
x=3; to=14; else=15; options=12345; digits=funny

if then = 3 then do = 14; else do 13
say do

Tom.
 
 
 

Reserved Words in REXX/Object REXX/NetRexx.

Post by imc » Thu, 13 Nov 2003 02:46:22

Probably Thomas Schneider typed into a real computer:

I'm answering with respect to the ANSI standard, which probably governs
how Classic and Object Rexx both behave with regard to keywords.
NetRexx has a different rule, which I believe states that any word
will behave as a keyword if possible unless you assign a value to
it, and from then on it will always behave as a variable.




As far as I know, it is a RETURN instruction, not a call to a function.


I believe this is invalid, since in classic Rexx "TO" is reserved within
the repetition-expressions of a DO instruction (while in NetRexx it's
either always a variable or always a keyword and can't act as both
within the same instruction).


Yes it should. (The error will probably be noted on the second line of
this example, since the following is valid syntax:
if abc='def' do
then do
x=3
end
)


"THEN" is reserved within the expression of an IF instruction, so this
is invalid again. However, if you renamed "then" to another name, the
rest of this should be valid.
--
---- Ian Collier : XXXX@XXXXX.COM : WWW page (including REXX section):
------ http://www.yqcomputer.com/

New to this group? Answers to frequently-asked questions can be had from
http://www.yqcomputer.com/

 
 
 

Reserved Words in REXX/Object REXX/NetRexx.

Post by Gunter Thu » Thu, 13 Nov 2003 18:00:06

Thomas Schneider schrieb:


To the first sample:



A keyword instruction is recognized if its keyword is the first token in
a clause. Any clause that starts with a keyword defined by Object REXX
cannot be a command. So:

Say('hello') --> same as: say 'hello'
do(5) --> same as do 5

are keyword instructions, not commands that start with a call to a
function.
And so is

return(v)

which returns v to the caller which is method yy.
BTW.: the function abc is executed twice, as the method does not end
with a return instruction. Method return is not executed. If you want
the method return to be executed you need to run:

self~return -- (where now the keyword is NOT the first token)

To the third sample:

This is right. Object REXX recognizes this as an error:

Error 18 running D:\code\tst2.cmd line 4: THEN expected
Error 18.1: IF instruction on line 3 requires matching THEN clause

To the fourth sample:

Object REXX recognizes this as an error, too.

Error 35 running D:\code\tst1.cmd line 4: Invalid expression
Error 35.902: Missing conditional expression following IF keyword

Gunter
 
 
 

Reserved Words in REXX/Object REXX/NetRexx.

Post by Thomas.Sch » Fri, 14 Nov 2003 05:18:40

Hello there,

... first I do APOLOGIZE for the many SPELLING errors in my initial
message.

But those of you involved in the TOPIC did obviously GET the message.

... Second, I do NOT fully agree so far:


A keyword instruction is recognized if its keyword is the first token
in
a clause. Any clause that starts with a keyword defined by Object REXX
cannot be a command. So:

Say('hello') --> same as: say 'hello'
do(5) --> same as do 5

are keyword instructions, not commands that start with a call to a
function.
<<<<<<

Unfortunately, This is NOT the case (the decision does NOT only depend
on the FIRST token in a CLAUSE, but at least on the second one, in
turn, and unfortunately is NOT dependenT of the VERB in question in
many cases !!!):
==============================================================================

Example 5:
==========

end = 14
do i = 1 to end
call info('thats my message')
end

1.) the 'FIRST token' 'END' after 'DO' is STILL recognized as a
Variable now, due to some magic rules.

2.) but 'end' is now defined BOTH as a 'Variable' and a 'Verb', at
least in my Parser (check your own one to see what happens) .


Hence example 6 is now:
=======================
call example5

do jj= 13 to 51
call info 'my second message')
end = 13 + 54 'or what' /+ which will be 'ABUTTED', as you know,
/* and probably RAISE or SIGNAL a SYNTAX exception (hopefullx) */
/* ::===>>>>note the deliberate 'SPACE' before the 'EQUAL sign !!*/
end again /* and the missing COMMENT before the currently
token 'again') */


should we throw '13 + 54 =='67 or what' to the 'underlying command
Processor'
'OR' report 'end again' as a SYNTAX fault' ??

Also, in the example above:

Is '/+' a SYNTAX error, 'OR '*/' an undefined OPERATOR, or what ??

Example 7:
==========
say 'x=' 123 'y=' 345 z= 14

a very common programmers typing error (forgot to enclose 'z =' in
quotes)

very nice, gives you: x= 123 y=345 0

Do you really expect this from the language in question?

Or should'nt we RESTRICT SAY to TEXT expressions ONLY, to avoid
pitfalls like the one above ????

kind regards, TOM.

PS:

I am now collecting those 'obstructive examples' in a file called
QUIRKS.cmd.

The reasoning is NOT to be 'obstructive', but maybe to get a
better (maybe sometimes MORE Restricted or Intuitive) solution
together.

Will forward QUIRKS.cmd to any parties interested when finished.
(especially those maintaining their OWN Rexx interpreters)

What I really would like to do is to get a proper discussion IF some
of the
ORIGINAL REXX syntax (25 years AGO) should be revisited for easier and
(hopefully) more intuitive usage.

Tom.

Exmaple 8: (both X and Y have NOT yet been used by your 'classic REXX'
prog:
==========

X = Y

(did throw '0' to my CMS machine when either X or Y have NOT yet been
defined)
( .... undefined X becomes 'X' by default, Y = 'Y', and thus 'X' =
'Y' is a
( Comparison in 'classic Rexx', which is '0' of course, and the
CONSOLE
( get's a ZERO (0) (( Operator console))

(( ... did/do we really expect that ??)

Full Stop.
 
 
 

Reserved Words in REXX/Object REXX/NetRexx.

Post by Gunter Thu » Fri, 14 Nov 2003 19:28:26

homas Schneider schrieb:

Too long to answer in detail, but some remarks:

yes, on example 5 (do i = 1 to end) Object REXX expects a variable and
searches for the variable 'end' in its variable pool.

>>> do end again

gives an error(symbol following end must either match control variable
of do specification or be omitted). Thats ok.

>>>say 'x=' 123 'y=' 345 z= 14

returns 0

as Object REXX compares the left part of the '=' sign('x=' 123 'y=' 345
z) with the right one (14), which is not identical.

It may be not intuitive at first sight for you, but thats how it is
implemented and lots of programs rely on that. I do not see any need to
start a discussion about changing or reimplementing the parser of REXX.
There are some hot topics in front of us. Reimplementing the parser is
not part of them.

Gunter


 
 
 

Reserved Words in REXX/Object REXX/NetRexx.

Post by imc » Sat, 15 Nov 2003 03:14:15

homas Schneider < XXXX@XXXXX.COM > told comp.lang.rexx:


The first message was OK, but I found the present message to be rather
eccentric (you do realise that writing random WORDS in CAPITALS is a bit
like writing the whole posting in green crayon?<g>).



We're talking about keyword instructions here. These are the keywords
that belong at the start of an instruction (such as "select" or
"interpret", but not "with" or "source"). Provided the second
token isn't an '=', these keywords will be recognised precisely when
they appear at the beginning of an instruction. Of course there are
additional rules which apply to those other keywords which don't appear
at the beginning of an instruction, but I'm fairly sure the above rule
can be relied upon to be correct.



That's correct. It's not at the beginning of the instruction, so it's
not recognised as a keyword.



The line:
end = 13 + 54 'or what'
is perfectly valid, and will set the value of the "end" variable to
"67 or what". The rest of this program has a few problems.


In "end again", the "end" is a keyword (it's at the start of the
instruction). So this is an error because the word "again" did not
match the control variable on the "do" instruction.



"/+" isn't a syntax error by itself, but that line will be rejected
probably because of the comma in the comment.

Note that you can perfectly validly say: a = 4 / +3 (or a=4 /+ 3).

Similarly, "*/" is possible in the instruction: a = 4 */*comment*/ 3.
In most other places it will be interpreted as a "*" followed by a "/"
which is a syntax error.

By the way, spaces before equals-signs don't count.


Actually it gives you "0".


Umm, no. What's a TEXT expression anyway? How would we write
"do i=1 to 10; say i; end" if we weren't allowed to print numbers?



It can't possibly have done that: you must have made a mistake. This
instruction is an assignment, pure and simple.
--
---- Ian Collier : XXXX@XXXXX.COM : WWW page (including REXX section):
------ http://users.comlab.ox.ac.uk/ian.collier/imc.shtml

New to this group? Answers to frequently-asked questions can be had from
http://rexx.hursley.ibm.com/rexx/ .
 
 
 

Reserved Words in REXX/Object REXX/NetRexx.

Post by Thomas.Sch » Sat, 15 Nov 2003 04:55:27

Hello there,

I do NOT want to raise any unwanted or unnecessary discussions in
this newsgroup.

I therefore propose to close this issue in comp.lang.rexx.
sorry if I raised an issue discussed so many times in the past
already.

If you are interested to discuss the topic in question, please conatct
me by mail at XXXX@XXXXX.COM

issue closed here from my point of view.

Tom (www.Rexx2Nrx.com)