End and the syntax parser

[Richard Kreiss]

> -----Original Message-----
> From: filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com
[mailto:filepro-
> list-bounces+rkreiss=verizon.net at lists.celestial.com] On Behalf Of Ken
Cole
> Sent: Monday, December 21, 2009 7:21 PM
> To: Alan Mazuti
> Cc: Filepro Lists
> Subject: Re: End and the syntax parser
> 
> Alan,
> 
> I can nearly remember that night in Philli!
> 
> Cheers
> 
> Ken
> 
> On Tue, Dec 22, 2009 at 10:10 AM, Alan Mazuti
> <amazu at trusteeservicesinc.com> wrote:
> > Spot on Ken.   Now for a round of dead ants!
> >
> > -----Original Message-----
> > From:
filepro-list-bounces+amazu=trusteeservicesinc.com at lists.celestial.com
> >
[mailto:filepro-list-bounces+amazu=trusteeservicesinc.com at lists.celestial.co
> > m] On Behalf Of Ken Cole
> > Sent: Monday, December 21, 2009 4:10 PM
> > To: Filepro Lists
> > Subject: End and the syntax parser
> >
> > This is something for everyone to toy with over the holidays (sorry
> > for the pun).
> >
> > Now I think this same point has been discussed previously but without
> > any action being taken.  Should anything be done is the point of the
> > email.
> >
> > One of the filePro programmers working here had a problem the other
> > day that some code didn't seem to be running.
> >
> > The processing table passed syntax check, created the tok file, etc
> > and ran to a particular point and then stopped with the rest of the
> > code not running.
> >
> > Now this is Sco 5v6.0.0 with filePro 5.0.14R4.
> >
> > After spending serious time trying to work out why the code wasn't
> > running, no goto's over the code, no gosub's without returns, etc I
> > had a look for them and found the problem.
> >
> > There was a long variable called "EndDate" being used.
> >
> > The fat fingered, well in this case light fingered, programmer instead
> > of entering:
> >
> > EndDate=lookup(6)
> >
> > had entered:
> >
> > End=lookup(6)
> >
> > Now I know Ken has mentioned before that everything after an "end"
> > statement is ignored when being parsed as it will never be processed.
> >
> > I am of the mind though that this is a syntax error as a "reserved"
> > word is being used as a variable and I feel there should have been an
> > error thrown at syntax check time.
> >
> > I believe the following rules should be checked.
> >
> > 1. If there is anything after "end" on a line that is not a comment
> > then it is an error.
> > 2. Reserved words should not be allowed as variables and if attempted
> > to do so as in this example then it is an error.
> >
> > What do the rest of you think?
> > I am wrong in thinking this should throw and error?
> >
> > Cheers, Merry Christmas and a safe and prosperous New Year.
> >
> > Ken
> http://mailman.celestial.com/mailman/listinfo/filepro-list

Ken,

Syntax check of using a reserved work for a variable - Yes.

The first suggestion would cause syntax warnings on most of my processing
tables.

I have programming where sub-routines are placed at the end of my processing
tables.  Some are accessed only once or rarely when an error occurs.  I have
found it more convenient to keep these at the bottom of a processing table
after any @once or @entsel processing.  

@once ends with an <end>.  Also, some of my looping routines which use a
goto, have an end statement so if the process fails, it doesn't fall
through.  Again this would cause problems.

I will add to the syntax check fix request, the ability at the time of the
syntax check or when entering a processing table, to select an alternate
auto process table.  This could also be used at tokenization time.  I have a
number of instances where I have processing tables for both input and output
which use an alternate auto table or none at all.  It is a unnecessary for
me to see that dummy field conflict errors in auto processing when I am not
using that table.

Would any of you like an option to display the dummy fields and/or long
variables defined in your auto process table when working on another table?
This would possibly eliminate the duplicate casting of variables.  Yes, if
one has more the a one use development license, one can open another session
and view the auto table.  But that uses a licensed session, which may not be
available.


Richard Kreiss
GCC Consulting
rkreiss at gccconsulting.net