agenda for the June 25 R5RS meeting

[halstead@crl.dec.com]

We propose the following agenda for the R5RS meeting at PARC on June 25.  This
schedule, like everything else about the meeting, can be changed by consensus,
but this is our starting point.

    8:30 -9     Talk by Jim Miller: "Scheme: Ready for Prime Time?"
    9    -10    tune agenda, dispose of section 1 topics
    10   -10:30 section 2 
    10:30-10:45 break
    10:45-12:00 section 2
    12:00-1:15  lunch
    1:15 -2:45  section 3
    2:45 -3     break
    3    -5     section 2

"Section 1," etc., refer to the triage of topics into categories, mentioned in
an earlier rrrs-authors posting.  Here is our initial triage of topics raised
for consideration at the R5RS meeting.  Topics are arranged in each category
roughly in priority order.  Some time at beginning of the meeting will be
allocated to fine tune the categorization and the order within categories.  If
we can get some of this done by e-mail before the meeting, that would be great.


1. Proposals that already enjoy a consensus.  We should agree as
   quickly as possible that these will be part of R5RS, and move on
   to other things.

    * multiple values [Ramsdell]
	  We have a proposal with broad consensus.

    * Make APPLY of >2 arguments essential. [Jaffer]

    * What should sec. 6.5.3 say about "/" and exactness? [Jaffer]

    * QUOTIENT, ..., LCM not required to accept inexacts. [Jaffer]


2. Proposals that probably will (or should) make it into R5RS, but
   which look like they still need significant work before consensus
   can be achieved.  Most of the meeting time should be spent on
   these proposals, identifying the areas of agreement and
   disagreement, and finally setting into motion a process to resolve
   things.

    * Macros. [most recently raised by Rozas]
	  Currently they are in the appendix, and there are three
	  proposed low-level mechanisms.  If at all possible, let's
	  choose one and put it on the main report, if so, we can add
	  a standard macros section, and move LET*, DO, COND, CASE,
	  and others there, with prototype definitions.

    * dynamic binding [Curtis]
	  We have a proposal that has been discussed, and has met with some
	  approval.

    * record types [Curtis, Rees, Adams]
	  We have a proposal with some consensus.

    * Exceptions. [Curtis]

    * How should we proceed with revision/expansion/evolution of the
      set of useful "standard" Scheme procedures?

       - Trial Use Standard. [Dickey]

       - defining more standard libraries (or forking off a new language
         definition for such to avoid marring Scheme's good name).

       - Filling out the standard library with missing operations (e.g.
         vector-for-each), and moving it to a separate section of the
         report. [Rozas]

    * n-ary functions [Curtis]
	  Pavel posted a proposal to the Scheme mailing list for n-ary
	  functions taking their extra arguments packaged as a function.
	  It got a favorable response, but people generally did not like
	  details of the proposed change to lambda-list syntax.


3. Issues that aren't likely to influence R5RS, but which are
   important in the long term for Scheme, and which would benefit
   from some discussion at the meeting.  These should be discussed
   enough to bring out why they are important and what are the
   relevant technical considerations, but there should be no attempt
   to drive toward consensus on these.  Discussion of these issues is
   mainly a "consciousness-raising" exercise in preparation for some
   future RnRS meeting where they may need to be discussed more
   seriously.

    * module systems

    * object-oriented programming extensions

    * multiprocessing

    * fixing Scheme I/O (so that it is not a toy)


4. Proposals on which a consensus is unlikely to be developed before
   R5RS comes out.  These should generally be tabled and saved for
   e-mail discussion, unless there is a consensus at the meeting to
   move them into one of the other categories.

    * Library issues that might be handled if we develop a systematic
      philosophy for growth of the Scheme library:

       - Bit vectors. [Blair, Pavel, Jaffer]

       - Read/write to strings. [Carlton]

       - Vicinities. [Jaffer]

       - Add DEFINED?. [Jaffer]

       - Allow control of error reporting from open-input-file. [Carlton]

       - Allow control over buffer flushing on output. [Carlton]

       - EXP, ..., ANGLE not required to accept exacts. [Jaffer]

    * EVAL. [Rozas]

    * Make ports a disjoint type. [oz]

    * Dynamic wind. [Rozas]

    * Improve description of LOAD and make it nonessential. [Carlton]

    * optional arguments
	  We didn't find a proposal, but seem to recall that this issue
	  was pending resolution of multiple values.

    * Entities (applicable data). [Rozas]

    * "Pushy" continuations. [Rozas]

    * Multi-dimensional arrays. [Rozas]


						-Norman Adams
						-Bert Halstead