[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

I'm not doing a good job



Fellow authors:

As "moderator" of our email dialog, I had assumed that most of my job
would be in reading the copious email generated by the RRRS-Authors
mailing list, tracking it, and helping resolve technical issues.

As it turns out, there has been no dialog to report, and we do not
seem to be any nearer our goal of issuing the fifth report in July
1993 than we were when we last met in July 1992.  I'm willing to take
the blame, but I don't know how to get things moving again.  As I
understand it, there are two things that MUST be done before we can
move on:

(a) I need to contact Norm (our editor) to find out what progress has
been made, and maybe pitch in to help him out if he needs it.  Maybe
Norm can post us all a note about what kind of help might be useful.

(b) Kent Dybvig needs to release the report of the exceptions
committee.  Kent: you promised this to me three times so far.  When
can we all see it?

As a reminder of what we agreed to do, I'm including Will Clinger's
draft minutes of our last meeting.  Since then, the only things I have
seen from the Authors relating to the next report consists of two
short notes (one from Bill Rozas, the other from Aubrey Jaffer)
correcting/elaborating points in the minutes, and a set of four
messages related to establishing the library.  I've appended the
messages from Bill and Aubrey following the minutes themselves.

--Jim

============================================================

Date: Fri, 9 Oct 92 14:57:51 -0700
From: William Clinger <will@skinner.cs.uoregon.edu>
Message-Id: <9210092157.AA24693@skinner.cs.uoregon.edu>
To: rrrs-authors@ai.mit.edu
Subject: draft minutes of June 1992 meeting

           Draft Minutes of the RnRS Authors meeting
                        25 June 1992
                         Xerox PARC
            recorded and edited by William Clinger

Bert Halstead called the meeting to order at 8:45.

The meeting began with a moment of silence in memory of Bob Hieb.
Then Jim Miller gave a 25-minute talk on applications of Scheme.

The next two hours were devoted to setting the agenda and related
matters, notably voting procedure.  Chris Haynes suggested that
we record votes without deciding their significance and leave it
to the R5RS editor to interpret those votes and reflect them in
the R5RS, including rationales on both sides of controversial issues.
A straw poll revealed three objections to this procedure.  Jeff
Dalton noted that the meaning of a vote would not be clear.  Kent
Dybvig observed that we shouldn't leave the meeting without a good
idea of what had been decided.  Kent Pitman wanted to change the
voting procedure, but felt that Haynes's suggestion was an attempt
to finesse the issue instead of resolving it straightforwardly.

Somewhere in this discussion Bill Rozas asked whether anyone
objected to making changes for conformance with the IEEE standard.
There were no objections, but then Kent Pitman objected that he
didn't understand the issue, which led back into the discussion
of process.

Jonathan Rees suggested that the job of R5RS editor be split into
a document ("TeX") editor and an electronic mail facilitator, who
would read and respond to electronic mail, seeking and declaring
consensus.

Olivier Danvy was chosen as editor for R5RS (but withdrew; see
below).  Jim Miller was chosen as email facilitor.  Carl Bruggeman
and Bruce Duba may assist Miller.

Dan Friedman suggested that the R5RS should be ready by February 1,
1994.  Others suggested 12 months from now.  Haynes noted that we
can't wait longer than 12 months, because the IEEE standards group
will have to be reconstituted in 18 months.  Olivier Danvy noted
that he might not have time to edit the R5RS within that time.

Jonathan Rees nominated Norman Adams as editor for an R5RS to be
ready in 12 months.  The nomination was seconded and approved by
consensus.

Chris Haynes reported that Dick Gabriel contemplated proposing that
the ISO Lisp standard be based on Dylan (a trademark of Apple
Computer).  The Dylan group has opened a window of six weeks,
beginning now, during which they will accept proposals for changes
to Dylan.  Chris suggested that that window could be used to propose
changes that would make Dylan a superset of Scheme modulo alpha
conversion, or that would make it easy to implement Scheme on top
of Dylan (or perhaps vice versa).  Chris had talked to David Moon
about this, who seemed open to it, but reported that the Dylan
group did not have the resources to perform the necessary analysis.
Haynes proposed that the Scheme community form a group of people
who can within six weeks propose something to the Dylan group,
including convincing rationales for first class continuations and
anything else missing from Dylan.

After discussion, William Clinger moved that the authors solicit
volunteers to work on resolving incompatibilities between Dylan
and Scheme.  Discussion clarified that the goal was to cooperate
with Apple to prevent further fragmentation of the Lisp community,
and that the Scheme authors were willing to change Scheme as well
as asking Apple to change Dylan.  The motion passed unanimously.
Asked whether the authors' willingness to change Scheme extended
to extensive renaming, the obvious sentiment of the group was
that it did.

Kent Pitman discussed exception systems.  Jim Miller suggested that
we appoint a group to work on this.  Jon L White observed that
exception systems usually depend on an object system, which Scheme
lacks.  Pitman suggested that we adopt his exception proposal but
flush handler-case.  Several people liked that idea.

We adjourned for lunch at 12:15.  The meeting resumed at 12:45
with a number of straw polls on technical issues that had been
raised over electronic mail, with no discussion permitted.  The
results of these straw polls were as follows.  ("--" means the
votes were not counted.)

    technical proposal          in favor   needs more   opposed
                                           discussion

    multiple values               10           2           0
    require distinct #f and ()    20           0           0
    make inessentials essential   25           0           0
    change description of /       --       consensus      --
    require exact arguments
      to the quotient procedure    1           0          10
    second paragraph of IEEE
      section 6                   --           8          --
    dynamic binding               --       consensus      --
    records                       --       consensus      --
    exceptions (see below)        --          --          --
    Curtis's n-ary proposal       --       consensus      --
    Rozas's eval proposal          7           5           0
    make ports a disjoint type    16          13           2

It was understood that the R5RS editor would implement the
consensus opinion on the three proposals that needed no more
discussion.  The authors felt that the issue of exceptions
needed no more discussion at this meeting, but that a committee
should be appointed to prepare a proposal.  A committee was
appointed at this time, but its composition changed later in
the meeting (see below).

Brief discussions of three issues then yielded a consensus:

Multiple values:  Dan Friedman stated that he understood the
motivations to be efficiency and a wish to hide representations.
The multiple values proposal was then adopted without objection.

Semantics of /:  The issue was whether (/ 5 3) could return an
exact 1.  The unanimous answer of the authors is that it cannot.
The R5RS editor is directed to repair any prose that might
suggest otherwise.

Second paragraph of section 6 of IEEE standard:  Should we add
this requirement to the R5RS?  14 voted in favor, 1 opposed.
After discussion, a second vote was unanimously in favor.

We then agreed on an order in which to discuss the remaining
issues.

Libraries:  The authors perceive a need to give some library
official status.  In fact, we need to give official sanction to
multiple libraries.  There is reason to distinguish between
accepted (or standard) libraries, experimental libraries, and
proposals.  The accepted libraries can reduce the intellectual
size of the language by removing things like string->list from
the RnRS.  The experimental libraries would contain solid
implementations of experimental stuff, including stuff that might
never deserve to be in the RnRS.  The proposal libraries could
contain anything implemented in standard Scheme.

A "require" facility as in Emacs was suggested as the best way
to include a specific library.  Four levels of library were then
proposed: a standard library (available without using "require"),
a "require" library (available using "require"), a moderated
library, and a free speech library.  Rees proposed an officially
sanctioned committee to set up the library, document the semantics,
and so forth.  It was noted that the committee should do something
rational about limiting a library's namespace.  Mlynarik objected
to "require", for the same reasons he objects to "load".

The apparent consensus was that the library should consist of
portable code written in standard Scheme, and should be stratified
into three levels:
    blessed by the RnRS authors
    blessed by the librarian
    unblessed
Implementation of this consensus was deferred to later in the
meeting (see below).

Macros:  Chris Hanson moved that the high level macro system be
moved from the appendix into the report proper.  Rozas seconded.
After discussion, including discussion of Dybvig's week-old
low-level macro proposal, 21 voted in favor of Hanson's motion
and none voted against.  Jim Miller then recommended that the
naming conventions suggest that a special character end the names
of macros.  This recommendation was opposed.  Miller then asked
to change his vote on Hanson's motion.  The final vote is therefore
20 in favor, 1 opposed.

A vote was taken on flushing the macro appendix, which would be
left with only the description of a low-level macro system.  Many
favored flushing the appendix, but 2 were opposed, both of whom
felt that the appendix should describe one or more new low-level
systems.  The fate of the macro appendix will be left to the
discretion of the R5RS editor.

Records:  Jeff Dalton suggested dropping the type-name argument
to MAKE-RECORD-TYPE.  This was considered reasonable by consensus.
[Secretary's note:  Would RECORD-TYPE-NAME also have to be dropped?]

Dybvig objected to the record proposal because it isn't at a high
enough level.  He also objected to its abstraction-breaking features,
its lack of immutable records, and its use of procedures instead of
special forms.  Dalton cited the Common Lisp experience in support
of abstraction-breaking features, admitting that they made it more
difficult to analyze programs.

A vote was taken on adopting the record proposal without prejudice
to further development of this issue.  9 were in favor, 11 opposed.

The authors then adjourned for 20 minutes.

Exceptions:  The exceptions committee was charged with preparing
a proposal to be brought to the authors via email, with consensus
to be determined by the email facilitator.  Six months is a
reasonable time frame.  The committee consists of:
    Kent Dybvig (chair)
    Chris Hanson
    Dan Friedman
    Richard Mlynarik
    Pavel Curtis

Dynamic binding was discussed very briefly without result.

Dynamic-wind:  The semantics of (dynamic-wind before during after)
should leave unspecified what happens if a throw occurs out of
before or after.  It is best to defer interrupts during before and
after.  Following these clarifications, DYNAMIC-WIND was then
approved unanimously.

N-ary procedures:  It is the sense of the authors that something
like the n-ary procedure proposal is worth trying to get into R5RS:

    (lambda (x ... "marker" fn n) ...)

binds fn to a procedure and n to the number of excess arguments.
The excess arguments are obtained by (fn 0), ..., (fn n-1).  The
apply problem is taken care of by (fapply foo x ... fn n).  It
was moved that this proposal be adopted modulo details of syntax
(including the syntactic marker and whether lambda is overloaded).
[This motion was apparently never voted on, and possibly never even
seconded, although three votes were taken to clarify it.]  It was
asked whether this new proposal should replace the existing dot
notation, or be in addition to the dot notation.  10 were in favor
of replacing, 2 in favor of addition.  Asked whether this replacement
should occur in the R5RS, 11 were in favor, 7 against.  Asked
whether the existing dot notation and rest lists were satisfactory,
the group said unanimously that they were not.

The issue of whether ports should be made disjoint from other types
was not resolved.  Jim Miller proposed:

    a procedure that creates a new disjoint type
    a predicate to test for elements of a type
    a predicate to project from a type to its representation
    a predicate to inject from representations to types
    a predicate to test for any user type [what does this mean?]
    a procedure to return the user type

No action on this proposal was recorded either.

Eval:  9 voted in favor of Rozas's eval proposal, 5 voted against.
After discussion, a straw poll showed that almost everyone wanted
to add some kind of EVAL; one person was opposed, apologetically.
A second vote on Rozas's proposal showed 12 in favor, none opposed.

Olivier Danvy said he still preferred Rees's proposal for a
one-argument eval with the r4rs-environment as the default, to be
called SCHEME-EVAL.  No top-level definitions would be allowed as
the argument, only expressions.  A preference poll showed that
7 favor Rees's proposal, 8 favor Rozas's.  It was observed that
either proposal could be implemented in portable Scheme as a
library.  Rozas noted that Rees's proposal does not give access
to the interaction environment, which is what most users want.

Rozas's proposal is the one that was approved.

A procedure to determine the arity of an arbitrary procedure's
value was discussed briefly, without result.

Jon L White, Morry Katz, and Jim Miller volunteered to investigate
incompatibilities between Dylan and Scheme.

The timing of the next RnRS meeting and of the R5RS was discussed.
It was decided that subcommittee reports should be due by
1 February 1993.  The draft R5RS should be out by 1 May 1993,
voting on it should end 1 June, and the R5RS should be published
by 1 July 1993.

Indiana folk volunteered to host the next meeting in Bloomington,
Indiana.  Dan Friedman volunteered to handle local arrangements.
Chris Haynes was nominated as chair, seconded, and chosen by
acclamation.  (As a point of order, it was clarified that this
group was actually recommending Haynes as chair to the entire
group of authors, who may choose someone else if they like.)

Haynes suggested that Norman Adams be encouraged to look at the
issue of splitting the R4RS procedures into libraries for the
R5RS.  This suggestion met with overwhelming approval.  Rees
remains temporary library.  Clinger and LaLonde volunteered
to be on the library mailing list and to pester Rees as
necessary.

Halstead summarized the remaining unresolved issues:  voting
procedure, charter of purpose, and the set of issues that
comprised category 3 of the agenda.

The meeting adjourned at 5:50 pm.

============================================================

Date: Fri, 9 Oct 92 20:02:07 -0400
From: "Guillermo J. Rozas" <jinx@martigny.ai.mit.edu>
To: will@skinner.cs.uoregon.edu
Cc: rrrs-authors@ai.mit.edu
Subject: draft minutes of June 1992 meeting

    ...
    a predicate to project from a type to its representation
    a predicate to inject from representations to types
    a predicate to test for any user type [what does this mean?]

What this means is a procedure to test whether an object is of _any_
user-defined type, as opposed to the initial types.  In other words,
this predicate is equivalent to saying "Does a projection function
exist for this object?" .

      It was observed that
    either proposal could be implemented in portable Scheme as a
    library.  Rozas noted that Rees's proposal does not give access
    to the interaction environment, which is what most users want.

Clarification:
The _required_ aspects of my proposal are implementable in portable
Scheme.  The optional aspects that give access to the interaction
environment are not implementable portably (except by using LOAD, if
it is still there).

============================================================

Date: Fri, 6 Nov 92 14:59:26 -0500
From: "Aubrey Jaffer" <jaffer@martigny.ai.mit.edu>
To: rrrs-authors@ai.mit.edu
Subject: draft minutes of June 1992 meeting

   Date: Fri, 9 Oct 92 14:57:51 -0700
   From: William Clinger <will@skinner.cs.uoregon.edu>

	      Draft Minutes of the RnRS Authors meeting
			   25 June 1992
			    Xerox PARC
	       recorded and edited by William Clinger

   ...
   Macros:  Chris Hanson moved that the high level macro system be
   moved from the appendix into the report proper.  Rozas seconded.
   After discussion, including discussion of Dybvig's week-old
   low-level macro proposal, 21 voted in favor of Hanson's motion
   and none voted against.  Jim Miller then recommended that the
   naming conventions suggest that a special character end the names
   of macros.  This recommendation was opposed.  Miller then asked
   to change his vote on Hanson's motion.  The final vote is therefore
   20 in favor, 1 opposed.

Since macros will be included in the Report, some things need to be
clarified:

In the first column of the Macro Appendix is the claim "With this
extension, there are no reserved identifiers."  This seems ridiculous!
What about LET-SYNTAX, LETREC-SYNTAX, SYNTAX-RULES, DEFINE-SYNTAX, and
BEGIN?

Although the Appendix says that "DEFINE-SYNTAX, ... are analogous to
DEFINE ...", I don't see how DEFINE-SYNTAX can reasonably interract
with a dynamic top level define.  For instance:

  (define (foo x) (+ 1 x))
  (define (bar x) (foo (foo x)))
  (define-syntax foo
    (syntax-rules () ((foo var) ''var)))
  (bar 3)

What should (BAR 3) return?  If macros share the top level environment
with variables then the definition of function FOO will be lost and
bar will get an error or return expanded code.  If they don't share
environments, which definition of FOO should be used?  If the macro
FOO is used then BAR, which was already compiled, would have to be
recompiled (and interpreted behaviour would differ from compiled!); If
the function FOO is used then DEFINE takes precedence over
DEFINE-SYNTAX, a condition I think most people will find
counter-intuitive; also, since there is no UNDEFINE syntax, once a
symbol is set it can never be used as a top level macro.  The only
other option is for DEFINE-SYNTAX of an already defined symbol to be
an error.

This problem would also be eliminated by making mandatory Jim Miller's
suggestion that a special character end the names of macros.  In this
case, macros would be syntactically distinguished and there would be
no conflicts in the name space.