RE: [sv-ec] RE: [sv-bc] Resolving name resolution

Jonathon,

Yes, I believe that is the key difference that Mark said he could not
see in his two examples. The 'with' clause has simple identifiers that
could either bind locally or bind to the object being randomized. The
latter example requires that you delay to the object, but if after
elaboration it is not found, it is an error.

What Gord and I are saying is that we want the decision about where to
search to be made at compile time. Without that, it becomes very
difficult to give useful error messages at compile time as well as
creating a bigger search space, which is prone to user errors that are
harder to detect.

It is difficult to define this in terms of backwards compatibility when
we have no rules to define what to be backwards compatible with. You are
essentially writing the 'with' clause from the perspective of a method
of that object, except that you don't have the visibility of that
method's scope.

My preference is to assume that identifiers inside the 'with' clause are
prefixed by 'this.' That will give us the most backwards compatibility
we can hope for. That also means that an explicit 'this.' or "super."
refers to the object being randomized, not the local 'this' or super. 

If you want to refer to an identifier outside that object, we have the
:: operator to access objects in other classes. Perhaps we could use
'local.' to mean not this, but that may present a parsing problem.

Another possibility is to assume that any identifier that is not a
simple identifier inside a 'with' clause binds locally, and you would
need to use an explicit 'this.' prefix to get to an identifier inside an
object.

Dave




> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Jonathan Bromley
> Sent: Wednesday, September 05, 2007 3:57 AM
> To: Vreugdenhil, Gordon; Mark Hartoog
> Cc: sv-bc; sv-ec@server.eda.org
> Subject: RE: [sv-ec] RE: [sv-bc] Resolving name resolution
> 
> I have been trying hard to follow these discussions,
> and I'm quite sure there are parts that have gone
> over my head; so, if I now show some naivety, I
> hope I can be forgiven.
> 
> It seems to me that - particularly in the last two
> emails from Gord and Mark - the dominant problem is:
> when does a name resolve through "this." (or, in the
> case of inline constraints, "item.") and when does it
> resolve outside the class of interest?  The answer to
> this question can be affected by code that is very,
> very far from the point of use, and which might change
> in an arbitrary and unpredictable way in the future.
> 
> From a user's point of view I absolutely agree that
> this is a problem.  It is much too easy to write code
> that unwittingly falls foul of this.  In particular,
> if I make reference from inside a class to a name in
> the environment, I would very much like to be able to
> force that reference to bind outside the class, just
> in case someone modifies the parent class in some way
> so that the binding might unexpectedly change.  As
> Gord has pointed out, it is not always possible or
> practicable to point the name explicitly at somewhere
> outside the class, since it might be something that
> has no hierarchical reference.
> 
> We can force a name to bind *inside* the class by
> using "super." or "this." but we have no explicit way
> to push the binding *outside*.  Is it worth exploring
> such a possibility - some syntax that would have no
> effect except to suppress the implicit "this." prefix
> of names referenced from within a class?
> The use of :: as a prefix springs to mind.
> 
> If we had *both* these options - explicit "this." and
> explicit "never-this." - it would become reasonable for
> tools to issue warnings in potentially ambiguous cases.
> A "never-this." prefix would also make it possible to
> get round the current absurdity of inline constraints
> whereby a name in the target class can irrevocably hide
> a name in the local scope.
> 
> I'm sure this doesn't cover all the concerns, but it's
> a change that would help me to deal with many of the
> situations that Gord and Mark have been discussing,
> and I'm fairly sure it could be done without breaking
> backwards compatibility.
> --
> Jonathan Bromley, Consultant
> 
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
> 
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
1AW,
> UK
> Tel: +44 (0)1425 471223                   Email:
> jonathan.bromley@doulos.com
> Fax: +44 (0)1425 471573                           Web:
> http://www.doulos.com
> 
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
> 
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.