[Fwd: Re: About IR2058]

-------- Original Message --------
Subject: Re: About IR2058
Date: Tue, 01 Mar 2005 16:40:28 -0800
From: Chuck Swart <cswart@model.com>
To: Peter Ashenden <peter@ashenden.com.au>
References: <0f1401c51eb3$43b127f0$0300a8c0@woodlands>



Issues, Issues, Issues!

1. Subtypes need not be static, so instead of

Ajay's

      subtype myenum is enum range blue to green ;

we could have

      subtype myenumn is enum range func1(1) to func1(2) ;

where func1 returns a value of type enum.
In this case it would be impractical, if not impossible, to create
restricted visibility based on the subtype.

2. Subtypes need not be declared in the same package as the type.

For example:

  package p1 is
      type enum is ( red, blue, green, yellow );
  end p1;

  use.work.p1.all;
  package p2 is
      subtype myenum is enum range blue to green ;
  end p2;


  use work.p2.myenum;
  entity e is
  ...


In this case does the use of the subtype myenum  make
visible all the operators (from package p1)?
If so, then 
   use p1.x ;


doe  not produce a "visibility" subset of

   use p1.all;



Remember, we still have to deal with

type int1 is range 1 to 10;

use p1.int1;--int1 is a subtype not a type.





Peter Ashenden wrote:

>Folks,
>
>Thanks to Ajay for keeping us honest!
>
>I recall that, at an earlier telecon where we discussed this, we agreed that
>a named base type should not be identified when a named subtype is
>referenced in a use clause.  The rationale was that the designer
>specifically mentioned just the subtype, so probably intended to constrain
>values to be of the subtype.  If they wanted to have unconstrained values,
>they would have mentioned the base type, either instead of or as well as the
>subtype.
>
>If the designer specifically mentions a subtype of an enumeration type, the
>same rationale would suggest that they intend enumeration values outside the
>subtype not to be legal in the using context.  Thus, I would argue that only
>the enumeration literals that are in the subtype should be identified.
>
>I guess my only concern about this analysis is on the implementation impact.
>Is filtering out the literals based on the subtype constraint too onerous?
>If so, I have no strong objection to identifying all enumeration literals of
>the base type.
>
>Comments?
>
>Cheers,
>
>PA
>
>--
>Dr. Peter J. Ashenden                        peter@ashenden.com.au
>Ashenden Designs Pty. Ltd.                   www.ashenden.com.au
>PO Box 640                                   Ph:  +61 8 8339 7532
>Stirling, SA 5152                            Fax: +61 8 8339 2616
>Australia                                    Mobile: +61 414 70 9106
>
>
>  
>
>>-----Original Message-----
>>From: owner-isac@eda.org [mailto:owner-isac@eda.org] On 
>>Behalf Of Ajayharsh Varikat
>>Sent: Tuesday, 1 March 2005 22:47
>>To: isac@eda.org
>>Subject: About IR2058
>>
>>
>>
>>Gentlemen,
>>
>>I have a question about the wording in the recommendation for future 
>>revisions. The current wording uses the phrase 'appropriate for the 
>>type'. What exactly does "type" here refer to? I am assuming that
>>(b) also applies to subtypes.
>>
>>In fact, when the type mark denotes a subtype, I think it is 
>>not very clear whether what becomes visible are the items 
>>associated with 
>>just the subtype or also those associated with the base type. 
>>Consider 
>>the following declarations:
>>
>>      type enum is ( red, blue, green, yellow );
>>      subtype myenum is enum range blue to green ;
>>
>>In this case, if we say something like "use work.pkg.myenum", 
>>then do all the enumeration literals associated with the base 
>>type become visible or just blue and green?
>>
>>-ajay
>>
>>    
>>
>
>
>  
>