× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Phil,

----- Original Message -----
From: "Phil Gregory" <pgregory@hillmgt.com>
To: <RPG400-L@midrange.com>
Sent: Thursday, June 21, 2001 10:09 AM
Subject: Re: MOVEA -> EVAL


> is an example of this.  The element of array that is modified depends on
> the value of x, which is changed in the same statement.
>
> The C compilers I tested the code on (gcc 2.95.4 and 3.0) both modified
> array[3], not array[1].  (They set the value of array[3] to 1.)  gcc 3.0
> warned me: "warning: operation on `x' may be undefined".  We don't have a
> C compiler on our 400, so I couldn't see what it would do.

That behaviour is what is defined in Java. I did believe that the order of
evaluation was undefined in C. However, not all Java programmers might be
aware of that and could be tempted to use such syntax, I suppose.

>
> RPG has similar limitations.  Hans gave the example of 'eval x=a+p(a);'.
> The compiler may use the value of the variable a either before or after it
> was modified by the function p().

I saw that and was surprised. Mostly because IBM has always been really big
on defining stuff I never saw reason for. Something as important as that I'd
have thought they'd iron out.

>
> >     Now, you defend the var1 = var2 = var3 ... etc. string as being
"pretty
> > clear." We'll forget for the moment that it is exactly that syntax I was
> > using.
>
> You were also putting in entangled variables.  If Java indeed handles such
> things differently, then the discussion on them only succeeded in muddying
> the waters.  I'll go through the rest of this assuming an assignment chain
> of orthogonal variables.

I don't see the variables as entangled, nor do I see Java as handling things
differently. I keyed in what is a perfectly acceptable Java statement. My
reason for doing so was the post I was originally responding to implied that
assignment chains were common among many languages. I did want to point out
that while this was true, that did not make it a good thing. It didn't also
mean it would work the same for people coming from different languages. My
point being, the fact that different languages have statements of that
syntax does not make it productive nor "universal."

> Perhaps it boils down to a question of style and idiom, but (to me) the
> statement

Perhaps it does.

> x = y = z = <some value>
>
> indicates a stronger correlation among the variables than does

Well, that could be the case, but where I usually see these chains is in
variable initialization. Reuse during the same method (function) where the
programmer wants to reset them. When it has bugged me is when I needed to
carry the value of y forward and needed to edit it out of the middle.

> x = <some value>
> y = <the same value>
> z = <the same value>
>
> I think we're just going to have to disagree on this (but I still wouldn't
> mind seeing it in RPG).

Well, at least now you know what jerk keeps casting the opposing vote! ;-)

Chris Rehm
javadisciple@earthlink.net

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.