From nobody Wed Oct 21 13:48:00 1998 Path: rice!mufasa.harvard.edu!rutgers!news.sgi.com!nntp.primenet.com!newsfeed.cwix.com!209.95.128.196!news-nyc.telia.net!masternews.telia.net!news-feed.inet.tele.dk!bofh.vszbr.cz!newsfeed.online.no!news.ccs.neu.edu!not-for-mail From: William D Clinger Newsgroups: comp.lang.scheme Subject: my notes from the Scheme workshop at ICFP98 Date: Mon, 19 Oct 1998 11:40:47 -0400 Organization: Northeastern University Lines: 400 Message-ID: <362B5D7A.22872047@ccs.neu.edu> References: Reply-To: will@ccs.neu.edu NNTP-Posting-Host: bonneville.ccs.neu.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.04 (Macintosh; I; PPC) To: mkgardne@cs.uiuc.edu CC: will@ccs.neu.edu Xref: rice comp.lang.scheme:24631 Will Clinger's revised notes (as of 19 Oct 1998) on the Scheme Workshop before ICFP '98 in Baltimore, 26 September 1998, from one to six o'clock. (Will's original notes included an incorrect description of WITH-HANDLER. These revised notes incorporate Matthew Flatt's code for WITH-HANDLER, and reflect Shriram Krishnamurthi's confirmation that he volunteered to provide the web site for RFIs. Will would like to emphasize that this was not a meeting of the R*RS authors, and that his opinions as expressed in these notes may not be shared by any of the other R*RS authors.) Richard Kelsey presided, counted votes, but did not vote himself. There were 25 attendees (including Kelsey) at the start of the workshop, growing to at least 32 as the workshop continued. The written proposals that were available before the workshop are still available at http://www.neci.nj.nec.com/homepages/kelsey/workshop.html. Kelsey presented a list of the proposals that had been received, and added a couple of new topics that were proposed for discussion even though no formal proposals were in hand. For each proposal and topic, he counted the number of attendees who wanted to cover that proposal or topic at the workshop. The most popular topics were then covered in decreasing order of popularity, except for a few reorderings to consider related topics together or to delay a topic that was expected to require an unusually long discussion. The more complex topics were discussed toward the end of the workshop. [Except as noted within square brackets, the proposals that gained the approval of a majority of those in attendance at the workshop are extensions that do not conflict with the Scheme standards.] RECORDS. 21 people wanted to discuss records. Kelsey reported that Kent Dybvig and Bill Rozas had been developing a record proposal and were almost finished. Their proposal was expected to be agreeable to all. Kent summarized this proposal after the workshop ended at six o'clock. DELIMITED CHARACTER SYNTAX. 20 people wanted to discuss an oral proposal by Kent Dybvig that a delimiter be required following the character syntax. For example, (#\123) would be an error instead of being equivalent to (#\1 23) as now. This change would make it possible to add some extensions to the character syntax, for example to support Unicode. Dybvig reported that Chez Scheme already requires a delimiter following the character syntax, and would like to see that behavior sanctioned by the Scheme standards. Will Clinger requested that those present be polled to provide some record of their opinions for posterity. Kelsey proposed that the poll be worded as something like "How many people would like to recommend this to the R*RS authors?" and "How many people would prefer not to recommend this to the authors?". As the moderator, Kelsey did not vote on this or any other proposal. This straw poll indicated that 24 people wanted to recommend that a delimiter be required following the character syntax, and none were opposed to this recommendation. [This requires minor changes to both the IEEE standard and the R5RS.] LET-SYNTAX AND LETREC-SYNTAX SHOULD NOT CREATE A NEW SCOPE. 15 people wanted to discuss an oral proposal by Kent Dybvig that LET-SYNTAX and LETREC-SYNTAX should not introduce a new scope. This would allow a LET-SYNTAX or LETREC-SYNTAX form to expand into one or more definitions that are visible in the scope in which they appear. This is impossible with the R5RS semantics, which effectively requires LET-SYNTAX and LETREC-SYNTAX to expand into an expression of the form (LET () ___). The straw poll for this issue was 17-3. [This requires minor changes to the R5RS.] REPOSITORY FOR PROPOSALS. 17 people wanted to discuss Alan Bawden's proposal for library support primitives, which had more to do with process than with technical changes to the language. Discussion led to a proposal to create a World-Wide Web repository for proposals in the form of requests for implementations (RFIs). Creating such a repository does not require any changes to the R*RS or IEEE standard, so the straw poll was amended to ask how many people thought this should be done. The straw poll was unanimously in favor. Shriram Krishnamurthi volunteered to do this. CHECKING FOR FEATURES SUPPORTED BY AN IMPLEMENTATION. 13 people wanted to discuss Marc Feeley's proposal for allowing a program to query an implementation to determine its name or version or other characteristics. This was considered early because it was relevant to Bawden's proposal. The attendees felt that it was more useful to inquire concerning the properties of an implementation than to ask for the name or version of the implementation, pointing to experience with the C preprocessor. Feeley had proposed three different times for this kind of query: A. execution time B. macro expansion time (as in C) C. read time (during lexical analysis and parsing, as in Common Lisp) A separate straw poll was taken for each of these three times, assuming a feature-oriented set of query predicates whose details would have to be worked out in a future proposal. The results of these straw polls were as follows: A. execution time: 9-7 B. macro expansion time: 25-0 C. read time: 0-25 INCLUDING SOURCE CODE. 12 people wanted to discuss Marc Feeley's proposal for an INCLUDE form that includes source code from a file. This was considered early because conditional inclusion of a file is expected to be one of the most common reasons for checking on the features that are supported by an implementation. Feeley's proposal was amended to allow (INCLUDE ) to appear anywhere an expression or definition can appear, and to wrap an implicit (BEGIN ___) around the contents of the file. The straw poll was 24-1 in favor of this proposal. Lars Hansen voted twice, feeling that it was both a good and a bad idea (bad because program-understanding tools become more sensitive to the file system). SAFER FILE I/O. 17 people wanted to discuss an off-the-cuff proposal by Will Clinger to make opening and closing of files into safer operations. As amended by the attendees, this proposal adds six new procedures: (file-exists? ) (delete-file ) (rename-file ) (with-input-from-port ) (with-output-to-port ) (call-with-file-error-handler ...) Several implementations already provide the first three, and the desirability of WITH-INPUT-FROM-PORT and WITH-OUTPUT-TO-PORT has been noted by many people. The second argument to CALL-WITH-FILE-ERROR-HANDLER is required to be one of the following procedures: open-input-file open-output-file delete-file rename-file This procedure is called on ... . If a file i/o error occurs, then the error is signalled by calling with no arguments and the same implicit continuation that was passed to CALL-WITH-FILE-ERROR-HANDLER. The straw poll was 20-4 in favor of this proposal. Kelsey asked how many people wanted to discuss exceptions. Since several people had arrived since the original vote was taken on which topics should be discussed, and exceptions were perceived to have the potential to consume the rest of the workshop, new votes were taken to gauge the interest in several other topics that had not yet been discussed. IEEE FLOATING POINT. 24 people wanted to discuss Brad Lucier's proposal for bringing Scheme's inexact arithmetic into line with the IEEE floating point standards and with other recommended practice for transcendental functions and complex arithmetic. Most of Lucier's proposals would apply only to implementations that use IEEE floating point for inexact arithmetic and would thus act as recommendations, much like the appendices on inexact arithmetic that were published with the IEEE standard for Scheme. A few of Lucier's proposals would require changes to the Scheme standards themselves, however. Discussion of Lucier's proposal required detailed knowledge of IEEE floating point arithmetic, which most attendees did not have. The straw poll was 31-0 in favor of bringing Scheme into line with IEEE floating point and with current practice, trusting experts to work out the details. [This requires changes to both the IEEE standard and the R5RS: The behavior of EQV? on inexact numbers would change. If x and y are inexact reals represented as IEEE floating point numbers, then (EQV? x y) would be true if and only if x and y are equal _and_ have the same base, sign, number of bits in the exponent, number of bits in the significand, and the same biased exponents and significands. For example, (EQV? +0. -0.) would be false, as would (EQV? 1e8 1d8) in an implementation for which 1d8 has more precision than 1e8. In most implementations (EQV? x y) would be computed by a bit-level comparison of the floating point representations for x and y. (REAL? 4.3+0.i) and (REAL? 4.3-0.i) would be false, although (REAL? 4.3+0i) and (REAL? 4.3-0i) would remain true (assuming an implementation allows the real and imaginary parts of a complex number to have a different exactness, which is not required by the Scheme standards and would not be required by Lucier's proposal). TRUNCATE, ROUND, CEILING, and FLOOR would be defined only on rationals, not on all reals. The motivation for this is that infinities and NaNs would be reals but not rationals, and there is no meaningful integer value that these procedures could return for infinities and NaNs. Similarly the first argument to RATIONALIZE would be required to be a rational. The branch cuts for certain transcendental functions would change to conform to current practice. Kahan reportedly would like for (MAX 1 +nan. 2) to return 2 instead of +nan., but this would conflict with the guiding principle of Scheme's inexact arithmetic so I oppose this. Returning an inexact 2. would be consistent with Scheme's arithmetic, and would not require any changes to the Scheme standards. The changes to EQV? and REAL? would probably be the most visible in programs. Generally speaking, the people who want these changes are also the only ones who are likely to notice them.] EXCEPTIONS. 18 people wanted to discuss exceptions. Starting with the Friedman/Haynes/Dybvig proposal, the attendees designed the core of an exception system with three procedures and one special syntactic form: (current-exception-handler) (call-with-handler ) (raise ) (with-handlers (( ) ...) ) These operations must be augmented by an abstract data type of exceptions, including operations that: create an exception return an error message that is appropriate for an exception extract other information that a programmer might want to package with an exception tell whether an exception is continuable tell whether an exception is an i/o exception ... Finally, an implementation would arrange for errors to be signalled by calling the current exception handler with an appropriate exception. (CURRENT-EXCEPTION-HANDLER) returns the dynamically current exception handler. Implementations would provide a default handler, much like (CURRENT-INPUT-PORT) is the default input port. (CALL-WITH-HANDLER ) uses DYNAMIC-WIND or an equivalent technique to make the dynamically current exception handler, and calls . The dynamic scope of the ends when returns. (RAISE ) calls the current exception handler with one argument, the . RAISE could be defined by (define (raise exception) ((current-exception-handler) exception)) but post-workshop deliberation has suggested that RAISE should be used only for non-continuable errors, in which case it would be defined by something like (define raise (letrec ((raise (lambda (exception) ((current-exception-handler) exception) (raise )))) raise)) where is an exception whose error message would be something like "Contining a non-continuable exception is not allowed.". Programmers who want to raise a continuable exception could call (CURRENT-EXCEPTION-HANDLER) directly. (WITH-HANDLERS (( ) ...) ) is syntactic sugar for something like Matthew Flatt's untested (define-syntax with-handlers (syntax-rules () ((_ ((predicate handler-procedure) ...) b1 b2 ...) ((call-with-current-continuation (lambda (k) (let ((rh (current-exception-handler)) (preds (list predicate ...)) (handlers (list handler-procedure ...))) (call-with-handler (lambda (exn) (call-with-handler rh (lambda () (let f ((preds preds) (handlers handlers)) (if (not (null? preds)) (if ((car preds) exn) (k (lambda () ((car handlers) exn))) (f (cdr preds) (cdr handlers))) (rh exn)))))) (lambda () (call-with-values (lambda () b1 b2 ...) (lambda args (k (lambda () (apply values args)))))))))))))) The idea here is that is evaluated within the dynamic scope of an exception handler that takes an exception and tests it using the predicates to select the specific handler that should handle the exception. If no predicate returns true, then the handler that was current when the WITH-HANDLERS form was entered is used. The selected handler is called after the handler that was current when the WITH-HANDLERS form was entered has been reestablished as the current handler. This helps to avoid infinite loops when a buggy exception handler generates an exception itself. Most programmers are expected to use WITH-HANDLERS and RAISE as a mechanism for exiting from a computation that encounters an error, while the lower-level CALL-WITH-HANDLER and CURRENT-EXCEPTION-HANDLER mechanisms allow for very fast continuable exceptions that do not necessarily correspond to errors. Kent Dybvig and Matthew Flatt were appointed to finish this proposal. Marc Feeley and Will Clinger volunteered to review it. The straw poll on this exception proposal was 31-1. Alan Bawden voted negatively out of concern for problems that are not solved by this proposal. The exception data type represents a kind of language that programs use to communicate between the code that encounters an unusual situation and the handler that deals with the situation. The design of this language is the hard part. We are hoping to finesse that by using a very simple abstract data type of exceptions for now, leaving extensions of that data type to the future. UNICODE. 12 people wanted to discuss Marc Feeley's proposal for supporting Unicode in Scheme. This proposal contained many parts, several of which appeared to be separable. Some of the syntactic details are fairly arbitrary and are justified by appeals to compatibility with other languages; these details deserve more thought. The attendees seemed to feel that some such proposal is needed but that the details of Feeley's proposal were a little too unsettled. The straw poll was 27-2 in favor of developing and adopting some similar proposal, but was not a vote on the details of this specific proposal. The negative votes apparently reflected a feeling that it was not a good idea to vote on the general idea of a proposal instead of its specific details. [If Feeley's proposal is interpreted as a proposal for how an implementation of Scheme should support Unicode, then the only incompatibilities between Feeley's proposal and the existing Scheme standards appear to be conflicts that could be resolved by requiring a delimiter to follow the character notation, as was discussed toward the beginning of the workshop. If Feeley's proposal is interpreted as a proposal for requiring all implementations of Scheme to support Unicode, however, then there are a great many incompatibilities between Feeley's proposal and the current Scheme standards. It is not clear which of these interpretations was intended. Feeley phrased his proposal in terms of a language called "System Scheme", whose precise relationship to the Scheme standards is unclear.] The workshop ended at about six o'clock.