× 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.


  • Subject: Re: Clever UNIX/C Constructs
  • From: John Hall <jhall@xxxxxxxxxxx>
  • Date: Thu, 04 Jan 2001 10:32:16 -0500


Evan Harris wrote:
> 
> Hi Scott
> 
> The original thread (which I think I started) was based on the premise that:
> 
> EVAL Variable = Variable + 5
> 
> is, in my opinion at least,
> 
> much more readable and obvious than
> 
> variable += 5
> 

I really don't get that argument ???   I can understand if you prefer
not to use +=  but to state that the eval statement is "much more
readable and obvious"  Just isn't so.  

I would assume that the reason that += only costs $2 is because it IS
the same as the ADD op code which already exists.  That's all it is

   ADD      VARA        VARB

   VARB += VARA

same thing

If anything is more prone to confusion it is the ADD op code

example

        ADD     VARA     VARB   /* add VARA to VARB and place result in
VARB

but what does the following do ?

VARC    ADD     VARA     VARB

Does it add VARC to VARA to VARB and place the result in VARB ???  Why
or why not ?

Oh because - that's right !! 
 



> So far the major argument for providing this syntax has been to save
> typing: if there is another argument I'd be more than interested to hear it
> as I really cannot see what it adds to any language. As per Richard's
> comments it seems it arose from a design decision due to limitations of the
> past - just as the columnar RPG format was rooted in its origins.

No the major improvement is readability.

> 
> I agree with your statements regarding RPG syntax not necessarily being
> obvious to the uninitiated, but it seems to me that += etc is just more of
> the same from a different language. To make it clear where I am coming
> from, would you want indicator logic added to C ? Why add something to RPG
> that adds nothing content-wise merely additional form ?

 Indicator logic may be a poor example since newer versions of RPG are
eliminating them.  But I would like to see some of the better features
of RPG added back into C

> 
> Excuse my ignorance if I get this wrong (I have no more than a passing
> acquaintance with C) but in the above example what would be the effect  of:
> 
> variable =+ 5
> 
> Would it (as I understand it) assign 5 to the variable rather than
> incrementing it by 5 ? What are the side-effects (bad choice of words
> possibly) of other incorrectly typed terse assignments ? And what is the
> effect on debugging to those that are not proficient with this style of
> expression ?
> 

Should be an illegal expression.  But even if its not it would be the
equivalent of using a z-add instead of an add.

> These days when I code I like to think that I am coding for "whoever comes
> next" and that they will (hopefully) be impressed with how easy it is to
> maintain or (god forbid) debug - not by having to refer to the manual to
> understand indicators, cycles, expressions or whatever.
> 

Let's face it the argument is truly about what you are used to seeing. 
If someone can master all of the EXISTING quirks of RPG then one more
"op code" (+=) won't make any difference one way or another. 


It would be nice to have but it won't be the end of the world if they
don't add it.

Oh well - have a good one :)

John Hall
+---
| 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 copyright@midrange.com.

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