John Havlicek wrote: > Hi Gord and All: > > The examples of recursive properties in Clause 16.12.4 include mutually > recursive ones that illustrate forward reference. > > While named sequences cannot be recursive, we have thought that the > similarity of the constructs merits treating them the same as > properties on this point. > > SV-AC have not yet, to my knowledge, considered the conflict between > forward reference and upward reference. > > How are mutually recursive functions or methods declared and > referenced in other parts of the language? The LRM doesn't actually address tasks and functions in a clear manner (that should come up on Monday's face-to-face). What all the implementations just "know" is that function and task enables are always resolved hierarchically, even when they are simple names. Once you get into a hierarchical (or topological) search, there is no notion of "forward" reference; something either is or is not in the scope. The LRM doesn't really have much notion of "sequencing" in the elaboration of a scope so it is up to the implementation to deal with the "is"/"is-not" in some manner. This is also why the determination of what is hierarchical is so critical -- hierarchical resolution is, in a sense, more declarative rather than the more procedural view that one might have in non-hierarchical resolution where "declaration before use" applies. > I expect that we should consider the tradeoff of sacrificing backward > compatibility with uniformizing the rules of references. I doubt there would be much in the way of compatibility issues if we just said "use the tf rules". The only likely issue would be in cases that don't resolve right now in the unparenthesized simple identifier forms. We'd have to be careful to make sure that the rules didn't admit upwards resolution to variables. They don't for task/function resolution due to the "scope" requirement in the upwards resolution; we'd simply have to ensure that something similar works out for sequences and properties. Gord. > > Note also that Clause 16 clearly says that named sequences and > properties may be referenced by hierarchical name. Curiously, though, > the syntax does not seem to allow this. We need to fix that. > > J.H. > > >> X-Authentication-Warning: server.eda-stds.org: majordom set sender to owner-sv-ac@eda.org using -f >> Date: Thu, 20 Sep 2007 13:40:07 -0700 >> From: Gordon Vreugdenhil <gordonv@model.com> >> Cc: SV_BC List <sv-bc@eda-stds.org>, SV_EC List <sv-ec@eda-stds.org>, >> sv-ac@eda-stds.org >> X-OriginalArrivalTime: 20 Sep 2007 20:40:08.0008 (UTC) FILETIME=[6E8B7C80:01C7FBC6] >> X-eda.org-MailScanner: Found to be clean, Found to be clean >> X-Spam-Status: No, No >> Sender: owner-sv-ac@eda.org >> X-eda.org-MailScanner-Information: Please contact the ISP for more information >> X-eda.org-MailScanner-From: owner-sv-ac@server.eda.org >> >> I think, but am not sure, that the "forward" for a property >> or sequence is not quite the same. In particular, I don't >> think that there is upwards resolution through the instance >> tree. >> >> Hopefully someone from AC can give a better explanation >> of the intent on this part. >> >> Gord. >> >> Bresticker, Shalom wrote: >>> Gord, >>> >>> Re item (3), do references to properties and sequences use the same >>> rules as references to tasks and sequences? The LRM says that 'forward' >>> references work. Beyond that, it is not clear. If they are like tasks >>> and functions, then a non-dotted reference would find them in an upwards >>> hierarchical scope, for example. >>> >>> Thanks, >>> Shalom >>> >>>> -----Original Message----- >>>> From: owner-sv-bc@server.eda.org >>>> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Gordon Vreugdenhil >>>> Sent: Thursday, September 20, 2007 7:34 PM >>>> To: SV_BC List; SV_EC List >>>> Subject: [sv-bc] Name resolution - questions and issues review >>>> >>>> All, >>>> >>>> Francoise asked for a summary of some of the name resolution >>>> issues. I don't want to try to capture all of the issues >>>> here since at least the very contentious issues were >>>> discussed exhaustively on the reflector. >>>> >>>> Here are some of the more basic issues that need clarification: >>>> 1) how "static" is :: ? Can you have "::" on a forward type? >>>> 2) how package like is $unit? Are later declarations visible? >>>> Is it even possible (as with a hierarchical reference in >>>> a module) to create a forward reference? >>>> 3) we need to agree on a statement regarding "declaration before >>>> use" to make things more explicit and explain exactly how >>>> exceptions (functions, etc) work. >>>> 4) when does a dotted name become a select versus a hierarchical >>>> name? Can you forward reference a struct variable member >>>> just because the reference contains a dot? >>>> 5) Is a clocking blocks a scope? If so, does that imply that all >>>> "cb.a" forms are inherently hierarchical and always bind using >>>> the hierarchical resolution rules? >>>> 6) we need to discuss forward visibility in non-opaque classes >>>> 7) management of $unit and package lookup during hierarchical >>>> name resolution >>>> 8) handling of package imports for bind >>>> 9) basic discussion of issues related to modports >>>> >>>> There are certainly more issues here, but the above is >>>> probably a fair sampling of issues for which the LRM should >>>> be much more clear. >>>> >>>> >>>> Here are some links to relevant reflector discussion between >>>> Mark and I: >>>> () Gord's very early (incomplete, etc) algorithm for >>>> basic resolution in June, 2006: >>>> http://www.eda-stds.org/sv-bc/hm/4623.html >>>> () a later form of Gord's basic approach in more of a rule form >>>> http://www.eda-stds.org/sv-ec/hm/4346.html >>>> () Mark's basic approach to name resolution >>>> http://www.eda-stds.org/sv-bc/hm/6472.html >>>> () a summary related to how type parameters interact >>>> http://www.eda-stds.org/sv-bc/hm/6567.html >>>> () a summary of some of the issues related to type referencing >>>> http://www.eda-stds.org/sv-bc/hm/6667.html >>>> >>>> There are many other issues and examples floating about. >>>> Here are a few that Mark and I have raised very early on. >>>> I'd have to re-evaluate where we both are on all of these. >>>> http://www.eda-stds.org/sv-bc/hm/6017.html >>>> http://www.eda-stds.org/sv-bc/hm/6029.html >>>> >>>> >>>> I am working on a powerpoint agenda for Monday and am >>>> planning on including the 9 basic issues above as well as a >>>> shorter summary of the long back-and-forth that Mark and I have had. >>>> >>>> If anyone has substantial questions that don't appear to be >>>> covered in 1-9, please let me know and I'll add them to my >>>> questions and issues list. >>>> >>>> >>>> Gord. >>>> -- >>>> -------------------------------------------------------------------- >>>> Gordon Vreugdenhil 503-685-0808 >>>> Model Technology (Mentor Graphics) gordonv@model.com >>>> >>>> >>>> -- >>>> This message has been scanned for viruses and >>>> dangerous content by MailScanner, and is >>>> believed to be clean. >>>> >>> --------------------------------------------------------------------- >>> Intel Israel (74) Limited >>> >>> This e-mail and any attachments may contain confidential material for >>> the sole use of the intended recipient(s). Any review or distribution >>> by others is strictly prohibited. If you are not the intended >>> recipient, please contact the sender and delete all copies. >>> >> -- >> -------------------------------------------------------------------- >> Gordon Vreugdenhil 503-685-0808 >> Model Technology (Mentor Graphics) gordonv@model.com >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Sep 20 16:18:00 2007
This archive was generated by hypermail 2.1.8 : Thu Sep 20 2007 - 16:19:01 PDT