From: Steven Sharp (email@example.com)
Date: Wed Jan 23 2002 - 16:18:00 PST
>> Also note that this is not the only situation where multiple attributes with
>> the same name can appear on the same object. We debated what to do if the
>> same attribute name is attached redundantly (e.g. produce an error, produce
>> an error only if the values don't match, use the last value seen). We
>> decided not to do anything about that either.
>Are you sure? :-) Section 2.8, page 14, last paragraph, states:
> "If the same attribute name is defined more than once for the same language
> element, the last attribute value shall be used ..."
Well, no, I'm not that sure. I don't know whether I am remembering wrong,
or whether the editor failed to remove that text. It doesn't appear in
draft 5, which tends to indicate that it was deliberately added. There
might be some meeting minutes with more detail.
It isn't a big deal either way. I can't think of any straightforward
situations where there would be a use for attaching the same attribute
multiple times to a single object. Saving applications the effort of
having to account for the possibility may be worthwhile.
>> >Yes, it seems the attribute object diagram in section 26.6.42 is missing
>> >several objects that can hold attributes according to the BNF. Notably,
>> > "IODecl"
>> > "ContAssign"
>> > "DefParam"
>> > "Parameter"
>> This is unfortunate. I expect implementors will extend the VPI to allow
>> access to these if it turns out anyone actually has a use for them.
>Perhaps an errata is appropriate?
Somebody on the PLI task force should probably make sure we haven't missed
>I was thinking of attributes attached to input/inout/output declarations
>as in my example with a port defined as a concatenation of three inputs
>in my original mail.
>If we agree that "IODecl" should be included in the diagram of section 26.6.42,
>then perhaps my issue is resolved.
I was assuming that you were correct and "IODecl" should be included.
>> My guess would be that this was a matter of getting carried away with
>> attaching attributes to everything in sight, and that such attributes
>> would be meaningless.
>Should this be an errata as well?
Unless somebody can come up with a use for an attribute on a generate and
defines a VPI mechanism for accessing them, I would say yes.
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:34 PDT
sponsored by Boyd Technology, Inc.