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

This is the kind of feature interaction that is very problematic
in the current language definitions.  I definitely appreciate
the always_comb issue and how it corresponds; that in fact
dovetails with an issue about which I've touched base with Karen P.
and which will also be raised.

There are, in my mind, a couple of alternatives:
   1) go the functional programming route and begin to talk about
      "closures" and require that such references retain access
      to their closure.
   2) restrict the use of "escaping" references within interfaces
      so that the closures are empty.

Interfaces are an issue right now since in some contexts people
want to think about them as "fancy macros" that expand to
be real references and in other cases they are talked about
as being equivalent to hierarchical references to things.
The semantic of interfaces have not, in my mind, been well
enough defined to have a clear model for what the "right"
answer is with respect to other features.  As a result, I think
that we're seeing relatively ad hoc definitions that in
other contexts don't make sense.

I'd rather have a clear and consistent semantic model, even if it
is more restrictive, than what we appear to have at this point.

I suspect that some people would object to requiring functions
to be pure within interfaces, so perhaps the right approach
is to adopt a "closure" semantic model.

Gord.

Mark Hartoog wrote:

>>Obviously, one expects "p" in "foo" to be the parameter.  This
>>is clear and is the case in virtually any language.  Why should
>>the name binding of a default parameter value be any different?
>>
>>The arguments over static versus dynamic name binding are decades
>>old.  Is there something distinct about this context that leads
>>one to disregard that history?
> 
> 
> I have no objection to changing it to this, but this is not what 
> the LRM currently says. You might want to think about the 
> following case:
> 
> interface if();
> int a;
> function foo( input int x = a);
>    return x;
> endfunction
> 
> modport bus ( import function foo);
> endinterface
> 
> module m(if.bus i);
> int y;
> initial y = i.foo();
> endmodule
> 
> module top();
> if i();
> m u(i);
> endmodule
> 
> I think the current LRM makes this illegal, and your proposal would make
> this legal, but for this to be legal, does the modport 'bus' need to 
> include 'a' as an input port so that the module calling the function 
> 'foo' can pass it as the default argument? 
> 
> We already have this issue in always_comb blocks. If the function foo had
> no arguments, but just returned the value of 'a' and it was called from
> an always_comb block, then that always_comb block has to be sensitive to 'a'.
> It is unclear whether 'a' has to be an input port in the modport for this
> to be legal.
> 
> Gordon Vreugdenhil wrote: 
> 
>>Mark Hartoog wrote:
>>
>>>In addition to the possibilities mentioned by Gord, you could also outlaw
>>>the use of non-constant default values on all hierarchical or interface
>>>function/task calls. You might still have some confusion for the case:
>>>
>>>module A();
>>>parameter p = 1;
>>>function int foo(int x = p);
>>>   return x;
>>>endfunction
>>>
>>>initial
>>>begin
>>>   int p = 2;
>>>   $display(foo());
>>>end
>>>
>>>endmodule
>>>
>>>Is this legal? If so, what value is displayed? 
>>
>>
>>In my version of reality, of course it is legal.  The "p"
>>in the default value binds to A.p.  The value displayed is "1".
>>There is no confusion here just as there is no confusion if
>>you have:
>>
>>   module A();
>>   parameter p = 1;
>>   function int foo;
>>      return p;
>>   endfunction
>>
>>   initial
>>   begin
>>      int p = 2;
>>      $display(foo());
>>   end
>>   endmodule
>>
>>
>>Obviously, one expects "p" in "foo" to be the parameter.  This
>>is clear and is the case in virtually any language.  Why should
>>the name binding of a default parameter value be any different?
>>
>>The arguments over static versus dynamic name binding are decades
>>old.  Is there something distinct about this context that leads
>>one to disregard that history?
>>
>>Gord.
>>-- 
>>--------------------------------------------------------------------
>>Gordon Vreugdenhil,  Staff Engineer               503-685-0808
>>Model Technology (Mentor Graphics)                gordonv@model.com

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