RE: [sv-bc] Aggregate expressions

That sentence does not preclude a data object from being other things.
In fact, the construction of a class is an object that does not have a
name.

Dave


> -----Original Message-----
> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> Sent: Tuesday, March 04, 2008 11:57 PM
> To: Rich, Dave; Greg Jaxon
> Cc: sv-bc
> Subject: RE: [sv-bc] Aggregate expressions
> 
> A data object is not defined that in the LRM. 6.2 says,
> 
> "A data object is a named entity that has a data value associated with
> it, such as a parameter, a variable, or a net."
> 
> And the LRM consistently uses 'data object' with that meaning. You
can't
> change its meaning in a single place.
> 
> Shalom
> 
> > -----Original Message-----
> > From: owner-sv-bc@server.eda.org
> > [mailto:owner-sv-bc@server.eda.org] On Behalf Of Rich, Dave
> > Sent: Wednesday, March 05, 2008 9:46 AM
> > To: Bresticker, Shalom; Greg Jaxon
> > Cc: sv-bc
> > Subject: RE: [sv-bc] Aggregate expressions
> >
> > It sure is - essentially it's an anonymous variable.
> >
> > > -----Original Message-----
> > > From: owner-sv-bc@server.eda.org
[mailto:owner-sv-bc@server.eda.org]
> > On
> > > Behalf Of Bresticker, Shalom
> > > Sent: Tuesday, March 04, 2008 11:31 PM
> > > To: Greg Jaxon
> > > Cc: sv-bc
> > > Subject: RE: [sv-bc] Aggregate expressions
> > >
> > > But an assignment pattern is not a data object.
> > >
> > > Shalom
> > >
> > > > -----Original Message-----
> > > > From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]
> > > > Sent: Tuesday, March 04, 2008 6:14 PM
> > > >
> > > > How about?
> > > >
> > > > "Unpacked structure and array data objects, including those
> > > > constructed using assignment patterns, can be combined into
> > > > aggregate expressions."
> > > >
> > > > The paragraph that follows /is/ sort of a hodge podge.
> > > > Sentences seems to just be throwing some things into the pot of
> > > > "unpacked data object"
> > > > and others throw operators like equality into the pot of
> > aggregate
> > > > expression.
> > > > I agree that ?: is an aggregate expression operator.
> > > >
> > > > We're a long way from thinking of this as a first class array
> > > > language.
> > > >
> > > > Greg
> > > >
> > > > Bresticker, Shalom wrote:
> > > > > Does anyone object to the editor replacing 'constructors' with
> > > > > 'assignment patterns'?
> > > > --------------------------------------------------------------
> > > > >     *From:* owner-sv-bc@server.eda.org
> > > > >     [mailto:owner-sv-bc@server.eda.org] *On Behalf Of
> > > > *Bresticker, Shalom
> > > > >     *Sent:* Thursday, February 28, 2008 12:20 PM
> > > > >
> > > > >     I also don't think the term 'aggregate expression' is
> > > > well defined.
> > > > >
> > > > >     I also don't think the first sentence makes sense:
> > > > >     "Unpacked structure and array data objects, as well as
> > unpacked
> > > > >     structure and array constructors, can all be used
> > as aggregate
> > > > >     expressions."
> > > > >
> > > > >     What is meant by "unpacked structure and array
> > > > constructors," which
> > > > >     are different from data objects?
> > > > >
> > > > >     The version of this sentence in SV 3.1a is,
> > > > >
> > > > >     "Unpacked structure and array variables, literals, and
> > > > expressions
> > > > >     can all be used as aggregate expressions."
> > > > >
> > > > >     So "literals and expressions" are contrasted to
"variables".
> > In
> > > > >     1800, we still have structure and array "literals". But
what
> > are
> > > > >     called structure and array "expressions" in 3.1a, are now
> > called
> > > > >     "assignment patterns". Since structure and array
> > > > literals are a form
> > > > >     of assignment patterns, I think "constructors" in
> > the sentence
> > > > >     should be replaced with "assignment patterns".
> > > > >
> > > > >     Shalom
> > > >
> >
----------------------------------------------------------------------
> > > \
> > > > >          *From:* owner-sv-bc@server.eda.org
> > > > >         [mailto:owner-sv-bc@server.eda.org] *On Behalf Of
> > > > *Bresticker,
> > > > >         Shalom
> > > > >         *Sent:* Thursday, February 28, 2008 11:47 AM
> > > > >
> > > > >         I don't think this paragraph was intended to be a
> > > > complete list.
> > > > >
> > > > >         Shalom
> > > > --------------------------------------------------------------
> > > > >             *From:* owner-sv-bc@server.eda.org
> > > > >             [mailto:owner-sv-bc@server.eda.org] *On Behalf
> > > > Of *danielm
> > > > >             *Sent:* Thursday, February 28, 2008 11:40 AM
> > > > >
> > > > >             1800-2005 states :
> > > > >             Unpacked structure and array data objects,
> > as well as
> > > > >             unpacked structure and array constructors, can
> > > > all be used
> > > > >             as aggregate expressions. A multi-element
> > slice of an
> > > > >             unpacked array can also be used as an aggregate
> > > > expression.
> > > > >             Aggregate expressions can be copied in an
> > assignment,
> > > > >             through a port, or as an argument to a task or
> > function.
> > > > >             Aggregate expressions can also be compared with
> > > > equality or
> > > > >             inequality operators. To be copied or compared,
> > > > the type of
> > > > >             an aggregate expression must be equivalent.
> > See 6.9.2.
> > > > >             IMHO there is more expression when aggregate
> > > > expression are
> > > > >             sensible i.e: conditional operator (?:), function
> > return
> > > > >             value. Maybe there are more?
> > > > >
> > > > >             Will 1800-2005 add some operators to this
> > description?
> > > > >
> > > > >             DANiel
> > >
> >
---------------------------------------------------------------------
> > > Intel Israel (74) Limited
> > >
> > > This e-mail and any attachments may contain confidential
> > material for
> > > the sole use of the intended recipient(s). Any review or
> > distribution
> > > by others is strictly prohibited. If you are not the intended
> > > recipient, please contact the sender and delete all copies.
> > >
> > >
> > > --
> > > 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.
> >
> >
> >
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.


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