RE: [sv-bc] Serious issue with default expressions for task and function arguments

Mark,

I think you and Gord are probably in agreement. I think Gord was trying
to go a bit further in saying that the boundary that defines a region of
ambiguity can not be itself ambiguous.

I think we need to take a step back and see what the original purpose of
this feature was. I think it was to connect the names of commonly used
actual arguments with identically named formals. Seems exactly like what
.* does for port connections, something the EC was probably not aware
of. I don't think the EC ever intended the level of complexity that you
folks are trying to work out.

I suggest we make things much simpler and just use the declaration
context for default values and add .* functionality to task arguments.

Adam Krolnik made a proposal over a year and a half ago:

http://www.eda.org/svdb/bug_view_page.php?bug_id=0000096

Dave


> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Mark
> Hartoog
> Sent: Friday, March 04, 2005 1:11 PM
> To: Vreugdenhil, Gordon; Mark Hartoog
> Cc: Greg Jaxon; ieee1800@eda.org; SV_BC List
> Subject: RE: [sv-bc] Serious issue with default expressions for task
and
> function arguments
> 
> Gordon Vreugdenhil wrote:
> > Mark Hartoog wrote:
> > [...]
> > > My opinion is that engineers are not language experts, and giving
an
> > > error when there is any ambiguity in what the default value
expression
> > > means is ok. I would just like to point out that the other
languages
> > > with this feature do not have things like hierarchical functional
> calls
> > > or interface function calls, which make this issue more
complicated.
> >
> >
> > Mark, the problem with this approach is that we're defining
> > a *standard*.  If you really want to permit ambiguity and room
> > for interpretation, fine, define the minimal required situations
> > in which something is guaranteed to have known behavior and
> > then add language for the remainder to the effect that
"implementations
> > may choose....".  Then it is clear to the users AND the implementors
> > what the base standard behavior is that one can rely on.
> 
> That is not what I meant at all.
> 
> Some knowledgeable people seem to expect default value expressions to
be
> evaluated in caller context. Other knowledgeable people expect default
> value expressions to be evaluated in the function/task declaration
> context.
> 
> Given this disagreement between knowledgeable people, we could simple
vote
> and pick one by majority vote on the committee, or we could say that
if
> it is not obvious to us, then it will not be obvious to users either,
and
> change the *standard* to say that any case were these two
interpretations
> might give different answers is illegal.
> 
> Mark Hartoog
> 700 E. Middlefield Road
> Mountain View, CA 94043
> 650 584-5404
> markh@synopsys.com