SV-EC Ballot Resolution Committee Meeting Monday April 25th 2005, 10:00am - 5:00pm (extended face-to-face) [Minutes distributed for approval at next (sv-ec) committee meeting] (0111122) Day (4125815) (0000000) Month (4444444) (0000000) Year (5555555) --------- Attendees ---------- (-AAAAAA) Arturo Salz (AAAAAAA) Brad Pierce (AA--AAA) Cliff Cummings (AAAAAAA) Dave Rich (AAAAAAA) Francoise Martinolle (A-----A) Karen Pieper (AAAAAAA) Mehdi Mohtashemi (AAAAAAA) Neil Korpusik (AAAAAAA) Ray Ryan (AAAAAAA) Steven Sharp (AA-AAA-) Surrendra Dudani (-AAAAAA) Gordon Vreugdenhil (------A) Tom Fitzpatrick (-------) Bill Paulsen (-----A-) Dennis Brophy (-------) Stu Sutherland (-------) Alex Wakefield (-------) Yogesh Pandey (-------) Don Mills (-------) Eugene Zhang (-------) David Smith ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi Agenda: 1) Review the IEEE patent policy ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Brad Second: Gordon Abstain: Opposed: 2) Review Meeting minutes, April 21st 2005 http://www.eda.org/sv-ec/Minutes/SV-EC_BallotRes_Meeting_April_21_2005_Minutes.txt Move: Dave to approve the minutes. Second: Arturo Abstain: Opposed: approved 3) Miscellaneous P1800 schedule times for next month: (from April 19, 2005 meeting): May 2 Monday Champions meeting May 5 Thursday P1800 meeting 8am to 10am May 9 Monday Champions meeting May 11 Wednesday Champions meeting May 19 Thursday P1800 meeting May 24 The draft of the LRM will be available for final review May 27 Comments on the May 24th draft are due to Stu May 31 The Balloting LRM is ready June 2 P1800 meeting to send the balloting draft back to reballot Next meeting times: Thursday: Apr 28th, 2005 11-1(may be longer) Wednesday: May 4th, 2005 11-1:00pm (possible) 4) Continue the resolution of ballot issues http://www.eda.org/sv/sv-champions/P1800_Committee_Assignments_05_03_29.xls NOTE: issue 240 was the main topic of discussion at this F2F meeting. Notes were taken by Neil and Mehdi. The meeting started with 240 discussion, then lunch, then a few issues/items were reviewed to get resolution on some Mantis items. The rest of the afternoon was taken with more 240 discussion. Here I will first note the issues/items that were discussed besides 240 in the meeting. Then I have pasted notes taken by Neil. At the bottom of this file, I have appended my own's raw notes, which have not been reviewed for any spelling (other) corrections for completeness. Issue 266: leave for end of meeting or next thursday Issue 2 (Mantis 219) (fork-join and existing verilog disables) - From Steven Steve: it is a complicated issue. This item came in from a positive ballot but was marked as high priority. Cliff: disable has problems with it throughout the LRM. "The committe read and considered this feedback. While it has merit, the committee believes it is not feasible to implement at this time." Move: Brad (to mark as not feasible) Second: Artuor abstain: opposed: passed (as not feasible) Issue 5 - Mantis 319 root thread related item, Mantis 370 - has a proposal for it from Ray. Adds the phrase "sub-system". Ray: why have hierarchical seeding if fork/join is unstable? Arturo: users can always add more repeatable control for RNGs. Motion: to pass the proposal in 319 Move: Brad Second: Cliff abstain: opposed Issue 8 (Mantis 370) (chapter 13.13 seed/RNG) change it: seed is deteremined before any thread is forked. [[ remove the sentence before the example remove the two sentences... between the two examples. The rng of all forked threads are determinde before any thread starts, ]] BUG-NOTE for the example. AI; Ray to update the text of proposal. for next time vote AI: arturo to look at this more in detail. Issue 188 - Mantis 595 LEAVE it for vote next week. (Brad AI) Issue 199 (Mantis 607) accessing values in clocking block -- from Charles At the last meeting we thought that this item was addressed in sections 16.12 and 16.14. Mehdi - sent email to Charles but he didn't respond yet. Motion: to mark 607 as not a bug Move: Brad (it is already specified) Second: Neil Abstain: opposed Issue 233, Mantis 317 bit-streaming of class Arturo: There was one case that wasn't covered. Behavior is undefined When cyclic structures are bit-streamed. - Using pre-defined methods for this would cause classes to get bloated AI: Dave to look in detail, at last meeting Dave asked for more time to review. AI: Arturo to look at this more LEAVE for next meeting. Issue 10 (Mantis 409) (ref arguments, Motion: to approve the proposal in mantis item 409 Move: Arturo Second: Gordon Abstain: opposed: AI: Brad (remove the last sentence out into bug. Issue 22 514 ( type for mailbox ) mailbox with ref semantics, equivalence type-mismatch (pass ref), AI: Francoise making proposal for next time update the proposal to clarify what is meant by "type mismatch". Mantis 384 -- It seems that Mantis item 384 is a duplicate item Move: Brad -- to make mantis 384 a duplicate (closed/resolved) Second: Gordon abstain opposed 384 is duplicate of 514 (closed/resolved) Issue 240 - mantis 681 Class semantics Issue 7 (Mantis 344) (anonymous program) Gordon - Main issue is scheduling semantics for classes, especially for tasks that block. - We walked through Gordon's email proposal (from Wed Apr 20,2005). - Arturo had sent a possible counter-proposal the morning of the F2F. Some people in the meeting didn't have time to review this writeup before the meeting. - Issue with requirement for NBA from program block to design. A task/function within a module is allowed to do either an NBA or BA to "anything" (ie design space or program space). A program may call one of these tasks/functions and hence break the current rules described in the LRM. Correcting this "loophole" would impact a lot of text in the LRM. Gordon mentioned that he doesn't see a clean solution for this. - A program calling a task with ref args can expose the reverse problem. The "holes" in the current LRM revolve around paradigm issues. There are several convoluted issues. [Gordon] - Program call to a function that uses an NBA --- conceptually could then cause an effect in the program. - With Gordon's proposal there may be some "surprising" behavior that could occur as a result of doing some allowed calls. Even though there may be some surprising behavior, it would be "well-defined" from an implementor's point of view. - It is Arturo's opinion that changing the base class behavior by extending it means that the base class type must also change. Gordon thought that this prevented polymorphism. - Arturo's email describes the use of parameters to extend a class. This allows a base class to be reused, which is what Arturo thought was one of Gordon's main goals. - [Dave] - it should be possible to reuse a class across the program/module domains if it doesn't contain any blocking tasks. - [Gordon] - his proposal allows handles to schedulefree classes, but they can't be new'd. This allows for full polymorphism. The semantic follows from the derived type. The proposal is clear about not mixing program/design semantics within a single class object. This proposal allows for a heterogeneous list to exist which contains handles to derived objects within both the module and program domains. The builtin mailbox class could be extended in either the module or program domain. - [Arturo] - System Verilog has both a functional and structural hierarchy. An anonymous (ie unnamed) program was suppose to be only used in 1 domain. It could be used in multiple programs but not in a module. Is there useful paradigm for this new capability? This was a point that was raised several times during the day. - [Gordon] - doesn't care about paradigm per se, but is insistent on having everything defined. Conceptually it is best to have orthogonality. Pardigms are outside the scope of the LRM. A book-keeping capability may need access to handles of classes that have been extended into both domains. - [Dave] - how use a mailbox to communicate between the design and program? [Arturo] - Having one list with objects with different scheduleing sematics would give you strange unpredictable behavior. - [Ray] - if a handle is placed on a data port you run into a problem. - [Arturo] - existing tools don't allow passing of objects from one domain into another domain. It should be ok to pass a handle to an object that doesn't have tasks. Orthogonality here isn't practical. Prefers to not confuse users and keep things simple. Thinks of classes as being just for the testbench. A heterogeneous handle across both domains would not be good. - [Gordon] - no, a class can be used for high-level design modeling. There is no hierarchy in a program. It doesn't make sense to disallow classes in modules. In one object we can't have tasks with both types of scheduling semantics. - [Arturo] - we need to address the issues of NBA and BA. The use of a Heterogenous list would create race conditions. This would be a new type of race that could now exist. The use of an "androgynous" handle is not ok. - [Ray] - randomize() uses blocking assignments. This seems to imply that this is only a program construct. The randomize() routines use BA. - [Gordon] - if there is a global handle to a program object then a program would be granting access to that object from the design domain. Virtual tasks can be extended to provide different behavior. How is changing the semantics by extending a class different from that? We should not go so far as to disallow tasks within classes declared within packages. - [Steven] - concept of a heterogeneous list would be well defined from an implementation point of view. - [Dave] - NBA mostly applies to static objects. The restriction on only allowing NBA from program domain into the design domain should only apply to static objects. This restriction should not apply to object data members. A class in a package is part of the design domain. - 1. He wants to require specific syntax (ie parameterized type) to specify the domain semantics to be used. This allows checking to be done. 2. Once a class is extended into either the program or design domain the corresponding base class is now also within the same domain. - [Arturo] - doesn't like the idea of anything that is semantic-free. - It was agreed that we would vote on mantis 240 at the next meeting. This was agreed to so that people could drop off the call and not miss an important vote. - [Gordon] - if things are left the way that they are currently defined there is a danger that different vendors will implement things their own way and we will have inconsitent implementations. 1. Anonymous program block is allowed by the BNF but there is no text describing it. They are allowed in a package which implies that they are part of the design. 2. scheduling - Parameterized class - implies that a task isn't fully defined until the enclosing class is instantiated. - what does it mean when a task method gets rescheduled, after unblocking? - [Arturo] - how get a type from one module to another? - [Gordon] - interfaces Process review: The following will go back to the re-balloting process. a. Feedback and changes due to comments from negative ballots. b. Feedback on comments from positive votes that resulted in changes to the LRM. - Summary of Arturo's issues 1. Wants the syntax to specify the domain semantics used (program vs design) 2. Extending a class into one domain causes a base class of the same domain to exist. - [Gordon] - 1. Should the LRM block the ability for a body of code to have a handle to objects in both domains (module, program). 2. Doesn't want a paradigm to drive the decision. - [Dave] - Wants to use a class to pass data between a program and a module. (ie pass a handle through a port). - [Arturo] - A package can be used to share types. - [Cliff] - it doesn't sound that foreign to allow a class to be used in both places. - [Neil] - concerned about all of the "surprises" that are being mentioned that users will run into. - [Dave] - SystemC uses ports. Vera supports a channel from Vera to SystemC. - The design writes to a mailbox if it is in the design region. - [Gordon] - semantics of a mailbox is determined by the thread of the call. - If a program calls a design task it starts to execute immediately until it blocks (suspends) and then will restart in the Q based on where it was defined. - [Arturo] - changing semantics based on class extension is a new concept. - there will be implementation problems if the semantics are not part of the declaration. In a program you could capture handles of both types but you would need to keep them separate. Static variables within a class are also an issue. - [Gordon] - calling tasks/functions from a program is already a loophole. - it is an elaboration problem with both proposals. AI:Gordon/ Arturo how the rules would look into the parametrized world explain the object that crosses both domain, derivation restriction. use model crossing the two domains, issue is there, extending through multiple domain. 6) Next meetings A) Possible time slot for Thursday April 28th, 2005 11:00 am - 1:00 pm B) Wednesday May 4, 2005 ======================================================================================== Action items: (4/25/2005): 1) AI(issue 266,): ALL review the latest updates from Cliff, comments 2) AI(issue 8, 370): Ray remove the sentence before the example remove the two sentences... between the two examples. The rng of all forked threads are determinde before any thread starts, AI; Ray to update the text of proposal. for next time vote AI: arturo to look at this more in detail. 3) AI(Issue 233, Mantis 317) Dave/Arturo to look into this in more details 4) AI(issue 10, 409): Brad (remove the last sentence into the bug) 5) AI(issue 22, 514): Francoise to place the proposal into svdb. 6) AI(issue 240, 681): Gordon,Arturo, more clarifications on how the rules would look into the parametrized world explain the object that crosses both domain, derivation restriction. use model crossing the two domains, extending through multiple domain. =========================================== == Issues not yet resolved/voted on ======= Issue # Mantis # 240 681 semantics of class [We can postpone this till 7 344 combined with 240 233 317 266 Notes issues (from Cliff) 8 370 ( chap 13.13 seed/RNG) 188 595 (invalid example clocking block assignment -- proposal) 22 514 ( type for mailbox ) 13 412 23 517 24 520 30 549 41 551 32 553 94 511 ( type assignments) 95 512 ( object copying) 96 516 ( type compatibility description) 97 518 ( queues, arrays, page 51) 98 519 ( empty array 99 521 ( queues, pattern assignment) 100 522 ( queues concatenation) 101 523 ( queue return type) 122 251 (enhancement -- coverage) 123 253 ( coverage) 171 564 (cross program references) 187 594 ( interface access through clocking block) 190 597 (unnamed clocking blocks in bnf) 200 608 (clocking block value resolution) 201 609 (##cycle meaning in 16.14 ===================================================================== ============== SUMMARY of action items and issue items ============ == Approved and resolved issues === on April 25, 2005; 2 ( Mantis 219 ) [has merit but not feasilbe at this time] 5 ( Mantis 319 ) [approved on 4/25/05] 199 ( Mantis 607 ) [approved on 4/25/05] 10 ( Mantis 409 ) [approved on 4/25/05] on April 21, 2005: 36 ( Mantis 270 ) [has merit but not feasilbe at this time] 162 (Mantis 552 ) [Closed as no-bug] on April 18, 2005: 283 ( Mantis 615 and 662 ) [approved on 4/18/05] 1 ( Mantis 93 ) [approved on 4/18/05] 281 ( Mantis 683 ) [approved on 4/18/05] 238 ( Mantis 671 ) [approved on 4/18/05] on April 15, 2005: 235 ( Mantis- 666) [approved on 4/15/05] 236 ( Mantis- 642) [approved on 4/15/05] on April 12, 2005: Issues approved: 232 ( Mantis- 652 ) [approved on 4/12/05] 236 ( Mantis- 642 ) [approved on 4/12/05] 189 ( Mantis- 596 ) [approved on 4/12/05] on April 11, 2005: Issues approved: 250 ( Mantis- 636 ) [approved on 4/5/05, re-approved 4/11/05] 252 ( Mantis- 637 ) [approved on 4/5/05, re-approved 4/11/05] 229 ( Mantis- 644 ) 230 ( Mantis- 646 ) 163 ( Mantis- 554 ) [one abstain -- Neil, (not read)] 255 ( Mantis- 641 ) [one abstain -- Neil, (not read)] on April 5, 2005: 11 ( Mantis- 410 ) 109 ( Mantis- 537 ) 161 ( Mantis- 550 ) 237 ( Mantis- 616 ) 250 ( Mantis- 636 ) 251 ( Mantis- 643 ) 252 ( Mantis- 637 ) 253 ( Mantis- 649 ) [combined with 254 into one Mantis (649) 254 ( Mantis- 649 ) [2 abstains: Francoise & Steven, no knowledge of coverage] 270 ( Mantis- 638 ) 271 ( Mantis- 639 ) [one abstain: Steven, not read the proposal] 272 ( Mantis- 640 ) 283 ( Mantis- 615 ) [Votes: 4 yes(Brad,Neil,Dave, Surrendra), & Mehdi 3 abstain:(Ray,Francoise, Steven), and 1 No (cliff)] Issues marked not feasible 204 Issues sent to other committees for review: 125 294 (sv-ac) (vpi question) 229 644 (sv-bc) (struct initialization) [NOTE: here is what sv-ec received on 229 from April 11th sv-bc meeting: The SV-BC reviewed the proposal to address issue 229 in its April 11th meeting. It was not approved. Here's the message that the committee agreed to convey to the EC: The SV-BC did not pass the proposed resolution to issue 229 as captured in Mantis #644. The motion failed with only abstention. Those abstaining felt that making such a change so late in the lifecycle of the LRM was not a good idea. They had concerns about issues such as: -continuous assignment to variables -initializer passed with with Type through parameters which is a new paradigm. ============================================================================== ---------- Mehdi's original 'raw notes' on issue 240 discussion ------------- ---------- with no review/correction ------------- Gordon: Class semantics, packaged classes to be rsolved in other areas semantics class extension be resolved before simulation both snps and cdn raised significant issues for implementation was a problem coupling the schedule of classes by the types. holes in current LRM regarding blocking and non-blocking assignment methods, program calls function/tasks in the design environment ignore the method calls from classes as separate issues (same as just calling function/tasks). Any proposal to address that will have impact on other items, it should be fixed at some time in the future Dave: blocking write from program, call a function to do it and come back, how would you check for it. Gordon: any task/functions has to be pure in design side Arturo: you can have local side-effects Dave: like modport, is it symbolic, getting around this by function. Arturo: the user needs to be aware. need to be carefull calling between the two sides, It is more pure functions. Ray: in the program you can tell which behaviour is there. Arturo: concerend about the properties of classes. Brad: why can you not put a continous assignment of the function. precedent for not allowing certain things. Cliff: more to make it hard to not do wrong the better. Arturo: task in the base class what is the semantics, if you declare it as virtual, if not you are changing the semantics. desire is to declare a class once and then use it everywhere. Defer code generation till I can use it. you want to change the schedule context, if you call it parameter, parameter getting its type where it is called. Dave: why should a data class be burdened with all the semantics. using a class like struct, all methods are non-blocking, should be no restrictions to create two versions, they should not be restricted. Arturo: if it is abstract, you can do it Gordon: the context parameter, the extension can do something different, get mixed semantics. our writeup, it is very clear in terms of derivation, with appropriate restriction, the parametrization and explicit extensions, can be the same conceptually. Arturo: given restrictions today, extension in program there is no going back. the only other thing is the module. stick with one domain no problem. the problem with your proposal, from package to module and program, you are still creating different base classes Gordon: but it gives you polymorphism, Arturo: limiations, classes can not be extended in other domains, Gordon: nothing like that was limited in LRM Arturo: it was intent, but not written in LRM. for example built-in classes know their scheduling. Gordon: if you extended mailbox in both domains, what are you going to do about it. it is artificial to bring restriction to do this. Artruo: it is sensible, in the case of mailbox it is easier to do. class T, derived in module and program, pass a handle from derive class to base, what is the semantics of this, Gordon: because scheduling semantics follow the type that was used to create the object. If object was created from program class type, it always follows the program scheudling. however you choose it. semantics of task invocation follows the object semantics. Dave: if you want simple paradigm, mailbox in both sides, fifo in both sides, how do they communicate, they have to communicate. Ray: if you want to place advanced data-type, you would run into problem, Arturo: it depends, if you are passing through the design Ray: are you using class as reprenstative of functionality, also data-values. Arturo: not a technical problem with class type, with no tasks, whole reason program block and design, facilitate the race-free testbench environment this is paradigm, orthogonality may not be practical. Gordon: number of scenrios, if you break things too much you lose reuse. for example 'include in package and in program. general purpose packages. start off with classes for your design, Arturo: that is testbench, Ray: does this mean that design is only the rtl synthesizable components, Gordon: it does not make sense for using classes within the heirarchy of modules, people want to use them in all areas. mailbox is an example, usefull in both domains, why should they. Ray: randomize does a blocking assignment, what does it do. Arturo: if someone writes for IP, the praramterizable ones, a base class extended in different domains, changes its semantics, no orthogonily, it changes, they are two separate types, anything that changes the behaviour of class it is different types. Gordon: if a virtual task and extend it to both, method will exhibit the problem, module extends, if it is virtual method the object will behave differently. i do not think it is different than the other one. Arturo: derive the same class in different module, you access two different, syntactical restriction. type that changes the behaviour of base is of different. Arturo: you design homogenous list of objects, the system can not protect you, what happens with this in-between class. Gordon: LRM premits such designs to exist, no technical issues here Arturo: program variables update differently, Dave: the designs that only used previous designs, you can say the rule is only for static objects. [non-blocking assignments only,] it should not apply the dynamic objects. Neil: it attempted to keep the execution separate between testbench and design. Gordon: it should not be a domain of LRM to restrict the usage. Dave: if some class in pacakge and instantiates it in program, they do not have inside a program Arturo: you need to know where the class came from, anonymous program, Ray: if i call randomize in the program, instance of that variable in the program, class declared in design, ranodmize either global, or A.randomize deferral of code generation 2 topics for getting agreement. 1) Specific syntax to check for program or design domain. 2) base class represent different type. implications of those two, scheduling, Dave: writability aspects Arturo: it defeats the purpose of synchornous elements, Dave: if you have a class just data on it, Arturo: we can agree on this. explicit parametrization, once these androgenous classes (and handles) once you extend, the base class represents different types. Gordon: the normal rules of class extension applies Arturo: if you extend it in both areas, it is different types, the way you distiguish is through parameter. Gordon: definition for mailbox, is then these parametrizable, Ray: take an example (simple). Karen: where we declare or instantiate Arturo: where we instantiate classes they define the semantics package had not semantics, Brad: anonymous programs are not defined, programs without names Dave: no language in LRM. Gordon: implication, base class in a apcakge, extend it in program can not be extended in module, intent of current LRM. -- heterogneous list of objects, -- the functions and methods in class in program will only have that semantics. <<< DISCUSSION RESUMES AFTER LUNCH >>>>>>>> Gordon: not paradigm desire to move that issue Dave: interface construct can not move a handle from design /program Arturo: the place sharing types is packages, Dave: passing a handle through port, Ray: port that the type is class, connection between design and testbench, Cliff: idea of having a class being different in two domain is not foreign, assertions the same, they would behave differently. Neil: maybe surprised behaviour, people will be using different Ray: IP developers want tool vendors create the same. Dave: mailbox is defined in design region has to wake up in reactive region. Cliff: can we have classes that can take two characteristics, Gordon: if we do not permit th Arturo: class with no task, extensio, the behaviour is different, two types. semanitcs is where they are called, context of call always determines the behaviour. from a program call task, it will execute its reactive region. Gordon: task schedules itself on the stack, queue defined by the region task at declration, active queue. Arturo: it is well defined. Gordon: object defined in a program, you can not assign it to one in design. Ray: example foo, use it in both design, and program foomodule and fooprogram; can not assign it to each other, 'include with the proposal, virtual foo, extend foomodule, in module, everything module semantics and one extension in program. Arturo: need scheduling and semantics as part of the declaration. Gordon: pointer that can go across, reference to object in the heirarchy, Arturo: what would user want, get an error in derived class. Ray: base class extended into program, in the unscheudle class, Arturo: if abstract class, it is ok, Gordon: how do you define a class, a handle to one of those, parametrized class, you have to define whether it is program or design when you define it. Arturo: if you have to have something to know what it is. Gordon: to allow for general case, class, parametrized class, different scheduling domain you have. Arturo: base object is different, it has to be different type, base class has to be different. same task behaves differently depend where it is instantiated Ray: similar to cannot call new, code in one placek not virtual task. Gordon: base pointers (do not know which region there is) cast it to specifc types Francoise: you can not extend functions and method today. Gordon: if regular taks, static variable inside it, why is it Arturo: if you get the handle separate, does not promote sharing, Ray: the purpose is to define the behaviour of the system and not methodology. Arturo: our mechanism, by syntax we can look at error. Gordon: if you pass type through type parameter the same time errro is reported Arturo: types of different things are Ray: can we do blocking assignment to design variables, from program block Gordon: we can not definitively say the behaviour of text of task is determined. simpler case: no scheduling semantics, no task, how this looks, if you wanted handles, anywhere in the system is. Arturo: properties, get/set method and pure function. have not parametrized it types of object is same, handle is the same, Gordon: can a class type in package that does not have a pararmeter syntax and a task in it Arturo: if not in an anonymous program it is in design world. today, you can not extend across any domain or even heirarchical scope. Dave: class RGB, not to be able to use a basic type, some one not to use a basic type of RGB class in both, make sense in both. Arturo: whole motiviation, synchronous test driving the design and eliminating races, non-blocking assignment, not on the design space, Ray: attribute needs to be on the variables, not on the types, Arturo: if you read it again, you will not get the same value, clocking block also have the non-blocking assignment like behaviour, dynamic constructs, part of environment, put it in the program, Gordon: parametrized class extend unparametrized base class, it allows one to have a base pointer that would represent an object into the new region. Ray: question, class with int, declared in a package outside unnamed program blcok, when would we know which type it is non-blocking assignment blocking assignment Gordon: can we research every point of expression, or come up with a rule that gets us the most of it. Arturo: anywhere you brought up the scheduling mechanism, Ray: the only data that passes through is primitive type, Both proposals disallow having methods to have different behaviour, object with different semantics is difficult, object task from a particular domain would not be coherence problem, Arturo: data-types, why those methods can be usefull, can I assign multiple times to this variables and not see results, Ray: the use model, what does it give to the user, as long we can separate them, Dave: can we talk about class that has no methods. Arturo: other than the reuse of base class. Ray: what is design data? by what type is Dave: not necessarily scheduling behaviour, example coverage, Gordon: rules for derivation, all of the rules of proposal, and more examples Arturo: the purpose of program, scheduling, Gordon: behaviour of built-in types, pre-defined class type rules (if different than the user-defined classes) will bring disagreement and not resolution Dave: where the handle is declared, Ray: if only data class, declare it in design, can not do non-blocking assignment, Gordon: ability to give us void * or cast, there has to be normalization loophole. legal and valid use model. you can not cast an object to derivative Artuto: can come up with language extensions that will break the paradigm, Gordon: ** all parametrizable classes of that same base type can be extended, the base type can reference object in either domain. Arturo: if you want, program class that can be extended in the module, no object of both type. Gordon: only virtual class. Arturo: only abstract classes can be looked into as a compromise. pure base class. Gordon: pass type parameters from module to programs, there is nothing that says you can not extend it. ---------------------------------------------------------------------------------- --------------- End of Mehdi's 'raw' notes ----------------------------------