Minutes from lunch 5 August 1986

[willc%tekchips.tek.csnet@CSNET-RELAY.ARPA]

Minutes from lunch on Tuesday, 5 August 1986

Attendance was not taken.

Jonathan Rees was congratulated on getting a draft of the R^3RS done in
time for the conference.

After lunch we drew up a list of language areas that need work.  In a few
of these areas we have proposals on the table, while a few others are
difficult research areas:

ERRORS & INTERRUPTS.  What are the errors?  How are they signalled?
How are the handlers found, what do they do, how are they defined?
What about I/O devices?

OPAQUE TYPES.  Three new procedures have been proposed for creating
and manipulating objects that answer false to all the standard type
predicates and cannot be taken apart by any of the standard deconstructors.
One procedure -- call it INJECT -- takes two objects and returns a new
opaque object consisting of the first object tagged by the second.
The second procedure -- call it IN? -- takes two objects and returns
true if the first object was created by calling INJECT with the second
object as the tag, and returns false otherwise.  The third procedure --
call it PROJECT -- takes an opaque object and a tag object and returns
the object encapsulated by the opaque object provided the tags match.
Axiomatically:

    (IN? (INJECT x y) y)      ==> #t
    (IN? (INJECT x y) z)      ==> #f    provided (NOT (EQV? y z))
    (PROJECT (INJECT x y) y)  ==> x

MACROS.  Difficult research area.  We're awaiting Eugene Kohlbecker's
thesis.

DYNAMIC-WIND.  DYNAMIC-WIND seems like a good generalization of
UNWIND-PROTECT, but what about multiprocessing?  Should an UNWIND/WIND
occur on every process switch?  What about I/O?  The formal semantics
of DYNAMIC-WIND is very operational, which I take to be a danger signal.

INPUT/OUTPUT.  What should happen to the current ports on a process
switch?  What should happen if the debugger gains control?  What should
happen if a transcript is desired?

SYNCHRONIZATION.  Ought to have some means of synchronization before we
have multiple processes.

MODULE SYSTEM.  First class environments do most things right, but they
render inter-module constant folding (e.g. procedure integration)
impractical.  I think we're finally agreed that the issue of first class
environments can usefully be separated from the question of incremental
definitions as used in S&ICP, and I don't think anyone is enthusiastic
about Common Lisp style packages as a mechanism for modularity.

SEMANTICS OF QUASIQUOTE, QUOTE.  In question are things like (EQ? '(A) '(A))
and (SET-CAR! `(A B ,C) 3) and (SET-CAR! `(A B ,@C) 3).  Does it matter to
the last two examples whether the compiler can determine that C is a
constant?

DECLARATIONS.  It is important to be able to say things like "CAR is a
constant", "N is an exact nonnegative integer less than 2^20", "This
procedure should be optimized for speed at the expense of space but
not safety".  Which declarations signal an error if violated, and which
are merely hints for better performance?  What is the syntax and scope
of a declaration?

SYNTAX CHECKER & CANONIZER.  How about a program that converts programs
written in full Scheme into a canonical form that uses only the primitive
expressions, checking syntax as it does so?  Tektronix has volunteered to
supply such a program.

VERIFICATION SUITE.  How about a verification suite to locate bugs?
Someone volunteered to coordinate this, but I'm not sure I remember
who it was, so please re-volunteer.

BENCHMARK SUITE.  This wasn't discussed at lunch, but I talked to
several people who would like to have a benchmark suite that generates
more meaningful and more easily interpreted numbers than do the Gabriel
benchmarks.  For example, the Gabriel benchmarks test property lists
and fluid variables but don't do anything with lexical closures.

MULTIPLE RETURN VALUES.  Two new procedures have been proposed for
multiple return values.  One procedure -- call it RETURN -- takes
arbitrarily many values and returns them.  The other procedure --
call it RECEIVE-VALUES -- takes a thunk and a procedure, and calls
the procedure on the (possibly multiple) values returned by the
thunk.  The semantics that appears in R^3RS was designed to work
with multiple return values, but we might want to change the help
function "single" so that extra return values (e.g. in the test
position of a conditional) are ignored as in Common Lisp.  (With
the current version of "single", extra return values would be an
error.)  Since RETURN doesn't do anything remotely like what RETURN
does in Common Lisp (and is identical to CL's VALUES function),
we might want to discuss the name.  We might also want to discuss
the argument order for RECEIVE-VALUES.

OPTIONALS.  Should there be a special syntax for optional arguments
so we don't have to use a rest argument and destructure it ourselves?
What should the syntax be?