Subject: Re: Comments on the yacc file in 1.37

From: Zheng Gengbing <[email-masked]>
Date: Sun, 21 Apr 1996 09:30:13 +0800 (EAT)

On Sat, 20 Apr 1996, Li Xinying wrote:

> Hi,
>   
>    I am happy to see the merged version of PKU and HIT. Now I want to 
> discuss some changes made by PKU in yacc file f90.y.
>    You know the present version reports
>       " 9 rules never reduce, 23 shift/reduce conflicts " 
> ,while not the "6 shift/reduce conflicts" offered by HIT.
>    Here I discuss the changes one by one.
> 
> (1) "null_program_stmt" . Do you know what will be caused by it? See the 
> following example
>          integer i
>          end program
> .Though it is very simple,it is a legal HPF program. But now the 
> shift/reduce conflicts caused by null_program_stmt rule make it 
> illegal.
>   This is a mistake,though it may be convenient to your programming.
> 

   I admit I changed them not very well . but if  create a AST , it will be 
   VAR_DECL
     |           (thread)
   CONTROL_END
     |           (thread)
   PROG_HEDR  	

	since the sequence is reverse of PROG_HEDR , our parser cannot
accept .

> (2) "where_stmt_begin" is added.
>  We think it is not necessary. And we suggest to modified it to 
> 
>   where_stmt
>     :   WHERE LEFTBRACKET mask_expr RIGHTBRACKET 
>         assignment_stmt 
>     ;
>  
>   , so does forall_stmt and if_stmt 
>   
>   forall_stmt
>     :   FORALL LEFTBRACKET forall_control
>         RIGHTBRACKET forall_assignment
>     ;
>  
> (3) I want to come up with the "if_stmt_begin" added by PKU specially.This 
> is a dangerous action,because it caused the conflict between the 
> " if_stmt" and " arithmetic_if_stmt " .So I said it should be the same as 
> where_stmt and forall_stmt in (2).

	These are the same problem as above .
	the AST will be
            ASSGN_STAT
               |
            CONTRO_END
               |
	    LOGIF_STMT

	the LOGIF is wrong placed .

> 
> (4) "label_end_do_stmt" added by PKU. This is a complex problem. As we 
> constructed the AST , we have thought about this problem already. So we 
> made some routines to check the possible errors here, such as in 
> label_do_stmt
> 
>       do 10 ...
>         do 20 ...
>            ....
>    20   ..
>    10   .. 
> 
> if label 10 and 20 are misturned or the label 10 or 20 is missed in the 
> program unit, we can find and report the error. 
>    So the label_end_do_stmt is not only non_necessary ,but also  causes 
> the conflict that between the "exectable..." and "end_do_stmt" in 
> "block_do_construct". This is an untolerant conflict as well.
> 

	But your parse can not parse
	do 10
     10 enddo  
	only 10 continue is allowed .

> (5) "dim2 deferred_shape_spec_list deferred_shape_spec substring1 " are 
> added in the front part by PKU, but they are not be reduced in the rules.
> Why? Are they useful?
> 
	
	This is changed by my co_worker , I don't really know why hw changed
that . I will ask him.

> (6) 
> %type<symbol>  progname blockname procname funcname  module_name /*zheng.gb*/
> Is there any modification here?
>

	I find there are 2 module_name declared here , so I make a tag .

***************************************************************************
*     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   *
***************************************************************************

---

From: Zheng Gengbing <[email-masked]>
Date: Mon, 22 Apr 1996 17:21:13 +0800 (EAT)

>   This is a mistake,though it may be convenient to your programming.

	there is also problem in your origin version , try the example above,
you will get core dump on Linux . 
That's because we do not create a PROG_HEDR and push it in scope table , 
so the cur_scope is a null pointer . Any operation refer to the field of the 
cur_scope will cause a core dump .

	So, I decide to deal this problem in an alternative way . You can 
retrieve the yacc rule about this as origin state . But , I will take a
dramatic change to some rules to correct this problem . The method is ,
to create a PROG_HEDR at initialization time and push it to scope_table.
then when  encounter every END of program_unit , create a PROG_HEDR
and push to scope_table. Then we will keep the scope not empty at all 
time . We will also modify the action of program_stmt , since there is
no need to create a bfnd now .
 
Do you have any better method ?