A Coup d'Etat

There has been some debate lately (2007-08-25) on comp.lang.scheme concerning the legitimacy and the results of the process which has given us the 5.97 draft candidate for a scheme 'standard'. The original notes from the 2003 Scheme Workshop contain the panel discussion which essentially established the process and are quite illuminating. I have included the relevant text below in case crawling through the entire day's workshop notes seems like too much effort. And I can also annotate them to my heart's content; which I have done below using DHTML/CSS pop-ups.

• [Panel] Scheme standardization
  • Panel Participants
    • Alan Bawden
    • Will Clinger
    • Richard Kelsey
      • Editor of R5RS
    • Marc Feeley
    • Mitch Wand
  • Origins
    • Back in 1984 the was a editoring process created
      • A mailing was created: RnRS
      • Some face to face meetings
    • In face to face meetings things had to be unanimous
      • This was good to deal with the incredibly vague idea
      • If you were in the room, you knew the language wouldn't change in a bad way
    • This led to incredible inertia and a long turn around... R5RS took a long time
    • After the last Scheme Workshop, the editing process needed to be modified
  • New model
    • The Steering Committee is supposed to give legitimacy
      • Put some graybeards on it
    • The Editors are appointed by the Steering Committee
    • Words about new charter
      • The technical content is secondary to the new process around the work.
      • The process is incredibly important and needs to be legitimate.
        • That's the only thing that really matters.
        • Perceived legitimacy though. And this is normally hereditary.
    • Old model was very flawed
      • The "Authors" were people who showed up
      • The "consensus" idea at the first meeting wasn't meant to be unanimity.
        • You couldn't move forward when there were two reasonable philosophies that were mutually exclusive.
      • The IEEE standard process has stagnated and not really useful.
        • Best suited for ratifying an existing standard, not design.
    • The SRFI process is very great, but it can't do anything
      • Too many people fighting over ideology
    • Scheme Workshops had enough history and participation, so that they could usurp the wedge R*RS process.
      • This is where we are today.
    • The Charter doesn't do everything
      • ie, by laws.
    • Goal
      • Sometimes you need one idea of how to move forward, rather than twenty.
    • Legitimacy of the Process
      • Laid out in the Charter, but it needs to be given by the choice of the Committees and Editors
      • The Strategy Committee should draw up a nomination process.
    • Some people should be responsible for looking for responsible people wrt the IEEE.
      • Problem is that IEEE has its own rules and not as free as R5RS.
    • Suggestion: Hereditary Monarchy is not a good process, it should be technical merit.
    • Why the random selection of dubious topics in the charter?
    • Will the old editors be resistant?
      • SK: Who cares! They haven't been around for the last 10 years.
    • These committees are rather large and numerous. They take people out of circulation.
      • 3 editors and 5 steerers? Or 5 editors and 3 steerers?
      • Editors group shouldn't be smaller that the Steering board.
        • Divide up the later better.
        • Editors will do the most work.
      • Steering board should be made up of older editors.
        • Maybe there should an old editor on the editor board to give experience
        • Maybe the old editors should pick the steering board and editors board.
      • SK: Ignore the steering committee, they won't do anything.
      • Maybe the editor-in-chief should sit on the steering committee?
        • They'd communicate better and dissolve power struggles.
      • Why are their no elections or feedback between community and committee?
      • Need to close the door, stop talking and being bureaucratic and pick some people.
    • Democracy the wrong model here.
      • An election right here wouldn't even be very democratic.
      • The legitimacy of the group will be defined by the technical merit of their results.
    • The Strategy Committee will appoint the initial Steering Committee and Editorial Board.
      • Are there any downsides?
      • Too late to not trust them.
      • RESOLVED!
      • Number of each committee is up to the Strategy Committee.
      • Criteria
        • Volunteers, Nominations
        • Technical Merit
        • Enough time
        • Motivated
      • The committees will be announced in 2 weeks.
    • Is the Authors List to be continued? Or will it be left behind.
      • Continued to be used for it's current purpose (nothing.)
      • Basically: No.
    • Should there be a Standard Document and Standard Rationale Document?
      • Suggest to the editors
  • Topics
    • Core Language vs. Libraries
      • You have to be clear that something is a core language or a library.
        • The Editors need to be clear about this, not the suggester.
    • Objection to idea
      • Premature to discuss concrete goals
      • This is a rare opportunity to discuss things because the community is not often together in one room.
    • How to promote and push progress
      • People who impede the process can just be removed.
      • The smaller number avoids the old issue.
    • How to keep the community involved in the process
      • Hard to define, but the SRFI process is explicitly mentioned.
      • There is a 6 month period for the Scheme community to comment on a proposal.
      • The community has ultimate veto power - they don't have to use it.
        • Not to mention, they can create another coup like this one.
      • Implementations need to be happy with the report, and by proxy their users.
        • There is a decade of changes that will be difficult for users and implementors to face.
      • Is comp.lang.scheme a good place to discuss?
        • Is a mailing list better to keep out the trolls?
        • The Editors can solicit advice from the community in any way.
          • Shouldn't be inane though, they are editors for a reason.
      • The community wants read only archive to discussions.
    • Time Periods seem a bit artificial
      • Maybe it should be linked to finished features and units of work.
    • Document repository
      • Offered on Schemers.org
    • Legitimacy
      • We need to get major users and implementors to go along with the result.
      • Support the committee without regard to philosophical disputes.
      • This sort of thing always just works out though.
      • Implementors are answerable to their users.
        • If the users want it then the implementors implement or die.
    • Are people happy with the Strategy Document?
      • Maybe minus the goals?
      • This doesn't imply being bound to the document.
      • Does the community believe in the group?
        • YES
    • What makes this system work where they other failed?
    • Lots of people in the past felt like there was no point to work on things
      • Because the old process had died. It felt like there would be no R6RS.
      • But now with a rejuvenated process people should get more excited.
    • Will this report be named R6RS?
      • It is up to the Editors.
  • Technical Topics
    • Why the listed goals were there
      • Re-assure people that the current R5RS wasn't going to be destroyed.
      • To suggest that it will be evolved.
      • Not "Open Season"
      • Don't take them too seriously.
    • List Goals
      • Portable Code
      • Module System
        • Is this a low level or high level issue?
        • Something like PLT or Scheme-48 module system
        • Standardize amongst the implementors?
      • New Macro System
      • Designate Library Modules
    • Suggested Goals
      • Abstract Data Types
        • This question is what stopped records in the past.
        • New Non-Forgeable datatypes.
      • Arrays (Multi-dimensional)
        • Arrays have evolved and everything else is expressed as them.
        • Some variants do them "good" with uniform types
          • Others go into the cave of vectors and lists.
        • Seems like something that should be in the language.
      • Better definition of constant values
        • Editor's Note: This was raised earlier one but never discussed.
      • SK: A recommendation: Every change should take into consideration the ability to have reasonable static type checking systems.
      • MF: I would like to an operational semantics for Scheme. We are capable and should hold ourselves to a high standard.
    • What are the 10 years of changes that need to be changed?
    • What extent of backwards compatibility with there be?
      • You have to allow incompatibility to bring the language forward.
      • If we could get portability without changing implementations we would already have it.
      • Specifying something more will not break when it is not specified at all.
      • Backwards compatibility means two things
        • Breaking portable code
        • Breaking non-portable code
      • SK: Don't want to become Common Lisp.
      • There will be pain! But it's good for you.
    • How does Common Lisp governing work?
      • So we know what to avoid.
      • Most design happened before committees were made.
      • "If a little feature didn't make the language a whole lot worse, then it's not worth fighting to keep it out"
        • Law of inconsequential degradation
    • How does the Haskell process work?
      • Truly different syntax that was some how resolved.
      • Don't want to follow the model of shutting out implementations