DIMension syntax checking...

[Fairlight]

Y'all catch dis heeyah?  John Esak been jivin' 'bout like:
> 
>      then: show("12","3") "blah" and show ("12","3") "blah"
> 
> are equivalent and pass syntax check. Fine, no problem. however, when I

If it makes you feel any better, it took me about a minute and a half, and
many double-takes to actually catch the difference there.

> over them because it just wasn't jumping out at me... What he saw... again
> after a good 15 minutes of scrutinizing was one of the array lines looked
> like this:
> 
>      dim date2["3"]:bal(160);  dim pay ["3"]:bal(60)
> 
> Now, assuredly, you are seeing the problem right away. I'm thinking/hoping

Now that I know what I'm looking for, yeah.  I surely would not have before
the previous example--at least not without another minute or two.
Definitely an insideous single-byte difference that will keep one chasing
their tail for a while.  In context, I'm looking at it as one line of code,
and it's taking me up to 2 minutes to find it.  In the scope of thousands
of lines...*whistle*  Not pretty.

> for not catching it right away... but shouldn't the syntax checker have
> helped along with this?  Why would it see pay ["3"]...  the same way it
> would see pay["3"]...  Isn't this a different enough thing than show (r,c)
> and show(r,c)?

Well, I think that kind of goes back to the structured languages that
filePro is based upon.  I can't speak for the FORTRAN side because I barely
remember more than the 'eq' and 'ne' type operators.  But in C, you can
emulate this:

#include <stdio.h>

int main(argc,argv)
int argc;
char *argv [];
{
     printf ("%s\n",argv [0]);
     exit (0);
}

I used the space in -all- array places in that example.  That actually
compiles -and- runs correctly under gcc 2.95.3.  It also works correctly
under the SCO C compiler shipped for 5.0.6--the official one, not gcc.  So
this isn't some GNU-ism like the odd things bash does that it shouldn't.

Stylistically speaking, I was taught that functions can optionally have a
space between the function name and opening paren--but that the "proper"
form is to not do so.  I was taught that functions are followed directly by
the paren, and you only use a space for blocking structures like "for ()",
"while ()", and other structural syntax keywords and their conditionals.
It was the convention I was taught, and I was told that it was a uniform
way to analyse what you were reading more carefully.  I'm not sure where my
mentor learned his style.

However, I've never -known- a language that allowed a subscript to be
separated by whitespace from what it modified--or thought I hadn't.
Apparently I've been ignorant all these years and didn't know it.  I
personally would have expected, from experience, a function to allow either
use, but an array reference to deny use of a space.  I'd have been wrong,
too--much to my surprise.

Apparently, other languages allow either syntax.  If filePro was modelled
on other languages as far as syntax (as opposed to flow structure), I guess
I can't really debate against it other than to say it looks -really- odd to
see a subscript floating way off what it's modifying.  You'd never see that
in a straight mathematical equation, to my knowledge--say, in a textbook.
I dunno...Ken's the C whiz, and Nancy's got a strong math background.  I've
just never seen that kind of notation with a space anywhere before.  Is
it actually considered legal mathematically?  If not, then I guess it's a
part of the convention of compilers and interpreters to simply strip all
irrelevant whitespace.  And filePro's basically got a compiler in it.

> see attention than this minor change to how things work now.  Besides, I
> realize there are probably people out there who *want* it to work the way it
> does not... but I would still argue for my view on this.

For what little it's worth, I agree with you.  I think it should probably
complain.  But I also think the C compilers should complain. :) Actually,
so should perl, and it also lets this go with flying colours.  I'd kind
of expect perl to let it slide more than a C compiler, but still...it's
like a consensus of sorts when four languages all permit it.  I wish I
had access to a pascal compiler right now, although I'm not even sure I
remember enough pascal to do the test.  Ditto BASIC.

It's apparently not "wrong", technically, but I don't like it, find it
confusing, and would likely fall prey to the same kind of bug hunt you went
through.  Which doesn't help any more than as moral support, but I'd indeed
be pretty annoyed if I got snagged by it.

And to add insult to injury, in all the time I've heard your JAWS setup in
the fP Room, I don't think I've ever heard it say "space".  Does it have a
"code mode" that would let you "see" it, or would it be entirely invisible?
If you couldn't hear it, that's even worse.  :(

There's one that'll keep you up nights--literally!  :(

Good catch, Rick!

mark->