Syntax errors that maybe aren't

[Jay R. Ashworth]

We had some discussion last week or the week before about syntax errors
in filePro, and whether that's a proper classification for them; it was,
as I remember, in the context of whether filePro ought detect that a
quoted literal argument to a function was non-numeric, in a position
where a traditional language wouldn't require the number to *be* quoted.
(That is, it was a actually a quoted *string* literal, which context
required to be numeric.)

I've just tripped over the opposite case.

Putting on my Captain Obvious jumpsuit...

 ===
I was working on a table today, and I needed to write this statement:

:288 eq "LAPTOP":mid(sk,"13","3")="L/T":

The problem was that the field *wasn't* 288 in *this* file, it was 2 --
it was 288 in a different file.  This file didn't *have* that many fields.

So, not noticing this, I ran the code.

That's a *syntax* error, according to dclerk.
 ===

No, it's not.

The proper thing to put in that particular lexical particle *is* a field
number(name).  That the particular field number I picked was too high
is certainly an error, but not one of syntax.

When I started typing this, I was going to contrast that to other
languages that wouldn't use numeric field names... but on reflection,
they wouldn't throw syntax errors for that, either, even the ones that
require all variables to be declared.

So, perhaps this isn't *quite* exactly the opposite of the mid
situation, but... still a bit confusing if you're not expecting it.

There probably aren't that many newbies on this list these days, but
what the heck.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth                   Baylink                      jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com                     '87 e24
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274