"Its the little things that count. Hundreds of 'em." -- Cliff Shaw

[Jim Miller <jmiller%cs.brandeis.edu@RELAY.CS.NET>]

Despite my vow never (well, hardly ever) to send mail these lists,
I'll take a whack at Ken's portability proposal.  My concerns:

(a) The IEEE draft standard should NOT include things that belong in
the yellow pages. We need to get that set of public, portable programs
started.  That's Ken's much-needed large library.  Come on gang, it's
been over two years since Bill Rozas was appointed librarian, and I
haven't heard of a single contribution. GET WITH IT.

(b) Neither document should attempt to constrain or describe the
interactive environment.  The standard should be for a programming
language, not its environment.

(c) The IEEE standard should not include special forms that are
trivially implemented on top of an extend-syntax type of macro
facility and the proposed standard language.  Macros are within sight
now (they will be in R4RS or R4+epsilonRS) and can be adopted
wholesale into the IEEE standard after they have been implemented and
studied thoroughly.

So:

(1) I believe FORMAT, RANDOM, SORT, and SORT! can and should be
implemented as yellow pages procedures.  Perhaps MIT will contribute
the latter three (I think their versions are portable).

(2) I endorse the proposal (Bill Rozas?) of standardizing port
constructors, but in R5RS, not IEEE.  In the interim, let's have a YP
format for use in IEEE Scheme that generates strings.

(3) I agree with Bill that user's shouldn't be aided in using (RESET)
from within a program; it is part of the user interface for dealing
with the system.

(4) I also agree with Bill that errors should be able to be
intercepted at runtime.  This is the whole area of exception handling,
and I don't believe that we're likely to get much agreement in this
area quickly.  There are, however, cogent arguments that the
environment in which the error occurs must be available for error
handling, and this dictates special forms rather than procedures
(unless someone seriously proposes putting in first-class
environments).  Thus, I believe that ERROR and FATAL-ERROR should be
reserved words, with the understanding that implementations will often
provide either a special form or a procedure of the "signature"
suggested by Ken.  >> I SUGGEST THAT BOTH IEEE AND R5RS RESERVE THESE
NAMES. <<

(5) The following are all environment issues and shouldn't be
addressed in the standard: INSPECT, TRACE, UNTRACE, SUSPEND, AUTOLOAD.

(6) I don't like ALIAS, but I'll just claim that it ought to be a
macro built with the soon-to-be syntactic closure mechanism.

(7) COMMENT is a fine idea, but it's a trivial macro.  So are UNLESS,
WHEN, and COMMENT-WHEN.

(8) I hate to say it, but don't forget about time zones and the
international date line.  If you want to do date and times at all,
let's add the "right" primitive and have YP to do the rest.

(9) I don't even want to think about what I'd like RUNTIME to mean in
MultiScheme.  If you propose a microsecond real clock for the base of
the date and time stuff, would that suffice?

(10) I'm not ready to byte off (sorry) your binary stuff.  I don't see
any reason to recommend byte vectors to all implementations, and I
certainly don't believe in conversion between strings and byte
vectors.

(11) I think you've already seen arguments about BOUND? and the
DEFINE-IF- stuff that are powerful enough to suggest we aren't ready
for standards here.

(12) Structures are great.  But (a) can we do them with macros, and
(b) can we come up with a more complete specification?  I think the
R5RS should deal with this one.

--Jim Miller