Re: converting string to a numeric

[Hans Boldt <boldt@xxxxxxxxxx>]

James H H Lampert wrote:
> > I have to back Hans up on this one, sub stringing numbers is ludicrous.
>
>
> I'm afraid I have to side with Joe. But I do think the MOVE and MOVEA
> statements ought to have come with some sort of "pad" or "fill" option.
> Rather like the CPYBLAP and CPYBRAP opcodes in MI, vs. CPYBLA and CPYBRA.

Actually, MOVE(P) and MOVEL(P) have been supported for a long time. It 
was added to RPG/400 well before RPG IV.

> And I stand by my assertion that free-source-format languages should
> remain free-source-format, while fixed-source-format languages should
> remain fixed-source-format, because imposing an unnatural source format on
> a language (rather than creating a derivative language in which the new
> source format is natural) really screws up readability.

One problem is that the traditional fixed-format syntax can't be readily 
extended. There's not a whole lot you can do with 14 character wide 
factors. Just look at the goofiness involved in squeezing more than 
three operands into some opcodes like XLATE and SCAN! The 
"Extended-Factor-2" opcodes alleviated that somewhat, but then you still 
were limited to ~45 characters, which meant that you often had to 
continue over multiple lines.

The two main reasons free-form calcs were added were: 1) to provide a 
more flexible path for future language enhancements; and 2) to 
demonstrate fully that there *was* indeed a future for the language.

> And may I bring up another assertion: there is no such thing as a
> programming language that is ideal for ALL purposes. And there never will
> be. So we should all learn as many languages as we can, and study their
> strengths and weaknesses, and learn to develop mixed-language
> applications.

I agree 110% with that!

Cheers! Hans