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

In my email, this was the question too, if we change it to be the actual
arg type, fine, but do we not lose backward compatibility? Should there
be some other function in that case? like typearg()?

ed 

> -----Original Message-----
> From: Rich, Dave [mailto:Dave_Rich@mentor.com] 
> Sent: Wednesday, April 11, 2007 3:12 AM
> To: Korchemny, Dmitry; Eduard Cerny; Brad Pierce; sv-ac@eda-stds.org
> Subject: 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.