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



Bob Cozzi wrote:
Hans,
I agree with all but your final point.

And no one in any of those community could possibly
imagine assignment operations that worked like RPG's MOVE and MOVEA.


Aren't we already working towards putting a lot of that into the /FREE spec
by adding functionality to %DEC/%INT/%CHAR/%SUBARR?
If we also had a shorter version of %SUBST (such as %SST or even %STR) I
would say we're nearly there. Doesn't C allow, effectively, a MOVEL anyway? memcpy(a,b,len) can be used
like MOVEL or MOVEL(P). Then there's always atoi() to take care of the
conversion. I don't see the issue. Perhaps the implicit vs explicit thing is
still bugging you (if I remember right that is one of your issues). But RPG
has so many implicit things, I don't see the problem if the following two
statements worked the same:
C MOVE CUSTNO ALPHACUST
Eval AlphaCust = CustNo
But this is also good enough:
Eval AlphaCust = %Char(CustNo)

Hmmm, where to begin? First, let's look at the history of the MOVE opcodes in RPG. Back in RPG II, before the days of packed decimal, MOVE and MOVEL simply moved bytes from the source to the target operands with no conversion, for the length of the shorter operand. Character to numeric moves worked since zoned decimal numerics look very much like EBCDIC characters. Very low-level.


In RPG III, packed decimal and binary decimal numerics were added to the language. MOVE and MOVEL were enhanced such that packed decimal and binary decimal operands would work exactly the same as zoned decimal. Like RPG II, if the target operand is longer than the source operand, bytes in the target would not get changed. If the target operand is shorter, bytes get truncated without warning. Again, very low-level.

In RPG IV, MOVE was enhanced with date and time conversions. This was purely a defensive design decision. At the time, I think most of us agreed the better design was to put the D/T/Z conversions into free-form expressions using BIF's. But expression support was late and still considered somewhat of a risk. The safer option was to put the conversions into the MOVE opcode, complicating MOVE further.

Does C allow effectively a MOVEL? No, it doesn't have MOVEL's weird behavior with respect to numerics. And no, atoi() doesn't work the same way as character to numeric MOVE in RPG.

No, what bugs me personally about MOVE and MOVEL is that the target operand is in many cases only partially modified, not completely changed. For certain combinations of types and lengths, it's essentially a substringing of a result. Which might not be too bad for character results, but it's ludicrous for numeric results.

When free-form calcs were being designed, my first proposal did in fact include MOVE, MOVEL, and MOVEA. Actually, I tried to include all opcodes. But others in the area were quite persistent in insisting that if there were two or more ways to do something in calcs, that only one be supported in free calcs. EVAL was preferred over the MOVE's for reasons discussed to death, here and in other forums.


And I prefer the way EVAL currently works vs MOVE/MOVEL with character only
data. But as I said however, I wish %SUBST would be lost to obscurity and
replaced with %SST() (see CPF Release 5 or 6 for reasons why CL implemented
%SST). Sure %SUBST is the same as the opcode name (whose name sucked from
the start) but who cares? I'd rather code %SST, %STR or %STG instead. This
is a tiny issue, but it has a huge impact on coding day-to-day when you have
to use %SUBST a million times. How many people on this list know that there is still a %SUBSTRING()
built-in function in CL? Originally that was the only substring built-in
there was. IBM added %SST after people bitched about the longer name for
years.
I could digress further and talk about QUAL vs QUALIFIED. I mean, I feel
like I'm typing in QUALIFIED.DATA.STRUCTURE.NAME when I type
Q.U.A.L.I.F.I.E.D. </blog>



Hindsight is always 20/20 in language design. Perhaps we should have chosen %SST() instead of %SUBST()? Or perhaps we should have looked to PL/I as a model and expressed substringing like "FIELD(I:J)" or "FIELD(I::K)"? Perhaps we should have used QUAL instead of QUALIFIED? But those discussions are pointless. The decisions have already been made, and the best you can do now is try to argue for alternate names for these things, risking complicating the language further.


BTW, I just came across an interesting white paper on dynamic languages that's worth a read:

http://www.activestate.com/Corporate/Publications/ActiveState_Dynamic_Languages.pdf?_x=1

Cheers! Hans


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.