[This document is NCITS/J13 99/010] [These minutes were approved at the 12/12/00 meeting.] DRAFT Minutes of the NCITS/J13 meeting on 10/14/99 at SRI Attendees: Steve Haflich (Franz) Kent Pitman (Self) Richard Billington (Sandia) Mabry Tyson (SRI) John L. White (Caelum Research/Nasa) Raymond de Lacaze (SRI) Natarajan Krishnaswami (Self) Eric Dahlman (Colorado State University) John Mallery (MIT AI Lab) Rainer Joswig (Lavielle) Chuck Fry (Caelum Research/Nasa) Tim Bradshaw (Self) Erik Naggum (Naggum Software) Kevin Layer (Franz) Mark Stickel (SRI) Andy Sizer (Harlequin) Agenda Item 1: (done) - Call to order 10:00 - Peter Lindahl & Rusty Johnson [Sterling] not present - J13 is a technical committee of NCITS (not ANSI) - Our business is LISP (mostly CL, but we represent the larger LISP community) - We are the author and maintainer of the ANSI CL standarad - $600 membership fee ($300 membership + $300 International) - New membership starts in December - You can only vote after attending your first meeting - To remain a member, must attend 2 out every 3 meetings - May, July & October meetings in 1999 - Most meetings will be virtual - Outsiders can serve on subcommittees - Additional members from member organizations are ok (informally). - 9 paid members, quorum is 4 for voting - (done) Agenda Item 2: Appointment of a Secretary Pro Tem - Ray de Lacaze - (done) Agenda Item 3: Approval of draft agenda - Do we need to draft project proposals? (vote by the committee) - Should we break into smaller groups? - Any item wanting to be discussed is legitimate - Not ok to discuss things too exuberant (e.g. MOP: need a proposal presented to committee) - Debates can be stopped by a 2/3 vote - Explore at least one or two proposals at this meeting - Need to talk about resources, what should be done, fears of failure - New agenda item 6.1: Sketch out the technical areas we will discussing - Motion to approve draft agenda (Naggum, Mallery) - Motion withdrawn by suggestion of Chair (Haflich) - Continue with Item 3 - Agenda items need happen in order - New Item 5.2: Mallery et al paper on Standards Process (used to be part of item 8) - Removed "(See notes below)" from item 6 - New Item 5.1: Should we have a Charter? - Agenda approved as revised - (done) Agenda Item 4: Approval of draft minutes from 27 July 1999 meeting - Need for a second channel of communication - Teleconference meeting not a good idea - Use IRC? (Naggum) - Either way, need everybody comfortable with alternate method - Table vote after lunch for July 27 minutes approval - Item 4a (teleconference evaluation) deferred till later - Lunch $4.80 [Break for Lunch at 12:15 / Reconvene at 1:00] Agenda Item 5: Exploration of possible J13 Actions (Haflich) - Distribution of materials 1. Possible J13 Actions 2. Four Sample Documents 3. SD-2 NCITS Rules & Procedures 4. SD-3 Project Proposal Guide - Normal maintenance - We are a technical committee founded in 1986 - Must review the ANS every 4 years - Errata - Cannot change what the standard is. - Can make changes that fix mistakes - Omitted text can be added - Chuck Fry (for the record): Fix errata that we know of - Revisions (require a project proposal) - Can do revisions anytime - Not appropriate for localized changes - Not appropriate for adding new stuff - Danger of not getting to other tasks - A revision is a large extensive task - Amendments (require a project proposal) - Catch-22 between "can think about it" and "requires a proposal" - Need to informally think about it - Importance for vendors to be represented - There is a mechanism for public exposure - Some things we can do, some we can't, but there is much freedom - How to do an amendment: - Good idea to do X - Project to do X - Project approval - Specify the details - Amendments are normative, can change the standard - Normative: Conform & abide to the standard - Technical Reports (require a project proposal) - Anything 2/3 feel is useful to the committee - TR are not normative - Lower standard of xxx, less antitrust issues - Faster approval (important) , no public review - Many things we want to do may be best as TR (important) - May point the way to an anticipated standard - Trial implementations - ANSI & NCITS charge for TR - $375 for a paper copy of ANSI CL - J13 has produced one ANSI TR - How are TR distributed? - Normal way is distribute electronically for $20 - [ISO standards available for free, but legally unbinding] - [Need to make Lisp easily available to young people] - Supplements (require a project proposal) - Modifies or enhances a TR - Contrast with amendment which changes the standard - New Independent ANS (require a project proposal) - Doesn't harm the standard - Non-compatibility with existing standard is possible - [ISO uses Registration Authority] - Action Item for Steve Haflich: Look at Registration Authority. - Amendment vs. new ANS is a tactical one - Cannot do things as J13 Committee outside of NCITS - Requirements for Project Proposal - "Where Sanity meets the road" (Haflich) - Important: Sect 3.2 Existing Practice & the Need for a Standard - Important: Sect 3.3 Implementation Impacts of the Proposed Standard - Layer: Franz categorically does not want to see things standardized that are not implemented and in use. A matter of common sense. - Discussion of research vs. standards objectives - PAS: Publicly accessible standard - Tomorrow: Lunch from 12:45  1:45 - Tomorrow: Meet from 9:30  5:30 - Motion to accept the amended minutes of July 27 1999 (Layer, Stickel) - Motion approved without objection - (Agenda Item 4 done) - Agenda Item 5.1 Charter - Kent Pitman: - Narrowing & Focusing - Outline intentions & commitment - Not make standards for things not in practice - FFI, Sockets - Rich Billington: - Lisp should play well with other things - MOP - Distributed computing - Cryptography - Natarajan Krishnaswami - Introspective capabilities - Eric Dahlman - Multiprocessing - Need Interoperability - John Mallery - Demographic problem: no young lispers - Lack of Interoperability - Network world - Introspective language - Focus on high impact items - Distributed KR - Rainer Joswig - Networking & Streams - Identify extensions - Cleanup the language - Chuck Fry: - Standardize implemented things that vary slightly between vendors - Better access to networks - Downsized version of the language - Historically the most malleable language: preserve & extend - Tim Bradshaw: - Charter is a good idea - Prevent stagnation - Enabling technologies - Don't standardize things that don't exist - MOP - Multithreading - Erik Naggum: - No massive featuritis - Character sets (scripts) - Time (see Erik's LUGM paper) - Don't add things on top of the language - Kevin Layer: - Use native OS threads for MP - Don't standardize current Franz & Harlequin MP - Changes will affect the vendors - Supports Naggum's view of not adding things on top of the language - Fully supports research, but no connection with J13 - Language not changing since 1994 is a good thing - Mark Stickel - Help the Lisp language thrive - Lisp community needs to grow - Interoperability - Standard GUI or via Java - Performance - De-emphasize the cost to vendors - Andy Sizer: - Lessons to be learned from Dylan - MP: Understand difficulties & consequences of current implementation - John L White: - Parentheses, Principles, Priorities & Practical Examples - Add parentheses to the LOOP macro - Principles (substitute for charter) - Conservatism for Lisp community - Time frame for the next standard - Cost - Agreement between vendors - Pick the fruit you can reach (low hanging fruit) - Practical Examples - Require - Export control - Java inspired multitasking - Notify & Synchronize (Java inspired) - Standardize MP, FFI - Plug Loophole in Unwind-Protect [Much discussion about doing MP the right way, using native threads] - Franz currently has native threads on Windows, but still using stack groups on Unix because of the platform discrepancies with POSIX (Layer) - Strawman version of MP API proposal (Haflich) - Include vendor-dependent issues (Naggum) - Exclude things user can easily provide (Naggum) - Had a vote to draft a Principles Proposal - Vote was passed unanimously - Mallery, Joswig & Johnson: J13 Work Plan Process - Evolving Vision - Incorporation Tracks - J13 Organization - Standard CL Site - Discussion of the Work Plan Process - Have the ALU do this? - CLTF: Common Lisp Task Force - NCITS constrained by ANSI & others - J13 liaison to ALU (official or not) - Appropriate to present to J13, Inappropriate for J13 to act on - Need funding to implement - Thesis topic for some student? - DARPA proposal? Minutes of NCITS 10/15/99 Attendees: Steve Haflich (Franz) Kent Pitman (Self) Richard Billington (Sandia) Mabry Tyson (SRI) Raymond de Lacaze (SRI) Natarajan (Self) Eric Dahlman (Colorado State University) John Mallery (MIT AI Lab) Rainer Joswig (Lavielle) Chuck Fry (Caelum Research/Nasa) Tim Bradshaw (Self) Erik Naggum (Naggum Software) Kevin Layer (Franz) Mark Stickel (SRI) Andy Sizer (Harlequin) - Call to order: 9:45AM - 2 items of business today - draft a charter - draft a proposal [distribution of Kent's x3j13 1987 charter] - proposal for a motion to draft a proposals - collect the proposals principles - vote on them seperately - vote on the final proposal - try to do this by lunch, else defer it till later time Principles organization suggestion (Mallery) 1. past practice 2. currrent practice 3. future issues - suggestion for a motion to draft a set of principles (with text formalized later) with the initial text to be it's title (Haflich) - Motion to draft "Principles" (Stickel, Natarajan ) - Motion passed without objection [brief pause to allow reading of Kent's x3j13 1987 charter] [discussion of Kent's x3j13 1987 charter] Mallery: - suppress, restate principle 3 - look at other languages - look at research areas - additional principle: make greater collaborative effort, code sharing Rich: - Item 2 should be changed to CLTL2 - Agree with the bulk of Mallery Erik - environmental issues - interfaces, interconnection as a principle - defpackage reconstruction Mark - syntax & esthetics, item 2 depreciates this - e.g. parens in loop Steve: - item 1 modified appropriately - item 3 will be a new list - item 4 add notion of conformmity - item 5 can go away Rainer - Ansi is the standard for CL - urge implementors to abide by the standard and by J13 - define existing practice - anticipate need for future development, and acknowledge process of language development Chuck: - recognition that CL has been substrate for embedded systems - good for experiments - principles need to recognize resource limitations of the committee Kevin: - priorities based on business & customers - J13 yet another need - 2 camps at this meeting - proposals - preservation with previous standard - modify & extend the language in ways user cant - add new features for existing implementations (e.g CLOS) - idea > implementation > TR > ammendment or subordinate standard Mabry: - item 1 is facilirtae protability - item 2 cost of adopting or not adopting - pay attention to provide transition path for CL - standard should not limit the language Mallery: - identify layering aspects of the language - lower level base Lisp - layering & modularity Chuck: - there are struggling vendors and those that are gone - get new ideas from users, empower community to do experimental language research - path to adoption of new standard Rich: - the standard embodies things that make Lisp unique - e.g. some MOP Kent: - add additional features - MOP, FFI, no new functionality - not concern itself with implementation Rainer: - CL seen as a modern language Chuck: - prioritize coonnectivity issues Erik: - things don't look so bad with respect to growth of community Kevin: - work more at the language level - vendors have spent millions conforming to the standard - push lisp via J13 is not the right way to go Tim: - false perspective of CL - no radical new language features [Discussion & ranting] Mark: - lisp be unexcelled in functionality Initial List - Work on the language and not what users cn easily do for themselves - Do what is important to the community - Enable Lisp to progress and evolve - Solve core problems not superficial ones - DTRT more important than ease of implementation - Back compatibility - Discourage standardization without implementation (PP > Impl > TR > AMND) - Favor modularity in standards (separate substandards) - Not bind to existing practice if it might limit future progress - (if codification increasing, TR rather than ANS) - Language aesthetics are subordinate, but still positive [disussion of principles] Motion to have a draft set of principles in the next 1/2 hour. (Mallery, Naggum) Motion ammended by chair to decide at that time when the issue will be revisted. Table the motion in 1/2 hour Motion approved without objection Enable sharing & group processes - Enable communication & cross-language interoperation Strive for Scientific & Engineering Excellence - provide examplers for emulation - support leading edge communities -> new language crucibles Balance needs of vnedors & customers w/ forward loooking applications Prioritize work toward high-payoff / short-term goals Differentiate language from libraries Think faster, smarter [discussion of principles] Table the issue, and focus on the technical areas we will want to work on. Discuss the principles 4-5:30, work on tehnical issues 2-4 [Lunch break] - agenda item for tonight for Steve: examples of proposals - agenda item for next meeting: - can we work electronically? - what are the appropriate technologies? - Action item for this afternoon: Quickly run down the two lists of items to work on and pick two items that are acceptable to the committee. Mallery: Read list of bullets from MIT's proposals Pitman: Read list of bullets from his proposals Rich: Read list of bullets from Sandia's proposals Joswig: Read list of bullets from Nick Levine Initial List: (The two vote tallies are by organization / all present. The initial number in parentheses are the number of times the item was listed in initial areas of concern.) (1) Multitasking / Uniform Process Model 5 6 (1) Network Interface 4 5 (1) URLs 1 1 (1) FFI 7 8 (2) Streams 3 4 (3) Character Sets 4 6 (1) Defsystem / Documentation 5 5 (1) Package System 2 2 (1) XML / RDF etc... 1 1 (2) File System / External File Format 1 2 (3) MOP/CLOS 3 4 (1) Code Walker / Environment 2 2 (2) File System / External formats 1 2 (3) Weak datastructures 3 4 (1) Iteration 0 0 (1) Persistence 0 1 (1) Regular expressions 0 0 (1) Sandbox security 0 0 (2) Corba 0 0 (1) Standard Conditions 1 1 (2) Time 0 0 (1) Performance / Tail 0 0 Strategies for FFI - Retroaspect, LCD approach - Full design approach - Define FFI wrt language-independent guidelines - Consider ILU from Xerox Park - Need for people to write proposals - Agreement among Lisp implementors - Standards work inherently boring - Need to understand the FFI issues in more depth - Take a look at what items people would be willing to work on: Naggum: Willing to work on Character Sets, Time, & XML Decision to stay with the current thread Motion to return to Principles first thing in the morning (Fry, Naggum) Motion approved without objection Steve: FFI, CS, XML Ken: CS, XML Rich: MP, Streams, Defsuystem, XML, MOP/CLOS, Code Walker, Persistence Sandbox, Vector Arithmetic Andy: MP, Weak datastructures Marc: Weak DS, Iteration Kevin: FFI, CS, RE, FS, Package, XML Erik N.: CS, XML, FS, Time, FFI (OS INterface) Tim: MOP (small subset), Weak DS, Chuck: Streams, MOP/CLOS, Coe Walker, Vector Arithmeti, Portable Base language Rainer: Streams, Network Interface Mallery: Adaptive Prog, Transactional memory, Parallel Dialects, Mobility, Portable Base Lisp, Defsystem / Documentation Facility, URL, Network, XML/RDF, Code Walker Nat: CS, Vector Sets, Portable Base Language Erik D.: Code Walker, Portable Base Lisp, FFI, Package System Mabry: Cleanup, FFI A vote was taken to show interest in potential areas of work. Three tallies are given: tally by member organization, tally by all present, and a tally of those who would be willing to invest work in the particular area. Finally, there is a volunteer Point of Contact to take charge of considering a project proposal. Topics for J13 Members All Work on POC (2) Multitasking/Uniform Process Model 5 6 3 (2) Network Interface 4 5 2 (2) URLs 1 1 1 (4) FFI 7 8 4 (5) Streams 3 4 3 (6) Character Sets 4 6 4 Layer (2) Defsystem / Documentation 5 5 4 (1) Package System 2 2 2 (4) XML / RDF etc... 1 1 6 Pitman (5) File System / External File Format 1 2 1 Layer (6) MOP/CLOS 3 4 4 Bradshaw (4) Code Walker / Environment 2 2 4 Fry (3) Weak datastructures 3 4 4 (2) Iteration 0 0 1 Stickel (1) Persistence 0 1 1 (2) Regular expressions 0 0 1 Layer (3) Sandbox security 0 0 1 (4) Corba 0 0 0 (3) Standard Conditions 1 1 0 (4) Time 0 0 1 Naggum (2) Performance / Tail 0 0 0 (3) Vector Arithmetic 2 2 4 JCMA (1) Portable Base Language 0 0 4 JCMA (1) Cleanups 1 1 1 Minutes of the NCITS/J13 meeting on 10/16/99 at SRI - Call to order: 9:40 - Things to get done today: - Schedule of next meeting - Principles - Project propasals - Discussion of "Priciples" document Principles List 1. Work on the language and not what users can do easily 2. Do what is important to the community 3. Enable Lisp to progress and evolve 4. Solve core problems not superficial ones 5. DTRT more important than ease of implementation 6. Back compatibility 7. Discourage standardization without implementation (PP > Impl > TR > AMND) 8. Favor modularity in standards (separate substandards) 9. Not bind to existing practice if it might limit future progress (if codification increasing, TR rather than ANS) 10. Language aesthetics are subordinate, but still positive - Discussion of first principle - Suggestion to strike first principle (JM) - Suggestion to add "Enable sharing & group processes" (JM) - No user can implement the defsystem correctly (KP) - Don't bulk the language up with defsystem (RB) - Create a single defsystem substandard (RB) - Goal of the language is to facilitate different people at different places (& time) using the same Lisp (MT) - Don't have a clear meaning of language (RJ) - Replace first principle with: "J13 will primarily concern itself with the reation and repair of that functionality necessary to support the development of user-defined code that is efficient, modular, portable and collaborative." (KP) - Take principle 8 seriously. (JM) - Don't restrict ourselves to single subsystem of a particular type. (MS) - Don't want in our principles to advertise limited resources. (RB) - Agree with Richard about limited resources (NK) - Include principles that will attract people to the standards effort. (RJ) - Suggestion to eliminate "user-defined" from suggested replacement for principle 1. (RJ) - Much objection by many. - Concerns about layering in the language. (CF) - Layering should be a design principle made explicit (JM) - Layering would move us in the direction of open systems (CF) [Discussion] - Eliminate the CL package and move to Java-like model where you specify exactly what parts of the language you want to use, [makes tree-shaking a lot easier.) (KP) - Strengthen the language so that it is easier to change the language (RB) - Use TR's as a vehicle to make some of these changes. (MT) - Change the term "creation & repair" in replacement for principle 1. with "standardization" and change "user-defined code" with "programs" [break] Suggetion to continue working on principles: A. J13 will primarily concern itself with the standardization of that functionality necessary to support the development of programs that are efficient, modular, portable and collaborative. B. Do what is important to the community C. Not bind to existing practice if it might limit future progress (if codification increasing, TR rather than ANS) Enable Lisp to progress and evolve D. Back compatibility E. Discourage standardization without implementation (PP > Impl > TR > AMND) F. Favor modularity in standards (separate substandards) G. H. Language aesthetics are subordinate, but still positive I. Solve core problems not superficial ones J. DTRT more important than ease of implementation (MIT >> NJ) - Suggestion to not order the principles - Must remain clear that principles are not laws or imperative - Principles not so much guidelines, but to ensure we are on same page - Descision made by table vote to not order the principles. New Principle K: In recognition of the historical uses of Lisp, consideration will be given to language features that facilitate the development of domain-specific embedded languages within the framework of Common Lisp (CF) New Principle L: Develop and promote Common Lisp as an unexeled language for imperative, functional, and object-oriented programming, and to support domain-specific embedded languages. (MS) Agreement to discuss the newly proposed principles. Suggestion to replace L: Maintain the scientific and tehnical excellence of Lisp for diverse programming styles by promoting the goals of generality, parsemony and completeness in solutions of core problems. Suggestion to inlude a principle that addresses mobility, internet-readiness etc.. as a means of making explicit our awareness of these issues. [Discussion of lunch, what to do, how to do it and how to proceed next] - 6 is the max number of meetings - 1 is the min number of meetings [Lunch break] - Discussion of next meeting - Could have a physical meeting - Could have a teleconference - Schedule the next meeting as a phone meeting for the sake of having a scheduled meeting. - We will most likely revert to some electronic meeting mechanism - The appointed subcomittee (EN, KP, JM, SH) will accomplish this by Dec. 1st. John Mallory will chair this subcomittee - The next meeting will be scheduled for Wednesady, January 26th 2000 - The agenda will go out by January 12th, 2000 - The call to meet will to go out by December 19th,1999 - The meeting time is 1700 UTC (9AM PST, 12PM EST) - Vote to approve next meeting time. (vote passed) - Motion for people to go of and work on the outlined proposals with the understanding that if anyone picks a topic with an existing chair they wil coordinating with any selected chair. (KP, TB) - Motion approved without objection. - The points of contacts will be replaced by actual names. - Motion to ask the points of contacts if they will produce in time for the next meeting proposals. (MT, KL) - Motion approved without objection. - Resume previous discussion about "Principles" - Discussion of Kent's editing changes: - KMP's proposed revision of the principles, v4 (10/16/1999, for discussion) Actual text of proposal: 1. J13 will primarily concern itself with the standardization of that functionality necessary to support the development and deployment of programs that are efficient, modular, portable, and collaborative. 2. The primary base of users that J13 seeks to serve are those producing robust, practical applications. a. J13 will give preferential treatment to those proposals which have been implemented and deployed and for which there is experience of use. b. Language aesthetics are an important consideration, but where practical needs come irresolvably into conflict with aesthetics, J13 will give greater weight to practical needs. c. Mindful of the presence of a substantial installed base that may be adversely affected by incompatible changes, J13 will seek to avoid such changes. 3. J13 will attempt to hold the size and nature of the core language relatively constant in order that there not be an ever-increasing level of difficulty faced by potential new entrants to the Common Lisp marketplace. a. Where feasible, new functionality will be added as modular additional components rather than as required changes to the core language. b. Functionality that makes the core language more receptive to modular extension will be considered appropriate. c. Changes that impose layering on parts of the core language, using the benefit of hindsight to retroactively separate some parts of the original "core" into layered extensions will also be considered. 4. Common Lisp is intended as a language not only for the present, but also for the future. a. In choosing among possible solutions to present day problems, preference will be given to those solutions that seem to provide for greater longevity of design and that seem to interfere least with forseeable options for future change. b. Recognizing that in a dynamically changing world, the need for change can and will sometimes occur suddenly, selectively, or unexpectedly to some users, and not always be synchronized with product releases or the language standardization process, priority will be given to language features which empower programmers to cope with such change directly rather than requiring programmers to wait for vendor or language level support. 5. Common Lisp is a language used by a diverse user community, and no single programming paradigm (such as, but not limited to, Object-Oriented or Functional programming) is considered to typify its user base. Rather, Common Lisp seeks to support a variety of programming paradigms and abstraction capabilities, as well as the possibility of seamlessly-embedded, layered languages. 6. In making changes to the language in service of identified problems, J13 will prefer general solutions over special-case solutions. The most easily implemented solution will not necessarily dominate, but technical and economic issues of implementation are important in determining which options will be given the most serious consideration. - Motion to take Kent's editing changes and use as the basis for discussion. (KP, EN) - Ammendment to motion: Go down point by point from whiteboard and KP written text and see whether or not whiteboard text is properly captured by KP's text.(JM) - Ammendment passed with one objection. - Motion passed without objection - Motion to start with the Mallery proposal of processs (MS, JM) - Motion not recognized by chair. - Mallery process completed. No gross omissions. [Discussion about use of "commercial" in principle 2 of KP's list of Principles] - Motion to replace the use of "commercial" with "practical" in 2c and 2b (CF, JM) - Motion passed unamnimously - Notice of objection given by Rainer Joswig. Objects to the use of KP's document as the basis for the discussion of the principles - Vote to strike first half of header of principle 2. Vote passed by large majority. - Motion to replace "commercial" with "robust, practical" applications (CF, EN). - Motion to ammend motion with the option to strike the entire header of number 2. (MS, NS) - Ammendment not passed by vote. - Motion passed unanimously without objection. [break] - Meta-discussion on nit-picking KP's text. - Around the table on the current text. - Much more positive outlook, not ready to accept as is. - More meta-discussion - Motion to adopt this document as our draft principles after another 20mn of discussion. (JM, CF) - Motion passed by majority vote. - Drop end of 2c after "such changes..". - Strengthen 5. Change the word "possibility" - Eliminate "marketplace" in 3. - In 6, insert after ..dominate, "scientific & technical excellence will be preferred" - In 6, remove "of implementation". - Chuck Fry will be the principle point of contact for the "Principles" draft revision. - KP discussed clean-up issues. Motion to adjourn (CF, EN) Meeting adjourned