Subject: Re: keywords reserved

From: Zheng Gengbing <[email-masked]>
Date: Thu, 6 Jun 1996 16:47:03 +0800 (EAT)

On Wed, 5 Jun 1996, Guansong Zhang wrote:

> This letters is concerned with keyword reserved problem and AST definition. I
> hope pku also pay attention to this please.
> 
> On Jun 5,  3:30pm, Li Xinying wrote:
> > Subject: keywords & contains
> > Hi,
> >
> >    I discussed contains with Zhengqiang. We agree on the suggestion of
> > you. If you and PKU are identical,it can be changed now, we think.
> >
> 
> Zheng Qiang, please change contains according to PKU's suggestion, and let me
> know when unparse need to change accordingly.
>

	Please inform me also , so that we will change hpfsc to fit your 
change.

> Please also check the format statement I talked to you in my previous letter.
> 
> >    And about the problem that keywords should not be regarded as reserved
> > words my difficulty is still the old saying: we should distinguish the
> > assignment_stmt,such as "if(3)=8" where if is an array,with if_stmt.I am
> > doing experiments to do it in lex, but it seems a bit difficult. I am
> > trying now.
> >
> 
> My opinion is don't try to use lex to solve this problem, I think that is not
> in the right direction.
> 
> Lex is used to recognize tokens, if you let lexer to understand things like if
> array or if statement, that is something too much. You will end up with, to the
> best, a too complicated lexer, which no one can add anything in the future. (In
> that case, I think we'd better do not solve the keyword reserved problem. The
> clarity of the project is more important than keyword reserved. Don't you think
> so?)
> 
> One such example is function name, I think right now, lexer has already do too
> much work to recognize this tokens, it is not only confusing, but also has
> things like input and unput, which prevent moving our lexer on linux (flex).
> 
> Please consider my suggestion carefully on this, to see if it is reasonable.
> 
> I think we still need yacc rule and yacc action to solve this. Of cause, the
> yacc action may give lexer some kind of instruction to let it beheave
> accordingly. (I wrote this in my previous letters, and I find the name for this
> technique, it is called lexical tie-in: a flag which is set by YACC actions,
> whose purpose is to alter the way tokens are parsed.)
> 
> After considering Li Xinying's comments on "if(8)=3", it occured to me that
> only lexical tie-in alone can not solve the keyword reserved problem. Because
> we can not decide a NAME is perfered or a Keyword-Value is perfered at the very
> begining of the sentence. (Again, here I emphasize my point of view above, let
> lexer to do analysis of the whole setence to get the result is not a good
> method, even it may solve the problem. Please think it again.)
> 
> The following is my analysis on this and partial solutions, please check to see
> if it is right:
> 
> First, suppose at the begining of the sentence, we let lexer perfer NAME, then
> after "if(", yacc action may decide to build up an array reference with its
> symble name as "if". At this point, LR(1) method can not distinguish what kind
> of statement the current one is. So my idea is just to do some acction to
> record every possible information (things like "if".) Then as yacc proceed
> ahead after ")=", we can decide this is a assignment now. If it is a if
> statement, we will get something a little wrong from the definition point of
> view, the ll1 is an arrary refference.
> 
> We may have multiple ways of solving this new problem:
> 
> 1, simply let it be, we can always know that if statement's ll1 is not an array
> ref, in fact, we only care about this "array"'s index part. (This does not
> conflicts with root-first-rule I described previously used in def and unparse.)
> 
> 2, We do not give array_ref tag to things like NAME(...), in stead, we can call
> it, say, UNKNOWN. and build it up just as we do to array_ref, then check this
> what this UNKNOWN mean when we can. Then change the structure of it
> accordingly. (In fact, hpfsc's deal with statement functin is same as this, we
> always can decide what kind of thing it is in semantics checking. The flowing
> is what we once discussed, read it carefully please.)
> 
> On Apr 25,  1:56pm, Guansong Zhang wrote:
> > Subject: combining hpf2dep and hpfcc
> >
> 
> > If fortran's feature does not allow building an accurate tree at yacc time
> with
> > one pass. We can add one more path in hpf2dep. This certainly can solve the
> > problem above. (In fact to this specific problem, we may even don't need
> > another pass, if an array is to be refferenced, it should be declared first,
> > other wise this pattern should be considered as a function. This can
> > implemented in yacc action. Though, I don't think it is necessary to do so,
> it
> > will complicated the yacc action job.)
> >
> >
> >-- End of excerpt from Guansong Zhang
> 
> 
> I hope both PKU and HIT can make comments on the possibility to do so, and if
> we can solve the keyword preserved problem completely by this method.
> 
> Then I hope you also make comments on how much it will cost us to do so if it
> is an successful method. If it is too expensive, we may decide not to touch
> keyword problem at present time.
> 
> 

	This certainly will cost a lot to change so,since we have implemented
already without consider this problem from the beginning.
	I think we can choose to solve the condition where the keywords are
not present in the beginning of the yacc rules first , these are 
comparatively easy .

Zheng Gengbin