Re: [sv-bc] Mantis 2106

Bresticker, Shalom wrote:
> If that is what you mean by saying that the block is automatic, OK, but
> that is not the same wording used by the LRM. The LRM says that the
> variables are automatic, not that the block is. I find it confusing. For
> example, in contrast to tasks and functions, you can't attach the
> keyword 'automatic' to the beginning of a block.

Yes, the "automatic block" is just shorthand for "a block in which
declarations are automatics by default".  If you'd like to
expand on that, fine.

>>> 2. "Variables declared inside a module, interface or program, but 
>>> outside a task, process, or function, are local in scope 
>> and static in 
>>> lifetime (exist for the lifetime of the module, interface 
>> or program)."
>>> Earlier, static is defined as "exist for the whole simulation".
>>>
>>> I think the parenthesized phrase should be deleted. It seems both 
>>> redundant and wrong.
>> Redundant, yes.  Wrong, no.  The lifetime of an instance is 
>> that of the simulation so the statements are equivalent.
> 
> Well, OK, but it does not make sense to define the same concept in two
> so different ways just a few lines distant from each other. Again I find
> it confusing. Why use a roundabout wording instead of a straightforward
> one? So you are OK with deleting that parenthesized phrase?

Oh, since I agreed that it was redundant, I certainly don't have
any problem with removing the comment.  Sorry, I should have
stated that clearly.


>>> Finally, I think the last sentence in 6.18, in the first 
>> part of 2106, 
>>> "It shall be an error if the type_identifier does not 
>> resolve to data 
>>> type, or basic data type if specified," has a grammar 
>> problem. Should 
>>> it be "a data type"?
>> Sure.
>>
>>
>>> In any case, I'm not sure of the meaning. What are examples of a 
>>> type_identifier resolving to a data type and to a basic data type?
>> The idea that Dave was trying to address (I think) 
> 
> Well, if you're not sure, then it definitely needs clarification!

Agreed.

>> was that given:
>>      typedef class C;
>> "C" has a "basic data type" of "class".  So the actual type 
>> definition of "C" must match the basic data type (i.e. be a 
>> class).  If no "basic data type" is given in a forward, the 
>> actual definition can be anything.
>>
>> Perhaps this should be something like:
>>
>>     It shall be an error if the type_identifier does not 
>> resolve to data type.
>>     It shall be an error if a basic data type was specified 
>> by the forward
>>     type declaration and the actual type definition does not 
>> conform to the
>>     specified basic data type.
>>
>> I used "conform" here since I couldn't use "match".  If you 
>> really feel it necessary, you could add detail to say that a 
>> only a class conforms to a "class basic data type" and so on, 
>> but I think the straightforward English intent here should be Ok.
> 
> That sounds much clearer.
> 
> What do you think about the reorganization of 6.21?

No real opinion.  I generally don't worry about that kind
of thing too much unless I think that changes actual lead
to incorrect inferences in the applicability of the text.

Gord

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


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