Subject: Re: bugs in type

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

On Thu, 9 May 1996, Guansong Zhang wrote:

> Please see the following program:
> 
> ++++++++++++++++++++++++++++++++++++++
>       module facts
>         type key_facts
>           character (len=WIDTH) :: when
>         end type key_facts
>       end module facts
> 
>       program history
>       use facts
>       type ( key_facts ) presidents(42)
> !
>       presidents(42) = key_facts ( "Bill Clinton", "Governor", &
>                                   "Little Rock, AK", "1993-?" )
> !
>       end program history
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>       module facts
>       type key_facts
>          character (len=WIDTH):: when
>       end type
>       end module
> 
> 
>       program history
>       use facts
>       default:: presidents(42)
>       presidents(42) = key_facts("Bill Clinton","Governor","Little Rock,&
>      & AK","1993-?")
>       end program
> 
> ==========================================
> 
> ***TYPE NODES***
> 
>    id   var   name length
>   12-T  561    4-S    6  n_flds=          1 first=    6-S             T_RECORD
>   13-T  586   ----   --  base_t=    5-T   kindexp=    3-E
>                 T_KIND
>   14-T  550    9-S   --                                                DEFAULT
> 
> Both 12-T and 14-T should be T_RECORD, why a new DEFAULT, how this is defined?
> 
> The above program also cause a memory fault to hpfsc on my machine.
> 
> Guansong
> 

	When first pass , use list have not created , so in 'program history'
no information about 'type key_facts  ' can be obtained .

	We created a tempoary type default to make this mark so as to
process it in the pass of hpfsc .
	Well , after we process , we did not record the type in TYPE_OP ,
so your unparser failed .

	Now , it'll be ok.

Zheng Gengbin

---

From: Zheng Gengbing <[email-masked]>
Date: Sun, 12 May 1996 12:56:08 +0800 (EAT)

On Fri, 10 May 1996, Guansong Zhang wrote:

> On May 10,  3:10pm, Zheng Gengbing wrote:
> > Subject: Re: bugs in type
> > >   14-T  550    9-S   --
>                                                DEFAULT
> >-- End of excerpt from Zheng Gengbing
> 
> 
> I don't understand this well.
> 
> See the following program:
> 
>           character (len=5) :: when
>         end type key_facts
>       end module facts
> 
>       program history
>       use facts
>          character (len=5):: when
>       type(key_facts):: presidents(42)
>       end program
> 
> 
> ======================================
> 
> ***TYPE NODES***
> 
>  T_TEMPLATE
>   12-T  561    4-S    5  n_flds=          1 first=    5-S             T_RECORD
>   14-T  550    8-S   --                                               DEFAULT
> I don't know why unpase can get correct result while dumpdep can not.
> 
> After hpfsc, Why the tage of 14-T is still DEFAULT?
> 
> I think change it to T_RECORD will let dumpdep ok. Other wise something must be
> wrong again. Do you think so?
> 

	I don't know what you want , 14-T is now useless . We assign the
correct type to TYPE_OP sothat your unparse can get correct output 
instead of modified the DEFAULT type . Also modified that type is wrong
in some cases .
Since it is very difficult to delete it from type table , so just leave it 
there .

***************************************************************************
*     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, 13 May 1996 09:55:16 +0800 (EAT)

On Sun, 12 May 1996, Guansong Zhang wrote:

> On May 12, 12:56pm, Zheng Gengbing wrote:
> > >   14-T  550    8-S   --
> I don't know why you think so. I think I have to make the following clear once
> more:
> 
> As a project, what the purpose of dumpdep is? The purpose is correctly show the
> internal representation as a readable form.
> 
> But it seems to you whether dumpdep's result is correct is not important, as
> long as unparse can produce right results. (If you really think so, you are
> wrong.)
>

	Did I say that thing ? As I think  what you mean is that
	some useless items in dumpdep means the result is incorrect.
Since nodes are linked by thread in AST , to delete a node will take some
effort  and have some side effects . And dumpdep donot know which node
is useful , and which one is not used by others , it will just display them
by thread . I don't want to pay energe to maintain this now .

> dumpdep has same significant meaning with unparse: one travel the list link of
> the internal representation, one travel the tree link. Even more, in some
> extend we can say, dumpdep is more important than unparse, since unparse is
> language dependent, while dumpdep is not, internal representation for any
> language can be displayed by dumpdep. If the def of it apply the same rules as
> we did for HPF.

	Do you need travel type nodes by thread one by one ? Type is just a 
table for other nodes to refer . It is important only when other nodes
point to them . 

> 
> A clear def will allow both of them reflects its contents.
> 
> Now let's come back to this specific problem. What do you mean by this 14-T is
> meaningless? From dumpdep point of view, it is a type node linked to the AST!
>

	But search that type , can you find other node refer to that type ?
If so , that type is useful and the content must be correct , if not , who
cares .

> If it is wrong to modify the default type, at least we can give it a new name,
> so from dumpdep we don't see something as DEFAULT.
> 
> (What does this DEFAULT mean? In symbol nodes, we also have a DEFAULT, my guess
> is that originally, this is used as the first meaningless element in linear
> list, so the implementation is a little easier.)
> 

	When we process checking , some useless items is produced , useless
means a symbol not be pointed by any LLNDs or BFNDs , or a type not be
used by any LLNDs or SYMBOLs . We can say they are gabage . Why pay so many
efforts to maintain gabage only to obtain a comfortable look ? 
DEFAULT or any other name will be ok, that doesnot matter , but DEFAULT in
type won't be confused with the DEFAULT  in symbol, they are different AST
nodes . How can we make confusion?