Subject: Re: token FNAME

From: Zheng Gengbing <[email-masked]>
Date: Mon, 10 Jun 1996 09:40:46 +0800 (EAT)

> 
> On May 27,  4:50pm, Zheng Gengbing wrote:
> > Subject: Re: function name
> >
> > 	In fact , we can remove the step to examine if a name
> > is FUNNAME or NAME , and simply return NAME in lexer .
> > 	We have done the same search in hpfsc once again .
> >
> > 	But input & unput problem still exists and it will keeping
> > disturbing us in other cases .
> >
> >-- End of excerpt from Zheng Gengbing
> 
> 
> On May 27,  2:26pm, Guansong Zhang wrote:
> > Subject: Re: function name
> >
> > I need to understand the way lexer works, please leave this for HIT. They
> have
> > spring vacation this week. We can discuss this with them when they come back.
> >
> >
> > Guansong
> >
> >
> >-- End of excerpt from Guansong Zhang
> 
> On May 30,  2:34pm, Guansong Zhang wrote:
> > Subject: return(NAME) in lexer.
> > On May 30,  4:51pm, Zheng Gengbing wrote:
> > > Subject:
> > >
> > >
> > > 	In this new version 1.56 , I wrote a return(NAME) imediatly after
> > > call to i=searchKey_m(name,FUNC_TAB_G,FUNC_TAB_LIMIT_G) , so unput() is
> > > jumped .
> > > 	Since then , flex can also do a good job .
> > >
> > > 	To enable the configure to check the yytext feature , don't forget
> > > to remove the comment in the line 53 , and comment the next line if you
> > > decide to use the lexer found by configure instead of forcing to use lex
> > > as the compiler of hpflexer.l .
> > >
> > >
> > >
> > > Zheng Gengbin
> > >-- End of excerpt from Zheng Gengbing
> >
> > I think this cause a problem, for example, the following program
> >
> >       program moving
> >       interface operator ( .runningaverage. )
> >           function series ( rough, run ) result ( smooth )
> >             real,    dimension ( size(rough) )   :: smooth
> >             end function series
> >       end interface
> >       end
> >
> > used to be correct, (this is part of a real program, hpfsc will complain).
> > "size" will be considered as a function call.
> >
> > Now, it is considered as an array reference. Though unparse can manage to let
> > it produce correct result, (which failed in the second 1.56, ok on my
> machine),
> > this is not correct for future compiler work.
> >
> > But I don't think your changing is wrong, as I previously wrote, the
> > implementation of detecting array-ref or function-call has problem. This
> > problem is concerned with portability of lexer, the keywords reserved
> problem,
> > and the functionility of hpfsc.
> >
> > (If we decide to implement this way, I think hpfsc can change it to function
> > call as it did in assign statement. If array and function can be detect at
> > hpf2dep time, hpfsc need not to check that as it do now.)
> >
> > So, please leave this for a while, HIT don't have time to react on this yet.
> We
> > need to make clear why to implement this way first.
> >
> >
> > Guansong
> >-- End of excerpt from Guansong Zhang
> 
> Now, let us discuss on this. Why we need a FNAME?
> 
> >From what I understand this is that, lexer try to decide if things like
> 
> sin(9)
> 
> is an array or a function.
> 
> But what if I simply write a f(9)? for example:
> 
>       program di
>       real :: a,b
>           a=f(b)
>       stop
>       end
> 
> In this case, f will be considered as an array referrence now by our parser.
> 
> This is not correct, if f is an arrary, it should be declared previously, (Once
> I discuss this with pku, but I can not find out where the Fortran book address
> this when pku ask for evidence.) Otherwise, it should be considered as a
> function name.
> 
> The above example will be parsed successfully by dec f90 compiler with -c flag,
> while failed by our hpfsc:
> 
> hpfsc: line 3 error 110:Variable: f  should be declared as array type !
> hpfsc: line 3 error 148:Type not match in assignment.
> 
> I think the problem exist in the following position:
>

	You are not right . Since -c is used in dec f90 compiler , this means
separate compilation , where f(c) is left to time of link to decide whether
it is a external function . WHile our hpfsc donot support this .

> 1, Token FNAME's meaning is not clear, it can only reflect intrisinc function
> name. So is it still necessary to remain this?
> 
> 2, Some thing wrong when we add an entry in symbol table. Now, we just add new
> things as array, (some of them will be checked out and changed by hpfsc.) while
> in fact, we should check the symbol first, then decide whether it should be an
> array or a function name.
> 
> We need a solution on this. Either solve this problem within the first pass
> done by yacc, or by the second pass hpfsc.
> 
> Please make comments on this.
> 
> 
> Guansong
> 
> 

***************************************************************************
*     Zheng Gengbin                 *                                     *
*                                   *                                     *
*  Dept. of Computer Science        *  Phone:  86-10-2585088              *
*         & Technology              *  Email:                             *
*                                   *      [email-masked]   *
*  Peking University P.R.China      *  Mail:                              *
*                                   *      Room 1077 ,Building 47,        *
*                                   *      Peking University, P.R.China   *
***************************************************************************