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

Ray,

I like this -- it preserves the same behavior
for access as normal reference which means
that a "local" or "protected" member couldn't
be explicitly randomized externally (which I think
is a good restriction that isn't addressed in the
current LRM).

Gord.


Ryan, Ray wrote:

> 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
>>
> 
> 

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