End and the syntax parser

[Fairlight]

In the relative spacial/temporal region of
Tue, Dec 22, 2009 at 10:10:09AM +1000, Ken Cole achieved the spontaneous
generation of the following:
> 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.
[snip]
> 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?

Welllllll....*vascilate*

Does it happen with other reserved words?  I mean, if it happens with, say,
dim, lookup, etc...  Everything would have to be changed to be uniform.

This wouldn't be a problem if fP wasn't a bareword-variable language.  You
don't run into this in perl because you have variable type indicators
($,@,%,*).  Other languages (JavaScript, Java [I think], et al) rely on
case sensitivity, so you can have variables that are reserved words but
don't collide due to case.

Actually, I did just run a little test:

#include <stdio.h>

int main() {
     int exit;
     exit = 2;
     printf("Got here.\n");
     exit;
}

[arcadia-SuSE] [~] [10:34pm]: ./a.out
Got here.

In light of C's behaviour of allowing collisions, it would make me tend to
say that an exception shouldn't be thrown in fP.  However, if you look at
C's -behaviour- when allowing collisions, it's sane in that it's
interpreting the first 'exit' as a variable because it's an lvalue.

Ideally, I think the parser should be redone to determine the semantic use
of the term in question and to behave accordingly based on context.

Barring that, I agree with you that variable names should not be able to be
reserved words.  

The thing is, when you try to -enforce- that policy, you -still- need to
determine the semantics of how a term is being used.  So instead of just
tossing up an exception, it really should go back to what I said in two
paragraphs ago.  If you need the semantics determined to throw the
exception, you may as well go the extra mile and perform the correct
operations rather than just toss errors at people, IMHO.

Actually, I am now confused, as I did an extra test...  I changed the last
line of the C program to exit(1) and get:  

[arcadia-SuSE] [~] [10:45pm]: !cc
cc test.c
test.c: In function `main':
test.c:7: error: called object `exit' is not a function

So it bails at compile time.  You've overridden the core function with a
variable.  It'll let you do it, but you can't have it both ways.

Either way you go, then, it seems that collisions should either be
disallowed entirely, or throw an exception.  But you still have to do the
same work to get to the point you can enforce -any- type of end behaviour,
whether it's overriding or throwing an error.  And that can't be pretty to
have to write.

I gotta ask, "Is it -really- worth changing?"  

Just don't screw it up.  :)

mark->
-- 
Audio panton, cogito singularis,