RE: [sv-ec] Re: Arguments to "randomize" method calls

Gord, Arturo,

Here is an additional alternative.

Remove the special scope rule for the arguments to a
class randomize method and remove the restriction that
the arguments (actuals) must be simple names. Then add
the semantic restriction that an actual to a class 
randomize function must refer to member of the class. 
Finally specify the arguments (formals) of randomize 
as 'ref' arguments.

So instead of
	st = x.randomize(a,b);
we would have
	st = x.randomize( x.a, x.b );


- Ray


> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On 
> Behalf Of Vreugdenhil, Gordon
> Sent: Wednesday, March 08, 2006 8:03 AM
> To: Arturo Salz
> Cc: SV_EC List
> Subject: Re: [sv-ec] Re: Arguments to "randomize" method calls
> 
> 
> 
> Arturo Salz wrote:
> 
> > Gord,
> > I see your point. Yes, this is the same old ambiguity due to 
> > hierarchical references. This type of ambiguity is 
> typically resolved 
> > by deferring the code generation until after elaboration (or by 
> > generating generic code to be interpreted at run time). But in the 
> > case of the randomize method this seems more severe because it 
> > involves different name binding semantics so it's harder to either 
> > defer or interpret at run-time. Do you have any ideas that may 
> > alleviate this problem?
> 
> The code gen issues could be handled (although it would be 
> horrendously ugly) -- the semantic issues involving things 
> like package import can't.  In particular if the name "x" 
> isn't defined but is a potentially visible name, the compiler 
> can't determine whether it actually needs to import "x" into 
> the local scope.  The reverse is also true; if this is a user 
> call and the compiler doesn't import "x", it would be 
> required to figure out all the impact of having done so and 
> retroactively apply that impact at elab time.  That seems a 
> bit over the top.
> 
> I can think of several ways to resolve this:
>    1) disallow hierarchical calls with named members (seems harsh)
>    2) require at least a trivial inline constraint for
>       disambiguation purposes
>    3) make "randomize" a keyword (disallowing a user task 
> with that name)
>    4) make the member name a string rather than an ident
>    5) introduce some other syntactic form -- perhaps a prefix
>       such as "member.x" or similar that is valid in only this
>       context.
> 
> I am predisposed to a syntactic differentiator -- based on 
> the principle of "least surprise", if something is different, 
> we should make it look different.  I'd prefer to have "x"
> look different.  Although I don't usually like highly context 
> sensitive rules, a "member." prefix is somewhat appealing to me.
> 
> If a syntactic change is not acceptable, then either 2 or 3 
> is probably the best.  I know that adding more keywords won't 
> be on anyone's preferred solution so perhaps (2) would be my 
> next suggestion.
> 
> Gord.
> 
> > 
> >             Arturo
> 
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
>