Sorry about that, the notes are attached this time. Neil Neil Korpusik wrote On 11/05/07 06:39 PM,: > Attached is a copy of my unofficial notes that I took during > the name resolution meeting that we had this morning. They will > not be approved as official minutes of the meeting, but some > of you may find them useful anyway. > > Neil > > > > > Gordon Vreugdenhil wrote On 11/05/07 02:11 PM,: > >>Here is a short summary of name resolution work that was >>discussed in today's meeting as well as some pending >>Mantis work that I know about. >> >>1) $unit :: is for disambiguation only >> >> Gord to propose >> >>2) rules for resolution into structs and classes in terms >> of downwards/upwards resolution >> >> Agreement: no "desperate binding" after we get to a struct >> or class attempt that fails >> >> Gord to propose >> >>3) tf binding rules for compilation units >> >> Current proposal is attached to 1809; no feedback yet. >> >>4) bind -- rules to follow suggestions discussed with AC >> -- no $unit/import refs; can only refer to names >> that would be hierarchically visible >> >> Mark to propose >> >>5) inline constraints -- can use "local ::" to bypass special >> resolution rules. Only permitted in an inline constraint. >> >> Arturo to propose >> >>6) typedef forms for type params, interface types, and forward types >> -- an explicit typedef is required to permit access to types >> within a class referenced through such forms >> >> Gord to propose >> >>7) extern method type resolution >> -- "parameterized_class :: " shall only be used for scoping and >> shall never denote a default specialization. >> -- "parameterized_class :: " shall be required for an extern function >> body declaration return type to name a type in the class >> -- "parameterized_class :: " shall only be legal within the parameterized >> class or an extern method >> >> Gord to propose >> >>8) forward typedefs to parameterized classes shall be legal. >> -- no definite agreement yet on whether such a forward would >> require an explicit specialization for the default type; >> Gord and Mark to post some examples for discussion. >> >> Mark to propose >> >> >>All - try to add "related" links to Mantis 2109 to track issues. >> >> >>Thanks to all for a very productive meeting. >> >> >>Please follow-up with any clarifications, corrections, etc. >> >>Gord. > > -- --------------------------------------------------------------------- Neil Korpusik Tel: 408-276-6385 Frontend Technologies (FTAP) Fax: 408-276-5092 Sun Microsystems email: neil.korpusik@sun.com --------------------------------------------------------------------- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. SV-EC Committee Meeting Monday November 5 2007 11:00am - 1:00pm PST Special meeting on name resolution issues "Unofficial notes" taken by Neil Korpusik This was a non-voting meeting. When you see (?) in these notes, it means I'm not sure I recorded it properly ------- Attendees ---------- Arturo Salz Dave Rich Francoise Martinolle Neil Korpusik Gordon Vreugdenhil Melvin Cardoza Mark Hartoog Mike Burns List of related mantis items: ---------------------------- Mantis 2109 - the anchor point for all name resolution mantis items. Agenda: ------- How to make progress on name resolution issues Dave - Has been writing up some proposals on what was agreed to so far. - declaration before use - he has written a proposal - Mantis 2106 Gord - a. task and functions - no feedback yet - Mantis 1809 b. bind issues svac is ok with what we talked about last time. It just needs to be written up c. $unit - Gord is writing it up - only used for disambiguation, not for forward references. d. downward resolution - Gord is writing it - will be tough to write up can't do a rewrite of all relevant sections - too time consuming AI/Mark - write up the bind stuff. Gord - would like to continue with a discussion on direction instead of existing specific mantis items. - authority of input and output for modports is one topic Mark - Gord are you ok with the local:: proposal? - some users like that local:: binds to the object first Gord - ok with it if users are ok with it Mike B. - still need a way to specify resolution outside of the object - if using an opaque type, users are expecting something to be there. Mark - local::obj forces it to look into the target object Gord - local:: implies this property must exist inside the object Mark - need to decide if local:: allowed anywhere other than 'randomize with' - allow for class extensions? Gord - only needed for 'randomize with' - not class extensions - type inheritance for opaque types (?) FM - why use 'local' instead of the object name? Arturo - you may not have the... Gord - inside a loop, automatic functions, etc. - there are cases that are problematic when trying to specify what is participating. Mark - 'a' that is being used and there is a variable named 'a' Gord - issues with imports and how resolutions happen there. - for a parameterized class, if the base is an opaque type, there is an explicit way to talk about the base (super) and can then default to visible resolution. Mark - local:: can be used to force outside the class. - if local:: used elsewhere it is a no op? - should local:: cause a wildcard import? Gord - if it is an error for the wildcard import case, need to be careful about going against normal resolution rules. - for inheritance, need to be careful about whether there are special rules or not. - local:: - for inline constraints - it is clear - not sure what it should be for other contexts. Mike B - axis of the names space local - just look at lexical scopes - his idea Gord - lexical scope for classes - can't split it that way can't have access to class properties that way(?). - opaque type as a base - what rules do you want to have, when you don't know if they resolve into the base or not. Dave - if don't say obj.randomize() Arturo - already in a class scope Dave - nothing special about 'with' clause anymore. - the only time 'with' is a problem is when say obj.randomize with() Arturo - only a problem when in the method of another class - 2 object are involved in that case. Gord - randomize with - in a method that has a local x the x in the inline are this.x (not the method x) - when call randomize with for an implied 'this' - the resolution rules get interesting Mark - a variable with same name as field of a class - issue a warning? Gord - there are 2 issues being mixed here - for inline constraints local:: - identifier is to use normal lookup rules for randomize Dave - obj.randomize with - local could say don't look inside Gord - the this can be implicit - can't talk about it structurally in this case. - if inside a method and call randomize with - can still have a problem. Need to be careful about what local means. obj. - part of it can be implicit Dave - this.randomize with - local:: Gord - start resolution in context of statement. - class properties take precedence in this case - agrees with Mark in that if there is possible confusion, the implementation should ask if you know what you are doing. - it is well defined, but could be a surprise Arturo - says that methodology can take are of these corner cases. Gord - local proposal follows the inline constraints Arturo - typical use of randomize with is not in IP Gord - let's now move off of inline constraints... Gord - local:: - could also be used for opaque base classes - not sure that it helps in that context still have issues with an undecorated identifier How deal with its resolution when in a method of a class that has an opaque base. Hard to know that to do if don't know if in the inheritance type. Arturo - can use 'super.' or 'this.' today Gord - what about the undecorated name Arturo - should have what it has today Dave - inline constraint - what is search rule in this case? -->Gord - first look into target object Arturo - then look into local scope Gord - local:: is strictly redundant except for inline constraint cases Mike - there isn't a target except for inline constraints (Gord agreed) Gord - local:: says to start searching with normal rules. - only has an effect when special rules are in effect - which is the inline constraint case. Mike B - 'with' is not a normal scope Dave - finally came around to agreeing with the gist of what Gord was saying about inline constraints being a special case. - would like to see similar syntax though Mark - if randomize with is only place that local:: will change anything, should we make it illegal for other places. Would allow future extensions without changing backward compatibility Mike B - if I were a user, would assume the following: when have a class in a module - using a type parameter if use local in this class - want local to go to module scope Gord - that is different from today - so in that case local would be defining new semantics. Mike B - would then prefer to not allow local in other places. Gord - agrees with Mark - disallow local:: in other places. - we currently only have a good use for it with inline constraints Mike B - is local the best word to use? Mark - local is already an existing keyword. FM - do we even need the word local - can we just use ::? Gord - not violently opposed to :: - possible parse issue FM - could use 'output' Mark - could use 'extern' Dave - can't we use a scope name? Gord - that may require a named block around the randomize call Dave - there may be a case to be made for upward referencing within a lexical scope Mark - if open that door, people may ask for that in other places. - What scopes can you refer to modulename::something - from not inside that module Not an upward reference in this case. Dave - clearly there needs to be some limit to allowing this needs to be a lexical scope, not a hierarchical scope Mark - it would need to be an upward reference, in other words Dave - name on LHS must have already been seen (declared) Gord - local:: - makes it clearly a special case Dave - local::function_name Gord - not a problem, go up the hierarchy - use same rules - local:: will bypass the set of special search rules - thats all Mike - also ok with the word local Gord - wants to ensure that the semantics of local:: are really clear Mark - special syntax that can only be used for randomize with calls. Gord - can only be used in an inline constraint (inside the {}) Mark - fears that there would be a lot of unforeseen issues if we allow in other places. Arturo - thought it could still be used for a method. OK to drop this if it would only cause more confusion. Mike - concerned that users would expect it to have special meaning. Dave - agreement reached to only allow local:: for constraint blocks Agreement was reached here on only allowing local:: for constraint blocks. AI/Arturo - do the writeup for the local:: rules (that were just agreed to) Mike B - dropped off here. His issues were already covered. Gord - typedef with a type parameter prefix - extern methods for parameterized classes Mark - thought we agreed on typedef points and we are ready for a proposal Gord - thinks that is also the case - if refer to a type in a class via a type typedef xx::name yyy; // I didn't catch all of this Arturo - thinks we already agreed to this. AI/Gord - writeup the typedef requirements Gord - extern methods for parameterized classes - hierarchical references through modports Mark - main issue for extern class methods for parameterized classes was what keyword to use Gord - also default specialization for C::T used inside and outside a class - the block form has the keyword issue - the word extern had a lot of opposition Arturo - 'use class' - prefers this - it is a verb Gord - 'inside class' - prefers this form Gord - leaning away from 'use class' in C++ it opens up the scope, here we are reentering a scope Mark - 'continue' FM - can we use C:: to mean unspecialized class type Gord - C - everywhere it is used as a type - treat as default specialization - C obj; // example - default specialization FM - C - could be used as default specialization - C:: - could mean a class scope Gord - C:: - couldn't use it outside the context of a class - appears that this would resolve all of the issues - C:: - this form is the only special form Gord - proposal - if have a parameterized class C C:: - only legal in scope of parameterized class or in one of its extern methods. Only used for name disambiguation. - C#()::method() - this means default specialization Gord - example - went out as an email during the meeting. class C #(int p = 1); static int x; typedef int T; endclass // declaring a variable outside of a class only defines a // single copy of that variable, and requires the specific // specialization of a parameterized class to be specified. C::T y; // illegal - C::T used outside of class C#()::T z; // ok - default specialization used initial C::x = 1; // illegal - C::T used outside of class initial C#()::x = 1; // ok - default specialization used function C::T C::getX(); // one getX() for each C specialization return x; endfunction function void C::setX(T newx); // ok x = newx; endfunction function void C::setX(C::T newx); // also ok x = newx; endfunction Mark - is it legal to refer to the type parameter in the parameterized class Gord - we can refer to C::p in the same places that we can refer to C::T - the whole question for the block form for extern class method declarations can be deferred, if we go with the solution used in the example above. FM - only an issue if the class is parameterized. Gord - yes, the type name and class name are the same in other cases. - currently the LRM has overloaded the class name and the default specialization, which had made C:: ambiguous. Mark - not sure if 100% backward compatible. Arturo - looks like implementations haven't taken a stand on this either way. - was in agreement with Gord's example Gord - if the rules are clear the implementors can explain it to users. <a big laugh was had by all> Arturo - the block form is an orthogonal issue AI/Gord - writeup the C::T proposal Note: when we get back to the block form for extern methods the following existing keywords could be considered. This wasn't covered in the meeting, but I was looking this up while some of the discussion was taking place. (Neil) within bind extends Gord - this week and next week he will be tied up with the day job. - the week of the 19th (by the 26th) hope to have proposals. Gord - typedef C d; // d is the default specification for d FM - don't allow that typedef if C is parameterized typedef C#() d; // need to do this instead Gord - should we allow a forward typedef for a parameterized class? Mark - we do need to allow this, for same reasons as any other classes FM - only tells you that it is a class name - you need to specify a specialization to allow this. Gord - not philosophically opposed - not sure if want to allow default special in this context. - initially uncomfortable with this. - more comfortable requiring explicit specialization for a parameterized class forward typedef. - would need more time to think through the issues. - any reference to the forward typedef would need to have a specialization specified before defining the body. Mark - thinks of a forward typedef as something from a typedef (which is just a name alias). - The forward typedef is just telling you it is a type name. Arturo - telling you that it might be a typename Mark - for non-special classes it can be thought of this way. - can be used as a type name. Gord - when a forward typedef to a parameterized class, don't know upfront if it is actually parameterized or not. Mark - creates a hardship for the user. Gord - today can't use :: operator into a forward typedef typedef C C#1 (?) C // is this ok? (when C is a parameterized class) - typedef C; C::T; - forward typedefs are still somewhat opaque until finalized. - ok with allowing forward typedefs to parameterized classes just not sure of what the rules should be yet. Mark - not sure why special treatment is required in this situation. Dave - typedef C; typedef C d; - renaming a type vs renaming a specialization - Was describing the notion of an alias to a parameterized class name Gord - where to leave it - ok to allow a forward typedef to parameterized class - less sure about allowing default specializations AI/Mark - write up a proposal on the forward typedef stuff. Gord - FM need to talk to people at Cadence - yes Mark - concerned about having to change existing code when adding a parameter to an existing class. Mark - we can try to go over what is written by next week in the svec Neil - we have an svec meeting on the 26th - Dec 10th is our last meeting...Received on Mon Nov 5 18:41:45 2007
This archive was generated by hypermail 2.1.8 : Mon Nov 05 2007 - 18:41:57 PST