I'll throw in my 2 cents.
Other languages prevent the use of commands as variables as they have active
editors that check syntax while you are typing.
MV typically has isolated text editors that get submitted later for
compilation.
While may commands or functions like OPEN PRINT READNEXT FIELD INDEX END etc
can be used as variables, common sense would dictate to come up with
different names for our variables.
The fact that they compile and work doesn't guarantee their success in
future releases or if migrating to another platform. It's not like you've
used every other variable in your program and READNEXT is the next 'word'.
For the newbies, this teaches them a lesson that they should not learn.
While MV can use reserved words as variables, I cannot see the purpose for
considering them. I don't even like using the variable DATE or TIME as they
are too close to being DATE() and TIME() respectively.
This thread could get out of hand and leave a newbie with the conclusion
that they can be sloppy and the use of reserved words as variables throws
off the visual appeal and becomes confusing.
Cosider the following code:
OPEN "VOC" ELSE STOP
SKIP=2
EXECUTE="SSELECT VOC"
EXECUTE EXECUTE
OPEN=0
LOOP READNEXT ID ELSE OPEN=1 UNTIL OPEN=1 DO
FOR READNEXT=1 TO 20 SKIP SKIP
PRINT READNEXT
NEXT READNEXT
FOR NEXT=1 TO 10
PRINT NEXT
NEXT NEXT
REPEAT
Some of it may compile and some doesn't. We programers first compile with
our eyes and fingers. Then the compiler does its job and the runtime does
its job. This example illustrates how stupid it would be to mix variable
names with known reserved words. It throws off our memory of what works as
we would have to learn new reasons for words working or not.
Obviously we have no crystal ball and may not know how the Platform
developers may change currently valid expressions to be invalid. But you can
bet, if they tighten up the use of their reserved words, we are the ones at
fault when things don't compile, not them.
My 2 cents.
Mark Johnson
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, April 06, 2007 6:57 PM
Subject: RE: [U2] [UD] Dynamic variable. Kids, Don't try this at home!!!
> You can come up with some bizzare and totally unportable code in unidata
> using equates:
> EQU READNEXT TO 12345
> ID='2R'
> LOOP WHILE READNEXT ID DO
> CRT READNEXT ID
> CRT ID
> *just for demo--won't make you go into an endless loop
> EXIT
> REPEAT
>
> Which on unidata prints
> 12\34\5
> 2R
> Because fmt(12345,'2R')=12\34\5.
> On universe, this compiles, but the equate processor doesn't replace the
> READNEXT, so it would exit the loop immediately.
>
> This innocent definition of an ascii table compiles and works on universe
> but won't on unidata:
> EQU NUL TO CHAR(0)
> EQU SOH TO CHAR(1)
> EQU STX TO CHAR(2)
> ...
> EQU DEL TO CHAR(127)
> A='1':@AM:'2'
> DEL A<1>
> CRT A
>
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Tony Gravagno
> > Sent: Friday, April 06, 2007 4:56 PM
> > To: [email protected]
> > Subject: RE: [U2] [UD] Dynamic variable
> >
> >
> > Ed wrote:
> > > Just discovered something kinda cool that I want to share:
> > >
> > > Here are a set of equates:
> > >
> > > 004: EQU TEF.TOTAL.VAL TO SUM(TEF.VAL)
> > > 0009: PRINT "TOTAL = ":TEF.TOTAL.VAL"R#3"
> > > 0010: PRINT "SUM = ":SUM(TEF.VAL)"R#3"
> > > When you run this, the variable "TEF.TOTAL.VAL" always
> > "knows" the sum
> > > of the values in TEF.VAL!!
> >
> > That's interesting because in other cases it could be a bug.
> > Ed, since you initiated this, could you tell us what happens
> > with the following? I don't have UD installed here at the moment:
> >
> > EQU DELETE TO 1
> > OPEN "FOO" TO F ELSE STOP
> > DELETE F,"KEY"
> > INFO = "BLAH"
> > INFO = DELETE(INFO,1)
> >
> > Does it give you an error telling you the delete lines are
> > invalid? If so it could be converting to this:
> > 1 F,"KEY"
> > INFO = 1(INFO,1)
> >
> > In other MV systems we do NOT want to do something like this
> > because the code is compiled into the object, not evaluated
> > at runtime like the SUM() :
> > EQU SCREEN.HDR TO @(-1):@(20,0):"Top of Page..."
> >
> > I would be careful about taking advantage of tricks like this
> > simply because it's a crap shoot as to whether the code will
> > be portable to another MV release - and even an upgrade of
> > the current environment could break this if some developer
> > decided it was a bug that needed to be fixed.
> >
> > Thanks for the tip.
> > T
> > -------
> > u2-users mailing list
> > [email protected]
> > To unsubscribe please visit http://listserver.u2ug.org/
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.446 / Virus Database: 268.18.26/748 - Release
> > Date: 4/5/2007 3:33 PM
> >
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.446 / Virus Database: 268.18.26/748 - Release Date: 4/5/2007
> 3:33 PM
> -------
> u2-users mailing list
> [email protected]
> To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
