|
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 mailing list archive is Copyright 1997-2025 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.