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

First BASH Meeting



			First BASH Meeting

Bay Area Scheme Hackers (BASH) is dedicated to fostering informal
communication among those interested in the programming language Scheme in
the San Francisco Bay Area.  Details to follow after we get organized.

Minutes:

The first meeting was held at Stanford on 1 August 1989 with Daniel Weise
graciously providing a place to meet and lunch.  Those in attendance were:

	Daniel Weise		daniel@mojave.stanford.edu
	Michael Shaff		shaff@sesame.stanford.edu
	Guillermo Rozas		jinx@zurich.ai.mit.edu
	Morry Katz		katz@polya.stanford.edu
	James O'Toole		james@zermatt.lcs.mit.edu
	Pierre Jouvelot		jouvelot@brokaw.lcs.mit.edu
	James Rauen		rauen.pa@xerox.com
	Pavel Curtis		pavel.pa@xerox.com
	Michael Plass		plass.pa@xerox.com
	Erik Ruf		ruf@dolores.stanford.edu
	Jonathan Rees		jar@zurich.ai.mit.edu
	Joel Bartlett		bartlett@decwrl.dec.com

Following the drafting of a scribe, the first order of business was a
discussion of rrrs-authors issues.

MAX/MIN/SUP/INF

Resolved:  these words may not be used in any conversation during the
meeting.

Uniform definition syntax

Pavel spoke in favor of his earlier proposal to rrrs-authors on 22 jun 89:

      I'd like to request that the syntax and semantics of bodies and programs
      be identical, but not quite like either one in R3RS.  Let the syntax be

	<program> ::= { <expression> | <definition> | (begin <program>) }*
	<definition> ::= (define <variable> <expression>)
	    | (define (<variable> <def formals>) <body>)
	<body> ::= <program>

      so definitions and expressions can be freely mixed, both at ``top level''
      and internally.  Also, BEGINs at top level need not consist entirely of
      definitions or entirely of expressions, as in R3.95RS.  The semantics is
      as follows:

     -- (begin <program>)  is entirely equivalent to  <program> .
     -- programs comprising only expressions and definitions have the same
        meaning as given in the formal semantics in R3.95RS; that is, bindings
        are established for all defined variables giving them unspecified
	values after which the program is evaluated in sequence, treating
	definitions as if they were assignments.

Jinx spoke in favor of the status quo, i.e. the incremental nature of top
level expression evaluation as noted in section 5.1 of R3RS.

Resolved:  no resolution.

Fluid Binding

Pavel discussed his proposal for a fluid binding construct that has been
discussed on rrrs-authors.  Objections were made to using the words
"fluid" or "bindings" in the name as they might conflict with existing
fluid constructs.  The word "dynamic" was suggested as an alternative.

Resolved:  Accept Pavel's constructs with the name changed to dynamic
variables.  He will edit his proposal and resubmit to rrrs-authors.

Regularization

Morry was assigned at Snowbird to look into "regularization" of Scheme.
He made a proposal to rrrs-authors on 14 Oct 88.

Resolved:  Accept his "non-controversial" recommendations.

Resolved:  Accept LIST? as a new predicate.  LIST? must always run to
completion, i.e. (LIST? x) => #f, where x is a circular list.  Report
should note that lists are a convention, not a primitive data type.  It
should also note that the property LIST? of an object may change due to
the effects of SET-CDR!.

Resolved:  Without making a value judgement, it is the sense of the
meeting that this is not the time to add additional member functions.

Resolved:  Additional control expressions in the style of MAP and FOR-EACH
are desirable, but the group did not muster strong support for any of the
current rrrs-authors proposals.

Resolved:  No changes to APPLY.

Multiple Values

Resolved:  While not everyone thinks they are a good idea, there is the
feeling that they belong in the language.

Resolved:  (values 1) is equivalent to 1.

Resolved:  The proposed ARITY procedure reveals too much about the
underlying implementation and should be replaced by a predicate ACCEPTS?
that tests whether a procedure will accept a given number of values. Morry
will change his proposal and resubmit to rrrs-authors.

Modules

Joel described the module system that is in Scheme->C.  Scheme->C is
intended to allow Scheme code to coexist with code written in other
languages.  The compiler compiles a module at a time.  The source for the
module may reside in multiple files and can contain DEFINE-EXTERNAL syntax
for defining variables or procedures in other modules.  A variable X that
a module wishes to make visible at the top level has the name X.  All
other variables in the module are also visible at the top level with a
name of the form module-name_variable-name.  It is an error for two
modules to place the same variable name at the top level.

Jinx described the MIT Scheme package system.  MIT Scheme supports multiple
environments, with each package in its own environment.  The package
definition is in the form of a "wiring diagram" that unifies variables
across environments.  The mechanism also allows procedure integration
information and syntax extensions to be exported.

Pavel described the proposed module Scheme for Scheme Xerox.  It will be
based upon Cedar's module system.  Each module will have a list of imports
and exports, with an implicit import of the "scheme" interface.  Imported
names cannot be assigned.  Backdoor for debugging as modules may hide
items (see meta issues).  When completed, the definition of the module
system will be posted to rrrs-authors (for information only, not a
proposal for RnRs).

Resolved: no proposals, no resolutions.

Macros

Jonathan reported that there is an impasse between those wanting extend
syntax and those concerned about capture problems.  It is not clear how to
resolve this to produce one macro proposal.

Resolved:  The macro committee should keep trying.  R4RS should not go out
without a macro proposal.  It should not go out with two macro proposals.

Records

Much discussion about opaque vs. non-opaque types.  In order to satisfy
Jinx and other members of the non-opaque faction, a procedure that maps a
record to its record type descriptor, and some procedure that permits one
to obtain all the selectors from a record type descriptor, will be added
to the proposal.

Resolved:  Pavel will update Jonathan's earlier proposal and submit to
rrrs-authors.

Meta Issue - rrrs-authors

How are decisions made?  How does a concensus form?  Should there be
strong leadership by the editor over the net?  A general feeling of
frustration that rrrs-authors discussions don't seem to converge.
Suggestions that might make this happen were to have "someone with
sufficient moral authority" to ride herd on the net, and to require that
proposals contain more information.  The example given was Common Lisp
cleanup, where each proposal had to have the problem, the solution, the
cost to users and implementers, plus pros and cons.  The proposal is
revised and reissued as new issues come up.

Resolved:  it would be nice if rrrs-authors worked better.  It may be time
for another rrrs-authors meeting.  Perhaps at POPL in San Francisco.

Meta-issue - Timing of RnRS

Proposal:  R4RS should hold until there is a macro proposal.  While we're
waiting, no other changes should be considered.  Instead, new proposals
should be for R5RS.

Resolved:  no resolution.

Meta Issue - Opaque vs. non-opaque types

Should the user of a module or record type be allowed to look inside it if
the implementer did not export such an interface?  Lively discussion topic!

Resolved:  no resolution.

Meta Issue - What is the purpose of the Scheme Report?

	(1) To allow us to read each others code, but not constrain
	    anyone's implementation.
	(2) To encourage the construction of common implementations to
	    allow the exchange of programs.

Another lively discussion topic.

Resolved:  no resolution.

After spending most of the day on rrrs-authors issues.  The meeting turned
to short presentations about implementations.

Scheme Xerox (Pavel Curtis, Michael Plass, James Rauen)

This implementation is intended to be the upper bound of Scheme and Cedar.
Additions include dynamic variables, macros, modules, strong typing,
concurrency, signals, and monitor locks to Scheme.  Signal handling will
be done in a straight forward manner.  When a signal occurs, the procedure
that is the value of the dynamic variable *handler* is called with the
signal.  It may handle it, or pass it to the previous value of handler.
The project is in the design and specification stage.  Implementation
expected to be under way later this year.  The system will run on top of
the Portable Common Runtime (threads, garbage collection, dynamic loading,
and name management) that is being done for the port of Cedar to UNIX.
Implementation will be intercallable with Cedar.  The intent is to make it
widely available.

Scheme->C (Joel Bartlett)

Scheme->C is a Scheme system designed to generate code that can be
embedded in other systems.  The compiler compiles Scheme to C that is then
compiled by the system's C compiler to produce a runnable object. The
system is designed to be very portable with a minimal amount of machine
dependent code in the implementation.  Besides the essentials of R3RS (and
many optionals), there are also modules, macros, foreign function calls,
and and an interface to X11's xlib. The system currently runs on VAX and
DECStation 3100 systems. For more details see Scheme Digest #47, #49, and
#63.  Currently the licensing is fairly restrictive.  This should change
in the near future so that it will be more generally available to
non-commercial users.  When this happens, a note will be posted to the
Scheme Digest.

S48 (Jonathan Rees)

A side project to build a Scheme virtual machine.  It consists of a byte
code interpreter that has a C and a Scheme implementation.  The rest is
coded in Scheme.  Seen as a pedagogical tool, but also as a "competitor"
to Xscheme.

Pseudoscheme (Jonathan Rees)

A Scheme to Common Lisp translator that runs in any Common Lisp system.
While it can't completely support call-with-current-continuation and tail
call, it is quite popular.

T (Jonathan Rees)

Waiting for changes from Yale.  Would like to modify it so that it comes
up in an R4RS compatible environment.  David Kranz has done code
generators for MIPS and SPARC processor architectures.

MIT Scheme (Jinx)

MIT Scheme is done as a tool for courses and research at MIT.  While it is
available to others, MIT's needs will direct development.  In the process
of shifting from an interpreter based system to a compiler based system.
Compilers are currently available for the VAX and 68020.  Future work to
include faster numeric code. For more details see the recent posting to
the Scheme Digest.

The meeting concluded with a few comments on applications.

RPC

Michael Plass is going to be doing an RPC system for Scheme Xerox.  It
will allow heterogeneous Scheme implementations with no shared memory to
cooperate.

Library

Jonathan Rees is the new Scheme librarian.  He'd like to develop a
strategy to get more stuff into it and publicize it.  He'd like to define
standard interfaces and then solicit multiple implementations, some
portable, some not.  Some discussion about using Brian Reid's archive
server to handle requests for software.

Resolved:  All in favor of the library.

Future BASH meetings

Resolved:  We should have more.  Pavel to set up a mailing list,
bash^@xerox.com.  Joel suggested that the next meeting could be at WRL
sometime in October.  To be further discussed via mail.  Speakers,
listeners, etc. needed.