Minutes of SV-EC telephone meeting, 11am PDT, 9 July 2007 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Notes taken by Jonathan Bromley in Neil's absence. Participants: ~~~~~~~~~~~~~ [PLEASE CHECK, as I was a few minutes late and missed the roll-call - Jonathan] Ray Ryan Dave Rich David Scott Cliff Cummings Françoise Martinolle Geoffrey Coram Jonathan Bromley Heath Chambers Arturo Salz Steven Sharp Mike Mintz Mehdi Mohtashemi (chair) IEEE Patent Policy ~~~~~~~~~~~~~~~~~~ Cliff proposed it be taken as read; [?] seconded; passed nem.con. Minutes of meeting of 25 June 2007: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cliff proposed acceptance; Heath seconded; nem.con. Mehdi noted that the minutes were on eda-stds.org/sv-ec together with assignments of sections of the merged LRM draft to reviewers. IEEE P1800 committee ~~~~~~~~~~~~~~~~~~~~ Mehdi: Meeting, to discuss funding and LRM edits, is scheduled for 12 July. Further meetings thru Jan.2008 already scheduled. Françoise: What will happen to Mantis items recently passed by sv-ec? Mehdi: don't know about individual items, but they WILL be reviewed, controversial items to be passed to champions. Dave Rich: no champions meetings until Aug.15, then Aug.30 they vote on the next batch of Mantis items - anything we want to go into 1800 draft 4 needs to be with champions by Aug.1 Mehdi: Mantis items passed up to end Nov.2006, and 890, have already gone into draft 3; nothing since. The next sv-ec meeting is our last chance to approve other Mantis items in time for draft 4. Merged LRM review ~~~~~~~~~~~~~~~~~ Mehdi: urged everyone to note review assigments on sv-ec website ACTION: all Mantis items for discussion/vote ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * 1623 (from 1462, added to our list by SV-BC): timeunit verbosity Heath: Add syntax "timeunit 10ns / 100ps;" to reduce verbosity; rationalize BNF syntax for timeunit, timeprecision. Proposal has been renumbered and reworded to fit draft 3a, see file mantis1623_D3.pdf Brief discussion revisiting choice of separator "/" or "," "/" is OK, matches `timescale, but means that future enhancement to allow expressions for time values would need to be in parentheses. Heath proposed; Cliff seconded; passed nem.con. * 1707: clarification of streaming operator * 1384: local/protected members in bitstream and streaming operator Taken toegther because they both affect the same LRM text. Jonathan has uploaded a new proposal. Some discussion of the meaning of "skipped (not streamed)" and what things can/cannot be streamed. Jonathan: can't stream tagged union. Arturo: you can, representation of tag is well defined, but unpacking into tagged union represents unacceptable type-safety loophole. Françoise: are strings OK to stream? Jonathan: thinks they are bit-stream types and therefore OK - agreed. General agreement it's OK to forbid streaming of reals and tagged unions. Must a tool follow the two-step streaming implied by Jonathan's proposal? Jonathan hopes not, intent was to describe effect as a two-step process, but result of first step is never visible, so tools can implement any way they wish that gives the same effect. Arturo: does Jonathan's proposal forbid the use of a streaming_concatenation as an argument to another? Jonathan: that wasn't the intent, but will clarify the wording. Will also attempt to tighten wording around "skipped". ACTION: Jonathan General agreement to postpone until next meeting so people can review more carefully. Dave Rich to revise 1384 to fit draft 3a for next meeting. ACTION: Dave Rich * 1857: out-of-body member functions syntax Gord has provided a proposal and some email discussion. In Gord's absence, postpone to next meeting. * 1608, 1594: type matching of class handles, result type of ?: Françoise: proposal has been updated to improve typography of last few bullet points (indentation) Cliff: are we OK with "nearest common parent"? Some discussion of why the result type matters; yes, it does. Existing proposal is problematic because result type must be determined dynamically - Steven pointed out that in the absence of "null" literal, you can statically determine the result type of ?: as the closest parent type of the two choices - the three most indented bullet points of the current proposal correctly describe how this is done, regardless of whether the condition in (condition? expr1: expr2) is ambiguous. Further discussion of the type of null: Steven pointed out that if it's the value of a class handle then its type is (statically) the type of the handle; only problem is a null literal - agreed that a null literal contributes nothing to the type of any expression in which it appears: condition?expr1:null has type of expr1 because null is assignment-compatible with that; cond?null:expr1 has type of expr1; cond?null:null is trivially null and has no type. Side-issue: what does type(null) mean? Should be illegal - null literal has no type. Ray, Steven: agree that it's right to determine type of ?: expression statically. Françoise to reword proposal to define "nearest common parent" more clearly, re-word to take account of today's discussion, and (if possible) update 1594 ACTION: Françoise * 1715: .triggered method of clocking block Jonathan: proposes closing with no action - there are workarounds that implement what he needs Steven: nice symmetry to make clocking block name act like a real event, albeit read-only - can then make another event variable reference it, pass it through ports, do .triggered etc. Jonathan: would like that very much, but recalls some opposition to it when first suggested - current 1715 proposal is more modest (only .triggered). General agreement that it would be good if possible to make clocking block name usable like any other event. Jonathan to update proposal. ACTION: Jonathan * 1858: use of item. in inline constraints to force resolution of member names into the target object Mark: Gord originally filed this, but Mark is working with Arturo to finalize a proposal - hard to find time to work together. Prepare proposal for next meeting. ACTION: Mark, Arturo * 1500: restriction on uses of forward typedef Ray: impacts elsewhere in LRM, which has other examples of forward typedef that don't conform. Jonathan: this because forward typedef looks like a type parameter? Ray: yes. Mark: Can you use type parameter as a base class? If so, forward typedef can do the same - and other issues around forward typedef are comparatively trivial. Arturo: it's not clear that generic base class adds any value for users - no other language has this. Mark: If it's OK to forbid type parameter as a base class, then it's OK to restrict forward typedef. Dave Rich: has seen people wanting to use type params in this way. Mark: can't then resolve anything until elaboration is done Dave Rich: that's true anyway, but the real problem is about name binding - knowing nothing about a typename makes it very messy. But SV-BC people want to use forward typedef to structs etc; it simplifies management of `include compilation order. Mike: often uses forward typedef in C++ to hide implementation details - but only for pointers to classes Dave Rich: need to fix name resolution issues before we can make much progress on this. Françoise: should we make BC aware of 1500 implications? Mark: yes, could be serious back-compatibility trouble with existing code that uses forward typedef to non-class things. ... Many further issues raised; general agreement to postpone this until we have name resolution problems sorted-out. Mehdi will discuss this with Gord. ACTION: Mehdi * 1871: clarify illegal and ignore transition coverage bins David Scott: outlined the issue and proposal. Jonathan: is the word "invalidate" precise enough? David: knew this was an issue, could choose different wording. General discussion: illegal/ignore transition doesn't remove a *bin* but only a *transition* in the bin; if that happens to leave the bin with no members in it, then it's removed. David: understands concerns, will reword proposal for next meeting ACTION: David Scott Next meeting: 11:00 PDT, 23 July 2007. Meeting closed at 13:00 PDT.