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.