RE: MOVE opcode in freeform (was Strange behavior w/%editc) -- RPG400-L

The /FREE /end-free thing is consistent with /EXEC SQL /COPY, /INCLUDE,
etc.
But if, in a future release, IBM wanted to support the ability to have
/FREE as the default for the compiled source member, they could simply
add a KEYWORD to the header specification:


.....H  OPTION(*FREEFORMCALCS)

Or similar.
Then /FREE would NOT be needed, and ALL calcs would implicitly be in
free format.  Then, the only way to NOT have free format would be, say
to allow me to put a C in column 6.  Hence, this subtle change would
allow you to code free format starting, effectively in column 7.

.....C                   MOVE  A           B
         If   A = B;
           C = A * 100;
         else;
           C = A * 50;
.....C                   SETON                         LR


Disclaimer: Code shown for syntax illustration purposes only. Periods
shown for clarity and are not really part of the code. :)

Bob Cozzi
cozzi@rpgiv.com
Visit the on-line  Midrange  Developer  forum at: http://www.rpgiv.com


> -----Original Message-----
> From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]
On
> Behalf Of Bartell, Aaron L. (TC)
> Sent: Wednesday, February 27, 2002 9:57 AM
> To: 'rpg400-l@midrange.com'
> Subject: RE: MOVE opcode in freeform (was Strange behavior w/%editc)
>
> I was suggesting it because coding /free and /end-free is a bigger
pain (in
> my opinion) than having a new opcode.  Unless of course you were using
100%
> free format, then you would only have one set of the 'free'
directives.  If
> I could change it, I would have it work off of a plain text member and
all I
> would have to do would be to enter my free format code.
>
> Not that IBM should create an environment just like Sun has with Forte
or
> any other gui editor that doesn't need special formatting, but why do
they
> go to lengths to create their own proprietary methods like this /free
stuff.
> Now it is yet another thing we have to get used to when they could
have
> created something similar to how java or C source works.  Just my
opinion.
>
> No I have not written any RPG free format code, but I have in many
other
> languages and I feel that experience is sufficient for my opinions.
>
> Aaron Bartell
>
>
> -----Original Message-----
> From: rob@dekko.com [mailto:rob@dekko.com]
> Sent: Wednesday, February 27, 2002 9:20 AM
> To: rpg400-l@midrange.com
> Subject: RE: MOVE opcode in freeform (was Strange behavior w/%editc)
>
>
>
> Because the Z in column 6 would look awful.
> Because the Z in column 6 would slow you down when coding in SEU.  It
would
> start at the Z instead of where your previous line began.
> Have you written any free formatted code?
> Granted the /free, /end-free is a pita when I use SQL, but I'd rather
do
> that then to code a Z in column 6
>
> Many people still code an A in column 6 of DDS when they serves no
valid
> purpose except to slow down people using editors like SEU because now
they
> have to move over to the right every time they create a new line.  Oh,
it's
> other purpose is to put a little clutter by the asterisk to give you a
> little eye strain when looking for commented lines.  The A is
optional,
> don't use it.
>
> Rob Berendt
> --
> "They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety."
> Benjamin Franklin
>
>
>
>                     "Bartell, Aaron
>                     L. (TC)"                To:
> "'rpg400-l@midrange.com'" <rpg400-l@midrange.com>
>                     <ALBartell@taylor       cc:
>                     corp.com>               Fax to:
>                     Sent by:                Subject:     RE: MOVE
opcode in
> freeform (was Strange behavior w/%editc)
>                     rpg400-l-admin@mi
>                     drange.com
>
>
>                     02/27/2002 10:02
>                     AM
>                     Please respond to
>                     rpg400-l
>
>
>
>
>
>
> >Since the intermixing of free and fixed calcs looks so gawd-awful
> horrible,
> no one should even consider using free-form calcs unless they are
prepared
> to write whole new procedures or modules in free-form style.
>
> I was hoping you would say this because I wanted to ask why you(IBM)
didn't
> just create a new specification code like Z or something instead of
having
> to start and end your code with compiler directives(/FREE and
/END-FREE)?
>
> I also agree that you shouldn't code both free and column-like coding
in
> the
> same program.
>
> Aaron Bartell
>
>
> -----Original Message-----
> From: boldt@ca.ibm.com [mailto:boldt@ca.ibm.com]
> Sent: Wednesday, February 27, 2002 8:51 AM
> To: rpg400-l@midrange.com
> Subject: Re: MOVE opcode in freeform (was Strange behavior w/%editc)
>
>
> Darn, another digest just rolled in while I was writing
> this, and so some of my points are again redundant!  I
> promise, this will be my last post for the morning!
>
> Bob wrote:
> >I think the bigger question is not even if a language that supports
both
> >free format AND fixed format useful, but rather, is the programmer
that
> >uses both free format and fixed format doing the right thing. In
that, I
> >can see your point. Mixing a MOVEL with all that free-format code
isn't
> >"cool".
> >
> >But to be honest, I have yet to see one example of free-format RPG IV
> >code posted to this list that has been written in a way that is
similar
> >to code written by people that write applications with free-format
> >languages for a living (not as a hobby). So perhaps we should
continue
> >using traditional RPG IV syntax (which includes the good old MOVE
> >opcode) until we get a bit more experience or until is become more
> >refined.
>
> You know Bob, I DO tend to agree with you more often than
> you might think.  I understand fully your concerns about
> free-form calcs, and to a large extent, much of the talk
> about free-form calcs is indeed hype.  (Perhaps even from
> us!)  Since the intermixing of free and fixed calcs looks
> so gawd-awful horrible, no one should even consider using
> free-form calcs unless they are prepared to write whole new
> procedures or modules in free-form style.  Although I do
> prefer coding in /free style, and I would like to see more
> /free code out there, I'm not sure I agree with the large-
> scale conversion of existing fixed-form calcs.
>
> Maybe you were right that RPG programmers weren't ready
> for free-form.  But then, when would they be?  Perhaps
> the problem was that expectations were too high?  I don't
> think any one of us expected the overnight conversion of
> all existing calc code.  Maybe some small percentage of
> new V5R1 code will be written using /free.  Maybe that
> percentage will rise as time goes on.  Unlike every
> other enhancement we've done, this one has relatively
> little practical importance in its first release.  It will
> likely become more important over time as programmers warm
> up to it and learn how to use it.
>
> If anything, I think /free is a really profound statement
> from us that we believe programmers will still be using
> RPG many years from now.  In a sense, /free is more useful
> as a statement of IBM's commitment to the language, rather
> than as a useful function.
>
> >On the other hand, since we have 6 or more ways to do the ADD
operation
> >in RPG, why not just include a new free-format opcode named MOVE and
> >MOVEL?
> >
> >/free
> >   movel  src  target
> >/end-free
> >
> >Oh crap! I just wrote free-format, and I told Hans I would never do
> >that! ;)
>
> That's not valid free-form calc code anyways, so it doesn't
> count, OK?  ;-)
>
> As I pointed out in my previous note, we purposely did not
> support all calcs in /free for the very reason that we
> should not have lots of ways to code something.  If, and
> this is a big IF, all new RPG code is written using /free,
> then the point is moot - there would be fewer alternatives
> to choose from.
>
> >Actually, Joe, Hans is not your enemy. The enemy is us as a group, we
> >RPG programmers who do not clearly articulate our views.  I think
rather
> >than say "I demand feature X in RPG" we need to say something like:
> >"Feature X is valuable to me because A, B, C, D... and this is how I
> >think it should be implemented."  And then let the smart compiler
> >writing figure out how it should be realistically implemented.
>
> I agree.  Often we see requests that we should add some
> particular functionality where the request is worded in
> terms of some specific syntax.  What we try to do is extract
> the real requirement and then try to determine the best way
> to meet that requirement.  That's not always easy, and it
> might not always be obvious how some enhancement meets a
> particular requirement.
>
> Basically, we prefer adding "enabling" enhancements, rather
> than enhancements that directly meet some specific need.  For
> example, procedures "enable" a lot of functionality.  For
> many things that programmers want to do, we would prefer
> that programmers write procedures to perform the desired
> tasks.  We had hoped that there would by now be a goodly
> selection of procedures and modules commonly available
> written by RPG programmers for the benefit of other RPG
> programmers.  Robust publically available function libraries
> is a prominent feature of many other currently popular
> programming languages, such as C++, Python, Perl, and Java,
> and is a big reason for the success of those languages.
>
> I know someone will pipe up and point out some web page or
> another with publically available RPG code.  But often,
> they're just touted as "demonstration" code.  The biggest
> problem is that there's no common repository of the code
> that's available.  And there's little sense of community
> with respect to improving the quality of publically
> available code (as there is with other languages).  At any
> rate, the amount and quality of publically available RPG
> code just doesn't compare to what's out there for other
> languages.  Just look at www.cpan.org to see how the Perl
> community deals with library packages.
>
> Cheers!  Hans
>
> Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com
>
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>
>
>
>
>
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.