@tin.it

at least the current OS/2 implementation...

according to the object REXX reference something like 'b2.' is a valid
stem name, but object REXX sometimes does not like it:

----------8<-------- cut here ---------------8<----------
/* test1.cmd : in this sample script SysStemCopy() returns -1 */

a.0 = 3
a.1 = "one"
a.2 = "two"
a.3 = "three"

b2. = retstem();

say SysStemCopy(b2., a., 1, a.0 + 1, b2.0, "I");

exit

/* test procedure returning a stem object */
retstem: procedure
c.0 = 3
c.1 = "111"
c.2 = "222"
c.3 = "333"
return c.
/* end of test1.cmd */
----------8<-------- cut here ---------------8<----------
/* test2.cmd : a reference to the b2. stem has been added and
SysStemCopy() now returns 0 */

a.0 = 3
a.1 = "one"
a.2 = "two"
a.3 = "three"

b2. = retstem();

c. = b2. /* c. is never used but it makes the next call succesful */

say SysStemCopy(b2., a., 1, a.0 + 1, b2.0, "I");

exit

/* test procedure returning a stem object */
retstem: procedure
c.0 = 3
c.1 = "111"
c.2 = "222"
c.3 = "333"
return c.
----------8<-------- cut here ---------------8<----------

--
bye
Alessandro

steven levine

In <2nqHEJzxPnOO092yn@tin.it>, on 03/20/2006
at 02:11 PM, @tin.it (Alessandro) said:

This is not a OREXX issue. This is a typical REXX coding error. If you
want to pass a constant string to function, you need to quote the
expression to prevent unexpected side effects that can occur if you let
REXX evaluate the string as an expression.

Add the following to test1.cmd

say 'b2.' b2.
say 'a.' a.

say SysStemCopy('b2', 'a', 1, A.0 + 1, b2.0, "I")

Note the trailing periods are not part of the stem name so I omit them to
avoid false assumptions.

I haven't checked to be sure, but I'm reasonably sure that your code would
have run in Classic REXX because the valude of b2. would have been 'B2.'
However, someone running Classic REXX needs to check this to be sure.

Regards,

Steven -- --------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net> MR2/ICE 2.67 #10183
Warp/eCS/DIY/14.103a_W4 http://www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

@tin.it

what constant string ??? I'm passing a stem object not a string !

OK! I had another look at the do***entation of SysStemObject and
realized that you are right...

BTW during the last few months, in my spare time, I've been reading
do***entation about many different scripting languages (java, python,
ruby, ici, lua, pike, etc...)
I hardly found a language as inconsistent and poorly designed as REXX

Yes you can do everything with REXX, even non trivial programs, but
even C will be easier in that case...

--
bye
Alessandro

bob eager

Then you haven't looked at Perl!

REXX isn't inconsistent - you just haven't absorbed the model yet!

paul ratcliffe

Whatever, but it is very difficult to predict what REXX is going to do,
which makes coding very unpredicatable and error prone.
A classic example of this is eCSMT - that thing has more bugs in it than
anything I've come across and most of those are because it is written in
REXX. The same old bugs over and over and over again.
Perhaps it is just poor do***entation which lets it down. It is very
powerful, but incredibly difficult to catch all the logic holes in anything
non-trivial.

steven levine

In <3X4HEJzxPjWa092yn@tin.it>, on 03/21/2006
at 05:49 AM, @tin.it (Alessandro) said:


Correct. You are passing the name of the stem as a string. Just keep in
mind that the REXX DLL API interface was never updated to support objects.
It's hard to pass something the API does not understand. Also, you
probably should re-read the definition of stems so you understand what
"stem." means.

There are aspects of REXX syntax I find annoying, but is entirely
consistent. The design is OK, but in general I prefer languages that help
the programmer not make obvious mistakes.

Steven

--
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net> MR2/ICE 2.67 #10183
Warp/eCS/DIY/14.103a_W4 http://www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

steven levine

In <slrne20imt.u1v.abuse@news.pr.network>, on 03/21/2006
at 06:50 PM, Paul Ratcliffe <abuse@orac12.clara34.co56.uk78> said:


IMO, the problem is that, by default, REXX ignores most errors. This is
OK if you are a perfect programmer. I'm far from that good. What I do is
start every REXX program I write with

signal on Error
signal on FAILURE name Error
signal on Halt
signal on NOTREADY name Error
signal on NOVALUE name Error
signal on SYNTAX name Error

which brings the base error checking up to something reasonable. Running
OREXX helps too because it catches the syntax errors sooner rather than
later.

The Classic REXX manual that IBM delivers with OS/2 is limited. There are
plenty of good REXX references available.

FWIW, I don't believe REXX should be used for large applications. Of
course, folks use what they know, so there are plenty of large


If one must write a large application in REXX, it should be designed a a
set of small REXX programs that work together. These should be small
enough so that they can be realistically validated with a reasonable
amount of effort.

Steven -- --------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net> MR2/ICE 2.67 #10183
Warp/eCS/DIY/14.103a_W4 http://www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

dave saville

<snip>


AIUI REXX was designed to make the REXX programmers task easy. That made
writing the interpreter hard - but you only do that once :-)

C on the other hand was designed to make writing the compiler easy and sod the
poor programmer.

--

Regards

Dave Saville

NB Remove -nospam for good email address

alex taylor

OTOH, one advantage of C is that, since it leaves so much up to the
programmer, the language itself is quite small and consistent. This means
that when you have a bug, you can usually be pretty sure it's something
you're doing wrong (which makes debugging a simple matter of legwork),
instead of something sneaky the compiler or interpreter is doing that
you didn't expect. Most of the time, anyway.

--
Alex Taylor
http://www.cs-club.org/~alex

Remove hat to reply (reply-to address).

bob eager

Taking that to its logical solution, they should have stuck with C's
predecessor's (B) predecessor (BCPL)....