RE: [sv-ac] Mantis #1647: Updated proposal

How is it that $issequence(q) knows about the actual type of q, but you
think type(q) can only know about the formal type of q? 

Put another way, why can't type(q) be defined to return the actual type
of q?

> -----Original Message-----
> From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
> Sent: Tuesday, April 10, 2007 11:51 PM
> To: Rich, Dave; Eduard Cerny; Brad Pierce; sv-ac@server.eda-stds.org
> Subject: RE: [sv-ac] Mantis #1647: Updated proposal
> 
> Hi Dave,
> 
> Consider the following example:
> 
> property p(sequence s, property q);
>     if ($issequence(q))
> 	s ##0 q;
>     else
> 	not (s |-> not q);
> endproperty
> 
> If you consider the formal argument type, this code is meaningless
since
> not (s |-> not q) will always be synthesized. The intention is that if
> the actual argument is a sequence (e.g., a ##1 b) then the first
clause
> will be synthesized. What will type(q) return? I think it should
always
> be property.
> 
> Thanks,
> Dmitry
> 
> -----Original Message-----
> From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org]
On
> Behalf Of Rich, Dave
> Sent: Wednesday, April 11, 2007 9:16 AM
> To: Eduard Cerny; Brad Pierce; sv-ac@server.eda-stds.org
> Subject: RE: [sv-ac] Mantis #1647: Updated proposal
> 
> Ed,
> 
> I think that's a brilliant idea to use the relational operators for
> testing the partial ordering of types and these 'virtual' types.
> 
> I still don't see a difference between the types of formal and actual
> arguments of properties and sequences. Since the formal arguments of
> properties and sequences are type-less in the current LRM, these
formal
> arguments are replaced by actual arguments in the elaboration process
> and the formals disappear. The enhancement that allows you to declare
> formal argument types doesn't change that process; it just restricts
the
> actual types.
> 
> If you do think there is a difference in the formal and actual
argument
> types after elaboration, the $issomething(arg) proposal would have the
> same problem.
> 
> Dave
> 
> 
> 
> > -----Original Message-----
> > From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com]
> > Sent: Sunday, April 08, 2007 7:38 AM
> > To: Rich, Dave; Brad Pierce; sv-ac@eda-stds.org
> > Subject: RE: [sv-ac] Mantis #1647: Updated proposal
> >
> > Hello,
> >
> > would it be too crazy to define some "virtual" types like
"integral",
> > "class", "property", "sequence", etc. and a partial order over all
> types
> > defined by a relation is_derived or member_of.
> >
> > Then we could use type(x) == type(y) as strict equivalence, type(x)
<
> > type(y) as x is derived from y or member_of y. For instance,
integral
> <
> > sequence < property.
> >
> > Perhaps we would have to use something else than "type" to apply
that
> to
> > the actual args rather than formal args.
> >
> > ed
> >
> >
> > > -----Original Message-----
> > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On
> > > Behalf Of Rich, Dave
> > > Sent: Wednesday, April 04, 2007 5:33 PM
> > > To: Brad Pierce; sv-ac@eda-stds.org
> > > Subject: RE: [sv-ac] Mantis #1647: Updated proposal
> > >
> > >
> > > >
> > > > Sequences and properties are not data types mentioned in Clause
4.
> > > Has
> > > > this been changed?  If not, is it OK to be talking about
"sequence
> > > data
> > > > type"?
> > > [DR>]
> > > Mantis 1549 introduced these new "types".
> > >
> > > If you can think of a sequence and property as a type, then
> > > there is no
> > > need for these system functions as we already have the type()
> function
> > > that lets you compare types in an elaboration context. I'd rather
> see
> > > type equality defined in terms to meet these requirements
> > > than introduce
> > > more language.
> > >
> > > Dave
> > >
> > >
> > > --
> > > This message has been scanned for viruses and
> > > dangerous content by MailScanner, and is
> > > believed to be clean.
> > >
> > >
> > >
> 
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.