[sv-ac] RE: Your feedback on 2093: Checker construct should permit output arguments

Dmitry,

Thanks for adding that note. I don't really understand the explanation about untyped output arguments for net_lvalue actuals, why the formal output argument wouldn't be a variable of the type of the actual. The kind of the data object (net vs. variable) is not an attribute of its data type. I would have thought that "output untyped res" for an actual net "w" would yield the same as "output $type(w) res".

Outside the note, I'm not entirely convinced on is "Having a default type for input arguments, but not for output ones may be confusing." But OK I can rely there on your prediction of the mind of the typical checker author.

-- Brad

________________________________________
From: Korchemny, Dmitry [dmitry.korchemny@intel.com]
Sent: Wednesday, October 12, 2011 4:47 AM
To: Brad Pierce; sv-ac@eda-stds.org
Subject: Your feedback on 2093: Checker construct should permit output arguments

Hi Brad,

Please, find below our comments to your feedback:

Some of the restrictions seem arbitrary, and there's no justification given for
them in the preamble.

---
We added the following note to the preamble:
“This proposal does not permit output checker arguments to be untyped. This limitation is not necessary in principle, but the consequences of introducing output untyped checker arguments should be well understood, for example their implications to the incremental compilation, etc. Another point to be considered is that the definitions of input and output untyped arguments are different. For input arguments untyped means substitution in place, whereas for output arguments untyped means creating a formal argument of the same type as the actual one. What should the formal argument be if the actual argument is a net? Currently checkers do not allow nets; therefore any output formal argument should be a variable. If at some point nets become legal in checkers, what should the semantics of the output untyped argument be? To avoid potential future back-incompatibility issues, the current proposal rules untyped checker output arguments out.”
---
1) "If the argument has an explicit direction qualifier, it shall be an error
   to omit its type." Why? "untyped" is a natural default, especially
   considering that "if the argument is the first argument of the checker, it
   is assumed to be input untyped". I can omit "untyped" only if I also omit
   "input"? Why?
---
Since there is no untyped option for output arguments, it is impossible to have a default type for output arguments. Having a default type for input arguments, but not for output ones may be confusing.
---
2) "The type of an output argument shall not be of untyped, sequence, or
   property." Why not "untyped"? Very inconvenient. Even example 1 in the
   preamble uses "output untyped".
Unless there are compelling reasons for these inconveniences, I think "output
untyped" should be legal and the default type for both "input" and "output"
should be "untyped".
---
See the comments above.
---
Other minor issues,
In "In a similar manner to sequences and properties a checker declaration may
specify a default value for each singular input port", the first part seems
superfluous to me in a standard. Why not just "A checker declaration may
specify a default value for each singular input port"?
---
This is substantial. The entire sentence reads: “In a similar manner to sequences and properties a checker declaration may specify a default value for each singular input port, as described in 16.8.”, and it provides a reference to the specific rules in 16.8, e.g., that $ can be a default value of a checker input argument.
---
"A.18" should be "A.1.8".
---
Fixed.
Thanks,
Dmitry
---------------------------------------------------------------------
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.