Subject: Re: Uninamous def

From: Zheng Gengbing <[email-masked]>
Date: Fri, 3 May 1996 17:45:32 +0800 (EAT)

On Thu, 2 May 1996, Guansong Zhang wrote:

> On May 2,  7:42pm, Zheng Gengbing wrote:
> > Subject: Re: 1.34
> >
> >
> > 	7.  rule : actual_arg_spec , Zheng Qang reverse the llnd1 and llnd2,
> > 		he said this is good for unparse . But this will change the
> > 		ll.h from ,
> > 	struct   KEYWORD_ARG_S  {
> >         PTR_SYMB    null;
> >
> >         PTR_LLND    expr;  /* for the arg expression */
> >         PTR_LLND    keyword;   /* for the keyword string */
> >         };
> > 	to
> > 	struct   KEYWORD_ARG_S  {
> >         PTR_SYMB    null;
> >
> >         PTR_LLND    keyword;   /* for the keyword string */
> > 	PTR_LLND    expr;  /* for the arg expression */
> >
> > 	}
> >
> > 		I have not made up my mind if to do so . Can unparse really
> > 		cannot overcome this difficulty ?
> >
> >
> >-- End of excerpt from Zheng Gengbing
> 
> 
> I just made comments about this, but I can find the old example to show why
> unparse need the new order.
> 
> But here is a new example, see the following program (cut from g6.f9 from pku)
> and its unparse results:
> 
> ++++++++++++++++++++++++++++++++++++++
> ! test     type declaration
> 
> program spec1
> i=21_2
> a=8_'DON'
> 
> end
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>       program spec1
>       i = 21_2
>       a = 'DON'_8
>       end
> 
> ======================================
> 
> 
> Why unparse can not unparse correctly the second ASSIGN_STAT?
> 
> look at the results from dumpdep, (Now I am working on 1.38, I have not time to
> check if 1.34 has the same problem.)
> 
> The two ASSIGN_STAT's second llnd are 6-E and 12-E respectively, and
> 
> ***L0W-LEVEL NODES***
> 
>     id    var    type    symb    ll1     ll2                     tag...
>     1-E   307     1-T     3-S    ----    ----                       VAR_REF
>     2-E   300     1-T                       2                       INT_VAL
>     3-E   300    12-T                      21                       INT_VAL
>     4-E   814    ----    ----     2-E    ----                       KIND_OP
>     5-E   312    ----    ----     4-E    ----                     EXPR_LIST
>     6-E   813    ----    ----     3-E     4-E                      KIND_VAL
>     7-E   307     2-T     4-S    ----    ----                       VAR_REF
>     8-E   300     1-T                       8                       INT_VAL
>     9-E   305    13-T   "'DON'"                      STRING_VAL
>    10-E   814    ----    ----     8-E    ----                       KIND_OP
>    11-E   312    ----    ----    10-E    ----                     EXPR_LIST
>    12-E   813    ----    ----     9-E    10-E                      KIND_VAL
> 
> we can see they are both KIND_VAL, at this position unparse will unparse the
> son of KIND_VAL, but which one first?
> 
> If unparse deal ll1 first, the second ASSIGN_STAT will not be correct (in the
> above case), if ll2 first, the first will not be correct.
> 
> To deal with this, unparse need to go down to ll1 first to see what is it, and
> then came to decide which to deal wich son first.
> 
> This is something I called "don't follow the root-first rule". In this example,
> it is lucky for unparse to go down one level. Without any rules, it quite
> possible to demand unparse to go down to the bottom of the tree to decide what
> should do at the root level.
> 
> In fact, if we adjust the order, the problem won't exist any more. Any program
> in the future, even hpfcc, also won't need to see the son first.
> 
> So, I will call this also a def bug. Please change it.
> 
> And be careful about using tags, both pku and hit. You should let unparse know
> how to deal with the tag.
> 

	Well , how about put the kind param of char_literal_constant to the 
llnd_2 . In this version I have modified as such . The unparse result is 
ok now .
++++++++++++++++
      program main
      i = 21_kind=2
      a = kind=8_'DON'
      end
++++++++++++++++

	Anyway I don't think add new tag is always a good way to deal the def 
bug . So many tags will make the AST impossible to understand .
Let's keep the meaning of tag tidy.

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