Why am I getting a syntax error?

[Dan Coutu]

Laura Brody wrote:
> On Wed, 8 Feb 2006 07:37:21 -0800 (PST), Jeff Harrison 
> <jeffaharrison at yahoo.com> wrote:
>
>> --- Howard Wolowitz <howiewz at beonthenet.com> wrote:
>>
>>> If your map includes associated fields starting with
>>> A) then you have to use
>>> an extra space after the a as in len(a  )
>>>
>>> Howie
>>>
>>
>> Wow!  Great Catch Howie.
>
>     Which is why he's Howie and your not <g>. (I would not
> have figured that one out either).
>
> --Laura Brody
Sigh, this is the kind of stuff that drives me crazy! While I can see 
that filePro does some very useful things in very useful ways it has so 
many little quirks, like the one above, that it can become quite 
expensive to develop with. If Howie had not pointed out to us the trick 
of adding a trailing space the chances are that none of the rest of us 
(except maybe Ken) would have even thought to try it.

Poor Boaz could have been chasing this one down for days, or longer.

I'd like to share another example of funky parsing that I ended up just 
working around by writing (a lot) more code when it sure seems to me 
like it should have worked just fine. If someone knows of an easier way 
to do what I wanted I'd sure love to hear it!

The code reads an external data file in order to update filePro data 
from an external source. The external data source is a single file that 
provides data to be placed into multipe filePro files. It seemed like it 
would be straightforward to set things up so that the external data 
specifies the name of the filePro file to be updated and possibly the 
filePro record number to update (unless it's a new record to be added.) 
It then lists the field numbers and field values to be putting into 
filePro in order to update the record.

So I store the name of the filePro file in a declared variable called 
FileName, simple enough. It seemed reasonable to want to have a gosub 
that did a lookup of an existing record like this:

lookup fil=(Filename) r=(RecordNo) -ex

(Naturally I had also stored the filePro record number to be updated in 
the declared variable RecordNo.) Well, this doesn't work because you 
can't use a variable for the name of the lookup file. Bummer. So instead 
of a single line of code for however many filePro files I was working 
with I had to make a line of code for each individual file with the file 
names hardcoded like this:

if:   FileName eq "customer"
then: lookup fil=customer r=(RecordNo) -ex
if:   FileName eq "contact"
then:  lookup fil=contact r=(RecordNo) -ex

A bother but in this case the number of files that I was dealing wasn't 
that large.

Okay, so we move on. Now it's time to save data into fields within the 
record that we just did a lookup on. Intuitively one should be able to 
put the field number into a variable, FieldNum, and the field value into 
another variable, FieldVal, and then save the value into the proper 
field in the record like this:

fil(FieldNum) = FieldVal

Again, bummer. It isn't allowed. This one is more painful. Some of the 
files have hundreds of possible fields. Instead of the simple code above 
I have to resort to this type of coding:

if:   FieldNum eq "1"
then: fil(1) = FieldVal
if:   FieldNum eq "2"
then: fil(2) = FieldVal

and so on for hundreds of lines. This is not an effective use of 
programmer time and results in expenses to employers and clients that 
are hard to justify. (Note: I wrote a tiny perl script to generate the 
hundreds of lines of code in seconds, but that doesn't detract from my 
point at all. Not everyone would do that.)

I would hope that there is some way to make the filePro parser more 
sensible but I'm betting that given the history of the thing (it's 
probably not a conventional parser as computer science majors are taught 
to build) it is very difficult if not impossible to revise so that it 
doesn't throw classically trained people completely off balance.

Anyway, thought I'd just point out that it seems clear from people's 
reactions to Howie's pearl of wisdom that filePro's quirks are simply 
accepted without question. From the perspective of increasing filePro's 
lifetime as a viable product this is not a good thing because developers 
trying to use it for the first time may easily run away, screaming, from 
their keyboards. Not exactly the kind of reaction that sells product.

Dan