Subject: Re: discussing on T_KIND

From: Zheng Gengbing <[email-masked]>
Date: Wed, 24 Apr 1996 10:09:05 +0800 (EAT)

On Tue, 23 Apr 1996, Guansong Zhang wrote:

> 
> Well, T_KIND is important, but it is definitly not as important as you
> described.
>

	We had discussed before we designed T_KIND , we felt that any existing
base type can not describe the complexity of T_KIND . That 's why T_KIND is
neccessary .

> Think about it, Sage++ use this AST structure express f77, part f90 and C++
> without T_KIND. And now, you say "To deny the existence of T_KIND is like deny
> the whole structure of AST"? You are certainly exaggerating.

	What I mean is your method to retrieve the T_KIND information from 
BFND is to deny the current AST , that is not exaggerating .
Please think it over .

	And does sage++ can express kind ? If is just a rather easy thing by 
using the existing AST , why they do not implement by the way ?
	It is natural to expand AST defintion when a new language present
some new feature . You can see sage++ expand many kind of TYPE in their 
defintion tags.h which will no longer useed by HPF.   

> 
> It is no use to accuse other's fault. I also can say unparse can not smoothly
> deal with T_KIND is because T_KIND is poorly defined.
>

	Then how to design a KIND type from current base_type ?

> Then does it solve the problem?
> 
> No! The problem still there!!!
> 
> It is time to cooperate, other wise we lose the battle together.
>

	I agree with you , but I am rather anxious that you still did not
understand what I mean . You are solving the issue by using a method that
is conflicting with the current way brought by the defintion of AST .

> To cooperate need understanding of each other's work. All I want to know is
> that if it is possible to define the thing expressed by T_KIND in another way.
> 

	I'd say , no matter you use any other way , you can not avoid to
design a new type to descibe the kind parameter . The current type is not
enough to describe it . And the method you present is deny the necessarity
of the TYPE . If we can always get all type information from the BFND ,
why we need TYPE ? Why not just number the base type from 0 to n , and 
why bother to create a TYPE struct ?

> You let me know it's "absolutely wrong !" But you certainly did not convince me
> why!

	That's what I anxious about .

> 
> Any way, I decide to give up. I will consider whether to stay the current def
> of T_KIND or your compromising way a little latter.
> 

***************************************************************************
*     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: Wed, 24 Apr 1996 15:31:29 +0800 (EAT)

Hi,
	
	Now , I want to explain the issue like this:

	In sage , the base_type are special types which is identical in the
whole scope. That means there is only one of these base type exist in a
module .
	But , because the KIND parameter , now the integer become complex,
there will be any number of integer types . The difference among these 
new integers is the kind expression which record the expression llnd of
the kind parameter . Now global_integer can only serve as a base type of
these new types . So it is resonable to create a new T_KIND to implement
this issue. So that we can use one global_integer to produce various
new integer type easily. 
	That' why T_KIND is needed .

	I am going to compromise , we will let the KIND_OP point to the
base type , and we will add other codes to get the infomation in our hpfcc.
	If you want the result immediately , you may get a new version .
hpfFrontEnd-1.38.tar.gz ,
	This version also includes our improved dumpdep . The testsuite 
is recorded according to the execution on hp9000/720 .

	I am also trying to ftp the *1.38 to  my account zhenggb in syr .You 
can also access it there .