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



James wrote

>And leave languages that are naturally fixed-source-format AS 
>fixed-source-format: if you're working in FORTRAN, for example, you >can 
>indent all you want BEYOND Column 7, but keep the statements at or beyond that 
>column, and the continuations in 6, and the >labels in 1-5. When a language is 
>designed to have a fixed source format, free-formatting the source just makes 
>it harder to read.

>You want free-format source? Use Pascal, C, ALGOL, PL/I, LISP, Java, or 
>Modula-2. They're designed for it.

Hans wrote

>no one - NO ONE - in any other language  community would (or could) even 
>imagine Java or C or C++ or Perl or Python or whatever >as a fixed-form 
>language. And no one in any of those community could possibly imagine 
>assignment operations that worked like >RPG's MOVE and MOVEA.

Some snippets from the discusion so far.

Each language its own pecularities: RPG's pecularity was the fixed format. And 
I like it, too.

I do not oppose to /Free, but there are some objections from my side.

I do not like the way /Free is enhanced.

1) Only the C-specs can be defined in free format, the rest of the specs are 
still fixed. More emphasis should be made to free the other  specs as well, 
even the O-specs (then you can "lay out" your form within the source).

2) Almost each traditional opcode has been replaced with a BIF and cannot be 
used in /Free. IBM should stop biffering RPG. Instead of replacing those 
traditional opcodes they should be made available in /Free as well, with their 
old functionality. I mean opcodes MOVE, MOVEA, SCAN, XLATE, etc. Then people 
can still code in their old fashioned way in /Free. Perhaps gradually they will 
transform. I think /Free is more acceptable, then.

3) Hans brought it up (hence his quote), so here we go: the MOVE debate. I 
think RPG has a powerfull opcode in MOVE. The other free styled languages, like 
java and Delphi, have only BIFs like StrToChar of CharToInt (what piece of code 
is behind those functions?). The replacement of MOVE in RPG /Free (%DEC and 
co.) are not fully functional the moment /Free hit the language: at V5R1 you 
can not use %DEC with a database field. So, %DEC is not an equivalent of 
CharToInt, but it should have been. It was never fixed for that OS release and 
thus those BIFs are completely useless. No MOVE and no substitutes, either. 
(Joe Pluta had good arguments at that time)

4) Because of all those BIFs we will be able to write code like

*INLR = %DoW(*NOT %eof(File):%read(File):%if(%eof(File):%leave:%add(NumField + 
1)))
(Don't worry about mismatching parentheses, this will compile at V6R3; no 
syntax checking, either, because, hey, you are using /Free)

or a whole programme in one statement (the zenit  of programming). Is this the 
way to go? See some examples to convert a date variable to a numeric one with 
BIFs like %date, %char, %int nested in one line. Such code should be easy to 
read and maintainable. Then I prefer more lines to do the same thing. This of 
course has nothing to do with the language, but with coding style. But the way 
I see the growth of BIFs, the only reason I can think of is the given above. 
This nonsense should end.

5) Another reason not to go to /Free is when maintaining code (RPG III, RPG IV) 
written in fixed format. You do not mix different formats in code within one 
programme or within an application (many programmes). You want to keep unity of 
code, in that respect. (Back to point 1)

Regards,
Carel Teijgeler






As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.