End and the syntax parser

[Ken Cole]

Richard,

I only meant to throw an error if there was anything after END on the
same line, not on subsequent lines.  I to put all my gosub blocks
after the "main processing" so I was not envisaging making END the
last statement in the entire processing.

Cheers

Ken

On Wed, Dec 23, 2009 at 1:13 AM, Richard Kreiss
<rkreiss at gccconsulting.net> wrote:
>
>
>> -----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
>
>
>
>
>
>
>
>
>
>