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.comReceived on Wed Mar 8 08:03:00 2006
This archive was generated by hypermail 2.1.8 : Wed Mar 08 2006 - 08:03:52 PST