Re: converting string to a numeric

[Hans Boldt <boldt@xxxxxxxxxx>]

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