End and the syntax parser

[John Esak]

Boy... You vacilate better than anyone I know!  :-) 

> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com 
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.co
m] On Behalf Of Fairlight
> Sent: Monday, December 21, 2009 10:50 PM
> To: Filepro Lists
> Subject: Re: End and the syntax parser
> 
> 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
>