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

I discussed this problem with Arturo. His original intention was
that the default value expressions be macros that were substituted
into the call context when required and that all interpretation 
of the default value expressions would be in the caller context.
This would mean that identifiers used in the default value expressions
would not even need to be defined in the scope of the function declaration.

The EC committee did not like that idea, and insisted that the
expressions had to be valid in the scope of the function also. The
result was the language that is now in the LRM, "The elements of 
the expression must be visible at the scope of subroutine". Arturo
thought this meant the "the symbols of the expression must be visible 
at the scope of subroutine", but he did not think they needed to resolve
to the same underlying objects as in the calling context. This is not
what I took this to mean. I do not know what other members of the EC
committee thought it meant. 

The term "elements of the expression" is not well defined in my mind.
The term "elements of the array" is commonly used and I think everyone
knows what that means. To me elements are not the symbols, but rather
the objects the symbols refer to. Obviously other people think this
means the symbols or indenters. 

Gord is arguing for the opposite of Arturo's original idea, that the
default value expression should be evaluated in the context of the
function declaration. 

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 Hartoog
700 E. Middlefield Road
Mountain View, CA 94043
650 584-5404
markh@synopsys.com 

> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> Sent: Thursday, March 03, 2005 2:30 PM
> To: 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
> 
> 
> 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