SV-EC Committee Meeting Monday December 3 2007 11:00am - 1:00pm PST continuation of the regular bi-weekly meeting of Monday November 26 2007 11:00am - 1:00pm PST The meeting count doesn't increase. Attendance on either day counts towards the attendance record. The attendance number remains as of November 26 2007 numbers, shown in the minutes. A * is used to show the attendace completion for Nov26/Dec3 meeting. With the new calculations for voting rights below... 3/4 rule = 0.75 * 33 = 25 Meeting number: ------------------------------------- 0000000000000000000000000000000000 0000000001111111111222222222233333 1234567890123456789012345678901233 Meeting Days: ------------------------------------- (1212020201020201013112020201012120) Day (4815936048825059560415936067159263) (0000111111000000000000000000111111) Month (8899001122112233444566778899000112) (0000000000000000000000000000000000) Year (6666666666777777777777777777777777) ------ Attendees -------------------- (-AAAAAAAAAAAAAAAAA-AAAA-A--AAAAA*A) Arturo Salz 28 (--AAA-AAAAAAA-AAAAAAAAAA--A-A-AAA*) Cliff Cummings 25 (AAAAAAA-AAAAAAAAAAAAAAAAAAAAAAAAA*) Dave Rich 32 (AA-A-AAA-AAAAAAA---AAAAAAAAAAAAAA*) Francoise Martinolle 27 (-AAAAAAAAAAAAAAAAAAA-AAAAAAAAA-AA*) Mehdi Mohtashemi 30 (AAAAAAAAAAAAAAAAAAAAAA-AAAAAAAAAA*) Neil Korpusik 32 (AAAAAAAAAA-AAAAAAAAAAAAAAAAAAAAAA*) Ray Ryan 32 (AAAAAAAAAAAA-AAA---AAA-AAAAAAAAAA*) Gordon Vreugdenhil 28 (AAAAAA--AAAAA-A--AAAAAAAAA-AAAAAA*) Steven Sharp 27 (--AAAA-A--------------------------) Phil Moorby 05 - No voting rights (---AA-AAA-AAAA-AA-A---------------) Doug Warmke 12 - No voting rights (AAAAAAA---AA-A-AAAAAAA---AAAAAAAA*) Stu Sutherland 25 (-AAAA--AAAA-A-AAAAA-AAAA-AAAAAAAA*) Heath Chambers 26 (-AAAAAA-A----AAAAAAAAA--AAAAAAA-A*) Don Mills 24 - (2 of last 3) (--AA--A---A-AAA--A-AAAA-A-A--A--A-) Jonathan Bromley 16 - No voting rights (--A-------------------------------) Logie Ramachandran 01 - No voting rights (----AAA---------------------------) Melvin Cardoza 03 - No voting rights (-----A-AAAAAA-AAAAAAAAAAAAAAAAAAA*) Mark Hartoog 26 (-------A-------------A------------) Satia (from Intel) 02 - No voting rights (--------AAA-----------------------) Rob Slater 03 - No voting rights (-------------A--------------------) Alex Gran - Mentor 01 - No voting rights (---------------A-AAA-AAAAA--A-AA--) Mike Mintz 12 - (2 of last 3) (------------------AAAAAAAAAAAA-A--) Geoffrey Coram 13 - (2 of last 3) (-------------------AAAAAAAAAA-AAA*) David Scott - Mentor 13 - (2 of last 3) (------------------------A---------) Benjamin Chen - Cisco 01 - No voting rights (---------------------------AAAAAA*) Mike Burns - Freescale 06 (2 of last 3) on December 3 2007 [for next meeting] 15 people (other than the chair) currently have voting rights ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// December 3, 2007 ///////////////////////// 1. Review IEEE patent policy ----------------------------- ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Continuation of the November 26 2007 meeting, no need to take a vote on this. 2. Review meeting minutes/Notes: ------------------------------------------------- http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_November_12_2007_Minutes.txt http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_November_26_2007_Minutes.txt Will review and vote next meeting. and the name resolution unofficial notes. http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_NameResolution_November_19_2007_notes.txt 3. Update Champions meeting November 28 2008 schedule updates and discussion ----------------------------------------------------------- a) version D4 of LRM is available b) New schedule from p1800 meeting (October 4 2007) c) Next p1800 working group meeting: November 15 2007. 11/12/2007 all committees must open active Mantis items that they are going to complete for this release. 12/15/2007 SV-BC and SV-EC must complete all items from their Mantis list. Past this date they are only authorized to work on merge, editing and champions issues. 1609 - had one no vote, import statement should not be allowed one word 'directly', Francoise: Stu was the one that was opposed to it. Opposed: Stu - thinks we need to know the intent of the word "directly" before sending this to the Working Group Gord: This is so, one can have an import inside a class method. Neil: sounds like Stu's question was answered. 1601 - from the sv-ac, for keyword., Motion failed - the sv-ec will be given time to review this proposalsv-ec to look at it to give feedback. - mailbox - has no formal type associated with it. - would like to solve this if had time. could use the same keyword for mailboxes - 'untyped' is a type itself. Gord: not to worry about it till after December 15.2007 1336 - SV-EC Rules for allowed statements in a function creates a contradiction, 13.4.5 is modified, Neil: champions disagreed with, 13.4.5 is in contradiction with 13.4 items c) and d) Was sent back to the svec to fix the contradictions. There maybe other places. 2087- SV-EC Semantic intent of qualified BNF terminals must be clarified passed with two friendly amendments, 1. duplicate this text in 1.6 2. fix typo at the end - spelling of array_identifiertypo. Neil: will update the mantis Next Champions meeting will be December 20th.2007. 4.Prioritized list for feature freeze review and plans: --------------------------------------------------------- 2109, 2080 name resolution and related items. [assigned: Gord] [2107, 2106, 2108, 1268, 1809, 1043, 1832, 1508, 1516, 1858, 1583] 1809: forward references into $unit package (was discussed in detail in name resolution meeting of 11/19) Francoise: is to write a proposal, the current proposal will be impacted if she makes the changes. will need a new mantis for changes to imports of packages. Neil: Gord was saying he knew how to do it, but did not have time to do it. Gord: all section that deal with imports or name referencing are impacted - the current proposal for 1809 falls out of the current rules. - describes the current import rules. If chang them, then 1809 will need to be updated to reflect those changes. AI: Francoise - provide a new proposal for Mantis item 1809. 1858: Name binding in inline constraints (see emails on name resolution - 11/5 through 11/8) Gord - what is in the proposal is not what we will end up going with. - Arturo was planning to write a proposal (for local::) (see minutes of July 23rd) - Jonathan had some reactions to the current proposal as well Ray - want to be able to ref vars in local scope in an inline constraint - when use in-line constraints it first looks in the class. - Changes the RNG that is used(?) no. Gord - ok with leaving the existing default rules. New techniques would only apply to altered rules. local:: combined with parenthesized form together would be best. Mike B - maybe this will be used for VIP - likes local:: since it is obvious what it means. The use of parens is not as visibly obvious Gord - the desired default is a function of your usage methodology. That is why he prefers to have both. Arturo - sees people that want to always bind to the class members. - thinks adding in the rest of it will add additional complexity Mike - if mostly in reusable VIP, most users won't see it. - his users are expecting to bind into the object. They like it. - when there is a danger of escaped names, want a way to explicitly specify where the names come from. Gord - wants a way to force a reference into the object. When apply constraints in the context of in-line constraint. Arturo - can use a method. The in-line constraint in not re-usable. Can't turn it off, etc. Francoise- is it related to extending classes using a type parameter? Arturo - this is related but a separate issue. Gord - that just makes it more difficult to reason about Francoise- best not to rely on some implicit rule - her customers want to be more explicit Gord - basing his input on feedback from customers. Arturo - local:: for outer scope Mark - local::c1.field_name can be used for an explicit reference to a class variable. Mike - wants local:: - ok if you want to also add the parenthesized form as well. Arturo - not a strong objection to also adding in the parenthesized form. Stu - maybe the parenthesized form could be added later. Francoise- doesn't like the idea of having two forms that rep the same thing - can already use existing syntax to force into the class scope. Gord - there isn't an easy way to force to a class scope. See slides from name resolution f2f. (see slide 46, 58) - if the local:: proposal can show up soon, he will provide an additional proposal with the additional form and see if it passes or not. He has sent it to the reflector several times. AI:Arturo - put together a proposal for local:: in the next couple of days. - 2164 Gord to complete the proposal for 1858 with above. 1702 801 list, covers all queue items [assigned: Jonathan, Francoise, Steven] 412 5.14.1 Queue operator examples use aggregate constructors incorrectly 522 use of concatenation in 5.14.2 (Francoise) 521 pattern assignment for queues (Francoise) 520 example of queues assignment (Francoise) 519 section 5.14,empty array literal syntax (Francoise) 518 queues and arrays (Francoise) 517 concatenation syntax usage section 5.14 (Francoise) 516 5.7 and 5.8 description of type compatible arrays 1702: Gord: we need to agree on, - persistence of references of elements in a queue. 7.11.3 any assignment with the {} form will outdate the contents of a queue. Arturo: but if you concatenate then it is not, creates a contradiction, it is blown away. Mike - relies on the idea that the {} assignment will wipe out existing. Arturo - the intent was for {} to be a special operator for a q. Gord - this is a semantic question, not an optimization question. Arturo - if have the same q on both sides, a corner case. Gord - the case where have the same entry now represented multiple times in the same queue (after using an {} update). That case is not defined in the LRM today. - the entire symmetry that Jonathan has been proposing may have to go away. Steven - the current LRM only has examples as a means of defining the {} form. There is no supporting text. Gord - Our choices 1. normalize all array types - Jonathan's approach 2. make operations on a queue be special. Arturo - Jonathan's proposal would obsolete the {} form. Cliff - has been teaching the {} method for a few years now. Stu - he teaches the method approach. Gord - the issue about outdated refs is not described at all. Mike - not clear to him that the issue of outdated refs is frequent. Dave - that functionality was created by a user request Gord - q of ints, if have a ref to 3rd element, can keep the ref. - what happens if end up with multiple copies of the 3rd element? Dave - cases where never delete from q, not a problem. Gord - could define {} to be same as some method. Then define the outdated semantics. There is a fair amount of work to do this though. - q's are not arrays, in a sense. Arturo - contiguous elements of a dynamic number of elements. Mike - more like a linked list? Arturo - no... Gord - it sounds like the normalization may not be doable. These cat rules may need to only be applied to queue's. Arturo - believes that we can get there by updating Jonathans proposal. Gord - can only do it by carefully outlining the specific cases that would have the special rules. Mike - q on both RHS and LHS, semantics are still valid? Arturo - yes, that is the case I was referring to Mike - may not be able to determine if the same q until runtime, if using handles for example. Gord - if do a pushback to a ref in an associative array of q's. Mike - simple identifier to a q versus other ways to access a q. Arturo - yes, there are some cases where it is problematic, but we could limit this to the simple cases. Gord - types could be parameterized. Arturo - that is still static. Gord - Jonathan's proposal "as-is" will most likely not be acceptable. The existing text is also an issue. Dave - is ref the only issue? Gord - if go with the proposal, we are committed to a direction for ref. - if leave it undefined, not portable behavior Arturo - users need to give guidance. Mike - what about a ref to a q? Gord - different case. Arturo - how use ref to a q element? Gord - it clearly makes sense to want to have a ref to a q element. Mike - should be a ref to the node itself... Neil - the simplest thing to do with mult copies of ref element is to say it is undefined which one is referenced. Gord - if want to say {} is special for just q's - need a definition for cases where legal and not legal Steven - should a ref be to a q plus an offset? - fixed time operations - there is contradictory stuff wrt to that Gord - we seem to now have further diverged. - need to define the q operations in these cases. - we have no clue to know if basic operations are consistent. Arturo - need to agree on user requirements. - homogeneous list of items - not really an array - agrees with symmetry of assigning a q to other data types. This was the original intent of the 1702 proposal. - Jonathan may have gone too far with the normalization process. Gord - svbc - the {} operation for q's were way too undefined in the LRM Dave: is the only problem with references? Steven: maybe problems with unions. Neil: does {} wipe out the contents of the queue?, another issue. Gord - the statements of equivalence need to be re-written. - will have questions about duplication inside {} for q's (ref issue) - would rather make it a new construction if duplicate it. Steven - it could be expensive to detect these cases Mike - doesn't like the idea of all the special rules. - would like the simple cases to work. Dave - concat 2 q into one q. - it would be expensive to create a 3rd q. - appending one q onto another. base is large and new is small. - qa = {qa + qb}; Gord - the semantics have to say you get a new q and originals are not disturbed. If append one onto the other one will be wiped out. Dave - prefers to not have to copy a long q in a concat. Arturo - could redefine what is meant by merging two q's. Cliff - all of this is since we can pass a q element by ref? Mike - the reason that people want the {} syntax is since it allows multiple elements to be dealt with at a time. Steven - because {} is so flexible, the ref makes it difficult Mike - ok with allowing any refs to become outdated if use {} Gord - if have a ref to an element, it stays alive while that element is still in the q. - use {} to add in middle, for example, q[5] will not get you back to there. Mike - allowing q refs to go out of date doesn't sound so bad. Cliff - he was agreeing. Mike - there are a lot of useful portions of this proposal. would like to keep most of it and allow refs to become outdated. Dave - has an issue with requiring them to become outdated. would prevent us from addressing this later. Steven - efficiency considerations - could define new methods for that. - users could alternatively write their own methods. Dave - for dynamic array get a new array if it is resized. Gord - agrees that user-written methods could be written Arturo - classes are not as easy to deal with Gord - svbc could vote to deprecate the whole section. Steven - it would most likely re-surface at ballot feedback time Gord - most said they weren't concerned about outdated refs when using the {} form (concat form) Arturo - concat form - could forego that - outdated references - could go either way Gord - method form - not a problem for him for outdated refs. - 1702 - methods only need a small number of changes. Cliff - doesn't want to obsolete the concat form. - outdated refs not a problem for him. Gord - any {} will cause refs to become updated - is in 1702 today (Gord read it in the beginning of the meeting) Cliff - ok if methods differ from {} wrt outdated refs. Arturo - there is a problem with refs to q elements, one way or another Dave - should say that if you want guaranteed behavior use a method. Mike - ref will keep a value, but will be wiped out in concat form - always outdated? Dave - would like to say that we can't rely on what will happen in that case. Gord - if others ok with saying undefined, gives implementors the maximum flexibility. Mike - undefined - is similar to saying illegal since not portable. Mehdi - ask Jonathan to update the proposal, could add to an email vote. Gord - have to have an email discussion on reflector, {} will have undefined semantics for q's with refs or have a specific behavior? Arturo - need to get some guidance to Jonathan before he can update it AI: Dave - start the email discussion on this topic. 1447 multidimensional arrays Mehdi - Neil sent detailed feedback on this one. Mike - took it over from Ralph Duncan - Has a lot of feedback now to incorporate. will work on it in next day or two. 5. Review mantis items with proposals ---------------------------------------------------- No issue was discussed during this meeting. 2113 Inconsistency in constraining assoc array size 2137 2181 Ambiguity in implicit declaration of production variables in randsequence 2183 6. Next meetings: -------------------------------- Monday December 10 2007 Monday December 17 2007 -- continuation of December 10 2007 meeting