RE: [sv-bc] 8.13.1 Array assignment patterns

Can a default value be an aggregate value, such as a structure or an
array (sub-array)?

This does not seem to be clearly stated.

Thanks,
Shalom


> -----Original Message-----
> From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]
> Sent: Wednesday, December 21, 2005 1:41 AM

> > 8.13.1 says,
> > "The default:value applies to elements or subarrays that are
> not matched by either index or type key. If the type of the
> element or subarray is a simple bit vector type, matches the
> self-determined type of the value, or is not an array or
> structure type, then the value is evaluated in the context of
> each assignment to an element or subarray by the default and
> must be castable to the type of the element or subarray;
> otherwise, an error is generated. For unmatched subarrays, the
> type and default specifiers are applied recursively according
> to the rules in this clause to each of its elements or
> subarrays. For unmatched structure elements, the type and
> default keys are applied to the element according to the rules
> for structures."
> >
> > Although I think I understand the intent of this paragraph, I
> find the wording very difficult.
> >
> > It seems to say the following (2nd sentence, my additions in
> uppercase):
> >
> > "If the type of the element or subarray is a simple bit
> vector type OR IF THE TYPE matches the self-determined type of
> the value OR IF THE TYPE is not an array or structure type,
> then the value is evaluated in the context of each assignment
> to an element or subarray by the default and must be castable
> to the type of the element or subarray; otherwise, IF THE TYPE
> DOES NOT MEET ONE OF THESE 3 CONDITIONS, an error is
> generated."
> >
> > It seems to say that either one of the 3 conditions is met or
> an error is generated.
> 
> The second sentence here runs-on too long for its own good.
> Your parse is accurate, and shows that this text does not
> capture
> the design intent.
> 
> One problem is the "; otherwise" conjunction, which should NOT
> be
> offering an alternative to the three-part conditional.  It only
> describes what happens when a "default:value" clause matches
> some
> element (or subarray) under one of those three conditions but
> whose value fails to be castable to the element (subarray)
> type.
> In such a case, an error issues.  The "match" succeeds - no
> further
> recursion happens - but the assignment operation fails!
> 
> The larger problem is that it has proven hard to express the
> precedence order between the different clauses AND how the
> recursion (of "type:" and "default:" clauses) applies to all
> unmatched elements.
> 
> I'd prefer rewriting these sentences; they should specify:
>    - When defaults are considered
>    - What it means for a default to "match"
>    - What happens on a match
>    - What happens to things that didn't match.
> 
> "Elements or subarrays that do not match any "index:" or
> "type:"
>   specifier become candidates to match a "default:value"
> specifier."
> 
> 
> "An element or subarray matches a given "default:value"
> specifier if it:
>    - has a simple bit vector type,
>    - has a type which matches the self-determined type of the
> value, OR
>    - does not have an array or structure type."
> 
> 
> "Each element or subarray that matches a "default:value"
> specifier
>   becomes (the left hand side of) an assignment context in
> which the
>   (right hand side) value is actually evaluated.  This value
> must be castable
>   to the type of the element or subarray; otherwise, an error
> is generated."
> 
> 
> "Subarrays that do not match any "index:", "type:", or
> "default:" specifier
>   are assigned a new pattern consisting of just the "type:" and
> "default:"
>   specifiers of the current pattern by recursively applying the
> rules
>   of this clause to each unmatched subarray."
> 
> 
> "Elements with a structure type that do not match any "index:",
> "type:", or
>   "default:" specifier are assigned a new pattern consisting of
> just the
>   "type:" and "default:" specifiers of the current pattern by
> recursively
>   applying the rules for structure-valued assignment patterns
> (see 8.13.2)."
> 
> 
> An analogous edit for 8.13.2 should be pretty obvious.
> 
> This is actually wordier than the C code needed to implement
> it.
> But we were too aggressive compressing it into a simple
> paragraph.
> So it's probably safer to lay it all out in tedious prose.
> 
> As you can see, this longer version uses all of the clauses
> from
> the existing text and it captures the discussions we had in sv-
> bc
> committee during the several meetings devoted to resolving
> these
> issues.  The key resolutions were: to consider the self-
> determined
> typee of the default specifiers, to use multiple context-
> determined
> evaluations of the default value expressions, to recurse into
> packed
> structure types, and to permit assignment coercions of scalar
> and simple bit vector types.  It is not my intent to reconsider
> those choices - recall that they are rather intricately
> interrelated.
> 
> Hope this helps, and sorry for my role in any confusion,
> 
> Greg Jaxon
> 
> 
> 
> 
> 
> >
> > Then it says,
> > "For unmatched subarrays, ... For unmatched structure
> elements, ..."
> >
> > These seem to talk about cases where none of the 3 conditions
> is met. But we said that an error is generated in that case.
> >
> > Even if I am misreading the text, it means that the text is
> at best unclear.
> >
> > Please clarify.
> >
> > 8.13.2 has a similar problem.
> >
> >
> > Thanks,
> > Shalom