End and the syntax parser

[Alan Mazuti]

Get a life and do dead ants!

Sent from my iPhone

On Dec 21, 2009, at 7:49 PM, Fairlight <fairlite at fairlite.com> wrote:

> 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,
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list