Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 5 Feb 87 10:33:30 EST Posted-From: The MITRE Corp., Bedford, MA Received: by linus.MENET (1.1/4.7) id AA00820; Thu, 5 Feb 87 07:51:00 EST Date: Thu, 5 Feb 87 07:51:00 EST From: John D. Ramsdell Posted-Date: Thu, 5 Feb 87 07:51:00 EST Message-Id: <8702051251.AA00820@linus.MENET> To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA Subject: Windows Even though I'm a Sun user, it looks to me that NeWS is a loser, and X window will be supported by many more venders. However, on reflection, I strongly agree we should spend our time on other matters rather than windows. Speaking of packages (ugh! -- too many Common Lisp connotations) what do people think of Gelernter, Jagannathan and London's paper "Environments as First Class Objects" in Jan 1987 ACM Symp. Princ. Prog. Lang? John  Received: from grape.ads.ARPA (TCP 1200400070) by MC.LCS.MIT.EDU 4 Feb 87 10:41:35 EST Received: by hobbes.ads.arpa (3.2/SMI-3.2) id AA12106; Tue, 3 Feb 87 09:16:18 PST Date: Tue, 3 Feb 87 09:16:18 PST From: andy@hobbes.ads.ARPA (Andy Cromarty) Message-Id: <8702031716.AA12106@hobbes.ads.arpa> To: rrrs-authors@mc.lcs.mit.edu Subject: Re: X windows Cc: ramsdell%faron@mitre-bedford.ARPA Reply-To: andy@ads.arpa Standardization on a window system seems premature. Use of X (or any other system) is a local phenomenon; in different locales many competing window systems are in use. If we were to support window system primitives, it seems to make more sense to support a metastandard like NeWS, which will incorporate X, Postscript, possibly Andrew, and other windowing and graphical display approaches -- although this too seems premature at the present. If we are going to support graphics and other "foreign" capabilities, I believe our time would be more fruitfully spent in defining a general mechanism for embedding foreign (non-Scheme) functions into the Scheme environment. This is far from a cleanly solved problem in current LISPs, and a good solution would subsume, and hence obviate the need for, definition of a case-by-case approach to embedding specific window, graphics, numerical, and other foreign packages into Scheme. asc  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 3 Feb 87 07:33:34 EST Posted-From: The MITRE Corp., Bedford, MA Received: by faron.MENET (4.12/4.7) id AA10580; Tue, 3 Feb 87 07:30:51 est Date: Tue, 3 Feb 87 07:30:51 est From: John D. Ramsdell Posted-Date: Tue, 3 Feb 87 07:30:51 est Message-Id: <8702031230.AA10580@faron.MENET> To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA Subject: X windows I seems that many are standardizing on X windows. Maybe we should add some X window calls as non-essential Scheme? John  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 2 Feb 87 13:34:57 EST Posted-From: The MITRE Corp., Bedford, MA Received: by faron.MENET (4.12/4.7) id AA04621; Mon, 2 Feb 87 13:30:28 est Date: Mon, 2 Feb 87 13:30:28 est From: John D. Ramsdell Posted-Date: Mon, 2 Feb 87 13:30:28 est Message-Id: <8702021830.AA04621@faron.MENET> To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA Subject: Time Scales Astromomers often measure time using the Julian Date and the Modified Julian Date. The Julian date is the number of days since the "begining of time" as estimated by some one from the god squad of the Middle Ages. The day begins at noon GMT, and today's date at 1PM EST is JD2446829.3. The Julian date is useful because there is no need to worry about things like leap years and changes in the calendar when measuring time differences. Another useful unit of measurement is the Modified Julian Date. It is the number of years after 0, January 1, noon GMT. The number looks like the year we are used to. Today's date is J1987.2. Useful conversions: J2000.0 = 2000 January 1, noon GMT = JD2451545.0. J2000.0 is the origin of many formulas that give the position of the sun and the moon, and these formulas often measure time in units of days. Hence, my suggestion for (days-after-J2000.0). John  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 18 Jan 87 23:26:54 EST Organization: The MITRE Corp., Bedford, MA Received: by faron.MENET (4.12/4.7) id AA10400; Sun, 18 Jan 87 23:25:14 est Date: Sun, 18 Jan 87 23:25:14 est From: John D. Ramsdell Posted-Date: Sun, 18 Jan 87 23:25:14 est Message-Id: <8701190425.AA10400@faron.MENET> To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA Subject: Scheme time I noticed there is no standard time function for scheme. Let me propose the following: (days-after-J2000.0) => current time in units of days as a floating point number. The time origin is noon, January 1, 2000. This date is called J2000.0 by astronomers, and represents a good time origin for those who are interested in computing the position of the sun and other stars. For example, a formula that gives the approximate location of the sun in these units is in "The Astronomical Almanac for the Year 1984", US Naval Observatory and Royal Greenwich Observatory, US Government Printing Office, Washington DC, 1984. John  Received: from ZERMATT.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 16 JAN 87 19:45:15 EST Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 24803; Fri 16-Jan-87 19:45:02 EST Date: Fri, 16 Jan 87 19:45 EST From: Jonathan A Rees Subject: multiple values To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <870116194506.1.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU> Maybe some of you missed or have forgotten the relevant discussion last October and November, so here's a digest. If you remember this stuff, you needn't examine this message any further, and I apologize for cluttering your mailboxes. The mechanism in T3 is essentially the same as that presented in my message of Thu, 30 Oct 86 22:08:03 EST. That message also includes some motivation, which I won't repeat here, and Dan has already sent out the technical content. The rather important detail ommitted from the T3 release notes is that it's an error whenever the number of values expected doesn't match the number delivered, and argument and predicate positions expect exactly one value. Thus (list (return 1 2)) is an error in T3 and in my proposal. The mechanism that Dan Friedman proposes was suggested on this list by Andy Freeman: Date: Thu 30 Oct 86 12:25:22-PST From: Andy Freeman This proposal is a variant on the technique Carolyn Talcott used in her thesis; Richard Weyrauch was also involved in that work. Their idea requires one procedure; I'll call it values. Procedure invocation spreads multiple values; (cons (values 1 2)) is completely equivalent to (cons 1 2) and (list (values) 4 (values 1 2) 3) is equivalent to (list 4 1 2 3). ... It was dismissed by the only people on the list (besides maybe Sussman) who had actual experience using it, namely Steele and Gabriel: Date: Mon, 3 Nov 86 11:24 EST From: Guy Steele It [MARVEL] did pretty much all the obvious things: every function call was implicitly like the Common Lisp MULTIPLE-VALUE-CALL, and most side-effecting forms such as SETQ, PRINT, and COMMENT were made to return zero values. I believe I also arranged for variables to be able to hold multiple values. My experience with the language was that it was perfectly clean and elegant, but programs that made non-trivial use of multiple values were very hard to read, precisely because of the loss of the one-form/one-value correspondence. Having the extra power everywhere in the language was not worth the loss of clarity. I therefore abandoned the experiment without writing it up. (Maybe I should have, but there were other, more promising variations of Scheme to explore.) ... I believe that experience with the POP languages (especially POP-2) may be relevant to this discussion, but I am not an expert there. Date: 03 Nov 86 1214 PST From: Dick Gabriel ... The code, as Steele mentions, was elegant in a certain sense, but very hard to read most of the time, because you had to take into account that some other values than the primary value (the first one) would be passed to some program. The places where SEUS code was easy to read were when you were writing something that, in Common Lisp, would be (multiple-value-call #'foo (baz) (bar)) The places where it was hard to read were when you were writing something that, in Common Lisp, would be (foo (baz) (bar)) That is, there was no easy way to check that the right values from the right places got passed. I think that the latter is the more commonly used case, so SEUS was optimized the wrong way. ... When the Common Lisp multiple value scheme was being devised, I thought that we (the designers) should look at SEUS for its experience. I'm now glad we didn't do anything more that invent MULTIPLE-VALUE-CALL as a result of that experience. I tend to agree that it's a bad idea, not only from the point of view of someone using it, but also for implementation reasons: unlike the T proposal, which is trivially implementable (VALUES = LIST) in any scheme implementation, it's grossly incompatible with current implementations; and it has a performance cost that you have to always pay for, even when you're not using the feature, because all calls to unknown procedures must be prepared to splice in an arbitrary amount of crud. Jonathan  Received: from yale-eli.YALE.ARPA (TCP 20011000001) by MC.LCS.MIT.EDU 16 Jan 87 16:59:39 EST Received: by yale-eli.YALE.ARPA; Fri, 16 Jan 87 16:22:37 est Date: Fri, 16 Jan 87 16:22:37 est From: Paul Hudak Message-Id: <8701162122.AA06172@yale-eli.YALE.ARPA> Received: by yale-ring (node-add2.ring.cs.yale.edu/ADD2) via WIMP-MAIL (Version 1.2/1.4) ; Fri Jan 16 16:19:37 Subject: Re: multiple values and T To: Dan Friedman Cc: rrrs-authors@mc.lcs.mit.edu In-Reply-To: Dan Friedman , Fri, 16 Jan 87 09:56:21 est ... End of disccusion from the Relases Notes. What disturbs me is the way that it does not seem to be as general as it could be. What I would like to propose is the ability to splice in return values. Here is an example: ((lambda (a b c q x y) ...) (return 1 2 3) 4 (return 5 6)). It is possible that this capability is exactly what T Version 3.0 does. However, there were no examples of this type so I believe this has been overlooked. No, T does not do this (by design). The problem is that it's not always obvious what the bindings are. For example, replace the above two occurrences of RETURN with calls to unknown procedures: ((lambda (a b c q x y) ...) (f) 4 (g)) The problem with this is that one cannot tell, looking at this code alone, which bound variable 4 is bound to. Indeed, different invocations of this may induce different bindings, depending on the bindings of f and g! This seems to us to violate one's notion of referential transparency. Paul Hudak David Kranz Richard Kelsey -------  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 16 Jan 87 11:45:30 EST Received: from indiana by csnet-relay.csnet id ac26709; 16 Jan 87 11:32 EST Date: Fri, 16 Jan 87 09:56:21 est From: Dan Friedman To: rrrs-authors%mit-mc.CSNET@RELAY.CS.NET Subject: multiple values and T Here is the material taken from "T Version 3.0 Release Notes" concerning multiple return values. Following this material will be a short example which demonstrates how this could be made more general. Version 3.0 of T supports multiple return values. This makes procedure call and return uniform, in te sense that a procedure can be invoked with zero or more values and can return zero or more values. (return {value}*) ==> {value}* procedure return returns its arguments as the values(s) of the current expression. In order to access the value(s) of a return expression the value(s) must be bound to identifiers using either receive or receive-values. For example, ((lambda () (return 1 2 3))) ==> 1 2 3 where "==> 1 2 3" denotes evaluates to the three values 1, 2, and 3. return when invoked with no arguments returns to the calling procedure with no value. Thus (return) will return to its caller with no value. It is an error to return no value to a value requiring poisition. For example, (list 'a (return)) ==> error The idiom (return) is useful for procedures that return an undefined value and many of the system procedures whose value(s) is(are) undefined now return no value. However, the procedure undefined-value may provide a more informative error message. (receive-values receiver sender) procedure ==> value(s) of receiver receive-values returns the value of applying receiver, a procedure of n arguments, to the values returned by sender. sender is a thunk, a procedure of no arguments, which returns n values. For example, (receive-values (lambda (x y) (list x y)) (lambda () (return 1 2))) ==> (1 2) (receive ({ident}*) expression {body}*) syntax ==> value of body In a receive form the expression is evaluated in the current environment and the values returned by the expression are bound to the corresponding identifiers. body, which should be a lambda body, i.e. a sequence of one or more expressions, is evaluated in the extended environment and the value(s) of the last expression in body is returned. The expression (receive (a b c) (return 1 2 3) (list a b c)) ==> (1 2 3) is equivalent to (receive-values (lambda (a b c) (list a b c)) (lambda () (return 1 2 3))) ==> (1 2 3) Other froms have been extended in T3.0 to allow multiple return values. (catch identifier {body}*) ==> value of body syntax The identifier is bound to the continuation of the catch form, which is now an n-ary procedure. This means that catch forms can return multiple values. The continuation can be invoked only during the dynamic extent of the catch form. In T2 the continuation was a procedure of one argument. For example, (catch x (list 1 (x 2 3) 4)) ==> 2 3 (ret {value}*) ==> {value}* procedure returns zero or more values as the value of the current read-eval-print loop. Note: Multiple values are implemented efficiently. It may be more efficient to use multiple values than to pass continuations. End of disccusion from the Relases Notes. What disturbs me is the way that it does not seem to be as general as it could be. What I would like to propose is the ability to splice in return values. Here is an example: ((lambda (a b c q x y) ...) (return 1 2 3) 4 (return 5 6)). It is possible that this capability is exactly what T Version 3.0 does. However, there were no examples of this type so I believe this has been overlooked. I know that when we met in Cambridge Jonathan offered to work on multiple values. This is something for all of us to consider. Dan  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 10 Jan 87 14:12:22 EST Date: Sat, 10 Jan 87 14:15:10 EST From: Jonathan A Rees Subject: 2nd test To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <138728.870110.JAR@AI.AI.MIT.EDU> This is a second test message for today, which everyone should feel at liberty to ignore.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 10 Jan 87 14:05:52 EST Date: Sat, 10 Jan 87 14:08:39 EST From: Jonathan A Rees Subject: Test message To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <138725.870110.JAR@AI.AI.MIT.EDU> Testing, testing. Andy Freeman and anyone (hopefully not everyone) at Indiana: let me know if you get this. Everyone else: don't bother. Mail has been unusually screwed up over the past couple of months, more so than usual; I've been struggling with bugs in everyone's software, changes in host names and routing like shifting sand, and unavailability of hosts like MC and CSNET-RELAY.  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 6 Jan 87 11:21:14 EST Received: from ti-csl by csnet-relay.csnet id ab01368; 6 Jan 87 10:22 EST Received: from (home.ARPA) by tilde id AA09833; Tue, 6 Jan 87 08:46:02 cst Received: by id AA20269; Tue, 6 Jan 87 08:46:09 cst Date: Tue, 6 Jan 87 08:46:09 cst From: David Bartley Message-Id: <8701061446.AA20269@> To: RRRS-Authors@MC.LCS.MIT.EDU Subject: What is comma-dot? > From: David Bartley > > Can those of us that permit the destructive splicing operation `,.' > inside quasiquote agree on the symbol it corresponds to? That is, if > ,@X is equivalent to (unquote-splicing X), what is ,.X equivalent to? > Perhaps a future R^nRS should mention this as an extension. > From: willc@tekchips.tek.com > >Just as standardization can be a destructive force, by encouraging the use >of standardized but doubtful features, so can lack of standardization be a >creative force, by discouraging use of non-standardized doubtful features. >I consider comma-dot an excellent candidate for non-standardization. Will seems to have stated the consensus, if the other replies to my original message are representative. I will adopt JAR's suggested name, UNQUOTE-SPLICING!, but agree that this is a "doubtful" feature and that standardization isn't called for.  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 5 Jan 87 23:44:13 EST Received: from tektronix.tek.com by csnet-relay.csnet id aa06713; 5 Jan 87 18:44 EST Received: by tektronix.TEK.COM (5.31/6.18) id AA10436; Mon, 5 Jan 87 12:57:18 PST Received: by tekchips.TEK (5.31/6.16) id AA06076; Mon, 5 Jan 87 12:58:16 PST Message-Id: <8701052058.AA06076@tekchips.TEK> To: JAR@AI.AI.MIT.EDU, bartley%home%ti-csl.csnet@RELAY.CS.NET Cc: adams%tekchips.tek.com@RELAY.CS.NET, rrrs-authors@MC.LCS.MIT.EDU Subject: Re: What is comma-dot? In-Reply-To: Your message of Wed, 31 Dec 86 16:01:03 EST. <135327.861231.JAR@AI.AI.MIT.EDU> Date: 05 Jan 87 12:58:13 PST (Mon) From: willc%tekchips.tek.com@RELAY.CS.NET Just as standardization can be a destructive force, by encouraging the use of standardized but doubtful features, so can lack of standardization be a creative force, by discouraging use of non-standardized doubtful features. I consider comma-dot an excellent candidate for non-standardization. Will  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 31 Dec 86 15:59:42 EST Date: Wed, 31 Dec 86 16:01:47 EST From: Jonathan A Rees Subject: [COMSAT: Msg of Monday, 22 December 1986 16:31-EST] To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <135329.861231.JAR@AI.AI.MIT.EDU> Date: Thu, 25 Dec 86 21:08:55 EST From: Communications Satellite To: JAR at AI.AI.MIT.EDU Re: Msg of Monday, 22 December 1986 16:31-EST Message-ID: <134306.861225@AI.AI.MIT.EDU> FAILED: rrrs-authors at MC.LCS.MIT.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Date: Mon, 22 Dec 86 16:31:02 EST From: Jonathan A Rees Subject: New, improved quasiquote To: bartley%home%ti-csl.csnet@RELAY.CS.NET cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Wed 17 Dec 86 16:40:28 cst from David Bartley Message-ID: <133673.861222.JAR@AI.AI.MIT.EDU> Date: Wed, 17 Dec 86 16:40:28 cst From: David Bartley You mailed out a copy of your expand-quasiquote procedure at my request 13 months ago. Do you have an updated version you could be persuaded to make public? We never switched over to your algorithm, but the recent changes to the specification mean we have to rewrite our quasiquote handler anyway, so it would be nice to continue our grand tradition of "borrowing" from university sources! I have several versions. Here is one from which I have removed several different optimizations. I did this in an attempt to make the code as simple as possible, without sacrificing too much efficiency. Simpler versions are possible, as are more optimal ones. E.g. this one won't generate (vector ...) or (list ...), but it does do maximal sharing of constant substructure. You can do (define (system x) x) to get this to work, although in the Scheme implementation from which this was taken I actually make this return a funny expression which is an absolute reference to x, so that things like (let ((cons +)) `(,a b)) works. - Jonathan ;;; Quasiquote (define-rewriter 'quasiquote (lambda (x) (expand-quasiquote x 0))) (define (expand-quasiquote x level) (descend-quasiquote x level finalize-quasiquote)) (define (finalize-quasiquote mode arg) (cond ((eq? mode 'quote) `',arg) ((eq? mode 'unquote) arg) ((eq? mode 'unquote-splicing) (error ",@ in illegal context" arg)) (else `(,mode ,@arg)))) (define (descend-quasiquote x level return) (cond ((vector? x) (descend-quasiquote-vector x level return)) ((not (pair? x)) (return 'quote x)) ((interesting-to-quasiquote? x 'quasiquote) (descend-quasiquote-pair x (1+ level) return)) ((interesting-to-quasiquote? x 'unquote) (cond ((= level 0) (return 'unquote (cadr x))) (else (descend-quasiquote-pair x (- level 1) return)))) ((interesting-to-quasiquote? x 'unquote-splicing) (cond ((= level 0) (return 'unquote-splicing (cadr x))) (else (descend-quasiquote-pair x (- level 1) return)))) (else (descend-quasiquote-pair x level return)))) (define (descend-quasiquote-pair x level return) (descend-quasiquote (car x) level (lambda (car-mode car-arg) (descend-quasiquote (cdr x) level (lambda (cdr-mode cdr-arg) (cond ((and (eq? car-mode 'quote) (eq? cdr-mode 'quote)) (return 'quote x)) ((eq? car-mode 'unquote-splicing) ;; (,@mumble ...) (cond ((and (eq? cdr-mode 'quote) (null? cdr-arg)) (return 'unquote car-arg)) (else (return (system 'append) (list car-arg (finalize-quasiquote cdr-mode cdr-arg)))))) (else (return (system 'cons) (list (finalize-quasiquote car-mode car-arg) (finalize-quasiquote cdr-mode cdr-arg)))))))))) (define (descend-quasiquote-vector x level return) (descend-quasiquote (vector->list x) level (lambda (mode arg) (case mode ((quote) (return 'quote x)) (else (return (system 'list->vector) (list (finalize-quasiquote mode arg)))))))) (define (interesting-to-quasiquote? x marker) (and (pair? x) (eq? (car x) marker)))  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 31 Dec 86 15:59:23 EST Date: Wed, 31 Dec 86 16:01:03 EST From: Jonathan A Rees Subject: What is comma-dot? To: bartley%home%ti-csl.csnet@RELAY.CS.NET cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 16 Dec 86 13:39:29 cst from David Bartley Message-ID: <135327.861231.JAR@AI.AI.MIT.EDU> Date: Tue, 16 Dec 86 13:39:29 cst From: David Bartley To: RRRS-Authors at MC.LCS.MIT.EDU cc: Bartley%home%ti-csl.csnet at RELAY.CS.NET Re: What is comma-dot? Message-Id: <8612161939.AA01741@> Can those of us that permit the destructive splicing operation `,.' inside quasiquote agree on the symbol it corresponds to? That is, if ,@X is equivalent to (unquote-splicing X), what is ,.X equivalent to? Perhaps a future R^nRS should mention this as an extension. I think this feature is a kludge; I presume you have Common Lisp in mind. How about "UNQUOTE-SPLICING!" ? Jonathan  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 17 Dec 86 10:11:42 EST Received: from ti-csl by csnet-relay.csnet id ah05539; 17 Dec 86 9:36 EST Received: from (home.ARPA) by tilde id AA06413; Tue, 16 Dec 86 13:40:14 cst Received: by id AA01741; Tue, 16 Dec 86 13:39:29 cst Date: Tue, 16 Dec 86 13:39:29 cst From: David Bartley Message-Id: <8612161939.AA01741@> To: RRRS-Authors@MC.LCS.MIT.EDU Cc: Bartley%home%ti-csl.csnet@RELAY.CS.NET Subject: What is comma-dot? Can those of us that permit the destructive splicing operation `,.' inside quasiquote agree on the symbol it corresponds to? That is, if ,@X is equivalent to (unquote-splicing X), what is ,.X equivalent to? Perhaps a future R^nRS should mention this as an extension.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 9 Dec 86 11:11:32 EST Date: Tue, 9 Dec 86 11:10:05 EST From: Jonathan A Rees Subject: (define foo) To: andy@ADS.ARPA cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Sun 7 Dec 86 22:56:01 PST from andy at hobbes.ads.ARPA (Andy Cromarty) Message-ID: <128392.861209.JAR@AI.AI.MIT.EDU> Date: Sun, 7 Dec 86 22:56:01 PST From: andy at hobbes.ads.ARPA (Andy Cromarty) A lot of MIT code (among other software) seems to contain the cliche' (define foo) ; Create an unbound instance of FOO (let ((some-lexical-var 'x)) ; Create a closure.... (set! foo (lambda () ; Define outer FOO to reference : ; vars visible only in this lexenv. : ))) This does not seem to be permitted, even optionally, by the existing R3RS, as far as I've noticed. Did I miss something, or is it intentional that (DEFINE FOO) is not permitted, or was it an oversight? I don't recall having seen discussion of this topic. If you missed something then I did too. I have no recollection of this being discussed. In trying to write portable Scheme code (it's difficult) I find myself saying things like (define foo 'undefined) pretty often. I don't find this to be a major inconvenience, but it is an inconvenience. I don't see any serious problem with the (define foo) construct. It would presumably mean the same thing as (define foo ) where is that mysterious expression described in the discussion of LETREC in section 7.3. A correct immplementation of would of course be 'undefined (or just about anything else), the only disadvantage of which is that it allow certain error situations to go undetected. For symmetry you'd want the syntax to be allowed for both internal define's and top-level define's. For this to work you'd have to apply the (define foo) => (define foo ) rewrite before applying the define => letrec rewrite. This feature is implicitly permitted "optionally", because it is a compatible extension. Jonathan  Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 8 Dec 86 13:03:21 EST Received: by GENEVA.AI.MIT.EDU; Mon, 8 Dec 86 12:51:20 est Date: Mon, 8 Dec 86 12:51:20 est From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas) Message-Id: <8612081751.AA02460@geneva> To: CPH@AI.AI.MIT.EDU Cc: GJS@AI.AI.MIT.EDU, JAR@AI.AI.MIT.EDU, RRRS-AUTHORS@MC.LCS.MIT.EDU In-Reply-To: Chris Hanson's message of Mon, 8 Dec 86 03:47:50 EST Subject: Ambiguity in number syntax There is yet another possibility, which is the one I like best: #x1234e57 means (* #x1234 (expt #x10 #x57))  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 8 Dec 86 03:49:17 EST Date: Mon, 8 Dec 86 03:47:50 EST From: Chris Hanson Subject: Ambiguity in number syntax To: GJS@AI.AI.MIT.EDU, JAR@AI.AI.MIT.EDU cc: RRRS-AUTHORS@MC.LCS.MIT.EDU Message-ID: <127818.861208.CPH@AI.AI.MIT.EDU> I was trying to implement a parser for the full number syntax in R3RS and noticed that #x1234e57 is ambiguous. Does it mean (* #x1234 (expt 10 57)) or 19091031 Some solutions: 1. Flush scientific notation for hexadecimal numbers. Does anybody really want to write real numbers (as opposed to integers or rationals) in hexadecimal? 2. Require an explicit sign character in the exponent for such numbers. Thus we would say #x1234e+57 which is unambiguous. I favor solution (2) since it leaves the syntax as general as possible.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 NOV 86 21:43:38 EST Date: Sat, 22 Nov 86 21:43:12 EST From: Jonathan A Rees Subject: truncate To: philbin-jim@YALE.ARPA cc: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <122229.861122.JAR@AI.AI.MIT.EDU> Date: 22 Nov 86 11:23:34 EST (Sat) From: James F Philbin To: Rees at YALE.ARPA Re: truncate The definition of TRUNCATE in R3RS, p 20., seems ambiguous. TRUNCATE returns the integer of maximal absolute value not larger than the absolute value of x. In the case of -1.1, for example, both 1 and -1 are of maximal absolute value not larger than the absolute value of -1.1. I suggest adding the phrase, ... with the same sign as x. Right.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 11 NOV 86 11:53:08 EST Date: Tue, 11 Nov 86 11:55:13 EST From: Jonathan A Rees Subject: Scheme errors? To: RDZ@AI.AI.MIT.EDU cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 11 Nov 86 01:22 EST from Ramin Zabih Message-ID: <[AI.AI.MIT.EDU].117255.861111.JAR> Date: Tue, 11 Nov 86 01:22 EST From: Ramin Zabih Have I missed something in my reading of the Scheme report, or is there in fact no defined way for a program to signal an error? You didn't miss anything. However, no such mechanism is needed, because as long as you avoid defining the variable "error", it should simply work to say (error ...). The effect will be a reference to an unbound variable, and if the debugging system is halfway decent you'll be able to see the arguments. Seriously though, I think most implementations have an "error" procedure (or special form) which is compatible with S&ICP (and not with CL). But it might be nice if we in fact standardized on this. Ideally of course it would be part of a real error (condition) system, though, and it's possible that that would in turn depend on having fluid variables... I wouldn't hold my breath... Jonathan  Received: from Sushi.Stanford.EDU (TCP 4402000065) by MC.LCS.MIT.EDU 10 Nov 86 22:04:23 EST Date: Mon 10 Nov 86 19:00:15-PST From: Andy Freeman Subject: silly multiple values To: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].116160.861108.JAR> Message-ID: <12253954092.9.ANDY@Sushi.Stanford.EDU> I once saw a proposal for passing arguments with the name used by the callee. The idea was that the caller could pass them in any order and the names provide some documentation. (I think this came up in a keyword discussion on CommonLisp; KMP, do you remember more? BTW - I don't think it is a good idea.) For example: (cons car 'a cdr 'd) = (cons cdr 'd car 'a) The major problem with using this idea for returning values is figuring out the inheritance of named values. One possible definition is the following. The names of returned values have dynamic scope. The special form "receive" creates a context for receiving named values. Its first argument is a list of the names of the values to be received, its second argument produces them, and following arguments use them. The special form "establish" has one or more arguments. The first is a list of name-value pairs. The name is the name of a value to return, the value is its value. Subsequent arguments are an implicit begin whose value is the value of the establish form. Establish should only appear in tail-recursive positions. Receive and establish can be implemented by the following T syntax definitions. (define-syntax (receive names produce . body) `(apply (lambda , names ,@ body) (bind , (map (lambda (name) `(, name (undefined))) names) , produce (list ,@ names)))) (define-syntax (establish name-value-pairs . body) `(begin ,@ (map (lambda (pair) `(set! ,@ pair)) name-value-pairs) (undefined) ,@ body)) I don't think this is a good proposal but there may be a good way to use the basic idea. It does allow forms to ignore "extra" values and (this variation) can be implemented simply. -andy -------  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 10 Nov 86 16:02:09 EST Received: from tektronix by csnet-relay.csnet id al11458; 10 Nov 86 15:24 EST Received: by tektronix.TEK (5.31/6.16) id AA09527; Mon, 10 Nov 86 10:53:31 PST Received: by tekchips.TEK (5.31/6.16) id AA04254; Mon, 10 Nov 86 10:53:46 PST Message-Id: <8611101853.AA04254@tekchips.TEK> To: JAR@AI.AI.MIT.EDU Cc: rrrs-authors@MC.LCS.MIT.EDU, willc%tekchips.tek.com@RELAY.CS.NET Subject: Re: multiple values In-Reply-To: Your message of Fri, 31 Oct 86 21:41:46 EST. <[AI.AI.MIT.EDU].113058.861031.JAR> Date: 10 Nov 86 10:53:41 PST (Mon) From: willc%tekchips.tek.csnet@RELAY.CS.NET I didn't mean for my message to squelch debate. Surely someone disagrees with me. Speak up. Ok, Jonathan. I won't say much because I'm very busy right now. The message in question: As Alan has tactfully pointed out to me, none of the multiple-value features that Gary Brooks and Andy Freeman and I and others have been talking about bear much resemblance to CL multiple values, and they are really intended to solve a different problem. The terminology is a problem here; we really shouldn't be saying that these constructs do "multiple value returns" because Lisp Machine Lisp and its derivatives (CL) have been using that term for quite a while to mean something quite different. (I might have called the LM feature "extra value returns"...) We should no more think that we're "cleaning up something CL did wrong" than we should think that omitting optional or keyword arguments, or macros or packages, solves the problems that those features were introduced to address. I see more of a resemblance than Jonathan does. I happen to think that CL came close to getting multiple values right, failing only in the choice of primitives, the complexity of the specification (which, as someone has observed, was due to the fact that CL doesn't do tail recursion right), and in the over-reliance upon special forms (which is consistent with the rest of CL). The main difference between the RECEIVE/VALUES proposals I've seen and the way CL does it is that people in the Scheme community seem to assume that most continuations will require exactly one result, while in CL all continuations accept any number of results (up to 20, anyway). It seems to me, however, that if you're going to have an efficient implementation mechanism that supports continuations that accept an arbitrary number of results, then it shouldn't be too hard to make all continuations accept an arbitrary number of results. Whether we do this or not should be determined by whether we think CL got this part of it right. I like the idea of adding RECEIVE and VALUES to Scheme *without specifying what happens when some VALUES go somewhere other than to a RECEIVE*. Me too. For one thing, it makes it legal for a Scheme to implement CL-style semantics for multiple values. Peace, Will  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 NOV 86 14:21:03 EST Date: Sat, 8 Nov 86 14:23:05 EST From: Jonathan A Rees Subject: multiple To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].116160.861108.JAR> I didn't mean for my message to squelch debate. Surely someone disagrees with me. Speak up. Jonathan  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 NOV 86 20:49:51 EST Date: Fri, 7 Nov 86 20:51:52 EST From: Jonathan A Rees Subject: MIT AIM 848a To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].115926.861107.JAR> I'll mail copies to y'all (unless I don't have your address or you tell me not to or you already have one). Jonathan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 3 Nov 86 15:16:56 EST Date: 03 Nov 86 1214 PST From: Dick Gabriel Subject: gls@AQUINAS/cc To: ANDY@SUSHI.STANFORD.EDU, gjs@MC.LCS.MIT.EDU, rrrs-authors@MC.LCS.MIT.EDU Multiple Values I wrote the SEUS compiler for the HP300 (?) version of SEUS. SEUS had what-I-guess-are-now-called CARTs, which are coalescing multiple values. Whenever 2 CARTs came near each other, they joined into one larger one. This resulted in this code (defun foo (x) (values x x x)) (defun bar (x)(values x x x x)) (list (foo 1)(bar 2)(foo 3)) doing this => (1 1 1 2 2 2 2 3 3 3) The code, as Steele mentions, was elegant in a certain sense, but very hard to read most of the time, because you had to take into account that some other values than the primary value (the first one) would be passed to some program. The places where SEUS code was easy to read were when you were writing something that, in Common Lisp, would be (multiple-value-call #'foo (baz)(bar)) The places where it was hard to read were when you were writing something that, in Common Lisp, would be (foo (baz) (bar)) That is, there was no easy way to check that the right values from the right places got passed. I think that the latter is the more commonly used case, so SEUS was optimized the wrong way. It was hard to do this: (defun foo (x)(values x (+ x 1) (+ x 2))) (defun baz (x y) ...) such that calling BAZ on (FOO 1) and (FOO 2) passed 1 and 2 to BAZ. I recall that SEUS had no way to do this until I was half-way through writing the compiler. I also recall that variables could be bound to CARTs, somehow, as part of the solution to the problem - that is, you could get X to be bound to the CART, [1 2 3], and Y to [2 3 4]. When the Common Lisp multiple value scheme was being devised, I thought that we (the designers) should look at SEUS for its experience. I'm now glad we didn't do anything more that invent MULTIPLE-VALUE-CALL as a result of that experience. -rpg-  Received: from Godot.Think.COM (TCP 30001264307) by MC.LCS.MIT.EDU 3 Nov 86 11:33:56 EST Received: from polycarp by Godot.Think.COM via CHAOS; Mon, 3 Nov 86 11:22:41 est Date: Mon, 3 Nov 86 11:24 EST From: Guy Steele Subject: Marvel? To: ANDY@Sushi.Stanford.EDU, gjs@MC.LCS.MIT.EDU, rrrs-authors@mc.lcs.mit.edu Cc: rpg@SU-AI.ARPA, gls@AQUINAS In-Reply-To: <12251488191.9.ANDY@Sushi.Stanford.EDU> Message-Id: <861103112403.4.GLS@POLYCARP.THINK.COM> Date: Sat 1 Nov 86 09:14:39-PST From: Andy Freeman Apparently you wrote a language that had a multiple values scheme much like the one I attributed to Talcott and Weyrauch. Can you comment on it to rrrs-authors? (T&W like it and have stayed with it; you abandoned it. I'm sure both had their reasons.) Yes. For a while I worked on a dialect of Scheme called MARVEL (Multiple-Return-Value--Expression Lisp; if you ask "where does the `A' come from?" I say "A is for Acronym"). It did pretty much all the obvious things: every function call was implicitly like the Common Lisp MULTIPLE-VALUE-CALL, and most side-effecting forms such as SETQ, PRINT, and COMMENT were made to return zero values. I believe I also arranged for variables to be able to hold multiple values. My experience with the language was that it was perfectly clean and elegant, but programs that made non-trivial use of multiple values were very hard to read, precisely because of the loss of the one-form/one-value correspondence. Having the extra power everywhere in the language was not worth the loss of clarity. I therefore abandoned the experiment without writing it up. (Maybe I should have, but there were other, more promising variations of Scheme to explore.) I am cc'ing this message to Dick Gabriel, who worked with Weyrauch on the implementation of SEUS, a language with this geneal flavor. I recall him having reported to me the same results with their language, but he should have the chance to speak for himself. I believe that experience with the POP languages (especially POP-2) may be relevant to ths discussion, but I am not an expert there. --Guy  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 OCT 86 21:39:55 EST Date: Fri, 31 Oct 86 21:41:46 EST From: Jonathan A Rees Subject: multiple values To: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Fri 31 Oct 86 03:23:10 EST from Alan Bawden Message-ID: <[AI.AI.MIT.EDU].113058.861031.JAR> Date: Fri, 31 Oct 86 03:23:10 EST From: Alan Bawden I don't use CL multiple values in any situation where LIST will suffice. I use it just in case I want some "by-products" to be transparently discarded by all but a few callers. This is why multiple values were added to the Lisp Machine in the first place, and its still the only reason I see to use it. ... As Alan has tactfully pointed out to me, none of the multiple-value features that Gary Brooks and Andy Freeman and I and others have been talking about bear much resemblance to CL multiple values, and they are really intended to solve a different problem. The terminology is a problem here; we really shouldn't be saying that these constructs do "multiple value returns" because Lisp Machine Lisp and its derivatives (CL) have been using that term for quite a while to mean something quite different. (I might have called the LM feature "extra value returns"...) We should no more think that we're "cleaning up something CL did wrong" than we should think that omitting optional or keyword arguments, or macros or packages, solves the problems that those features were introduced to address. I agree that the RECEIVE/VALUEs feature is of marginal usefulness. I don't think this is the most important outstanding issue we have to talk about; macros, modules, opaque types, tables, and even bitwise logical operators all loom larger. Of course, the more agreement we can get on any feature at all, the better. A suggestion on how to proceed: we needn't think of every discussion as aiming towards something to be included in R^4RS. If just 2 implementations agree on a way to do something, we have still gained something. We should consider creating an auxiliary document, much more informal and open-ended than a R^nRS, describing possibilities for standard libraries and utilities, possibly with multiple different ways to do things if no agreement can be reached. Unanimity may be too stringent a requirement if this group is to make much progress.... Jonathan  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 OCT 86 22:06:22 EST Date: Thu, 30 Oct 86 22:08:03 EST From: Jonathan A Rees Subject: multiple values To: rrrs-authors@MC.LCS.MIT.EDU, klotz@OZ.AI.MIT.EDU In-reply-to: Msg of Mon 27 Oct 86 16:08:57 cst from Gary Brooks Message-ID: <[AI.AI.MIT.EDU].112644.861030.JAR> Since I'm the one who added the procedures VALUES (a.k.a. RETURN) and RECEIVE to T, it seems appropriate that I should say a word or two about what the heck I had in mind when I did so. In the T implementation, the low-level protocols for call to unknown procedure and return to unknown continuation are almost identical. The compiler does CPS conversion and doesn't see the difference much, and the data representation for implicit continuations is the same as that for procedures. The implementation symmetry suggested that maybe some surface-language symmetry was worth experimenting with. This was corroborated by the frequent need for some way to return more than one result value to the caller. I had been doing the latter with (foo arg1 arg2 ... argn (lambda (val1 val2 ... valm) body)), and this syntax seemed pretty unweildy (it doesn't indent nicely, for example); using lists and destructuring wasn't much better. So in T2, anticipating future compiler support in T3, a procedure VALUES was defined to be more or less the same as LIST (actually closer to VECTOR -- the details are irrelevant), and a macro RECEIVE was invented to get result values: (receive (val1 val2 ... valm) (foo arg1 arg2 ... argn) body) == (apply (lambda (val1 val2 ... valn) body) (foo arg1 arg2 ... argn)) The beauty of VALUES and RECEIVE is that they're totally noncommittal about implementation. The above is a correct implementation of the abstraction, but so is the T3 implementation, where (define (values . vals) (c-w-c-c (lambda (k) (apply k vals)))) and (receive (val1 val2 ... valm) (foo arg1 arg2 ... argn) body) == (receive-values (lambda () (foo arg1 arg2 ... argn)) (lambda (val1 val2 ... valm) body)) [maybe I have the argument order reversed, I alwasy forget] and RECEIVE-VALUES is a new primitive procedure. (We'd never expect a user to invoke RECEIVE-VALUES explicitly, but it has to exist so that RECEIVE can be a macro rather than a special form. It would be necessary in Scheme to exactly the same extent that MAKE-DELAY is necessary, which is somewhat.) Thus if T programs have to ported to some other Scheme dialect, or if T decides at some future point that multiple-value-returns are a horrible idea and should be retracted, all our code will still work because the abstraction is noncommittal. The nice thing is simply the notation, not the implementation. The fact that T3 implements it well encourages its use (and makes GC's less frequent, which, unfortunately, is a concern), but is incidental. A small benefit of having this facility be primitive is that you have an opportunity for some error checking not previously available, namely you can get wrong-number-of-return-value errors. This is good for the same reason that wrong-number-of-argument errors are good. But note that it is a necessary condition in order for the facility to permit varying implementations. (I don't see strong reasons for adding destructuring to LET or for any other linguistic support for the multiple return values besides VALUES and RECEIVE.) I'm still not sure how I feel about the feature. Certainly the abstraction is a good idea. As for the semantical foundations, I feel pretty strongly that call and return should be symmetrical. If you can have many arguments, you should be able to return many values. But note that (P -> Q) does not necessarily imply Q, it might imply not P. My opinion now is that it's probably better to achieve symmetry by flushing multiple-argument procedures rather than by introducing multiple-value returns, but this is incompatible with the present shape of Scheme, so I won't recommend it for this audience. Gary gives good reasons for introducing immutable data structures. Algol 68 and ML have the right idea; Lisp and Scheme got it wrong. It would certainly be worthwhile to experiment with immutable pairs, strings, and vectors. Adding immutable objects onto Scheme (especially one type without the others) might be a mistake, and it could be the case that adding immutable objects as an afterthought like this, coexisting with mutable objects, would result in a very inelegant language. (Maybe it could result in a very elegant language... anyone for ((immutably cons) x y)? I don't know.) But I think this is a question independent of the multiple-value question, and Gary's proposal is both more complicated and has more far-reaching consequences than RECEIVE and VALUES, which are trivial. I like the idea of adding RECEIVE and VALUES to Scheme *without specifying what happens when some VALUES go somewhere other than to a RECEIVE*. The mechanism can be added trivially to any Scheme, and those that want to optimize it (or which already do) may feel free. Minimalists can implement the mechanism with lists or closures, Gary can implement it with immutable vectors, Schemes which are embedded in Common Lisp or cohabit with it may use CL's multiple values, and T can do what it does. It is minimal and noncommittal, it's a pleasant notation, it captures a common pattern of usage, so why not. - Jonathan  Received: from CSNET-RELAY.ARPA (TCP 1201000005) by MC.LCS.MIT.EDU 30 Oct 86 16:38:01 EST Received: from geneva.ai.mit.edu by CSNET-RELAY.ARPA id aa01525; 30 Oct 86 10:51 EST Received: by GENEVA.AI.MIT.EDU; Thu, 30 Oct 86 10:42:41 est Date: Thu, 30 Oct 86 10:42:41 est From: "Guillermo J. Rozas" Message-Id: <8610301542.AA17018@geneva> To: harris%hplwhh@HPLABS.HP.COM Cc: brooks%home%ti-csl.csnet%csnet-relay.arpa%csnet-relay.arpa@CSNET-RELAY.ARPA, rrrs-authors%MC.LCS.MIT.EDU%csnet-relay.arpa%csnet-relay.arpa@CSNET-RELAY.ARPA In-Reply-To: Warren Harris's message of Tue, 28 Oct 86 11:33:30 PDT Subject: Multiple Values: An Opinion I'm sorry, I know I'm not supposed to be on this line, but I just had to state my opinion of multiple values. I think this is one (!) of the most poorly thought out (and most haphazardly integrated) concepts in common lisp. I'd hate to see scheme suffer from the same disease. I can understand your objections when you look at the CL book and examine the rules for when multiple values are passed back and not. On closer inspection, however, you will notice that the rule is uniform (although specified in utmost detail): When dealing with a compound expression, multiple values are passed back from the subexpression into which the evaluation of the compound expression reduces. In other words, tail-recursion is what determines when multiple values are passed back. Unfortunately CL does not require its implementations to be properly tail-recursive, so they could not explain the semantics of multiple values in terms of tail-recursion. We don't have this problem, so the behaviour can be described simply, and the huge case list can be added as examples, not as the definition of the bahaviour. Agreed that there is no semantic need for multiple values, and that the main consideration is efficiency, but there is no reason not to add them to the language with inessential status, as long as we also specify that implementations are free to make them be the obvious procedures which work on lists, or even the suggestion below (which I prefer). I don't agree with you on one count however. Most of the compiler optimizations that I see proposed very often suffer from a few bad bugs: - The idea is simple, so it is assumed that the implementation is also simple. This is obviously a fallacy. I'm specially wary of optimizations that require a great deal of analysis. I'm not saying it cannot be done, just that it is often the case that it takes a great deal more work than anticipated. - The optimizations break down across module boundaries. The main problem with static analysis is that it needs a closed world model. This is often hard to provide, and even inappropriate in an interactive development environment. - Static optimizations to improve performance badly hurt interpreters. I know the MIT crowd is in the minority here, but we believe in interpreters as our main development tool. Although we also want high performance compilers, we don't want to sacrifice any performance in the interpreter. Consider the following proposal instead, which does not require much (if any) compiler overhead: (define (receive-values fn th) ((th) fn)) (define (values . all) (lambda (receiver) (apply receiver all))) Note that a compiler which understands a little about tail arguments can optimize the above relatively easily, given that the construction and destructuring of the list is purely local and contained inside VALUES. Even further, since the whole mechanism is contained in 2 procedures, they can easily be implemented as primitives, with whatever efficiency is desired. Static compiler analysis to reduce consing can still be used, but this time it is closure analysis of the sort many Scheme compilers already do. Note that the above proposal implies that intermediate forms in AND, OR, and possibly other special forms would have to be treated specially, since there is a difference between returning a "normal" value, and explicitely returning 1 value. PS: There are two other objections to your message, both minor: - SET! is a the keyword of a special form, thus it cannot be mapped. - I (and a fair amount of other people) do not believe in cdr-coding. It is clearly expensive on stock hardware, and it is not clear to me that it is not expensive on special purpose hardware, besides adding unnecessary hair to the complete system and in particular the garbage collector, and we all know where this leads.  Received: from Sushi.Stanford.EDU (TCP 4402000065) by MC.LCS.MIT.EDU 30 Oct 86 15:27:28 EST Date: Thu 30 Oct 86 12:25:22-PST From: Andy Freeman Subject: Re: multiple values To: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: <8610292028.AA08573@tekchips.TEK> Message-ID: <12250998624.20.ANDY@Sushi.Stanford.EDU> I'd like to bring up another multiple-value proposal but first I have a question. Why is the scheme community attempting to standardize this now? Is it really that well understood? This proposal is a variant on the technique Carolyn Talcott used in her thesis; Richard Weyrauch was also involved in that work. Their idea requires one procedure; I'll call it values. Procedure invocation spreads multiple values; (cons (values 1 2)) is completely equivalent to (cons 1 2) and (list (values) 4 (values 1 2) 3) is equivalent to (list 4 1 2 3). (It should be obvious that (values 1) is completely equivalent to (values (values 1)).) In Talcott's system, the last variable in a lambda expression's formal argument list is preceded by an implicit period; I feel that the optional explicit period of r^3rs' syntax is superior. Call/cc is generalized appropriately as well. If I understand receive-values correctly, it is the same as apply. Most of the other proposals strike me an attempt to add yet another aggregate data type (in addition to lists and vectors) that predefined procedures will use to return a number of values. This is not a bad idea, different implementations can use different representations, yet the coercion rules and additional procedures (if a form returns multiple values, all but the first are discarded unless the programmer has mastered subtle rules involving tokens not unlike funcall and #') bother me. Talcott's scheme is succinct and builds on the rest of the language. (Look how much of this message was used to explain the idea.) Its only disadvantage is that you can't tell how many arguments are being passed by counting s-expressions. -andy -------  Received: from CSNET-RELAY.ARPA (TCP 1201000005) by MC.LCS.MIT.EDU 30 Oct 86 11:32:29 EST Received: from tektronix by csnet-relay.csnet id ab14659; 29 Oct 86 15:49 EST Received: by tektronix.TEK (5.31/6.16) id AA02978; Wed, 29 Oct 86 12:26:44 PST Received: by tekchips.TEK (5.31/6.16) id AA08573; Wed, 29 Oct 86 12:28:59 PST Date: Wed, 29 Oct 86 12:28:59 PST From: Norman Adams Message-Id: <8610292028.AA08573@tekchips.TEK> Subject: multiple values To: rrrs-authors@MC.LCS.MIT.EDU The language syntax and procedure library both favor calling with multiple arguments over returning multiple values (no surprise considering that we haven't have multiple return values in the language). I seems to me easier to fix the procedure library than the syntax. (Anyone want to adopt the "{...}n" notation that Steele mentions in "The Ultimate Declarative"?) Gary's survey identifies some rough edges that adding multiple values causes. I favor: a) changing call-with-current-continuation as described in 5a (call/cc creates n-ary procedures that invoke the continuation with as many arguments) b) using RECEIVE (or the equivalent), instead of the alternatives of either hacking up all the binding forms, or adding a bunch of new binding forms. c) living with it until we have more experience. I'm for no coersions, no multiple-value-call. -Norman -------  Received: from CSNET-RELAY.ARPA (TCP 1201000005) by MC.LCS.MIT.EDU 29 Oct 86 05:34:37 EST Received: from hplabs.hp.com by CSNET-RELAY.ARPA id aa01350; 28 Oct 86 14:42 EST Received: from hplms1. by hplabs.HP.COM ; Tue, 28 Oct 86 11:34:15 pst Received: from hplwhh (hplwhh) by hplms1; Tue, 28 Oct 86 11:33:33 pst Return-Path: Received: by hplwhh ; Tue, 28 Oct 86 11:33:38 pst From: Warren Harris Message-Id: <8610281933.AA05914@hplwhh> Date: Tue, 28 Oct 86 11:33:30 PDT Subject: Re: Multiple Values: An Opinion To: brooks%home%ti-csl.csnet%csnet-relay.arpa@CSNET-RELAY.ARPA, rrrs-authors%MC.LCS.MIT.EDU%csnet-relay.arpa@CSNET-RELAY.ARPA In-Reply-To: Your message of 27-Oct-86 16:09:35 X-Mailer: NMail [$Revision: 2.6 $] I'm sorry, I know I'm not supposed to be on this line, but I just had to state my opinion of multiple values. I think this is one (!) of the most poorly thought out (and most haphazardly integrated) concepts in common lisp. I'd hate to see scheme suffer from the same disease. First of all, I see no need for the construct whatsoever. Each of the functions to deal with multiple values can be replaced by existing scheme functions: (values ... ) => (list ... ) (receive-values ) => (apply ) (single ) => (car ) (multiple-value-set! ( ... ) ) => (map set! '( ... ) ) Therefore, the multiple value constructs add no new functionality to the language (shame). They are simply included to increase lisp's efficiency (a job which is best left up to the compiler). In light of todays cdr-coded lists I would think consing can be accomplished as efficiently as vector allocation for multiple-value objects. I would assume the same tricks could be employed for register or stack allocation of some lists, as they are returned to functions which immediately destructure them. All of your efficiency considerations still hold: Efficiency considerations ------------------------- A compiler/runtime strategy could be to return lists spread out on the stack or in registers. When lists are returned to a context which expects them the corresponding list object would never have to be reified. For example, in (define mvs (lambda (a b c) (list a b c))) (let* ((m (mvs 1 2 3)) (x (first m)) (y (second m)) (z (third m))) ...) a list object would not be allocated. List objects would only have to be allocated in the heap when lists are returned to a context which is not expecting a list. For example, (cons (list ... ) ...) would require a list object to be allocated. However, a smart compiler could avoid allocating a list object in many situations where lists are indirectly expected. For instance, if the equivalent of Common Lisp's (multiple-value-prog1 ... ) was implemented as: (let ((x )) ... x) a smart compiler could avoid the allocation of the list bound to x by: 1) Leaving the list returned by spread out on the stack. 2) Evaluating through . 3) returning the spread out list of . Similar optimizations could be applied to lists returned by know continuations, like cont, in: (call/cc (lambda (cont) ... (cont (list ... )) ...)) where the presence of the list in argument position would normally require a list object to be allocated. ----- Lets work at optimizing the compiler, not giving the programmer his own hooks to optimize. I think most people avoid multiple values anyway. Warren Harris HP Labs, bld 3U 1501 Page Mill Rd. Palo Alto, CA 94040 harris%hplwhh@hplabs.HP.COM P.S. How about a nice destructuring facility similar to multiple-value-bind except for lists (like zetalisp's destructuring-bind). For example, what could be implemented with multiple values as: (defun foo (x y z) (values x y z)) (multiple-value-bind (x y z) (foo 1 2 3)) or regular lists as: (defun foo (x y z) (list x y z)) (let* ((all (foo 1 2 3)) (x (first all)) (y (second all)) (z (third all))) ...) could be more concisely stated as: (destructure (x y z) (foo 1 2 3) ...) Also, arbitrary trees could be destructured: (destructure ((x . y) z) '((a b c d) e) (print y)) => (b c d) This would help the compiler in its optimization, as well as give the programmer a succinct syntax for a routine procedure. -------  Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 28 Oct 86 16:46:55 EST Date: Tue, 28 Oct 86 13:48:40 PST From: andy@hobbes.ARPA (Andy Cromarty) To: rrrs-authors@mc.lcs.mit.edu Subject: Re: Multiple values If multiple values are to be defined for Scheme, I personally would prefer that (a) They be assigned inessential status, and (b) Some comment be made in the R?RS admonishing implementors to attempt to make lists be of roughly equivalent efficiency, or suggesting some stylistic conventions for MV use. The latter suggestion is motivated by frequent observation of what seem to me to be excessive or abusive instances of MV use in practical code written in other LISPs. Returning both the number-theoretic quotient and the remainder from a division routine seems like a use of MV's about which few people would complain; but using MV's instead of creating and passing composite data structures for related values that are meant to be treated as an abstract object seems an unnecessary and obfuscatory use of MV's. Often it seems people use MV's in such cases either out of lack of aesthetic sense or because consing up a data structure is too costly. An admonition to programmers could address the former problem; and admonition to implementors, the latter. asc  Received: from geneva by MC.LCS.MIT.EDU 28 Oct 86 09:14:34 EST Received: by GENEVA.AI.MIT.EDU; Tue, 28 Oct 86 09:13:52 est Date: Tue, 28 Oct 86 09:13:52 est From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas) Message-Id: <8610281413.AA14222@geneva> To: ramsdell%faron%mitre-bedford.ARPA@mc Cc: rrrs-authors@mc.lcs.mit.edu In-Reply-To: John D. Ramsdell's message of Tue, 28 Oct 86 08:49:57 est Subject: Multiple values I agree completely! All the extra mechanism proposed seems unnecessary. A single comments though, What is the problem with having continuations expect multiple arguments when they in fact are capable of returning them? It seems to me that, it is not only the case that it would be nice if (receive-values (lambda (x y) (list x y)) (call-with-current-continuation (lambda (k) (k 1 2)))) => (1 2). worked, but instead it SHOULD work. Certainly the simplest implementation of the whole mechanism that I can think of would take care of this.  Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 28 Oct 86 08:55:41 EST Organization: The MITRE Corp., Bedford, MA Received: by faron.MENET (4.12/4.7) id AA21551; Tue, 28 Oct 86 08:49:57 est Date: Tue, 28 Oct 86 08:49:57 est From: John D. Ramsdell Posted-Date: Tue, 28 Oct 86 08:49:57 est Message-Id: <8610281349.AA21551@faron.MENET> To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA Subject: Multiple values Cc: ramsdell@mitre-bedford.ARPA I do not see any need for anything other than some thing like the T version of multiple values. That is RECEIVE-VALUES, RETURN (possibly called VALUES), and the macro RECEIVE. It would be nice if escape procedures can be applied to a variable number of arguments, so that the following would work: (receive-values (lambda (x y) (list x y)) (call-with-current-continuation (lambda (k) (k 1 2)))) => (1 2). but given how often call-with-current-continuation is used, I think we should be content to pass back list structure in those rare cases. I strongly object to Gary Brook's proposal for multiple values. The idea of adding a new data structure smacks of a case of reading the semantic specification of Scheme too literally. Using sequences as arguments to expression continuations is a trick to get around the fact that functions only take one argument in the lambda calculus. The T experience shows that trick is not needed in real implementations. The most serious objection I have to Gary Brook's proposal was the design philosophy that is implicit in the proposal. There seemed to be no attempt to explain why his proposal had any merit over the much simpler version as proposed by Will Clinger. Any proposal to solve one single language problem with a large addition of functions and macros must be accompanied by an explanation. While such proposals may be the norm in the Common Lisp community, we must all remember that the Scheme report starts its introduction with the words "Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary." John  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 Oct 86 01:03:52 EST Received: from ti-csl by csnet-relay.csnet id ah12153; 27 Oct 86 18:09 EST Received: from (home.ARPA) by tilde id AA25301; Mon, 27 Oct 86 16:13:04 cst Received: by id AA29167; Mon, 27 Oct 86 16:09:35 cst Date: Mon, 27 Oct 86 16:09:35 cst From: Gary Brooks Message-Id: <8610272209.AA29167@> To: rrrs-authors@MC.LCS.MIT.EDU Subject: Multiple Values: An Opinion Multiple Values: An Opinion ---------------------------- Values Objects -------------- My view on multiple values is based on the principle that everything in the language should be first class. For multiple values I postulate an *IMMUTABLE* values object type. Values objects are created by the values function. So, (values ... ) creates a values object with values ... . Since values objects are first class objects it would makes sense to bind a values object to a (single) variable or cons up multiple value objects in a list. Components of a values object can be explicitly extracted with the values-ref function. Like vectors, values object indexing is 0-based: So, (values-ref (values ... ... ) I) ==> Note that the function single can be simply defined as: (lambda (vals) (values-ref vals 0)) The number of values in a values object can be computed with the function values-length. Eg. (values-length (values ... )) ==> N+1 Lastly, values objects can be identified by the predicate values?. Values Objects and Identity --------------------------- Since values objects are immutable they are intentionally (operationally) identical (eqv?) if they have the same number of values and if all the values are intentionally identical. Thus, (eqv? (values ) (values )) ==> #T iff (eqv? ) ==> #T and (eqv? ) ==> #T Because of their immutability, The extensional identity (eq?-ness) of multiple values is left unspecified. The contention here is that asking the eq?-ness of values objects is uninteresting (maybe even meaningless). It would be analogous to asking whether two bignums are eq?. Returning Values Objects ------------------------ A Values object is returned (directly or indirectly through a continuation) just like any other type of object is returned. Applying Functions to Values Objects ------------------------------------ Multiple-value-call takes a function and an expression which evaluates to a values object and applies the function to the values in the values object. (multiple-value-call (lambda (x y) (+ x y)) (values 1 2)) => 3 Also, LAMBDA is augmented so that a lambda expression with a single (unparenthesized) formal parameter (eg. (lambda x x)) is applied via multiple-value-call, the formal parameter is bound to a values object of all the actual parameters (Note BVL). Thus, (multiple-value-call (lambda x x) (values 1 2)) <=> (values 1 2) (Note: In (apply (lambda x x) ...), x would get bound to a list, while in (multiple-value-call (lambda x x) ...), x would get bound to a values object. I'm not enthused about the overloading of the single unparenthesized bvl variable, but could not think of better syntax.) Summary ------- First class multiple values, values objects, are desirable for several reasons: 1) It simplifies specifying which forms pass multiple values through. Simply put, multiple values are passed through any form just like any other values. 2) It simplifies from where multiple values can be returned. They can be returned from anywhere. In contrast, in Common Lisp multiple values can only be returned from the last form in an OR expression. In this scheme multiple values can be returned from any form in an OR expression. 3) In contrast to the original, thunkified proposal, the forms that expect multiple values (multiple-value-call, single, etc.) could be redefined such that the cumbersome multiple value thunks are replaced with a simpler multiple value expression. Eg. (single (lambda () (mvs ...))) => (single (mvs ...)) 4) It simplifies the interaction with call/cc. To return multiple values from a continuation just incant (cont (values ... )). 5) It allows programmers to manipulate multiple values without having to inefficiently and unaesthetically coerce them to and from list structures. Consider: Expression oriented as opposed to thunk oriented. (set! l (set! l (cons (mvs ...) ...)) (cons (multiple-value-call list (lambda () (mvs ...)) ...))) (multiple-value-call f (car l)) (apply f (car l)) Efficiency considerations ------------------------- The immutability of values objects allows the compiler in cohoots with the runtime system much latitude in representing multiple values. A compiler/runtime strategy could be to return multiple values spread out on the stack or in registers. When multiple values are returned to a context which expects them the corresponding values object would never have to be reified. For example, in (define mvs (lambda (a b c) (values a b c))) (multiple-value-let (((x y z) (mvs 1 2 3))) ...) a values object would not be allocated. Value objects would only have to be allocated in the heap when multiple values are returned to a context which is not expecting multiple values. For example, (cons (values ... ) ...) would require a values object to be allocated. However, a smart compiler could avoid allocating a values object in many situations where multiple values are indirectly expected. For instance, if the equivalent of Common Lisp's (multiple-value-prog1 ... ) was implemented as: (let ((x )) ... (multiple-value-call values x)) a smart compiler could avoid the allocation of the multiple values bound to x by: 1) Leaving the multiple values returned by spread out on the stack. 2) Evaluating through . 3) returning the spread out values of . Similar optimizations could be applied to multiple values returned by know continuations, like cont, in: (call/cc (lambda (cont) ... (cont (values ... )) ...)) where the presence of the return in argument position would normally require a values object to be allocated. In even more esoteric situations, the compiler could represent (a single group of) multiple values in a values object as well as spread out on the stack. For example, in (let [[[x (mvs ...)]]] ; spread x out on the stack for ; fast access (multiple-value-call frob x) ; use the spread out values (foo x) ; use the values object bound to x (multiple-value-call frob x) ; use the spread out values, since ; we don't have to worry about ; foo side-effecting the values ; in x. ...) My Answers to the Survey ------------------------ 1) (a & b) (multiple-value-call ) (c) (values ... ) and make it non-essential. 4) Don't allow multiple multiple-value expressions in multiple-value-call. 5) call/cc is not a problem with first class values objects. 6) Multiple values (i.e. values objects) are passed through forms just like any other value is. 7) Just return a (first class) values object. 8, 9 & 10) Include: (multiple-value-let (((ids*) form)*) ), (multiple-value-let* (((ids*) form)*) ), (multiple-value-letrec (((ids*) form)*) ) (maybe), (multiple-value-set! (ids*)
), and (multiple-value-define (ids*) ) (maybe with mv-* nicknames) as non-essential. In any of the constructs signal an error if too many or too few values are returned. 11) a) Include (values->list ) as non-essential. b) Include (list->values ) as non-essential. c) Include (values->vector ) as non-essential. d) Include (vector->values ) as non-essential. e) other include (values-ref ) as essential (values? ) as essential  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 27 Oct 86 21:21:24 EST Received: from ti-csl by csnet-relay.csnet id ag12153; 27 Oct 86 18:08 EST Received: from (home.ARPA) by tilde id AA25293; Mon, 27 Oct 86 16:12:30 cst Received: by id AA29154; Mon, 27 Oct 86 16:08:57 cst Date: Mon, 27 Oct 86 16:08:57 cst From: Gary Brooks Message-Id: <8610272208.AA29154@> To: rrrs-authors@MC.LCS.MIT.EDU Subject: Multiple Values: A Survey Multiple Values: A Survey -------------------------- The current proposal (from Will's lunch minutes) for multiple return values consists of the two functions: (receive-values ) which applies to the multiple values returned by . And: (return ... ) or (values ... ) which returns the values ... . Also, in the semantics there is an auxiliary function single, which currently raises an error if multiple values are returned. Question (3) deals with issue of making the auxiliary function available in the language and questions (7) and (10) indirectly deal with the semantics for single. 1) Syntactic questions: 1a) What argument order do we want for receive-values? 1b) Do we want to use a different name for receive-values? Eg. Multiple-value-call, multiple-value-apply, or something else? 1c) What name do we want for the multiple value return construct? Return, values, something else? 2) Do we want receive-values and return to be essential or non-essential? 3) Do we want to incorporate the auxiliary semantic function single into the language (see also (6b)) as: (single ) such that (single (lambda () (return ... ))) => . Should it be essential or non-essential? 4) Should receive-values allow multiple multiple-value-thunks in a manner similar to Common Lisp's multiple-value-call? That is all the values from the various multiple-value-thunks would be "concatenated" before being passed to the function. 5) Interaction with call-with-current-continuation. How are multiple values returned from a continuation? Presumably, (call/cc (lambda (cont) ... (cont (return ... )))) does not work since the (return ... ) is in argument position. Furthermore, I presume that (call/cc (lambda (k) (receive-values k (lambda () (return ... ))))) won't work, since the escape procedure generated by call/cc is a "function" of one argument, which would make the above application of receive-values analogous to: (receive-values (lambda (x) ...) (lambda () (return ... ))) which (presumably) is an error. 5a) Modify continuations to take a variable number of arguments that are returned as the multiple values of the continuation. Eg. (k ... ) 5b) Add a new procedure called call-with-multiple-values-current-continuation (or call/mv/cc for short) that takes a function of one argument, a multiple value escape procedure. The escape procedure takes a thunk as an argument and transmits the values returned by the thunk. Eg. (call/mv/cc (lambda (k) (k (lambda () (return ... ))))) 5c) Somehow modify the existing version of call/cc so that when the escape procedure k is invoked, (k v) returns v and (receive-values k (lambda () (return .. ) returns ... . 5d) Somehow modify multiple values so that they can be cohesively returned in argument position. I.e. so (cont (return ... ) would work. (See Opinion message.) 5e) Something else? 6) What forms pass multiple values through? More likely than not the following (relatively) tail recursive forms pass back multiple values. 6a) Do LAMBDA, LET and LETREC pass back multiple values from their bodies? 6b) Do IF, COND and CASE pass back multiple values from the arms of the conditional? 6c) Does explicit and implicit BEGIN blocks pass back multiple values from the last form in the block? But what about other forms? 6d) Does DO pass back multiple values from the last form in the exit clauses? 6e) Do AND and OR pass back multiple values from the last form? Or in OR's case from any form? 6f) Can FORCE return multiple values? (If so how is DELAY implemented (i.e. how is make-promise written)) 6g) What other forms pass back multiple values? 6h) Are there any forms that never pass back multiple values? 7) What happens when multiple values are returned to a context which doesn't expect them as in predicate position within a conditional or argument position within an application. For example: (if (return v1 ... VN) ) or (f (return v1 ... VN) ...) 7a) Coerce the multiple values to a single value as in Common Lisp. 7b) Instantiate a (first class) multiple values object (see Opinion message) 7c) It would be an error. 7d) An error would be signaled. 7e) Other? 8) Do we want to augment existing binding forms (let, let* letrec) to destructure multiple values or introduce a multiple value version for each binding form, or not include such a capability? In each of the following examples, b1 would be bound to ... and bN to VN. Which is preferred? 8a) (let (((b1 ... bN) ;; i.e. ((ids*) ) (return ... )) ) ) or (perhaps) 8b) (multiple-value-let or (8c) (multiple-value-let (b1 ... bN) (((b1 ... bN) (return ... ) (return ... )) ) ) ) or 8d) other Should (a)-(d) (if any) be essential or non-essential? 9) Similarly, do we want to augment set! and define to accept multiple values, define new versions of these constructs or not include these constructs? (In the case of define, augmentation would be incompatible with the non essential forms of define.) Do we want to make this essential or non-essential syntax? In the case of set!, which of the following is preferred? 9a) (set! (id1 ... idN) (return ... )) And (b) or (c) for define. or 9b) (multiple-value-set! (id1 ... idN) (return ... )) (multiple-value-define (id1 ... idN) (return ... )) or 9c) (multiple-value-set! id1 ... idN (return ... )) (multiple-value-define id1 ... idN (return ... )) or 9d) other 10) For those constructs that expect multiple values (presumably, receive-values, multiple-value-let, multiple-value-let*, multiple-value-letrec, and multiple-value-set!) what happens when too few or too many values are returned. For example in: (multiple-value-let (((Id1 ... IdM) (return ... ))) ) M arguments are expected and N arguments are returned. 10a) N > M More values returned than expected. 1) Ignore extra values. 2) It is an error. 3) An error is signaled. 4) other. 10b) M > N More values expected than returned. 1) Return as many as needed additional default values. 2) It is an error. 3) An error is signaled. 4) other. 11) What (if any) other constructs do we want for returning multiple values? What should their names be? Do we want a thunk or an expression for the multiple values form (see (6c)). Should these constructs be essential or non-essential? 11a) the equivalent of (receive-values (lambda x x) ) 1) (multiple-value-list ) or 2) (values->list ) or 3) none 4) other 11b) The equivalent of (apply values ) 1) (values-list ) 2) (list->values ) 3) none 4) other 11c) The equivalent of (receive-values (lambda x (list->vector x)) ) 1) (multiple-value-vector ) or 2) (values->vector ) or 3) none 4) other 11d) The equivalent of (apply values (vector->list )) 1) (values-vector ) 2) (vector->values ) 3) none 4) other 11e) Any others?  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 27 Oct 86 21:15:18 EST Received: from ti-csl by csnet-relay.csnet id af12153; 27 Oct 86 18:08 EST Received: from (home.ARPA) by tilde id AA25245; Mon, 27 Oct 86 16:11:46 cst Received: by id AA29149; Mon, 27 Oct 86 16:08:22 cst Date: Mon, 27 Oct 86 16:08:22 cst From: Gary Brooks Message-Id: <8610272208.AA29149@> To: rrrs-authors@MC.LCS.MIT.EDU Subject: Multiple Values I'd like to see a consensus emerge on multiple values. To that end I have summarized the existing proposal and questions from Will's lunch minutes and added a number of other questions and issues. As the text of these questions and issues is somewhat long (280 lines) I have submitted it in a separate message entitled "Multiple Values: A Survey". Also, since my own responses to the survey depend on a particular view of multiple values, I have submitted yet another message explaining my views on these issues and my response to the survey. The latter message is entitled "Multiple values: An Opinion". Enjoy! -- brooks  Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 OCT 86 15:44:25 EDT Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 11868; Wed 1-Oct-86 15:44:55-EDT Date: Wed, 1 Oct 86 15:44 EDT From: Jonathan A Rees Subject: R^3RS sources To: rrrs-authors@MC.LCS.MIT.EDU cc: carr@UTAH-ORION.ARPA Message-ID: <"861001154411.1.jar@AI"@ROCKY-GRAZIANO.LCS.MIT.EDU> Those of you with Internet FTP capabilities should now be able to get the report sources from MIT-PREP. Login as user scheme password scheme, and get the file /scheme/r3rs.tar if you can use a unix tar file, otherwise get all the files in the directory "/scheme/documentation/r3rs".  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 SEP 86 15:36:31 EDT Date: Mon, 15 Sep 86 15:39:29 EDT From: Jonathan A Rees Subject: Begin in the Formal Semantics To: ramsdell%faron@MITRE-BEDFORD.ARPA cc: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].94274.860915.JAR> Date: Mon, 15 Sep 86 15:15:40 edt From: John D. Ramsdell To: rrrs-authors%mc.lcs.mit.edu at mitre-bedford.ARPA Re: Begin in the Formal Semantics Organization: The MITRE Corp., Bedford, MA Posted-Date: Mon, 15 Sep 86 15:15:40 edt Message-Id: <8609151915.AA16806@faron.MENET> Begin is described in the abstract syntax, but there is no semantic function for it. Later, on page 35, the semantics of begin is given under the derived expression types heading. Should begin be described in the abstract syntax section? It should be flushed from the abstract syntax. I intended to do this but only partially succeeded. Jonathan  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 SEP 86 15:35:43 EDT Date: Mon, 15 Sep 86 15:38:17 EDT From: Jonathan A Rees Subject: Begin in the Formal Semantics To: ramsdell%faron@MITRE-BEDFORD.ARPA cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Mon 15 Sep 86 15:15:40 edt from John D. Ramsdell Message-ID: <[AI.AI.MIT.EDU].94273.860915.JAR> Date: Mon, 15 Sep 86 15:15:40 edt From: John D. Ramsdell To: rrrs-authors%mc.lcs.mit.edu at mitre-bedford.ARPA Re: Begin in the Formal Semantics Organization: The MITRE Corp., Bedford, MA Posted-Date: Mon, 15 Sep 86 15:15:40 edt Message-Id: <8609151915.AA16806@faron.MENET> Begin is described in the abstract syntax, but there is no semantic function for it. Later, on page 35, the semantics of begin is given under the derived expression types heading. Should begin be described in the abstract syntax section? It should be flushed from the abstract syntax. I intended to do this but only partially succeeded. Jonathan  Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 15 Sep 86 15:22:59 EDT Organization: The MITRE Corp., Bedford, MA Received: by faron.MENET (4.12/4.7) id AA16806; Mon, 15 Sep 86 15:15:40 edt Date: Mon, 15 Sep 86 15:15:40 edt From: John D. Ramsdell Posted-Date: Mon, 15 Sep 86 15:15:40 edt Message-Id: <8609151915.AA16806@faron.MENET> To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA Subject: Begin in the Formal Semantics Begin is described in the abstract syntax, but there is no semantic function for it. Later, on page 35, the semantics of begin is given under the derived expression types heading. Should begin be described in the abstract syntax section? John  Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 9 Sep 86 07:28:53 EDT Organization: The MITRE Corp., Bedford, MA Received: by faron.MENET (4.12/4.7) id AA17988; Tue, 9 Sep 86 07:21:18 edt Date: Tue, 9 Sep 86 07:21:18 edt From: John D. Ramsdell Posted-Date: Tue, 9 Sep 86 07:21:18 edt Message-Id: <8609091121.AA17988@faron.MENET> To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA Subject: Slade's book in bib? Maybe Stephen Slade's book on T should be added to the r^3rs bibliography. Would some one with access to it, make a recommendation? John  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 8 Sep 86 19:14:47 EDT Received: from indiana by csnet-relay.csnet id ak01084; 8 Sep 86 16:19 EDT Date: Mon, 8 Sep 86 13:10:49 est From: Perry Wagle To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA Subject: substring-vector-null-fill!, coliti If |(set-car! '(a b) 'c)| is an error, how about |(set-car! '(d e) 'f)|? That is, when do backquoted expressions denote constants? (I vote never). [A related question is whether |`(d e)| returns the same list each time it is executed. I suspect you may want to table the above paragraph.] Vectors have constant length. Strings have variable length. With this view it would make sense to "fill" a vector, but not a string. Perry Wagle, Indiana University, Bloomington Indiana. ...!ihnp4!inuxc!iuvax!wagle (USENET) wagle@indiana (CSNET) wagle%indiana@csnet-relay (ARPA)  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 SEP 86 18:10:23 EDT Date: Mon, 8 Sep 86 18:11:24 EDT From: Jonathan A Rees Subject: Good & bad news To: rrrs-authors@MC.LCS.MIT.EDU cc: slade@YALE.ARPA, meehan@YALE.ARPA Message-ID: <[AI.AI.MIT.EDU].92170.860908.JAR> The good news is that the scheme report is in the mail, and the editor of SIGPLAN Notices will have it within a couple of days. The bad news is that the November issue of SIGPLAN, like the October issue, is devoted to conference proceedings for some conference or other. So there is no room for the Scheme report. Barring other unforeseen catastrophes, it will be in the December issue. A few people have asked me whether page numbers are known, and I expect they won't be until known until mid-December. I suggest calling Dick Wexelblat on the phone around that time if you really want to know. We plan to print this version as an MIT AI memo. I'll make the LaTeX sources available on MIT-PREP sometime this week. I'll also US mail hardcopy to the authors. If the Indiana CS department is interested in issuing it as a new tech report, I'd be happy to mail a magnetic tape with the sources & DVI file. Jonathan  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 SEP 86 09:05:17 EDT Date: 3 Sep 1986 09:02 EDT (Wed) Message-ID: From: Bill Rozas To: Jonathan A Rees Cc: rrrs-authors@MC.LCS.MIT.EDU Subject: substring-vector-null-fill!, colitis, etc. In-reply-to: Msg of 2 Sep 1986 18:19-EDT from Jonathan A Rees 1) I vote to change the grammar to only allow the final ELSE case. It does not seem like a very large change. 2) VECTOR-FILL! and STRING-FILL! are completely symmetric. They both must exist internally for the MAKE-STRING and MAKE-VECTOR procedures. FLush both or keep both, but I vote to flush both since they can be written using VECTOR-SET! and STRING-SET! 3) I think that except in a few cases, it is not necessary to agree on default exactness in the number syntax. Anybody who is going to use advantage of it (whenever somebody implements it), will certainly want to force the exactness/inexactness of his/her explicit numerals by using prefixes, and nobody else will care, probably. The only case that must be decided, in my opinion, is making things like 3, 123, -456 ("obvious" integers) exact, so they can be used as indeces to VECTOR-MUMBLE and STRING-MUMBLE. Thus some implementations could agree to be compatible with CL, and some to take a completely different approach, but the most common case (and needed by non-numeric code) would be compatible. 4) I like alphabetic colon, and dislike the CL package system too, but giving up colon seems like a very minor issue. There are too many people trying to make a dual CL/Scheme environment, and we should not make this job harder than it has to be. Thus I vote moving colon to unspecified.  Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 3 Sep 86 07:24:24 EDT Organization: The MITRE Corp., Bedford, MA Received: by faron.MENET (4.12/4.7) id AA03165; Wed, 3 Sep 86 07:17:30 edt Date: Wed, 3 Sep 86 07:17:30 edt From: John D. Ramsdell Posted-Date: Wed, 3 Sep 86 07:17:30 edt Message-Id: <8609031117.AA03165@faron.MENET> To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA Subject: call-with-xxput-port Please do not forget the change associated with call-with-input-port and call-with-output-port. I suggest changing the names of no other I/O routines. John  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 SEP 86 18:18:38 EDT Date: Tue, 2 Sep 86 18:19:59 EDT From: Jonathan A Rees Subject: substring-vector-null-fill!, colitis, etc. To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].90180.860902.JAR> Here are changes I've made at the requests of people too numerous to mention (I wish I could acknowledge everyone individually, but time presses): I've flushed SUBSTRING-FILL! and STRING-NULL?. If STRING-NULL? is retained then VECTOR-NULL? should be added. These are both in a somewhat different class than NULL? since NULL? is often used to terminate recusrions but STRING- and VECTOR-NULL? aren't. It's now clearly an error to alter an object returned as the value of a constant expression, e.g. (string-set! "foo" 1 #\x) and (set-car! '(a b) 'c) are errors. The list of extended alphabetics has been moved from "other notations" to "identifiers". I'll try to flush the garbage about immutability from the eqv? section, and leave the question of (eq? '(a) '(a)) unbreached. Small organizational error fixed: the nonterminal is gone, and (begin ) is now an alternative right-hand side for . The equation defining exponentiation has been repaired. ----- Questions: - Advice sought on what to do about the grammar for COND and CASE. In question is the treatment of non-final ELSE clauses. Two people have mentioned that as it stands the grammar is too liberal. Should I change it so that there are two rules for each, viz. --> ... | (cond +) | (cond * (else )) | ... | (case +) | (case * (else )) | ... ? Seems to me it's not grave if it's left as is, since the text explains that actually the else clause should come at the end. - I can sort of see why VECTOR-FILL! exists (it has to exist internally in any case, in order to support the optional argument), but symmetry considerations would suggest either flushing it or adding STRING-FILL!. Opinions? No change here so far. - I don't think I have time to change number syntax, although I think specifying default exactness on input is easier, since I can just copy text from Will's messages. I have two small arguments with Will's rule which says that 1e3 is exact. One is that this makes exactness somewhat tricky to determine -- you have to be able to count in order to determine whether a string represents an exact number or not. I prefer the simpler rurule which says that the presence of an exponent marker makes the number inexact by default. The second argument stems from CL compatibility concerns: if Scheme's exact integers are identical to CL's integers, and Scheme's inexact (rational) flonums are identical to CL's flonums, then making 1e3 represent an exact number would be an incompatibility between Scheme and CL. This correspondence seems natural to me. I'd like to hear arguments in favor of Will's rule. - I'm inclined to demote colon from alphabetic to unspecified (like \ and |), although I'd like the case to be made more clearly. I would really hate to see someone add Common-Lisp-like read-time packaging to any Scheme, so I don't admit that as a good reason for this change, although if foo:bar read in the same as (access bar foo) that wouldn't be so bad. However, I'm primarily a Scheme-in-Common-Lisp user myself these days, and the implementation and its integration into the host CL would indeed be cleaner if colon weren't extended alphabetic, so I DO see CL compatibility as a good reason for the change. On the side of an alphabetic colon, I should mention that the moderate-sized community of pro-Scheme people raised on Riesbeck, Charniak, and/or McDermott's book(s), or otherwise immersed in Yale AI Lisp culture, use colon pretty heavily as an alphabetic character. Also, there are some other alternatives for CL <--> Scheme communication: - A way to coerce packages to environments, so e.g. if you want Lisp's ELT function you can say (access elt lisp-package). This is what CLSCH does now. - A procedure which makes Lisp symbols, e.g. (make-lisp-symbol 'lisp 'elt). - A reader syntax such as #[Lisp-symbol lisp elt] or #>Lisp>elt. None of these is quite as attractive as just saying lisp:elt. I'll wait for more comments, then flip a coin. - Jonathan  Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 29 Aug 86 18:01:17 EDT Date: Fri, 29 Aug 86 06:41:16 pdt From: andy@ads.ARPA (Andy Cromarty) To: rrrs-authors@mit-mc.ARPA Subject: graphics for Scheme A good alternative to providing graphics capability is to solve the more general problem of designing a clean foreign function interface standard. This would permit a variety of useful existing software packages to be integrated into Scheme environments without requiring that we deflect our attention from substantive language design issues (and our plate is rather full already) to address ancillary and difficult problems such as design of packages for graphics, window systems, etc. This would also make Scheme much more attractive to people who actually want to use Scheme as a programming language rather than as an object of study. Designing a good foreign function interface is nontrivial if we wish to maintain a principled design approach. I suspect that it would require us to revisit some of the thorny problems we've brushed up against but not really solved in the past few months, such as whether Scheme should be thought of as having a dynamic binding environment vs. an essentially static one defined purely by the lexical structure of our programs. In the former case, a relatively conventional dynamic loading scheme might work best; for the latter case, a declaration-based system might be more appropriate. In either case, we would need a spec for translating Scheme data structures into those of other languages. (Perhaps the SUN xdr might be a good spec to work from for this part of the problem.) A foreign function interface might also make Scheme a better base language environment for studying some difficult contemporary programming paradigm problems, such as techniques for distributed and parallel processing. Currently we achieve this locally at ADS by extending our Scheme with functions written in C and linked in statically by the linkage editor. This has the disadvantage of requiring that the researcher know not only how to code the new parallelism/distributed processing primitives, but also what the internal structure of the Scheme environment is in some detail. A foreign function interface would provide a sort of firewall that would prevent the designer of new constructs from having to know what the Scheme implementation's internals look like. asc  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 AUG 86 14:23:45 EDT Date: Thu 28 Aug 86 14:21:58-EDT From: "Gerald Jay Sussman" Subject: Re: Minutes from lunch 5 August 1986 To: JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: Message-ID: <12234461088.59.GJS@OZ.AI.MIT.EDU> I disagree that it is good to mix graphics in with other things. I think that graphics is pretty poorly understood and rather idiosyncratic -- it will just cause lots of wasted flamage to work on that. -------  Received: from hplabs.HP.COM by MC.LCS.MIT.EDU 28 Aug 86 12:07:54 EDT Received: from hplmhw by hplabs.HP.COM ; Thu, 28 Aug 86 09:01:43 pdt Received: by hplmhw ; Thu, 28 Aug 86 09:02:41 pdt Date: Thu, 28 Aug 86 09:02:41 pdt From: Henry M. Wu Message-Id: <8608281602.AA00425@hplmhw> To: JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Cc: willc%tekchips.tek.csnet@RELAY.CS.NET, rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: Bill Rozas's message of 28 Aug 1986 11:11 EDT (Thu) Subject: Minutes/Standardize Graphics One comment I have heard from talking to people around here is that they are surprised Scheme is trying put everything into the language specs rather than define libraries (like C, I guess). I'm not claiming this is the right thing, but it does seem like something worth pondering. Henry  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 AUG 86 11:48:45 EDT Date: 28 Aug 1986 11:11 EDT (Thu) Message-ID: From: Bill Rozas To: willc%tekchips.tek.csnet@RELAY.CS.NET Cc: rrrs-authors@MC.LCS.MIT.EDU Subject: Minutes from lunch 5 August 1986 In-reply-to: Msg of 14 Aug 1986 16:00-EDT from willc%tekchips.tek.csnet at CSNET-RELAY.ARPA Wow! we have a full schedule ahead. Given the amount of flame which just agreeing on the language has generated, I can imagine what trying to agree on these issues will cause. I definitely look forward to it. Something we might also think about standarizing is graphics primitives. I realize this is hardware/system dependent, but it is probably no harder than agreeing on interrupts and similar things. It would be nice if simple graphics programs were also portable.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 25 Aug 86 21:26:35 EDT Received: from tektronix by csnet-relay.csnet id ae02269; 25 Aug 86 18:44 EDT Received: by tektronix.TEK (5.31/6.16) id AA12524; Mon, 25 Aug 86 14:26:48 PDT Received: by tekchips.TEK (5.31/6.16) id AA07580; Mon, 25 Aug 86 14:29:50 PDT Message-Id: <8608252129.AA07580@tekchips.TEK> To: rrrs-authors@MC.LCS.MIT.EDU, jar@MC.LCS.MIT.EDU Subject: Another nit; my favorite numbers In-Reply-To: Your message of Sat 23 Aug 86 20:37:17-EDT. <12233218691.23.GJS@OZ.AI.MIT.EDU> Date: 25 Aug 86 14:29:47 PDT (Mon) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA The description of map in section 6.9 says that its first argument must be a procedure of one argument. The description should say instead that "The {\it list}s must be lists, and {\it proc} must be a procedure taking as many arguments as there are {\it list}s." ---------------------------------------------------------------- Gerry asked what my favorite proposal was for the implicit exactness of numeric constants. It is: 1. Constants of the form x+yi, x-yi, and x@y are exact iff both x and y are exact as real constants. 2. Constants of the form x/y are exact iff both x and y are exact as integer constants and there is no explicit prefix that says otherwise. 3. Constants that contain sharp signs to indicate imprecise digits are inexact unless there is an explicit prefix that says otherwise. 4. Constants that contain a nonempty exponent suffix are exact iff they are exact after shifting the decimal point and/or adding zeroes to eliminate the exponent. (For example, 1.1e6 would be treated as 1100000, 40e-3 would be treated as .040, 2/3e2 would be treated as 200/3, and 2/3e-2 would be treated as 2/300.) 5. Constants that contain a decimal point but no exponent or sharp signs indicating imprecise digits are exact iff there are no digits to the right of the decimal point and there is no explicit prefix that says otherwise. 6. Constants that contain no decimal point, exponent, or sharp signs indicating imprecise digits are exact iff there is no explicit prefix that says otherwise. Whew! Rule 4 is probably the most controversial, followed by rule 5. peace, Will  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 23 AUG 86 20:38:18 EDT Date: Sat 23 Aug 86 20:37:17-EDT From: "Gerald Jay Sussman" Subject: Re: numbers To: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA cc: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: <8608210013.AA03947@tekchips.TEK> Message-ID: <12233218691.23.GJS@OZ.AI.MIT.EDU> The real numbers committee met today (all C of us, but we are not sure if C=2^Aleph0) in closed session!. We commend you, David Bartley and Norm Adams for noticing our grievous errors and we thank you for the nice suggestions. We move that suggestions 1-5 be immediately adopted. Suggestion 6, concerning the syntax of exact/inexact numerical constants is still not clear. What is your favorite proposal anyway? -------  Received: from Godot.Think.COM by MC.LCS.MIT.EDU 22 Aug 86 14:08:11 EDT Received: from SEBASTIAN.THINK.COM by Godot.Think.COM; Fri, 22 Aug 86 14:05:52 edt Date: Fri, 22 Aug 86 14:06 EDT From: Guy Steele Subject: 1986 Lisp conference bibliography To: common-lisp@SU-AI.ARPA, rrrs-authors@MC.LCS.MIT.EDU Cc: gls@AQUINAS Message-Id: <860822140628.4.GLS@SEBASTIAN.THINK.COM> With the help of Bill Scherlis, I have massaged the table of contents (with some corrections) for the 1986 ACM Conference on Lisp and Functional Programming into the form of a bibliography database suitable for use with LaTeX/BibTeX and (almost) SCRIBE. The database has been tested with BibTeX, and uses TeX conventions for forcing capitalization and for accenting characters (there are three accents acute, one umlaut, and one "i" with a circumflex over it). The database should require only slight modification to make it suitable for use with SCRIBE. I am mailing out the database in the interest of making it easier for everyone to refer to all these great papers from the conference. The database follows at the end of this message, followed by the BibTeX transcription of it for a bibliography format very similar to that required by CACM. (I considered just mailing out a pointer to an FTP-able file, but I find that in practice this method is rather clumsy and people don't use it.) --Guy ---------------------------------------------------------------- @InProceedings(LAWS-IN-MIRANDA ,Key = "Thompson" ,Author = "Simon Thompson" ,Title = "Laws in {M}iranda" ,Pages = "1-12" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(MINI-ML ,Key = "Clement" ,Author = "Dominique Cl\'ement and {Jo\"elle} Despeyroux and Thierry Despeyroux and Gilles Kahn" ,Title = "A Simple Applicative Language: {M}ini-{ML}" ,Pages = "13-27" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(INTEGRATING-FUNCTIONAL-AND-IMPERATIVE-PROGRAMMING ,Key = "Gifford" ,Author = "David K. Gifford and John M. Lucassen" ,Title = "Integrating Functional and Imperative Programming" ,Pages = "28-38" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(EXPERIENCE-WITH-AN-UNCOMMON-LISP ,Key = "Alberga" ,Author = "Cyril N. Alberga and Chris Bosman-Clark and Martin Mikelsons and Mary S. Van Deusen and Julian Padget" ,Title = "Experience with an Uncommon {L}isp" ,Pages = "39-53" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(DESIDERATA-FOR-THE-STANDARDISATION-OF-LISP ,Key = "Padget" ,Author = "Julian Padget and others" ,Title = "Desiderata for the Standardisation of {L}isp" ,Pages = "54-66" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(OPTIMIZING-DYNAMICALLY-RETARGETABLE-COMPILER-FOR-COMMON-LISP ,Key = "Brooks" ,Author = "Rodney A. Brooks and David B. Posner and James L. McDonald and Jon L. White and Eric Benson and Richard P. Gabriel" ,Title = "Design of an Optimizing, Dynamically Retargetable Compiler for {C}ommon {L}isp" ,Pages = "67-85" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(IMPLEMENTATION-OF-PC-SCHEME ,Key = "Bartley" ,Author = "David H. Bartley and John C. Jensen" ,Title = "The Implementation of {PC} {S}cheme" ,Pages = "86-93" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(CODE-GENERATION-TECHNIQUES-FOR-FUNCTIONAL-LANGUAGES ,Key = "Fairbairn" ,Author = "Jon Fairbairn and Stuart C. Wray" ,Title = "Code Generation Techniques for Functional Languages" ,Pages = "94-104" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(ARCHITECTURE-FOR-MOSTLY-FUNCTIONAL-LANGUAGES ,Key = "Knight" ,Author = "Tom Knight" ,Title = "An Architecture for Mostly Functional Languages" ,Pages = "105-112" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(EFFICIENT-MULTIPROCESSOR-COMBINATOR-REDUCTION ,Key = "Lemaitre" ,Author = "M. Lema\^\itre and M. Castan and M.-H. Durand and G. Durrieu and B. Lecussan" ,Title = "Mechanisms for Efficient Multiprocessor Combinator Reduction" ,Pages = "113-121" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(CURRY-CHIP ,Key = "Ramsdell" ,Author = "John D. Ramsdell" ,Title = "The {CURRY} Chip" ,Pages = "122-131" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(VARIATIONS-ON-STRICTNESS-ANALYSIS ,Key = "Bloss" ,Author = "Adrienne Bloss and Paul Hudak" ,Title = "Variations on Strictness Analysis" ,Pages = "132-142" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(EXPANSION-PASSING-STYLE ,Key = "Dybvig" ,Author = "R. Kent Dybvig and Daniel P. Friedman and Christopher T. Haynes" ,Title = "Expansion-Passing Style: Beyond Conventional Macros" ,Pages = "143-150" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(HYGIENIC-MACRO-EXPANSION ,Key = "Kohlbecker" ,Author = "Eugene Kohlbecker and Daniel P. Friedman and Matthias Felleisen and Bruce Duba" ,Title = "Hygienic Macro Expansion" ,Pages = "151-161" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(EXACT-REAL-ARITHMETIC ,Key = "Boehm" ,Author = "Hans-J. Boehm and Robert Cartwright and Mark Riggle and Michael J. O'Donnell" ,Title = "Exact Real Arithmetic: A Case Study in Higher Order Programming" ,Pages = "162-173" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(RECONFIGURABLE-RETARGETABLE-BIGNUMS ,Key = "White" ,Author = "Jon L. White" ,Title = "Reconfigurable, Retargetable Bignums: A Case Study in Efficient, Portable {L}isp System Building" ,Pages = "174-191" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(LISP-ON-A-REDUCED-INSTRUCTION-SET-PROCESSOR ,Key = "Steenkiste" ,Author = "Peter Steenkiste and John Hennessy" ,Title = "{L}isp on a Reduced-Instruction-Set-Processor" ,Pages = "192-201" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(PARTITIONING-PARALLEL-PROGRAMS-FOR-MACRO-DATAFLOW ,Key = "Sarkar" ,Author = "Vivek Sarkar and John Hennessy" ,Title = "Partitioning Parallel Programs for Macro-Dataflow" ,Pages = "202-211" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(NORMA-GRAPH-REDUCTION-PROCESSOR ,Key = "Scheevel" ,Author = "Mark Scheevel" ,Title = "{NORMA}: A Graph Reduction Processor" ,Pages = "212-219" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(FOUR-STROKE-REDUCTION-ENGINE ,Key = "Clack" ,Author = "Chris Clack and Simon L. Peyton Jones" ,Title = "The Four-Stroke Reduction Engine" ,Pages = "220-232" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(USE-OF-LISP-IN-IMPLEMENTING-DENOTATIONAL-SEMANTICS ,Key = "Lee" ,Author = "Peter Lee and Uwe Pleban" ,Title = "On the Use of {L}isp in Implementing Denotational Semantics" ,Pages = "233-248" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(SEMANTICS-DIRECTED-COMPILING-FOR-FUNCTIONAL-LANGUAGES ,Key = "Nielson" ,Author = "Hanne R. Nielson and Flemming Nielson" ,Title = "Semantics Directed Compiling for Functional Languages" ,Pages = "249-257" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(CONNECTION-GRAPHS ,Key = "Bawden" ,Author = "Alan Bawden" ,Title = "Connection Graphs" ,Pages = "258-265" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(IMPLEMENTING-FUNCTIONAL-LANGUAGES-IN-THE-CATEGORICAL-ABSTRACT-MACHINE ,Key = "Mauny" ,Author = "Michel Mauny and Asc\'ander Su\'arez" ,Title = "Implementing Functional Languages in the Categorical Abstract Machine" ,Pages = "266-278" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(CONNECTION-MACHINE-LISP ,Key = "Steele" ,Author = "Steele, Guy L., Jr. and W. Daniel Hillis" ,Title = "Connection Machine LISP: Fine-Grained Parallel Symbolic Processing" ,Pages = "279-297" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(MYSTERY-OF-THE-TOWER-REVEALED ,Key = "Wand" ,Author = "Mitchell Wand and Daniel P. Friedman" ,Title = "The Mystery of the Tower Revealed: A Non-Reflective Description of the Reflective Tower" ,Pages = "298-307" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(TYPE-INFERENCE-APPROACH-TO-POLYMORPHIC-EXPRESSIONS ,Key = "Mitchell" ,Author = "John C. Mitchell" ,Title = "A Type-Inference Approach to Reduction Properties and Semantics of Polymorphic Expressions (summary)" ,Pages = "308-319" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(EQUATIONS-SETS-AND-REDUCTION-SEMANTICS ,Key = "Jayaraman" ,Author = "Bharat Jayaraman and Frank S. K. Silbermann" ,Title = "Equations, Sets, and Reduction Semantics for Functional and Logic Programming" ,Pages = "320-331" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(SEMANTIC-THEORY-FOR-EQUATIONAL-PROGRAMMING-LANGUAGES ,Key = "Thatte" ,Author = "Satish R. Thatte" ,Title = "Towards a Semantic Theory for Equational Programming Languages" ,Pages = "332-342" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(PROTOCOL-FOR-DISTRIBUTED-REFERENCE-COUNTING ,Key = "Lermen" ,Author = "Claus-Werner Lermen and Dieter Maurer" ,Title = "A Protocol for Distributed Reference Counting" ,Pages = "343-350" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(SEMANTIC-MODEL-OF-REFERENCE-COUNTING-AND-ITS-ABSTRACTION ,Key = "Hudak" ,Author = "Paul Hudak" ,Title = "A Semantic Model of Reference Counting and its Abstraction (detailed summary)" ,Pages = "351-363" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(DISTRIBUTED-COPYING-GARBAGE-COLLECTION ,Key = "Rudalics" ,Author = "Martin Rudalics" ,Title = "Distributed Copying Garbage Collection" ,Pages = "364-372" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") ---------------------------------------------------------------- \bibitem{EXPERIENCE-WITH-AN-UNCOMMON-LISP} Alberga, Cyril N., Bosman-Clark, Chris, Mikelsons, Martin, Deusen, Mary S. Van, and Padget, Julian. Experience with an uncommon {L}isp. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 39--53. \bibitem{IMPLEMENTATION-OF-PC-SCHEME} Bartley, David H., and Jensen, John C. The implementation of {PC} {S}cheme. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 86--93. \bibitem{CONNECTION-GRAPHS} Bawden, Alan. Connection graphs. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 258--265. \bibitem{VARIATIONS-ON-STRICTNESS-ANALYSIS} Bloss, Adrienne, and Hudak, Paul. Variations on strictness analysis. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 132--142. \bibitem{EXACT-REAL-ARITHMETIC} Boehm, Hans-J., Cartwright, Robert, Riggle, Mark, and O'Donnell, Michael J. Exact real arithmetic: a case study in higher order programming. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 162--173. \bibitem{OPTIMIZING-DYNAMICALLY-RETARGETABLE-COMPILER-FOR-COMMON-LISP} Brooks, Rodney A., Posner, David B., McDonald, James L., White, Jon L., Benson, Eric, and Gabriel, Richard P. Design of an optimizing, dynamically retargetable compiler for {C}ommon {L}isp. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 67--85. \bibitem{FOUR-STROKE-REDUCTION-ENGINE} Clack, Chris, and Jones, Simon L. Peyton. The four-stroke reduction engine. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 220--232. \bibitem{MINI-ML} Cl\'ement, Dominique, Despeyroux, {Jo\"elle}, Despeyroux, Thierry, and Kahn, Gilles. A simple applicative language: {M}ini-{ML}. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 13--27. \bibitem{EXPANSION-PASSING-STYLE} Dybvig, R. Kent, Friedman, Daniel P., and Haynes, Christopher T. Expansion-passing style: beyond conventional macros. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 143--150. \bibitem{CODE-GENERATION-TECHNIQUES-FOR-FUNCTIONAL-LANGUAGES} Fairbairn, Jon, and Wray, Stuart C. Code generation techniques for functional languages. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 94--104. \bibitem{INTEGRATING-FUNCTIONAL-AND-IMPERATIVE-PROGRAMMING} Gifford, David K., and Lucassen, John M. Integrating functional and imperative programming. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 28--38. \bibitem{SEMANTIC-MODEL-OF-REFERENCE-COUNTING-AND-ITS-ABSTRACTION} Hudak, Paul. A semantic model of reference counting and its abstraction (detailed summary). In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 351--363. \bibitem{EQUATIONS-SETS-AND-REDUCTION-SEMANTICS} Jayaraman, Bharat, and Silbermann, Frank S. K. Equations, sets, and reduction semantics for functional and logic programming. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 320--331. \bibitem{ARCHITECTURE-FOR-MOSTLY-FUNCTIONAL-LANGUAGES} Knight, Tom. An architecture for mostly functional languages. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 105--112. \bibitem{HYGIENIC-MACRO-EXPANSION} Kohlbecker, Eugene, Friedman, Daniel P., Felleisen, Matthias, and Duba, Bruce. Hygienic macro expansion. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 151--161. \bibitem{USE-OF-LISP-IN-IMPLEMENTING-DENOTATIONAL-SEMANTICS} Lee, Peter, and Pleban, Uwe. On the use of {L}isp in implementing denotational semantics. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 233--248. \bibitem{EFFICIENT-MULTIPROCESSOR-COMBINATOR-REDUCTION} Lema\^\itre, M., Castan, M., Durand, M.-H., Durrieu, G., and Lecussan, B. Mechanisms for efficient multiprocessor combinator reduction. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 113--121. \bibitem{PROTOCOL-FOR-DISTRIBUTED-REFERENCE-COUNTING} Lermen, Claus-Werner, and Maurer, Dieter. A protocol for distributed reference counting. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 343--350. \bibitem{IMPLEMENTING-FUNCTIONAL-LANGUAGES-IN-THE-CATEGORICAL-ABSTRACT-MACHINE} Mauny, Michel, and Su\'arez, Asc\'ander. Implementing functional languages in the categorical abstract machine. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 266--278. \bibitem{TYPE-INFERENCE-APPROACH-TO-POLYMORPHIC-EXPRESSIONS} Mitchell, John C. A type-inference approach to reduction properties and semantics of polymorphic expressions (summary). In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 308--319. \bibitem{SEMANTICS-DIRECTED-COMPILING-FOR-FUNCTIONAL-LANGUAGES} Nielson, Hanne R., and Nielson, Flemming. Semantics directed compiling for functional languages. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 249--257. \bibitem{DESIDERATA-FOR-THE-STANDARDISATION-OF-LISP} Padget, Julian, et al. Desiderata for the standardisation of {L}isp. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 54--66. \bibitem{CURRY-CHIP} Ramsdell, John D. The {CURRY} chip. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 122--131. \bibitem{DISTRIBUTED-COPYING-GARBAGE-COLLECTION} Rudalics, Martin. Distributed copying garbage collection. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 364--372. \bibitem{PARTITIONING-PARALLEL-PROGRAMS-FOR-MACRO-DATAFLOW} Sarkar, Vivek, and Hennessy, John. Partitioning parallel programs for macro-dataflow. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 202--211. \bibitem{NORMA-GRAPH-REDUCTION-PROCESSOR} Scheevel, Mark. {NORMA}: a graph reduction processor. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 212--219. \bibitem{CONNECTION-MACHINE-LISP} Steele, Jr., Guy L., and Hillis, W. Daniel. Connection machine lisp: fine-grained parallel symbolic processing. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 279--297. \bibitem{LISP-ON-A-REDUCED-INSTRUCTION-SET-PROCESSOR} Steenkiste, Peter, and Hennessy, John. {L}isp on a reduced-instruction-set-processor. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 192--201. \bibitem{SEMANTIC-THEORY-FOR-EQUATIONAL-PROGRAMMING-LANGUAGES} Thatte, Satish R. Towards a semantic theory for equational programming languages. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 332--342. \bibitem{LAWS-IN-MIRANDA} Thompson, Simon. Laws in {M}iranda. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 1--12. \bibitem{MYSTERY-OF-THE-TOWER-REVEALED} Wand, Mitchell, and Friedman, Daniel P. The mystery of the tower revealed: a non-reflective description of the reflective tower. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 298--307. \bibitem{RECONFIGURABLE-RETARGETABLE-BIGNUMS} White, Jon L. Reconfigurable, retargetable bignums: a case study in efficient, portable {L}isp system building. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 174--191.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 22 Aug 86 08:38:51 EDT Received: from indiana by csnet-relay.csnet id ac02619; 22 Aug 86 8:33 EDT Date: Fri, 22 Aug 86 03:03:54 est From: "R. Kent Dybvig" To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA Subject: a few more comments It may be too late to bother with any of this, but here are a few comments on the R3RS copy handed out at the conference. Functionality ------------- char-ready? looks too much like char-lower-case?, char-alphabetic?, etc., and not enough like read-char. I think read-char-ready? would be much more appropriate. Besides, some implementation or future RnRS may want to have a write-char-ready?. Is there any reason not to change the name? In the number formats, the syntax (exactness) is used within two of the examples of 6.5.6, but this form is not explicitly allowed in 6.5.7. My feeling is that the modifier s or e should be required, as implied in 6.5.7. The formats are pretty complicated as is. What happens on string?, string<=?, string>=?, string-ci?, string-ci<=?, string-ci>=? when one string is longer than the other? I would add "If two strings differ in length but are the same up to the length of the shorter string, the shorter string is considered to be lexographically less than the longer string". The procedure substring-fill! is the only procedure left that sticks out to me as unnecessary and rarely useful. Perhaps someone can explain to me why it should be in the standard. Why is there not a vector-null? function..., or why not delete null? and string-null? to be consistent? Presentation ------------ 1.3.1 strike the word "will" 2.1 it is not clear what "extended alphabetic characters" are here; I think that the list should be moved here from 2.3, which is, after all, titled "other" notations. At the least, a forward pointer is needed. 2.1 last sentence, replace "between" with "among" 2.3 mention that ) is used to close a vector constant 6.9 optional if syntax should not be used in example True Nitpick ------------ 7.3 in first case description... (let ((key ) ^ extra space Kent  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 20 Aug 86 23:02:06 EDT Received: from tektronix by csnet-relay.csnet id ag24407; 20 Aug 86 22:44 EDT Received: by tektronix.TEK (5.31/6.16) id AA21860; Wed, 20 Aug 86 17:10:36 PDT Received: by tekchips.TEK (5.31/6.16) id AA03947; Wed, 20 Aug 86 17:13:22 PDT Message-Id: <8608210013.AA03947@tekchips.TEK> To: rrrs-authors@MC.LCS.MIT.EDU Cc: willc%tekchips.tek.com@CSNET-RELAY.ARPA, adams%tekchips.tek.com@CSNET-RELAY.ARPA Subject: numbers In-Reply-To: Your message of Wed 16 Jul 86 10:53:32-CDT. <12223161873.35.BARTLEY@CSC60> Date: 20 Aug 86 17:13:20 PDT (Wed) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Abstract: Scheme numbers are still inadequately specified in several respects. I propose several improvements. Some are minor enough to deserve incorporation in the SIGPLAN Notices publication of the Revised^3 Report, but the others probably deserve more debate. Some problems that I perceive with Scheme numbers are: 1. The quotient procedure is not adequately specified. 2. The floor etc procedures are not adequately specified. 3. The syntax for numbers has a redundancy. 4. The integer? procedure may not be adequately specified. 5. Valid indexes may not be adequately specified. 6. The read and string->number procedures are not adequately specified. (David Bartley has also suggested that the syntax should be made more compatible with Common Lisp and has proposed that the report be clearer on which parts of the number syntax are essential and which are not essential.) 1. Norman Adams pointed out to me that it is unclear from the description of quotient in 6.5.4 whether (quotient -13 4) should be -3 or -4; likewise (quotient 13 -4). I propose that the sentence beginning "For positive integers n1 and n2" be followed by the sentence For all integers n1 and n2 with n2 not equal to 0, (= n1 (+ (* n2 (quotient n1 n2)) (remainder n1 n2))) ==> #t 2. In the description of floor, ceiling, truncate, round, and rationalize, the sentence "Their results are not exact---in fact, their results are clearly inexact, though they can be made exact with an explicit exactness coercion" is incorrect. I propose that the sentence be replaced by "Their results are exact if and only if their arguments are exact." 3. The third production for is redundant. 4. In MacScheme and a few other implementations, (integer? 4.0) evaluates to #f. Even assuming that 4.0 is inexact, this seems wrong. I would like to see an example in the report to show that it's wrong. 5. I believe the index or size arguments to list-tail, list-ref, make-string, string-ref, string-set!, substring-fill!, make-vector, vector-ref, and vector-set! should be required to be exact integers instead of just integers. 6. It isn't clear from the report whether 3.0 reads as an exact or inexact number. Indeed the same can be said of 3, or 3/1, or 3###-4###i. I propose that this sort of thing be specified more formally, as in the following example---which does not match up very well with the syntax and is not my favorite proposal anyway. exactness [ + i ] = exactness [ - i ] = minexact (exactness [ ], exactness [ ureal ]) exactness [ @ ] = minexact (exactness [ ], exactness [ ] exactness [ ] = exactness [ ] exactness [ ] = if explicit [ ] then prexact [ ] else if empty [ ] then exactness [ ] else #f ; this is what I don't like exactness [ ] = if empty [ ] then exactness [ ] else #f exactness [ + #+ ] = #f exactness [ + ] = #t exactness [ / ] = minexact (exactness [ ], exactness [ ]) exactness [ + #+ ] = #f exactness [ + ] = #t exactness [ * . + #* ] = #f exactness [ * . #+ ] = #f exactness [ + . ] = #t exactness [ + #+ . ] = #f minexact (b1, b2) = if b1 then b2 else #f explicit [ ... #i ... ] = explicit [ ... #e ... ] = #t explicit [ ... ... ] = #f prexact [ ... ... ] = prexact [ ] prexact [ #i ] = #f prexact [ #e ] = #t Peace, Will  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 16 AUG 86 00:49:37 EDT Date: Sat, 16 Aug 86 00:50:15 EDT From: Chris Hanson Subject: "Final" comments on RRRRS To: JAR@AI.AI.MIT.EDU cc: RRRS-Authors@MC.LCS.MIT.EDU In-reply-to: Msg of Fri 15 Aug 86 15:22:44 EDT from Jonathan A Rees Message-ID: <[AI.AI.MIT.EDU].84332.860816.CPH> Date: Fri, 15 Aug 86 15:22:44 EDT From: Jonathan A Rees To: Bartley%ti-csl.csnet at CSNET-RELAY.ARPA Date: Fri 8 Aug 86 15:20:50-CDT From: David Bartley -- Kent Dybvig has asked that the colon (:) be removed from the set of extended alphabetic characters (section 2.3). I agree completely. My joint implementations of Scheme and Common LISP need a reasonable syntax for Scheme procedures to refer to symbols in various Common LISP packages. Using Common LISP's syntax seems best. I have no strong objection to this. It's conceivable that it could be construed by the uninitiated as an endorsement of read-time packaging, but I think we should be able to guard against that. I would like to hear from people who object to the this (Hanson?) before making the change. If the screams aren't too loud I'll do it. I guess that I should respond to this. I really, truly abhor the read-time package system and would strenuously object to any such thing being introduced into Scheme. I have gone out of my way (a little) to use colons in my code just to parody the package system and, unfortunately, that would make my code non-portable given this decision. Understand, I have no really serious objections to this suggestion, except that if anyone tries to define what `:' means when it appears in an identifier, I promise to raise heck. But I don't mind agreeing to disagree about it. And, of course, anyone who implements this change will not be able to port my code without significant rewriting. Sigh. I guess that would be your loss, not mine. (Seriously, though, what would the symbol `rtl:interpreter-call:lookup' mean in a system with such a syntax?)  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 AUG 86 15:22:24 EDT Date: Fri, 15 Aug 86 15:22:44 EDT From: Jonathan A Rees Subject: "Final" comments on RRRRS To: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA cc: RRRS-Authors@MC.LCS.MIT.EDU In-reply-to: Msg of Fri 8 Aug 86 15:20:50-CDT from David Bartley Message-ID: <[AI.AI.MIT.EDU].84135.860815.JAR> Date: Fri 8 Aug 86 15:20:50-CDT From: David Bartley -- Kent Dybvig has asked that the colon (:) be removed from the set of extended alphabetic characters (section 2.3). I agree completely. My joint implementations of Scheme and Common LISP need a reasonable syntax for Scheme procedures to refer to symbols in various Common LISP packages. Using Common LISP's syntax seems best. I have no strong objection to this. It's conceivable that it could be construed by the uninitiated as an endorsement of read-time packaging, but I think we should be able to guard against that. I would like to hear from people who object to the this (Hanson?) before making the change. If the screams aren't too loud I'll do it. -- I hope that Jonathan will be able to incorporate our proposed number syntax. Sorry, I just won't have time to work on it, and I don't think there's time for proper review. If you could prepare the changes in fine detail (maybe edit the TeX sources yourself), this might be feasible, but a last-minute change of this magnitude is bound to have problems with it. Probably it would be best to just include a statement to the effect that this change is being considered for a future revision of the report. Jonathan  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 AUG 86 13:57:24 EDT Date: Fri, 15 Aug 86 13:57:51 EDT From: Jonathan A Rees Subject: scheme report tar file To: goodhart@NOSC-COD.ARPA cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Wed 6 Aug 86 10:26:55 PDT from Curtis L. Goodhart Message-ID: <[AI.AI.MIT.EDU].84083.860815.JAR> OK, there's now a tar file for the draft of the scheme report on host MIT-PREP in the file "/u/jar/r3rs.tar". Use user scheme password scheme if user & password are required. The tar file is about .25 Mbytes. Sorry this took so long. Jonathan  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 AUG 86 13:46:41 EDT Date: Fri, 15 Aug 86 13:47:03 EDT From: Jonathan A Rees Subject: r-cubed syntax (nits) To: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of 14 Aug 86 13:58:14 PDT (Thu) from willc%tekchips.tek.csnet at CSNET-RELAY.ARPA Message-ID: <[AI.AI.MIT.EDU].84074.860815.JAR> Date: 14 Aug 86 13:58:14 PDT (Thu) From: willc%tekchips.tek.csnet at CSNET-RELAY.ARPA parsimony: 7.1.1: : * can be written + OK, will fix. ambiguity?: 7.1.3: and both allow (else ) to be any clause, rather than the last clause. Is this intentional? I had it this way for a while, and decided that it was unnecessary clutter in the syntax. You need to give two rules instead of one for the syntax of cond (and case), and it looks really bad. But the fact that someone noticed & cared is probably enough to indicate that I should change it back to the more verbose, pedantic form.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Aug 86 11:50:44 EDT Received: from indiana by csnet-relay.csnet id aa07414; 15 Aug 86 11:12 EDT Date: Fri, 15 Aug 86 00:51:46 est From: "R. Kent Dybvig" To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA Subject: Re: Minutes from lunch 5 August 1986 It was I who volunteered to coordinate the verification suite. Kent  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Aug 86 00:58:33 EDT Received: from tektronix by csnet-relay.csnet id ag02938; 15 Aug 86 0:47 EDT Received: by tektronix.TEK (5.31/6.16) id AA10107; Thu, 14 Aug 86 13:55:24 PDT Received: by tekchips.TEK (5.31/6.16) id AA01706; Thu, 14 Aug 86 13:58:17 PDT Message-Id: <8608142058.AA01706@tekchips.TEK> To: JAR@AI.AI.MIT.EDU Cc: rrrs-authors@MC.LCS.MIT.EDU Subject: r-cubed syntax (nits) In-Reply-To: Your message of Tue, 29 Jul 86 16:35:08 EDT. <[AI.AI.MIT.EDU].77171.860729.JAR> Date: 14 Aug 86 13:58:14 PDT (Thu) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA The following comes from Ken Dickey (kend%tekla@tek.csnet; my previous note said kend@tekla, but I don't think that works unless you're at Tektronix.). ---------------------------------------------------------------- Will, parsimony: 7.1.1: : * can be written + ambiguity?: 7.1.3: and both allow (else ) to be any clause, rather than the last clause. Is this intentional? Again, let me say that this is the best language spec that I have read in some time (I still have 7.2 to slog through). -Ken  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 14 Aug 86 23:00:21 EDT Received: from tektronix by csnet-relay.csnet id ab00212; 14 Aug 86 18:46 EDT Received: by tektronix.TEK (5.31/6.16) id AA09635; Thu, 14 Aug 86 13:06:50 PDT Received: by tekchips.TEK (5.31/6.16) id AA25920; Thu, 14 Aug 86 13:09:35 PDT Message-Id: <8608142009.AA25920@tekchips.TEK> To: kend%tekla.tek.csnet@CSNET-RELAY.ARPA Cc: rrrs-authors@MC.LCS.MIT.EDU Subject: substring indexes In-Reply-To: Your message of 13 Aug 86 08:37:36 PDT (Wed). <8608131537.AA25142@tekla.TEK> Date: 14 Aug 86 13:09:33 PDT (Thu) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA The following comes from Ken Dickey (kend@tekla). I favor changing the description of substring-fill! to say START *to* END. Peace, Will. ---------------------------------------------------------------- Will, I have not yet read the full report, but R-cubed is a significant improvement over R-squared. I did find section 6.7 on strings, however, to be somewhat confusing. Some functions (eg substring) use START *to* END, while others (eg substring-fill!) use START *through* END. I think it would be better to either maintain 0 <= START <= END < (string-length ) XOR use 1 based indexing. In both cases, I favor using start through end (both inclusive). The latter is probably more in keeping with the spirit of Scheme in that one based indexing seems more natural to naive programmers**. Pax, -Ken ------------- ** (based on my experience teaching Pascal and C).  Received: from Sushi.Stanford.EDU by MC.LCS.MIT.EDU 14 Aug 86 21:34:10 EDT Date: Thu 14 Aug 86 18:30:00-PDT From: Andy Freeman Subject: Re: Minutes from lunch 5 August 1986 To: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA cc: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: <8608142000.AA24878@tekchips.TEK> Message-ID: <12230868993.15.ANDY@Sushi.Stanford.EDU> I'd be happier if the Scheme community said nothing about multitasking, multiprocessing, or anything related to parallelism. This isn't intended to discourage informal communication, but any hint of agreement/standardization is premature. Why is this coming up now anyway? We don't understand macros, errors, interrupts, declarations, etc. I'd rather have (hash) tables than project/inject/in?. -andy -------  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 14 Aug 86 20:27:24 EDT Received: from tektronix by csnet-relay.csnet id aa00212; 14 Aug 86 18:43 EDT Received: by tektronix.TEK (5.31/6.16) id AA09292; Thu, 14 Aug 86 12:57:59 PDT Received: by tekchips.TEK (5.31/6.16) id AA24878; Thu, 14 Aug 86 13:00:49 PDT Message-Id: <8608142000.AA24878@tekchips.TEK> To: rrrs-authors@MC.LCS.MIT.EDU Subject: Minutes from lunch 5 August 1986 In-Reply-To: Your message of Tue, 29 Jul 86 16:35:08 EDT. <[AI.AI.MIT.EDU].77171.860729.JAR> Date: 14 Aug 86 13:00:46 PDT (Thu) From: 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?  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 8 Aug 86 20:16:20 EDT Received: from ti-csl by csnet-relay.csnet id ai03255; 8 Aug 86 18:15 EDT Received: by tilde id AA15700; Fri, 8 Aug 86 15:48:46 cdt Date: Fri 8 Aug 86 15:20:50-CDT From: David Bartley Subject: "Final" comments on RRRRS To: RRRS-Authors%mit-mc@CSNET-RELAY.ARPA Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Message-Id: <12229239846.30.BARTLEY@CSC60> Before I go on vacation, I'd like to submit a (very) few comments on the current draft report for consideration for the SIGPLAN revision. -- I'm very pleased with its appearance and happy that it was distributed to all of the attendees at the LISP conference. Thanks again to Jonathon. -- Kent Dybvig has asked that the colon (:) be removed from the set of extended alphabetic characters (section 2.3). I agree completely. My joint implementations of Scheme and Common LISP need a reasonable syntax for Scheme procedures to refer to symbols in various Common LISP packages. Using Common LISP's syntax seems best. -- Reference [2] to our conference paper on PC Scheme may now be updated to refer to pages 86-93 of the proceedings. The same goes for reference [6] by Dybvig, Friedman, and Haynes. Reference [51] to the TI Scheme manual should be changed from ``preliminary version 1.0, November 1985'' to ``Original issue: December 1985''. -- I hope that Jonathon will be able to incorporate our proposed number syntax. Regards, David Bartley -------  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 AUG 86 11:20:48 EDT Date: Fri, 8 Aug 86 11:19:12 EDT From: Jonathan A Rees Subject: [Masinter.pa: synonym streams..] To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].80953.860808.JAR> How about a similar rule for Scheme? With the obvious extension to ports created by with-input-file, etc. - Jonathan. Date: 5 Aug 86 11:09 PDT From: Masinter.pa at Xerox.COM To: common-lisp at su-ai.ARPA Re: synonym streams.. In-reply-to: David Bein 's message of 5 Aug 86 09:05 PDT Message-ID: <860805-111034-2460@Xerox> I propose the following rule: "It is an error to attempt to close a stream that wasn't created with open." With this rule, it would follow that, since synonym, broadcast and two-way streams are not created with open, it is an error to perform "close" on them.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 JUL 86 09:54:34 EDT Date: Thu, 31 Jul 86 09:52:31 EDT From: Jonathan A Rees Subject: rrrs authors meeting, lunch Tuesday To: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Wed 30 Jul 86 17:01:20 PDT from Norman Adams Message-ID: <[AI.AI.MIT.EDU].77967.860731.JAR> Date: Wed, 30 Jul 86 17:01:20 PDT From: Norman Adams To: jar at AI.AI.MIT.EDU It occurred to me that the bulk of the RRRS authoripods will be at the lisp conference and that a meeting might bring quick resolution to issues outstanding for the SIGPLAN edition of the R3RS. A meeting might be fun even if there is nothing to resolve... What say you? Perhaps there is not enough time to get a note out on RRRS; maybe we could post something at the registration desk. Good idea. What with Monday night being the banquet, and Tuesday night being various Eulisp and Common Lisp meetings, I think lunchtime would be best. Therefore I propose lunch on Tuesday, promptly following cessation of the morning sessions. If there's a major problem with this time then we can change it to lunch Wednesday or some other time. I'll post something near the registration desk in any case. See y'all there. Jonathan  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 Jul 86 20:14:24 EDT Received: from tektronix by csnet-relay.csnet id am07403; 29 Jul 86 18:48 EDT Received: by tektronix.TEK (5.31/6.16) id AA06974; Tue, 29 Jul 86 15:23:57 PDT Received: by tekchips.TEK (5.31/6.16) id AA22297; Tue, 29 Jul 86 15:26:48 PDT Message-Id: <8607292226.AA22297@tekchips.TEK> To: rrrs-authors@MC.LCS.MIT.EDU Subject: Re: critical problems with call---file, with---file Date: 29 Jul 86 15:26:46 PDT (Tue) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA ...For example, if I write: (with-input-from-file "foo.in" (letrec ((loop (lambda () (write-char (read-char)) (loop)))) loop)), it is clear that a clever Scheme system can prove that the thunk will never return; however, it would be entirely inappropriate to close the new default port and restore the old. Nice example. Should we say instead that "If the procedure does not return, Scheme will not close the port unless it can prove that the continuation with which the procedure was called has become inaccessible"? I can't get very excited if ports aren't closed the instant they become inaccessible, because I suspect that pairs aren't added to the free list the instant they become inaccessible either. I can't see how it affects my life. As I read the report, implementations are not required to try to close ports in the exceptional cases. Likewise, though implementations are "permitted to reclaim the storage occupied by an object if they can prove that the object cannot possibly matter to any future computation", I don't see where implementations are actually required to reclaim storage. I think it's clear that implementations are encouraged to do both, and it's great that Chez Scheme is setting such a good example for us to follow. It would be reasonable to say that "in order to avoid running out of file-system resources, implementations usually close ports it can prove are inaccessible" if it were true. Is it? Implementation note: In a very large multiprocessing implementation of Scheme it might be more practical to remove limits on file-system resources than to determine whether ports are accessible. ---------------------------------------------------------------- The section that describes differences between RRRS and R3RS should note that (DEFINE (FOO ...) ...) is now equivalent to (DEFINE FOO (LAMBDA (...) ...)) instead of to (DEFINE FOO (REC FOO (LAMBDA (...) ...))). Peace, Will  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 JUL 86 16:52:21 EDT Date: Tue, 29 Jul 86 16:35:08 EDT From: Jonathan A Rees Subject: schedule To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].77171.860729.JAR> A version of the report is now at the printer. There will be a copy in every Lisp conference registration packet. As for SIGPLAN, I seem to have screwed up pretty badly; I thought that having it done by early August would be good, since it would then get into the October issue. However, I just found out from Wexelblat that the October issue is proceedings for some conference. (This decision was made rather late; the previous time I spoke with him, the October issue was still open.) Therefore the earliest it can be out is the November issue, and our new deadline is September 12. For the Lisp conference version, I didn't do anything about number syntax, since there seemed to be a bit of controversy remaining; also I did nothing about the question of number input exactness, and didn't rename the call-with-transput-pile procedures. What got printed was rather close to the July 15 draft, incorporating, of course, most of the corrections people sent me. Maybe we can fix these and other problems by September, though. Thanks to everyone who read the July 15 and other drafts so carefully. If you won't be at the Lisp conference, let me know and I'll mail you a copy of the latest thing. Jonathan  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 Jul 86 15:58:06 EDT Received: from indiana by csnet-relay.csnet id ab02982; 29 Jul 86 9:57 EDT Date: Tue, 29 Jul 86 02:10:41 est From: "R. Kent Dybvig" To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA Subject: critical problems with call---file, with---file Cc: bartley%ti-csl.CSNET@CSNET-RELAY.ARPA, jar%mit-mc.CSNET@CSNET-RELAY.ARPA, willc%tekchips@iuvax.indiana.edu Regarding these quotes from the latest revision: (under call-with-input-file, call-with-output-file) If the procedure returns, then the port is closed automatically and the value yielded by the procedure is returned. If the procedure does not return, then Scheme will not close the port unless it can prove that the port will never again be used for a read or write operation. (under with-input-from-file, with-output-to-file) Furthermore, in contrast to call-with-input-file and call-with-output-file, these procedures will arrange to close the default port and restore the previous default whenever the system can prove that the call to the thunk will never return. I have two problems with the wording of these two quotes. One of these probems can be ignored, and we'll only have an ill-specified and confusing set of procedures. The other cannot be ignored. First, the one that cannot be ignored: From the wording of the second quote, it is technically possible (and perhaps required!) for a Scheme system to close a port out from under a procedure in a way we do not intend. For example, if I write: (with-input-from-file "foo.in" (letrec ((loop (lambda () (write-char (read-char)) (loop)))) loop)), it is clear that a clever Scheme system can prove that the thunk will never return; however, it would be entirely inappropriate to close the new default port and restore the old. The second problem takes a little more explaining: I think that most users will be very confused and rather upset that call-with-input-file does not close the port automatically in the case of a non-local exit, either programmed or through some sort of error. Also, in the case of with---file, it is not clear whether an implementation is required to close the port as soon as it can prove that the call will never return, or sometime thereafter. Furthermore, it is not clear how sophisticated the system must be in proving this fact. In the most recent version of Chez Scheme, ports are closed by the storage manager once it determines there is no possibility of reference. This will not necessarily occur as soon as the port becomes inaccessible, but it is guaranteed that the system will not run out of ports if there are any open, inaccessible ports around. In addition, all ports are closed on exit from the system. This is a much more general and reasonable solution to the problem of closing ports than forcing the programmer to use confusing, ill-defined procedures that don't necessarily help in the case of non-local exits or errors. It is fine to say that the port is closed when the procedure or thunk returns, but we should flush the descriptions of what happens when the procedure or thunk does not return, perhaps mentioning that, in order to avoid running out of file-system resources, implementations usually close ports it can prove are inaccessible. This would be in the spirit of the earlier statement about not (usually!) running out of storage (section 1.1, paragraph 4), and would also reinforce the first-class status of ports. Kent p.s. We don't have much time, so please respond quickly.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 Jul 86 18:47:41 EDT Received: from tektronix by csnet-relay.csnet id ai01735; 28 Jul 86 18:43 EDT Received: by tektronix.TEK (5.31/6.16) id AA07871; Mon, 28 Jul 86 09:51:20 PDT Received: by tekchips.TEK (5.31/6.16) id AA02924; Mon, 28 Jul 86 09:54:03 PDT Message-Id: <8607281654.AA02924@tekchips.TEK> To: cth%indiana.csnet@CSNET-RELAY.ARPA Cc: rrrs-authors@MC.LCS.MIT.EDU Subject: Re: corrections and suggestions In-Reply-To: Your message of Thu, 24 Jul 86 17:21:19 est. <8607270553.AA19279@tekchips.TEK> Date: 28 Jul 86 09:54:02 PDT (Mon) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 3.1. may name --> names Question: Why say "A variable that does so is said to be bound to the location." Is it possible to have variables that aren't bound to locations? If so, how? The reader should not be kept in the dark. There exist identifiers that are not syntactic keywords. According to the first sentence of 3.1, any such identifier may be used as a variable. The catch comes in an implementation with unbound variables, such as PC Scheme, where just using an identifier as a variable does not make it name a location; that must be done with a binding construct. I see your point, but I suspect that many readers would prefer to remain in the dark about this sort of thing until the next paragraph. A related issue is that (top level) DEFINE is missing from the list of binding constructs in the next paragraph. I don't like the last sentence of 6.9. Opinions also differ on the merits of SEQUENCE, but we didn't apologize for it or give SEQUENCE less than optional status by not listing it under BEGIN as an (optional) form. List CALL/CC as a procedure under CALL-WITH-CURRENT-CONTINUATION and replace the last sentence with a statement that CALL/CC is equivalent. Several of us feel rather strongly about this. Whoa! Two wrongs don't make a right. Let's try to get rid of SEQUENCE instead. Several of us feel rather strongly that CALL/CC ought to call the C compiler. Seriously, to add alternative names for procedures now would be inconsistent with our success in getting rid of =? et cetera. Replace the last sentence of the WITH-*-*-FILE paragraph with "Furthermore, when these procedures return, they close the default port and restore the previous default. If an escape procedure is used to escape from the continuation of these procedures, their behavior is implementation dependent." [[Rational: the existing "in constrast" statement is incorrect. Where is the contrast? And more important, some systems will automatically change the default port if the continuation is escaped, but we probably don't want to even mention, let alone require, such behavior.]] The contrast is that WITH-*-*-FILE will close the default port whenever you throw out of it without having done a CALL-WITH-CURRENT-CONTINUATION, even if you stored the value of (CURRENT-*-PORT) in a global variable before you did the throw. CALL-WITH-*-FILE would never do a thing like that. To me, this is a striking contrast. Peace, Will  Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 28 Jul 86 11:10:39 EDT Organization: The MITRE Corp., Bedford, MA Received: from jymme.sun.uucp by linus.MENET (1.1/4.7) id AA27194; Mon, 28 Jul 86 11:08:54 EDT Posted-Date: Mon, 28 Jul 86 11:06:06 edt Received: by jymme.sun.uucp (2.0/SMI-3.0DEV3) id AA02270; Mon, 28 Jul 86 11:06:06 edt Date: Mon, 28 Jul 86 11:06:06 edt From: ramsdell%linus@mitre-bedford.ARPA Message-Id: <8607281506.AA02270@jymme.sun.uucp> To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA Subject: Fault logic in eq? comment Opps! I used faulty logic in: 7) [Page 14, col 1, line 22] The previous page states that there is only one empty string. Therefore, (eqv? "" "") => #t, which implies that (eq? "" "") => #t. If I am wrong, what does the statement about the existence of one empty string mean? Please ignore it! [Page 27, col 2] I think there is support for changing call-with-xxput-file to call-with-xxput-port. I am not convinced that open-xxput-port is any better than open-xxput-file, the latter expresses what the function does just as well as the former does. [Page 2] While the introduction implies Scheme has no dynamic variables and no separate name spaces for global values and functions, maybe that difference with existing Lisps should be made more explicit. Thus, after "... in the same way as an operand position." one might add "In contrast, many other dialects of Lisp associate two values with some variables, and the bindings in effect at run time may depend on the run time history of a program --- not simply the static program structure." John  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 27 Jul 86 00:39:23 EDT Received: from indiana by csnet-relay.csnet id ac11703; 27 Jul 86 0:39 EDT Date: Thu, 24 Jul 86 17:21:19 est From: Chris Haynes To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA Subject: corrections and suggestions I prefer "A Report ..." or "Fourth Report ...". In any case, remove the bit about the ^3 not being a footnote. No one is apt to mistake the title's ^3, for it is big and bold. It is *references* to the title in other publications where the ^3 will cause confusion, and the note in the report won't do any good then. I prefer "C.T. Haynes" in the author list, and "Christopher Haynes" in the Background (p. 2). In the summary, delete "and very few different ways to form expressions", which is unnecessary and questionable. p. 2: make those features --> make additional features first real programming language --> first widely used programming language sub-dialects --> dialects , while many others remain to be adopted. --> . With Kent Dybvig, I would prefer that : not be an extended alphabetic character, but be reserved for special uses. 2.3. unspecified future uses --> possible extensions in discussion of [ ] and { }. 3.1. may name --> names Question: Why say "A variable that does so is said to be bound to the location." Is it possible to have variables that aren't bound to locations? If so, how? The reader should not be kept in the dark. Delete "Note: internale definitions not mentioned here." 3.2. #fand --> #f and 4.1 and 4.2. The "Syntax:" and "Semantics:" paragraph flags are nice, but are not used after "case" (p. 8). I suggest flushing them. Better to be consistent, and they aren't necessary for understanding. 4.2.4. Some implementations of Scheme permit a ... --> This ... pretty printing of (let loop ...) is messed up. 5.1. consists a sequence --> consists of a sequence 6.2. if applying a mutation procedure to one causes the other to change as well. --> if they have operationally equivalent values in corresponding positions and applying a mutation procedure to one causes the other to change as well. For example, two pairs are equivalent if a set-car! operation on one changes the car field of the other. --> For example, two pairs are not equivalent if a set-car! operation on one does not change the car field of the other. Questions: is "side-effect" defined anywhere? (A referee recently critisized me for not defining it.) 6.4. (in the sense of eqv?) --> (in the sense of eq?) [[the reader should be encouraged to think eq? on symbols]] 6.9, p. 27. is an ordinary Scheme procedure --> is a Scheme procedure The classic use --> A common use flush "when programmers need to do something fancy," I don't like the last sentence of 6.9. Opinions also differ on the merits of SEQUENCE, but we didn't apologize for it or give SEQUENCE less than optional status by not listing it under BEGIN as an (optional) form. List CALL/CC as a procedure under CALL-WITH-CURRENT-CONTINUATION and replace the last sentence with a statement that CALL/CC is equivalent. Several of us feel rather strongly about this. 6.10.1. I also prefer CALL-WITH-*-PORT and OPEN-*-PORT. Replace the last sentence of the WITH-*-*-FILE paragraph with "Furthermore, when these procedures return, they close the default port and restore the previous default. If an escape procedure is used to escape from the continuation of these procedures, their behavior is implementation dependent." [[Rational: the existing "in constrast" statement is incorrect. Where is the contrast? And more important, some systems will automatically change the default port if the continuation is escaped, but we probably don't want to even mention, let alone require, such behavior.]] 6.10.4. Delete the LOAD rational. The LOAD description expressly says that expressions and definitions are read, so any uses of LOAD to load such things as compiled files are implementation extensions anyway. Delete the TRANSCRIPT-* Note. We haven't provided elementary tips to implementers anywhere else. BIBLIOGRAPHY: add the following Daniel P. Friedman, Christopher T. Haynes, and Eugene Kohlbecker, Programming with continuations. {\it In Programming Transformation and Programming Environments,\/} P. Pepper (Ed.), pages 263--274, Springer-Verlag, 1984. The Report reads quite well now, and has come a long way in the last few months. Thanks for all your efforts, Jonathan. Chris Haynes  Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 25 Jul 86 15:47:55 EDT Organization: The MITRE Corp., Bedford, MA Received: from clyde.sun.uucp by linus.MENET (1.1/4.7) id AA09549; Fri, 25 Jul 86 15:45:49 EDT Posted-Date: Fri, 25 Jul 86 15:42:54 edt Received: by clyde.sun.uucp (2.0/SMI-3.0DEV3) id AA01028; Fri, 25 Jul 86 15:42:54 edt Date: Fri, 25 Jul 86 15:42:54 edt From: ramsdell%linus@mitre-bedford.ARPA Message-Id: <8607251942.AA01028@clyde.sun.uucp> To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA Subject: July 15th draft On title wars, I am reminded of Norman's comments: Scheme is fun and happy, and a bit quirky -- or are CDR and CAR and so many relatives the ideal names for those procedures? Scheme is as serious as LAMBDA, but as casual as CAR. Alas, what has become of dear PROGN? The names are arbitrary and incidental; CAR and CDR remind us. Scheme is as much an approach as a detailed concrete specification. But to be taken seriously, for Scheme to be widely used, we must have the details and concretions; they are essential but unimportant. While publishers will most likely want to put out contracts on the typing fingers of those who perpetrated the weird title, I think we should have a little fun and keep the superscript in the title. However, I do like the idea of NOT using all caps for Scheme in the title. David Bartley suggests changing "Snobol" into "SNOBOL" because it is an acronym. If we do that, shouldn't we change "Algol" into "ALGOL" and "Lisp" into "LISP"? 1) [Page 2, col 1, line 3] I am worried about the phrase "with absolutely no restrictions on how they are composed". Certainly, the expressions "1" and "2" should not be composed as "(1 2)". Doesn't Scheme show that a small number of rules for forming expression combined with a simple, uniform method of combining the expressions, suffices to form a practical and efficient programming language? 2) [Page 5, col 1, paragraph 2] Too many parentheses. Only the first pair are needed. Use commas for the others. 3) [Page 3, col 1, paragraph 3] Too many parentheses. 4) [Page 6, col 1, paragraph 1] From my reading of the paragraph, I conclude that Common Lisp has no dynamic variables. After all, it says that "To each place where a variable is bound in a program there corresponds a region of the program text within which the binding is effective." The lack of dynamic variables distinguishes Scheme from Common Lisp and makes the above statement true. 5) [Page 10, col 1, line -16] Odd space between the words "region" and "of". 6) [Page 10, col 2, line 1] Change to "general looping construct than do, and may also be used to express recursive procedures." 7) [Page 14, col 1, line 22] The previous page states that there is only one empty string. Therefore, (eqv? "" "") => #t, which implies that (eq? "" "") => #t. If I am wrong, what does the statement about the existence of one empty string mean? 8) [Page 27, col 2] I will simply say that, in my opinion, call-with-xxput-port gives a user a better idea of what is going on, as compared to call-with-xxput-file. In the interest of harmony, I will rest my case unless I hear support from others. John  Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 JUL 86 14:26:41 EDT Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 5047; Fri 25-Jul-86 14:24:41-EDT Date: Fri, 25 Jul 86 14:25 EDT From: Jonathan A Rees Subject: (eqv? #e1 #i1) To: rrrs-authors@MIT-MC.ARPA Message-ID: <860725142516.4.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU> Date: 22 Jul 86 11:31:02 PDT (Tue) From: willc%tekchips.tek.csnet at CSNET-RELAY.ARPA Technical question relating to exactness: Are 1 and 1.0 operationally equivalent? (That is, if we wind up adopting the proposal that 1 be read as an exact integer while 1.0 is read as an inexact integer, then (EQV? 1 1.0) must be false. This is incompatible with the RRRS, which says that EQV? returns true when its arguments are numbers that are equal according to the = procedure. This incompatibility is not listed in the notes on page 35. I wonder if the incompatibility was recognized and intended.) I assumed that this detail was an unintentional omission from RRRS. Clearly #e1 and #i1 are distinguishable. I'll list this in the notes section. - Jonathan  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 25 Jul 86 13:19:12 EDT Received: from tektronix by csnet-relay.csnet id ab23107; 25 Jul 86 12:51 EDT Received: by tektronix.TEK (5.31/6.16) id AA08596; Wed, 23 Jul 86 11:48:49 PDT Received: by tekchips.TEK (5.31/6.16) id AA29292; Wed, 23 Jul 86 11:51:24 PDT Message-Id: <8607231851.AA29292@tekchips.TEK> To: Bartley%TI-CSL.CSNET@CSNET-RELAY.ARPA Cc: JAR@AI.AI.MIT.EDU, rrrs-authors@MC.LCS.MIT.EDU Subject: Re: number syntax In-Reply-To: Your message of Wed 16 Jul 86 10:53:32-CDT. <12223161873.35.BARTLEY@CSC60> Date: 23 Jul 86 11:51:22 PDT (Wed) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA After studying the recent proposal by David Bartley and Mark Meyer, I'm afraid I have to object to using it in the report. I probably just don't understand it, and I might change my mind if they'll explain it to me better. I don't have much problem with the syntactic changes they propose. The main problem I have with their proposal is that it addresses the syntax, which I don't much care about, but doesn't address the semantic properties like exactness and integer-ness. I have repeated most of their proposal (indented two spaces) in order to point out the parts I object to. (4) CL provides only the #C(real real) notation for complex numbers; R^3RS provides infix notations for both polar and rectangular forms. For compatibility with CL, R^3RS should support the #C notation and the infix forms should be non-essential extensions. Shouldn't the #C syntax be inessential also, since integer-only implementations are allowed? Shouldn't all productions with decimal points or slashes be inessential as well? (5) CL integers may optionally terminate in a decimal point; R^3RS permits such a number to be treated as floating point and it is debated whether it is to be considered exact. This is a serious problem, since many procedures are defined to accept only integer values. Is the call (INTEGER->CHAR 55.) valid? We propose that this be a non-essential feature in R^3RS. It seems to me that most procedures that are currently defined to accept only integer values should have been defined to accept only exact integer values. Our concept of an integer needs to be tightened up. I propose that INTEGER? be defined to be compatible with (define integer? (lambda (x) (and (real? x) (= x (truncate x))))) With a definition such as this it seems likely that 55. will be an integer. The real question is whether it is exact. I haven't been able to answer that question on the basis of the proposal. We propose the following syntax for numbers in Scheme. (Recall that letter case is insignificant in the grammar and that the rules for , , etc., should be replicated for R = 2, 8, 10, and 16.) --> | #c( ) --> --> --> | #i | #e --> #b --> #o --> | #d --> #x --> | + | - --> | | --> + #* --> + #* / + #* --> . + #* | + . * #* | + #* . #* --> | + I believe the + in the above production was intended to be +. --> e | f | d | l | s --> 0 | 1 --> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 --> | 8 | 9 --> | a | b | c | d | e | f Although we have incorporated and the use of `#' above, they should be stated to be non-essential features of Scheme. Nonessential feature: integers with optional decimal points. --> + #* . This production is redundant, since all the strings it generates are generated by the third production for . I judge by this and other redundancies that the name of the non-terminal is intended to carry semantic freight, but I can't tell what semantics is intended. This is my fundamental objection to the proposal: it is a syntax without a semantics. Nonessential feature: integers and ratios with exponents. --> + #* --> + #* / + #* Similarly the production above for is redundant, since it is exactly the same as the first production for . Nonessential number productions representing complex numbers. We worry that the forms +i and -i can be hard to parse. Perhaps combining the suffix `i' with the infix `+' or `-' would be palatable to those who want this feature. --> +i | -i | @ I'm not sure that this syntax is any easier to parse than the old syntax, but it isn't any worse. Regards, David Bartley Mark Meyer ------- Peace, Will Clinger  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 25 Jul 86 03:24:07 EDT Received: from ti-csl by csnet-relay.csnet id ab19183; 25 Jul 86 3:23 EDT Received: by tilde id AA27498; Fri, 25 Jul 86 00:40:16 cdt Date: Fri 25 Jul 86 00:35:05-CDT From: David Bartley Subject: Re: July 15 draft sent To: JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA, rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA In-Reply-To: <[AI.AI.MIT.EDU].71397.860716.JAR> Message-Id: <12225408585.58.BARTLEY@CSC60> I probably won't start another pass over it until a week from tomorrow (i.e. the 17th), so don't feel guilty if you don't send your remarks to me before that. After the 20th is when you can start feeling guilty. I received my copy of the new revision to the R^3RS yesterday (July 23) and enclose my detailed comments below (boy, do I feel guilty!). I am quite impressed overall with the current state of the document and want to commend Jonathan for the success of his efforts! Nearly all of my objections to the previous draft have been resolved satisfactorily. I will repeat below some that have not, but in general I am content to leave their resolution in JAR's hands. [page 1] I prefer to change "SCHEME" in the title to "Scheme", since it is not an acronym. [page 3] I prefer to change "Snobol" to "SNOBOL", since it IS an acronym. [page 4] [line 4, left col] Change "if the feature is not AS essential feature" to "if the feature is not AN essential feature". [line 21, left col] Change "for a call to the procedures" (plural) to "for a call to the procedure" (singular). [line 29, left col] Change "indicates that THE in" to "indicates that, in". [first bullet under 2.1] Remove the comma after "Certain identifiers". [page 5] [first paragraph of 2.2] Whitespace may also occur in the space character (denoted by "#\ "). [near the end of 2.3] You say that #T and #F are boolean CONSTANTs and that #\ introduces a character CONSTANT; shouldn't you say that #( introduces a vector CONSTANT also? [last 2 lines of 2.3] If my proposed number syntax is adopted, #S and #L will not exist. [last 2 lines, right col] Flush the "Note: ..."; I assume it is a note to yourself (?). [page 6] [section 3.2] Change "#fand" to "#f and". [paragraph 6, sec 3.2] Change "Note that THAT the" to "Note that the". [page 7] [last paragraph of sec. 4.1.3] Change "Note also that in many dialects..." to "{\em Note:} In many dialects...". [page 8] [line 6, right col] Shouldn't the notation ( => ) be listed as a non-essential syntax in the heading rather than buried as an implementation note in the body of the text? [last paragraph, right col] I was very happy with your use of {\em Syntax:} and {\em Semantics:} headers but they disappeared from AND onward. I guess you ran out of time... [page 9] [first paragragh, sec 4.2.2] There is a mysterious whitespace at the beginning of the fourth line of the paragragh. [description of LET*] Shouldn't you replicate the description of and ? You do for LETREC. Try to avoid the "widow" line for the heading of LET*. [last line, right col] Here, and elsewhere, you have incomplete sentences in which the subject is missing. This doesn't particularly offend me, and it seems to read well, so I see no reason to correct it right away... [page 10] [end of 4.2.4] The indenting for the "(LET LOOP ((NUMBERS ..." example has gone awry. [page 12] [end of 6.1] I'd like to see the example (EQ? NIL 'NIL) ==> #F added. This reinforces the wording in the last paragraph of the left column, which might be missed by someone looking only at the definition of NIL. [page 14] [last paragraph of the description of EQ?] Omit the words "instead of as a subroutine call". It seems to imply that anything other than a pointer comparison must be performed out of line, or that a pointer comparison would necessarily be performed in line. [page 17] [lines 10, 11 of left col] Omit the sentence: "It is questionable whether these features [slashification and uninterned symbols] are worth their complexity, so they are not standard in Scheme." This editorial comment is unnecessary and invites the response: "Then why is SYMBOL->STRING worth while?" [page 22] [sec 6.6] Clarify the sentence: "This rule resolves the ambiguous case ... the space character AS AS the ...". [page 30] [sec 7.1.2, syntax of numbers] I mailed out a proposal for a syntax of numbers compatible with Common Lisp last week but haven't received any feedback. Did it fail to make it to the mailing list or is it that non-controversial? [page 36] Try to avoid the "widow" line for the subtitle "EXAMPLE". [Index] Add #T and #F, and possibly #!TRUE and #!FALSE (page 12), to the index. Regards, David Bartley -------  Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 JUL 86 15:24:28 EDT Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 4905; Thu 24-Jul-86 15:13:30-EDT Date: Thu, 24 Jul 86 15:12 EDT From: Jonathan A Rees Subject: call-with-xput-port vs. call-with-xput-file To: rrrs-authors@MIT-MC.ARPA Message-ID: <860724151248.1.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU> Date: Mon, 14 Jul 86 11:47:21 est From: Kent Dybvig To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA Subject: call-with-xput-port vs. call-with-xput-file I favor changing call-with-input-file and call-with-output-file to call-with-input-port and call-with-output-port. However, I have some questions related to the change and to ports in general. 1. I saw lots of confusion over the fact that you open a file (with open-input-file and open-output-file) but close a port (with close- input-port and close-output-port). Changing the "call-with" names could increase the confusion. Should we change open-input-file and open-output-file to open-input-port and open-output-port? 2. I have added string ports to Chez Scheme and need to choose names. If we have call-with-...-file and open-...-file, I can introduce the names call-with-...-string and open-...-string. On the other hand, if we have call-with-...-port and open-...-port, I can introduce the names call-with-...-string-port and open-...-string-port. The names are longer but perhaps more descriptive. How do these names sound? The point of this question is that any names we choose should generalize to other types of ports. I see these two points (together with general conservatism) as arguments AGAINST changing the names. I am now inclined not to make the change. 5. Why is call-with-input-file essential and open-input-file not? This resulted from a general spirit of minimalism at the Brandeis meeting. The first is sufficient while the second isn't. Personally, I never use the second. If call-with-input-file is analogous to call-with-current-continuation, why do we not have (call-with-new-string ) instead of make-string or (call-with-pair ) instead of cons, etc? Because call-with-current-continuation is special---a function make-continuation would be problematic. In short, while I see the merit in with-input-from-file since it closes the file and rebinds a standard port, I cannot see the merit in call-with-input-file. The merit is that it makes certain that the port gets closed. If we had to deallocate resources and locks associated with allocated objects like strings, then I think it would be a good idea to have call-with things for those too. Jonathan.  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 JUL 86 20:56:23 EDT Date: Tue 22 Jul 86 20:41:50-EDT From: "Gerald Jay Sussman" Subject: title To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <12224830912.34.GJS@OZ.AI.MIT.EDU> I think that the current title -- R^4 and all -- is really nice. -------  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 22 Jul 86 18:11:14 EDT Received: from ti-csl by csnet-relay.csnet id al09489; 22 Jul 86 17:49 EDT Received: by tilde id AA28902; Tue, 22 Jul 86 15:46:53 cdt Date: Tue 22 Jul 86 15:37:57-CDT From: David Bartley Subject: Re: title wars To: JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA, CPH%ai.ai.mit.edu@CSNET-RELAY.ARPA Cc: rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA, Bartley%ti-csl.csnet@CSNET-RELAY.ARPA In-Reply-To: <[AI.AI.MIT.EDU].73822.860722.JAR> Message-Id: <12224786515.36.BARTLEY@CSC60> Date: Tue, 22 Jul 86 14:57:41 EDT From: Jonathan A Rees Date: Tue, 22 Jul 86 14:08:30 EDT From: Chris Hanson A minor note: I'd prefer that the word "Scheme" not be upper-cased in the report. While this is appropriate for an acronym like "ALGOL", it does not seem to be for "Scheme", which is not an abbreviation for anything. Rationale: I agree that "Scheme" generally shouldn't generally be in upper case, and I think that it's "Scheme" everywhere else in the report. However, I wanted to capitalize it in the title because this helps make it look like the Algol 60 report. I agree with Chris -- Scheme is a word, not an acronym. ALGOL is an acronym and should be written in all caps. If you want it to look EXACTLY like the Algol 60 report, name the language ALGOL! David Bartley -------  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 22 Jul 86 15:44:34 EDT Received: from ti-csl by csnet-relay.csnet id aa08670; 22 Jul 86 15:37 EDT Received: by tilde id AA23855; Tue, 22 Jul 86 13:40:20 cdt Date: Tue 22 Jul 86 13:32:20-CDT From: David Bartley Subject: Re: title wars To: JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA, rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA In-Reply-To: <[AI.AI.MIT.EDU].73688.860722.JAR> Message-Id: <12224763647.36.BARTLEY@CSC60> I have no real problem with leaving the title the way it is. Another alternative would be ``1986 Revised Report ...''. David Bartley -------  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 JUL 86 14:58:42 EDT Date: Tue, 22 Jul 86 14:57:41 EDT From: Jonathan A Rees Subject: title wars To: CPH@AI.AI.MIT.EDU cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 22 Jul 86 14:08:30 EDT from Chris Hanson Message-ID: <[AI.AI.MIT.EDU].73822.860722.JAR> Date: Tue, 22 Jul 86 14:08:30 EDT From: Chris Hanson A minor note: I'd prefer that the word "Scheme" not be upper-cased in the report. While this is appropriate for an acronym like "ALGOL", it does not seem to be for "Scheme", which is not an abbreviation for anything. Rationale: I agree that "Scheme" generally shouldn't generally be in upper case, and I think that it's "Scheme" everywhere else in the report. However, I wanted to capitalize it in the title because this helps make it look like the Algol 60 report.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 JUL 86 14:09:25 EDT Date: Tue, 22 Jul 86 14:08:30 EDT From: Chris Hanson Subject: title wars To: JAR@AI.AI.MIT.EDU cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 22 Jul 86 10:10:29 EDT from Jonathan A Rees Message-ID: <[AI.AI.MIT.EDU].73801.860722.CPH> A minor note: I'd prefer that the word "Scheme" not be upper-cased in the report. While this is appropriate for an acronym like "ALGOL", it does not seem to be for "Scheme", which is not an abbreviation for anything. I don't really feel strongly about this, I just thought I would point it out. BTW, if we *must* change the title, I vote for "Fourth Report...".  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 JUL 86 10:17:57 EDT Date: Tue, 22 Jul 1986 10:16 EDT Message-ID: From: HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: Jonathan A Rees Cc: rrrs-authors@MC.LCS.MIT.EDU Subject: title wars In-reply-to: Msg of 22 Jul 1986 10:10-EDT from Jonathan A Rees i like the title as it is.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 JUL 86 10:11:32 EDT Date: Tue, 22 Jul 86 10:10:29 EDT From: Jonathan A Rees Subject: title wars To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].73688.860722.JAR> The title I chose for the report is under siege. I guess this means we need to discuss what it should be. I think the complaint is that the superscript will pose typesetting and pronunciation problems for people who cite the report. But think of the hundreds of papers with "SL_2(R)" in their title. Oh well. The main thing that's important to me is that it be as similar as possible to "Revised Report on the Algorithmic Language ALGOL 60". Beyond that I don't much care. Here are other possibilities: - Dan Friedman has suggested "Revised Report on the Algorithmic Language SCHEME" but this could be confused much too easily with the "Revised Report on Scheme". - "Another Report on the Algorithmic Language SCHEME" (suggestive of YACC.) I sort of like this one. - "A Report on the Algorithmic Language SCHEME" - "Thrice Revised Report on the Algorithmic Language SCHEME" This raises fomatting problems, since without the "thrice" it's already as wide as it can be without deviating from the Algol report layout. - "Fourth Report on the Algorithmic Language SCHEME" This has the advantage that it makes the next version easier to name. "Report #4 on...", "The Next Report on ..." [imitative of "the next whole earth catalog"], ... or we could give the language a new name? no.  Received: from Godot.Think.COM by MC.LCS.MIT.EDU 21 Jul 86 16:10:31 EDT Received: from boethius by Godot.Think.COM via CHAOS; Mon, 21 Jul 86 15:12:23 edt Date: Mon, 21 Jul 86 15:13 EDT From: Guy Steele Subject: Re: Scheme's DO construct To: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA, rrrs-authors@MC.LCS.MIT.EDU Cc: gls@AQUINAS In-Reply-To: <8607152252.AA19578@tekchips.TEK> Message-Id: <860721151311.0.GLS@BOETHIUS.THINK.COM> Date: 15 Jul 86 15:52:52 PDT (Tue) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA ... It seems to me that if we truly want to discourage people from writing functional programs, a more effective way to do it would be to change Scheme so people can't program in the functional style until they master a set of arbitrarily chosen rules for inserting tokens like #' and FUNCALL into their programs. Heh, heh, heh. Well put, Will! --Guy  Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 21 Jul 86 12:40:47 EDT Received: from boethius by Godot.Think.COM via CHAOS; Mon, 21 Jul 86 12:36:35 edt Date: Mon, 21 Jul 86 12:37 EDT From: Guy Steele Subject: Scheme's DO construct To: andy@AIDS-UNIX.ARPA, rrrs-authors%mit-mc@AIDS-UNIX.ARPA Cc: gls@AQUINAS.ARPA In-Reply-To: <8607132227.AA23925@Zarathustra.Think.COM> Message-Id: <860721123716.3.GLS@BOETHIUS.THINK.COM> Well, you have constructed a great case based on anecdotal evidence, which is worth having, but I think you have not even addressed my main point. The other constructs you mentioned (FOR, REPEAT, and WHILE) have what I regard as an important flaw: a reliance on side effects to accomplish some part of the iterative process. There is seldom any use in stepping just one variable in an iteration; you want to step two or more. Because FOR, REPEAT, and WHILE (and for that matter DOLIST and DOTIMES) each step at most one variable, it is necessary to have some side effect in the body to get anything done. DO is the only iteration construct we have (other than LOOP) that encapsulates completely the notion of iteration: the iterative transformation of a state (normally a compound state, therefore consisting of two or more quantities) in such a way that an invariant is maintained at each step, terminated when the state satisfies some condition. The problem is not that DO has too many features, but that each of the other iteration constructs is incomplete in a way that must be patched up using side effects. I would be quite happy to eliminate one feature of DO: the body! If the body is used, then side effects are necessarily involved. The most perspicuous uses of DO have no body. The other problem with DO is that sometimes there is more than one reason to exit. I admit that as a flaw; but then again, sometimes there is reason to return more than one value from a function, and I believe SCHEME is not yet addressing that either with explicit features. (Having a body compensates somewhat for that: (defun memq (x l) (do ((z l (cdr z))) ((null z) nil) (when (eql x (car z)) (return z)))) This leads me to propose that a good iteration construct would be like DO but instead of having a body would have more COND clauses.) --Guy  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 JUL 86 11:01:29 EDT Date: Mon, 21 Jul 86 11:00:01 EDT From: Jonathan A Rees Subject: schedule To: ramsdell%linus@MITRE-BEDFORD.ARPA cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Mon 21 Jul 86 07:47:45 edt from ramsdell%linus at mitre-bedford.ARPA Message-ID: <[AI.AI.MIT.EDU].73291.860721.JAR> Date: Mon, 21 Jul 86 07:47:45 edt From: ramsdell%linus at mitre-bedford.ARPA I cannot keep up with your schedule. I received the July 15th draft on Friday afternoon, and did not have access to a computer until this morning. There is no way I could have gotten my reply to you by July 20th. Jeez, did I tell people to send me comments by the 20th? I meant to say that I won't be doing anything until the 24th, so don't kill yourself to get stuff to me before that. Within 5 days after the 24th would be very nice. The main guideline is this: the report must absolutely be in its final form before the Lisp conference; in fact, it probably has to be done by Thursday July 31, so that there's time to make zillions of copies of it to hand out at the conference. Jonathan  Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 21 Jul 86 07:39:53 EDT Organization: The MITRE Corp., Bedford, MA Received: from jymme.sun.uucp by linus.MENET (1.1/4.7) id AA02999; Mon, 21 Jul 86 07:38:54 EDT Posted-Date: Mon, 21 Jul 86 07:35:50 edt Received: by jymme.sun.uucp (2.0/SMI-3.0DEV3) id AA12384; Mon, 21 Jul 86 07:35:50 edt Date: Mon, 21 Jul 86 07:35:50 edt From: ramsdell%linus@mitre-bedford.ARPA Message-Id: <8607211135.AA12384@jymme.sun.uucp> To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA Subject: typos 1) [Page 5, col 2, line 8] atsign => at-sign. 2) [Page 5, col 2, line -1] The note seems out of place. I suggest deleting it. 3) [Page 5, col 1, line 19] #fand => #f and. 4) [Page 9, col 1, line 21] Odd indent. 5) [Page 10, col 2] Program example not indented correctly. 6) [Page 10, col 2, line -l] comma/at-sign/expression => comma at-sign expression OR comma-at-sign-expression. 7) [Page 12, col 2, line -14] In the phrase "equal? is the coarsest or most liberal", liberal has too many meanings; I suggest dropping the phrase "or most liberal". 8) [Page 20, col 1, line -20] rouding => rounding. 9) [Page 22, col 2, line -19] uppper => upper. 10) [Page 27, col 2] call-with-xxput-file => call-with-xxput-port. 11) [Page 38, col 1, ref 14] No page numbers. Wow! What an improvement! John  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 18 Jul 86 03:13:19 EDT Received: from tektronix by csnet-relay.csnet id af00418; 18 Jul 86 2:58 EDT Received: by tektronix.TEK (5.31/6.16) id AA19060; Thu, 17 Jul 86 15:26:12 PDT Received: by tekchips.TEK (5.31/6.16) id AA14145; Thu, 17 Jul 86 15:28:40 PDT Message-Id: <8607172228.AA14145@tekchips.TEK> To: brooks%tilde%TI-CSL.CSNET@CSNET-RELAY.ARPA Cc: rrrs-authors@MC.LCS.MIT.EDU Subject: Re: Substring & friends In-Reply-To: Your message of Wed, 16 Jul 86 11:01:18 cdt. <8607170501.AA05456@tekchips.TEK> Date: 17 Jul 86 15:28:38 PDT (Thu) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA An advantage of an inclusive and an exclusive is that (substring s 0 (string-length s)) is the entire string. If both were inclusive you'd have to say (substring s 0 (-1+ (string-length s))), which seems less convenient. Using (- x 1) instead of (-1+ x) makes it even harder to read. An aside on -1+: As Marianne Moore said, I too dislike it. I can't agree that it can't be pronounced, however, since I pronounce (-1+ x) as "the predecessor of x" or "one less than x". As Kent Pitman once pointed out, we can pronounce things however we like. (Kent wanted things like EQ? to be pronounced "eek-pee". I propose that EQ? be pronounced "eek-hunh?", with a rising inflection. Just kidding.) By the way, I don't care whether 1+ and -1+ go or stay; whatever Jonathan decides is fine with me. Peace, Will  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 17 Jul 86 17:39:23 EDT Received: from tektronix by csnet-relay.csnet id ah14030; 17 Jul 86 16:04 EDT Received: by tektronix.TEK (5.31/6.16) id AA02159; Thu, 17 Jul 86 09:42:29 PDT Received: by tekchips.TEK (5.31/6.16) id AA10005; Thu, 17 Jul 86 09:44:56 PDT Date: Thu, 17 Jul 86 09:44:56 PDT From: Norman Adams Message-Id: <8607171644.AA10005@tekchips.TEK> Subject: Re: Substring & friends To: Gary Brooks Cc: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: Gary Brooks , Wed, 16 Jul 86 11:01:18 cdt On the other hand and could be defined to both be inclusive. Now, I realize that there are probably too many instances of substring & friends running around, and that this would be incompatible with CL's subsequence, but I for one dislike the notion of (exclusive) indices that may not be (really) valid indices. Comments? Here's a comment: Currently, if given and , then = + ; whereas with inclusive indices = + - 1. I prefer to not have to adjust by 1 in index computations. -Norman -------  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JUL 86 15:00:16 EDT Date: Thu 17 Jul 86 13:09:44-EDT From: "Gerald Jay Sussman" Subject: Re: Substring & friends To: CPH@AI.AI.MIT.EDU, rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].71736.860717.CPH> Message-ID: <12223437888.36.GJS@OZ.AI.MIT.EDU> I agree with CPH about his choice of "half-open interval" representations of strings. I believe that the choice he made is pretty optimal because of good nesting and adjacency relations that are clear if one thinks abstractly. -------  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JUL 86 11:50:47 EDT Date: Thu, 17 Jul 86 11:50:46 EDT From: Chris Hanson Subject: Substring & friends To: brooks%tilde%TI-CSL.CSNET@CSNET-RELAY.ARPA cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Wed 16 Jul 86 11:01:18 cdt from Gary Brooks Message-ID: <[AI.AI.MIT.EDU].71736.860717.CPH> I object to changing the substring indexing scheme. I chose the imbalanced inclusive-start/exclusive-end pair because it has a some nice properties: 1. The pair for the entire string is (0, length(string)), which is trivially computable. 2. The pair for the empty string is (i, i) for any i <= length(string). There is no natural representation for this if both indices are inclusive. Don't think that no thought went into this. I know that on first encountering this scheme it seems unintuitive, but experience has shown it to be quite effective, and once learned, easy to remember. I don't think that the issue of whether or not the end index is a valid index for the string is very interesting. In practice, it is easy to decide whether a given index pair is valid: 0 <= start <= end <= length(string)  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 16 JUL 86 22:21:14 EDT Date: Wed, 16 Jul 86 22:21:24 EDT From: Jonathan A Rees Subject: July 15 draft sent To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].71397.860716.JAR> Today I US-mailed another draft to everyone (except GLS, KMP, and people at MIT, who I'll get to Thursday or Friday, or who can steal them from my desk). It is closer to done than the previous one was, but note that it does NOT reflect any changes in number syntax, LOAD, or names of call-with-*put-port. There are a few other things I didn't get to, which I can't recall right now, but I'm confident that y'all will miss them and tell me. I probably won't start another pass over it until a week from tomorrow (i.e. the 17th), so don't feel guilty if you don't send your remarks to me before that. After the 20th is when you can start feeling guilty. Jonathan  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 16 Jul 86 16:22:46 EDT Received: from ti-csl by csnet-relay.csnet id bn04187; 16 Jul 86 15:40 EDT Received: by tilde id AA19590; Wed, 16 Jul 86 11:21:40 cdt Date: Wed 16 Jul 86 10:53:32-CDT From: David Bartley Subject: Re: number syntax To: JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA Cc: rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA, Bartley%TI-CSL.CSNET@CSNET-RELAY.ARPA In-Reply-To: <860710120911.5.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU> Message-Id: <12223161873.35.BARTLEY@CSC60> > Date: Thu, 10 Jul 86 12:09 EDT > From: Jonathan A Rees > > Date: Tue 17 Jun 86 16:00:31-CDT > From: David Bartley > > One irritant in the Report that we have neglected to comment on until > now (sorry!) is the syntax of numbers. We believe that Scheme numbers > are essentially equivalent to Common Lisp numbers except for the new > notion of exactness. To the extent that that is so, it seems to be a > (shudder!) ``gratuitous difference'' from Common Lisp to have an > incompatible syntax. [...] > > What we'd like to see is an essential syntax for numbers which is > compatible with Common Lisp's. Additional features, including > exactness, would be optional extensions. Even so, they should not > conflict with Common Lisp. For example, the use of `#s' and the order > of and are different in the two languages. [...] > > Does anyone agree with us? Is there time to make such a change before > R^3RS goes to press? > >I think everyone agrees with you, and that there is time. Could you >please write a concrete proposal, preferably something close to being >suitable for inclusion in the report. Also please provide BNF. Thanks. > >Jonathan Here's a stab at it---we expect and welcome debate over the details. The major differences between the syntax of numbers in Common Lisp (CL) and heretofore in Scheme (R^3RS) are: (1) CL has the prefix denoting base precede the sign; R^3RS has the sign precede the prefix, which includes the base specifier. I see no reason to differ from CL. (2) CL uses several exponent markers to specify levels of precision for floating point numbers; R^3RS specifies precision levels (S and L) in the prefix. Again, why differ from CL? (3) CL does not provide for the use of `#' to indicate insignificant digits. Making this a non-essential feature in R^3RS seems reasonable. (4) CL provides only the #C(real real) notation for complex numbers; R^3RS provides infix notations for both polar and rectangular forms. For compatibility with CL, R^3RS should support the #C notation and the infix forms should be non-essential extensions. (5) CL integers may optionally terminate in a decimal point; R^3RS permits such a number to be treated as floating point and it is debated whether it is to be considered exact. This is a serious problem, since many procedures are defined to accept only integer values. Is the call (INTEGER->CHAR 55.) valid? We propose that this be a non-essential feature in R^3RS. (6) CL integers and ratios are not permitted to have exponent markers. This feature should be a non-essential extension to Scheme. (7) CL does not have the concept of exactness. Most (all?) existing implementations of Scheme do not support this feature, so it should be non-essential. We propose the following syntax for numbers in Scheme. (Recall that letter case is insignificant in the grammar and that the rules for , , etc., should be replicated for R = 2, 8, 10, and 16.) --> | #c( ) --> --> --> | #i | #e --> #b --> #o --> | #d --> #x --> | + | - --> | | --> + #* --> + #* / + #* --> . + #* | + . * #* | + #* . #* --> | + --> e | f | d | l | s --> 0 | 1 --> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 --> | 8 | 9 --> | a | b | c | d | e | f Although we have incorporated and the use of `#' above, they should be stated to be non-essential features of Scheme. Nonessential feature: integers with optional decimal points. --> + #* . Nonessential feature: integers and ratios with exponents. --> + #* --> + #* / + #* Nonessential number productions representing complex numbers. We worry that the forms +i and -i can be hard to parse. Perhaps combining the suffix `i' with the infix `+' or `-' would be palatable to those who want this feature. --> +i | -i | @ Regards, David Bartley Mark Meyer -------  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 16 Jul 86 16:21:33 EDT Received: from ti-csl by csnet-relay.csnet id aq04187; 16 Jul 86 15:26 EDT Received: by tilde id AA18614; Wed, 16 Jul 86 11:01:18 cdt Date: Wed, 16 Jul 86 11:01:18 cdt From: Gary Brooks To: rrrs-authors@MC.LCS.MIT.EDU Subject: Substring & friends As stated in the R^3 Report, the documentation for the and indices for substring & friends is consfused. The report states that and must be valid indices (with <= ). This is certainly not the case if you are taking the substring of an entire string, where the index for must be one greater than the largest valid index. The previous report, RRRS, included a paragraph explaining that is inclusive and is exclusive, which is clearer though still inconsistant with the documentation for substring. This inconsistency should be rectified. On the other hand and could be defined to both be inclusive. Now, I realize that there are probably too many instances of substring & friends running around, and that this would be incompatible with CL's subsequence, but I for one dislike the notion of (exclusive) indices that may not be (really) valid indices. Comments? -- brooks  Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 16 Jul 86 00:05:50 EDT Date: Tue, 15 Jul 86 21:03:00 PDT From: jleech@sun6.ads (Jay Leech) To: rrrs-authors@MC.LCS.MIT.EDU Subject: the rrrs authors Cc: andy@sun3.ads.ARPA Myself and a couple of others on the rrrs-authors mailing list were associated with AI & DS. We have changed our company name to Advanced Decision Systems, and our arpanet address should now be ads or ads-unix. Also, good work! I am looking forward to the publication of the report. -- Jay Leech  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 JUL 86 23:19:19 EDT Date: Tue, 15 Jul 86 23:19:07 EDT From: Jonathan A Rees Subject: rrrs-authors To: adams%tekchips.tek.csnet@CSNET-RELAY.ARPA cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 15 Jul 86 14:30:07 PDT from Norman Adams Message-ID: <[AI.AI.MIT.EDU].70741.860715.JAR> Date: Tue, 15 Jul 86 14:30:07 PDT From: Norman Adams To: jar at AI.AI.MIT.EDU Re: rrrs-authors Message-Id: <8607152130.AA18643@tekchips.TEK> Who is on the rrrs-authors list? I'm just curious ... -N Here's the current membership of the list. It's pretty much the same people as were on the SCHEME mailing list before it was opened up to the general public. - Jonathan ;;; -*- Mode:LISP; -*- ;;; Authors of the Revised^3 Report on the Algorithmic Language Scheme ;;; To be added or deleted, send mail to SCHEME-REQUEST. ;;; Sorted alphabetically by name of institution, and alphabetically ;;; within institution, except for MIT, which appears first. (file [LSPMAI;RRRS MAIL]) ;Local archive file (SCHEME-RRRS MIT-OZ) ;Oz people ;;; Also on SCHEME-TEAM (LS.SRB EE) (cherian vx) YEKTA ;Yekta Gursel JAR ;? (katz vx) (alco vx) (CPH AI) ;;; Others ALAN NICK ;Nick Papadakis RHH ;Bert Halstead Daniel ;Daniel Weise RDZ ;Ramin Zabih ;;; Non-MIT (jleech aids-unix) ;AI & DS / Jay Leech (william aids-unix) ; William Bricken (andy aids-unix) ; Andy Cromarty (wand%northeastern CSNET-Relay) ;Brandeis / Mitch Wand (dyb%indiana CSNET-Relay) ;Indiana / Kent Dybvig (scheme-rrrs%indiana CSNET-Relay) ;Indiana / ... (linus!ramsdell Mitre-Bedford) ;MITRE / John Ramsdell ("#COMSCH.MSG[SCH,LSP]" SU-AI) ;Stanford / File archive (ANDY SU-SUSHI) ; Andy Freeman (RPG SU-AI) ; Dick Gabriel KMP ;Symbolics / Kent Pitman (adams%tekchips%tektronix csnet-relay) ;Tektronix / Norman Adams (willc%tekchips%tektronix csnet-relay) ; Will Clinger (Scheme-Local%TI-CSL CSNET-Relay) ;TI / ... GLS ;TMI / Guy Steele (patel CS.UCLA.EDU) ;UCLA / Dorab Patel (Hudak Yale) ;Yale / Paul Hudak (Kelsey Yale) ; Richard Kelsey (Kranz Yale) ; David Kranz (Philbin-Jim Yale) ; Jim Philbin  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Jul 86 21:07:47 EDT Received: from tektronix by csnet-relay.csnet id aa14951; 15 Jul 86 20:49 EDT Received: by tektronix.TEK (5.31/6.16) id AA29117; Tue, 15 Jul 86 15:50:33 PDT Received: by tekchips.TEK (5.31/6.16) id AA19578; Tue, 15 Jul 86 15:52:54 PDT Message-Id: <8607152252.AA19578@tekchips.TEK> To: rrrs-authors@MC.LCS.MIT.EDU Subject: Re: Scheme's DO construct Date: 15 Jul 86 15:52:52 PDT (Tue) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA There are two things to be said in defense of Scheme's DO: 1. Unlike most general purpose iteration constructs, DO is useful for functional programming. 2. DO is the only general purpose iteration construct in Scheme that doesn't force you to think up a name (such as LOOP) for the loop. This is a long message, but the two points above are the gist of it. It seems to me that Andy has missed the first point entirely, considering his remarks that: I have no prima facie objection to the use of iterative constructs, and in particular, none to supporting iteration in Scheme. Indeed, I think that it is often very effective to think procedurally and iteratively rather than functionally and recursively. (I understand these are apples and oranges, but the styles are usually associated with each other.) ... I have performed the following informal experiment. I had one or two of the people working with me who were true devotees of LOOP and DO go back and recode fairly large (5000-15000 lines) LISP programs, ripping out LOOP and DO and putting in DOLIST, DOTIMES, and mapping functions. I should say that they did it "kicking and screaming," not because of the work involved but because they so loved all the features that LOOP offered. LOOP is indefensible, but Andy is mistaken to lump DO with LOOP. If by "mapping functions" Andy here means the standard Scheme mapping functions, then MAP is the only functional alternative to DO that Andy offered his people. MAP isn't general enough to replace DO, and DOLIST, DOTIMES, and FOR-EACH are completely useless for functional programming. Thus it seems that in the name of style Andy was coercing his people to convert functional programs that use DO into non-functional programs. It seems to me that if we truly want to discourage people from writing functional programs, a more effective way to do it would be to change Scheme so people can't program in the functional style until they master a set of arbitrarily chosen rules for inserting tokens like #' and FUNCALL into their programs. Let's consider the functional alternatives to DO using a simple example. The example is not too simple; it cannot easily be written using Scheme's standard mapping procedures. (Aside: In the example, SEQUENCE is a procedure, not a special form, so this is not portable Scheme code. The name SEQUENCE was meaningful to my audience, so I used it anyway. As I recall the discussion at Brandeis, SEQUENCE as a special form was supposed to disappear over time so we could use the name for such higher purposes, and I was very disappointed that the recent vote was phrased as a referendum on dropping BEGIN rather than on dropping SEQUENCE.) The example is: (define find-word-break (lambda (x k2) (do ((x x (rest x))) ((or (empty? x) (not (break? (first x)))) (do ((x x (rest x)) (word '() (concat word (sequence (first x))))) ((or (empty? x) (break? (first x))) (k2 word x))))))) The most straightforward elimination of DO yields: (define find-word-break (lambda (x k2) (letrec ((loop1 (lambda (x) (if (or (empty? x) (not (break? (first x)))) (letrec ((loop2 (lambda (x word) (if (or (empty? x) (break? (first x))) (k2 word x) (loop2 (rest x) (concat word (sequence (first x)))))))) (loop2 x '())) (loop1 (rest x)))))) (loop1 x)))) This code is rather forbidding, so I would probably define loop1 and loop2 in a single LETREC. That works in this case but would not work if a variable introduced by the outer DO were free within the inner DO. REC or NAMED-LAMBDA would improve the code a little. Can Scheme do better? I could instead use named LET, which would have the advantage of moving the initialization expression for each loop variable into proximity with its binding, and would make some of the LAMBDAs invisible: (define find-word-break (lambda (x k2) (let loop1 ((x x)) (if (or (empty? x) (not (break? (first x)))) (let loop2 ((x x) (word '())) (if (or (empty? x) (break? (first x))) (k2 word x) (loop2 (rest x) (concat word (sequence (first x)))))) (loop1 (rest x)))))) This version still has two disadvantages: (1) I had to think about (or avoid thinking about!) the names LOOP1 and LOOP2; and (2) it is hard to find the new bindings for the loop variables. The way to overcome these disadvantages is to invent a new special form that moves the expressions that compute the new values for the loop variables next to their bindings (Dick Gabriel has already pointed out the value of doing this) and to suppress the names of the loops; in other words, to invent DO. Having invented DO, we still have to decide on its syntax. The syntax of Scheme's DO is less than optimal for functional programming primarily because it is designed to support an additional feature: you can insert non-functional statements to be executed every time around the loop. Because Scheme is not a purely functional language, this is a reasonable feature to support; even I use it on occasion. Unless we can come up with a significantly better syntax, we might as well enjoy the advantages of Lisp tradition and compatibility, while fixing any randomness (as we did by flushing the implicit binding of RETURN and by using binding instead of assignment for the loop variables). I could go on and talk about why functional loops such as the ones you write using tail recursion or DO are easier to understand than imperative loops such as the ones you write using DOTIMES, DOLIST, FOR-EACH, or Andy's straw FOR, VARYING, REPEAT, or WHILE, but I don't think it's necessary for this audience. Peace, William Clinger  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 JUL 86 12:51:31 EDT Date: Tue, 15 Jul 86 12:51:27 EDT From: Jonathan A Rees Subject: convergence To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].70360.860715.JAR> Apparently we could go on forever thinking of and arguing over ways to improve the language. If you have changes you want considered for the SIGPLAN version of the report, please send them right way (actually, send them in several months ago). Otherwise PLEASE just sit on them for a while, and when this report is out, then let's start discussing the next version. For now, orient your messages towards achieving stability. If you want perfection then nothing will ever get published. And, as they say in the soaps, I need to get on with my life. Thanks Jonathan  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Jul 86 00:56:33 EDT Received: from indiana by csnet-relay.csnet id ak05326; 15 Jul 86 0:49 EDT Date: Mon, 14 Jul 86 21:47:54 est From: Kent Dybvig To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA Subject: exp versus expt We have a way to find an exponent of e (exp n) and of an arbitrary base (expt b n). We have a function to find the log base e (log n) but not the log in an arbitrary base. How about adding (log n b)? Why do we have (expt b n)? We could instead give exp an optional argument specifying the base, i.e., (expt b n) => (exp n b). Why is it not done this way in Common Lisp, as it is for log? Perhaps because the argument order would seem backwards? Kent  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Jul 86 00:56:25 EDT Received: from indiana by csnet-relay.csnet id aj05326; 15 Jul 86 0:48 EDT Date: Mon, 14 Jul 86 21:34:01 est From: Kent Dybvig To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA Subject: the colon (:) in identifier syntax Can we omit colon (:) from the enumeration of characters that can be used in identifiers, to allow implementations to support some sort of package system using colon as the separator?  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 14 Jul 86 19:42:14 EDT Received: from indiana by csnet-relay.csnet id ac02754; 14 Jul 86 19:26 EDT Date: Mon, 14 Jul 86 11:47:21 est From: Kent Dybvig To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA Subject: call-with-xput-port vs. call-with-xput-file I favor changing call-with-input-file and call-with-output-file to call-with-input-port and call-with-output-port. However, I have some questions related to the change and to ports in general. 1. I saw lots of confusion over the fact that you open a file (with open-input-file and open-output-file) but close a port (with close- input-port and close-output-port). Changing the "call-with" names could increase the confusion. Should we change open-input-file and open-output-file to open-input-port and open-output-port? 2. I have added string ports to Chez Scheme and need to choose names. If we have call-with-...-file and open-...-file, I can introduce the names call-with-...-string and open-...-string. On the other hand, if we have call-with-...-port and open-...-port, I can introduce the names call-with-...-string-port and open-...-string-port. The names are longer but perhaps more descriptive. How do these names sound? The point of this question is that any names we choose should generalize to other types of ports. 3. Currently, there is no way to change the current ports to anything other than a freshly-opened file (as with the inessential with-input- from-file and with-output-to-file). Stylistically, I think it is better to never change the standard ports. But if they can be changed, I'd like to have a way for a debugger, say, to change them back to an existing file (usually the original current ports), so that anything the user executes goes to the expected place. Without this we cannot hope to write a reliable portable debugger (and debug code with calls to with-input-from-file or with-output-to-file). 4. Also, there is no way to change the current ports permanantly. That is, it is not possible to write (set-current-input! ) or (set-current-output! ). Again, I don't think this is good practice, but some might rue the inability to do so. 5. Why is call-with-input-file essential and open-input-file not? If call-with-input-file is analogous to call-with-current-continuation, why do we not have (call-with-new-string ) instead of make-string or (call-with-pair ) instead of cons, etc? Because call-with-current-continuation is special---a function make-continuation would be problematic. In short, while I see the merit in with-input-from-file since it closes the file and rebinds a standard port, I cannot see the merit in call-with-input-file. Can we flush call-with-input-file and call-with-output-file and promote open-input-file and open-output-file to essential status?  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 14 Jul 86 18:59:35 EDT Date: 14 Jul 86 1557 PDT From: Dick Gabriel Subject: Politics To: rrrs-authors@MC.LCS.MIT.EDU Naturally I'm not pissed at Andy. Were I truly pissed, and truly flaming, my message would have begun, ``Andy, you total and complete bagbiter, you are such a big loser that they had to extend the city limits to include....'' My point was that I could imagine someone forwarding Andy's vitriol to Common-Lisp or ARPA-BBOARDS and thereby lose some allies that we, who are Scheme lovers one and all, would prefer to not lose if at all possible. Someday I'd like Lucid to be the ``most successful and best-known supplier of Scheme products,'' on that happy day when Common Scheme becomes the standard. Homage, an item of low cost to the RRRS-authors, buys a lot from the Common Lisp troops. Messages like Andy's, keyboard-in-cheek as they may be, possibly buy more grief than the fun of typing them gains. Politics and science are not so radically removed from each other. When one propose some technical viewpoint, his goal is to have it accepted, usually before he dies. Having his viewpoint accepted helps his self-esteem, his quest for fame as a scientist, his reach for tenure. This isn't much different from politics, in which the goals are probably self-esteem, fame, and a reach for office. Although there may be more technical content to a technical debate, the tactics used in arguing for a political end really don't differ significantly. This design committee should aim at producing the best possible Lisp. If that happens to mean that nothing in it is like the corresponding thing in Common Lisp, that's fine. All technical debate regarding these choices should be open. If nothing in Scheme is like the corresponding thing in Common Lisp simply because Common Lisp is bad, and disjointness is a goal, then I think this design committee will have blown it. ******************************** On a related note, now that there has been a fair bit of experience with Common Lisp, it might be worthwhile for this group to ask some of the Common Lisp hackers about their experience with the parts of Common Lisp that the Schemers find objectionable. Similarly, it might be instructive to look at what the Common Lisp hackers find nice about Common Lisp that might be surprising. -rpg-  Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 14 Jul 86 17:33:32 EDT Date: Mon, 14 Jul 86 14:31:19 PDT From: andy@sun3.ads.ARPA (Andy Cromarty) To: rrrs-authors%mit-mc@ads.arpa Subject: Scheme vs. Common Lisp, #1: Politics Cc: andy@ads.arpa, gls%think@ads.arpa, rpg%su-ai@ads.arpa Reply-To: andy@ads.arpa This is the first of two notes on CommonLisp vs. Scheme. I have written two notes in an attempt to separate political concerns from design concerns, in part to keep them clear in my own mind and in part in consideration of those of you who, like me, generally have neither the time nor the temperment for long political debates on the ARPANET. This note concerns the politics, or what I think of (perhaps a little unkindly) as the "form rather than the content" of the CL-Scheme issue. Those of you who stick it out and read through this note (and the ones that are sure to follow) should bear in mind that, as we've already seen, politics is necessarily a somewhat more personal discipline than is the technology most of us are really interested in, and for that reason writing styles for the political notes can be expected to differ from those composed with primarily technical purposes in mind. asc ------------------------------------------------------------------------ Shortly after receiving Dick's flame, the following scenario popped into my head. You are listening in on a phone conversation somewhere in Arlington, Virginia. Squires: Clint, I hear a rumor that Andy Cromarty is concerned about CommonLisp's influence on the development of Scheme. Kelly: Scheme? Squires: Yes, another kinky LISP dialect being designed by some researchers. It only has a fraction of CommonLisp's features and they can't quite seem to decide what it should look like. Kelly: Well, Steve, I guess I'll have to ask you to simply rescind DARPA's support for CommonLisp, then, and from now on we'll require all our AI projects to use Structured COBOL. I suppose I should be flattered at the suggestion that a few sentences from me would reshape the course of LISP history, especially coming as it does from Dick Gabriel. But somehow I give the research funding community and the commercial tool market a little more credit for indepedence of thought than this scenario (or Dick's note) suggests. Perhaps more importantly, I am somewhat troubled by the idea that Dick would advocate censorship of ideas and opinions concerning LISP design and development (viz. his instructions that we "Don't let anyone outside this list see Andy's message."). My assumption is that the RRRS-AUTHORS list exists for the purpose of supporting "open discussion within a closed community" concerning what form Scheme should take, and that we all implicitly agree to attempt to ground our argumentation for our favored alternative views on a substantive technical basis. In this regard, I probably agree with the suggestion that my comment "represents a low point in political thinking." I think the implied converse option -- that we all need to suppress concern or public discussion about the *costs* of CL compatibility, or for that matter, any other dangerous thoughts we might have -- represents a new high water mark in politicization of the Scheme design process, and I would not feel complimented to be accused of having set that new standard. Certainly there are others in the Scheme community with whom I disagree, but I cannot imagine proposing (for example) that we censor Dan Friedman because his ideas about internal DEFINE differ from mine. Quite the contrary: I look forward to hearing why alternative views are held; and when I decide I can't stand the heat, *I* get out of the kitchen. But yes, please don't repeat my messages outside this community. I think we all assume that our discussions are held reasonably private by this community, since this is still a design-in-progress, and at the present I'm sensitized by having been poorly quoted a little too often in the press recently. (And anyway, if anyone at DARPA wants to know what I think of CL, they have my phone number.) Now let's take a good hard political look at who disagreed most vocally with my comment. The few responses I've received so far all have been from competent LISP designers and implementors, to be sure. But it is also true that they have been from: the implementor(s) of Texas Instruments' Common Lisp and Scheme products; the author of the premier Common Lisp text; and the president of the most successful and best know Common Lisp product company in the world. In addition, many or most of these people were personally involved in the Common Lisp design effort. Their credentials are impeccable, but their goals and commitments may not be the same as those of, say, a professor who is using Scheme for its pedagogical value and has no career or financial stake per se in the long-term viability or political acceptance of this year's best production quality LISP environment. I certainly believe that having their views represented is critical to a good Scheme's development, and I made it clear in my original note that I do consider myself to be an outlying point in the distribution of views on CL vs. Scheme. But I think they are, too; and let us not assume that the most vociferous advocates of extreme positions (myself included) represent either the norm or the best compromise position to take. Since Dick couldn't see from his location down the street that my tongue was towards the side of my mouth when I used the term "dark forces," let me say that (a) I think Common Lisp is one of the most successful technology results of any standardization committee I've seen and (b) my reference was to the risk of Scheme becoming just like Common Lisp, rather than a criticism of the quality of Common Lisp as a LISP. Overall, Common Lisp is very good at being what it tries to be. I am utterly unconvinced that that's what Scheme is trying to be, however. I will treat the question of the goals of the two languages in my companion note, but for now suffice it to say that the idea that these languages have (forgive the pun) common goals strikes me as nonsensical. If that were true, we could submit Guy's excellent book to SIGPLAN and retire this list. I might go so far as to say that it is precisely because Scheme exists that Common Lisp can be successful, in the following sense: Those of us who are concerned with what LISP should look like for the next several decades can preoccupy ourselves with design debates over Scheme morality, while people like Dick and Guy go on to take a snapshot of what the community knows about good LISP design and then integrate that knowledge, addressing and overcoming all the political obstacles along the way, to produce a viable, saleable LISP product. And good luck to them; but I do not see that Lucid's chimeras need to be ours. Rather than worry that people will learn that there is more than one LISP, let's advertise the fact. Let's make it clear that LISP is an ideal language for embedding new constructs in, and that the presence of a good heavily-featured standardized dialect has not quenched the long-standing historical drive for LISPers to remain at the forefront of programming language and programming environment design. Let's advocate a plethora of LISP-like languages to get people out of the Pascal-derivative language design syndrome and instead get them directly and cleanly addressing individual hard language design problems, like the keyword shadowing problem, design of appropriate multiprocessing constructs, embedding of evidential reasoning techniques into a programming language, integration of advanced database technology into the programming environment in a coherent fashion, getting distributed inheritance graphs to work across loosely-coupled processors, and (somebody, please!) developing a reasonable model of I/O. Let's get them thinking that LISP is not dead, that it is not a "solved problem," that it's there to experiment with, and that there are and will continue to be good reasons for all the debates we engage in on how languages should be designed. asc p.s. Dick, if you're still pissed off at me, we can go out for dinner at the LISP conference and you can throw darts at me.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 14 Jul 86 16:33:54 EDT Date: 14 Jul 86 1332 PDT From: Dick Gabriel Subject: Use of DO in Common Lisp Code To: rrrs-authors@MC.LCS.MIT.EDU I looked at a spectrum of code in the Lucid implementation of Common Lisp to see how DO is used where DOLIST and DOTIMES could not be used. The breakdown of use of iteration is this: the frequency of use of DO is the same as the use of DOTIMES and DOLIST combined the use of LABELS/FLET is used as often as DOLIST. The uses of DO in place of DOTIMES and DOLIST are interesting. Sometimes the stepper is not CDR, so the use of DO is exactly like DOLIST, but with the stepper (and end test) different; typically: (DO ((current data-structure (next-data current))) ((empty-data current)) ...) Sometimes the use is exactly like DOLIST, but the test is different. (DO ((l l (cdr l))) ((end-test l)) (let ((x (car l))) ...)) But the most frequent use (by a margin of 3 to 1) is a combination of DOTIMES and DOLIST: (do ((l l (cdr l)) (i 0 (1+ i))) ((null l)) (let ((x (car l))) ...)) The use of DO outside of these paradigms is almost non-existent. Hairier control structures are usually done with LABELS/FLET, and there are 3 large ATN's in the implementation, written with (glarg) TAGBODY. One principle of Lisp design that DO follows is that the binding of the iterator, its initial value, and its updator are apparent immediately upon inspection - they are usually on one line. This principle is the basis of (LET ((x value)) ...) being preferred to ((lambda (x ...) ...) value ...): X and VALUE are not near each other on the page. I don't have a proposal to make, but this data might be of use in thinking about iteration in Scheme. -rpg-  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 JUL 86 13:09:07 EDT Date: Mon, 14 Jul 86 13:08:53 EDT From: Jonathan A Rees Subject: [ANDY: dedication] To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].69636.860714.JAR> Date: Mon 14 Jul 86 02:09:08-PDT From: Andy Freeman To: jar at AI.AI.MIT.EDU Re: dedication Message-ID: <12222563967.24.ANDY@sushi.STANFORD.EDU> Has everyone else forgotten that Knuth dedicated his series to a 650 at case? -andy  Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 14 Jul 86 10:41:54 EDT Organization: The MITRE Corp., Bedford, MA Received: from jymme.sun.uucp by linus.MENET (1.1/4.7) id AA19058; Mon, 14 Jul 86 10:41:36 EDT Posted-Date: Mon, 14 Jul 86 10:38:32 edt Received: by jymme.sun.uucp (2.0/SMI-3.0DEV3) id AA07736; Mon, 14 Jul 86 10:38:32 edt Date: Mon, 14 Jul 86 10:38:32 edt From: ramsdell%linus@mitre-bedford.ARPA Message-Id: <8607141438.AA07736@jymme.sun.uucp> To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA Subject: Common Lisp I certainly qualify an no fan of Common Lisp, however, I too would like to point out a simple argument against gratuitous incompatibilities with Common Lisp. Scheme's impact will be limited if it is very difficult to convert CL code to Scheme, even if many agree it is a superior language. The best way to port CL to Scheme is in an environment that supports both languages. To me, Scheme would be an excellent language in which to implement Common Lisp. A Scheme implementation of Common Lisp would facilitate the conversion of CL code by allowing versions the program to be written in a mixture of both languages. Let's not make a Scheme implementation of Common Lisp such a pain that no one will do it. John  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 14 Jul 86 09:41:16 EDT Received: from ti-csl by csnet-relay.csnet id aa01646; 14 Jul 86 9:37 EDT Received: by tilde id AA09613; Mon, 14 Jul 86 08:20:24 cdt Date: Mon 14 Jul 86 08:11:52-CDT From: Don Oxley Subject: Re: Compatibility with Common Lisp: A meta comment To: RPG%su-ai@CSNET-RELAY.ARPA, rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA In-Reply-To: Message from "Dick Gabriel " of Sat 12 Jul 86 18:35:00-CDT Message-Id: <12222608155.17.OXLEY@CSC60> I must second Dick Gabriel's reply. A little "friendly rivalry" with Common Lisp is fine, but the ultimate acceptance of Lisp (of either dialect) is the crucial concern. I am probably as biased toward Scheme as anyuone, but if Scheme is to succeed, it will owe a significant debt to Common Lisp. --Don -------  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 14 Jul 86 06:25:26 EDT Received: from tektronix by csnet-relay.csnet id aa01226; 14 Jul 86 5:49 EDT Received: by tektronix.TEK (5.31/6.16) id AA28438; Sun, 13 Jul 86 10:01:39 PDT Received: by tekchips.TEK (5.31/6.16) id AA21626; Sun, 13 Jul 86 10:04:09 PDT Date: Sun, 13 Jul 86 10:04:09 PDT From: Norman Adams Message-Id: <8607131704.AA21626@tekchips.TEK> Subject: Flaws of form To: rrrs-authors@MC.LCS.MIT.EDU I would prefer to see no dedication in preference to making the dedication serious. I think a serious dedication would read as insincere because the Scheme report is an obvious parody of the Algol 60 report. As much for my asusement as for anything else, I wrote this explanation: The Algol 60 report is gravely earnest. Among its many firsts, Algol was first to use a grammar-like construct to define its syntax. The first report -- "Preliminary report - International Algebraic Language" -- as well as the revision, were published as cover stories in the @i(Communucations of the ACM) (*). The report was the culmination of an international effort, followed with international attention. In the style of world war commentary, the reader learns of the Zurich meeting, the Paris meeting, and of the seven European representatives who held a final prepatory meeting in Mainz in December 1959. And let us not forget the seven American representatives with a similar quest, in Boston that same year. We are spared the details of the lunch meats; judged, with Ph.D. precision I am certain, to be expendable from the accounting. In each re-reading, I look (in vain) for the mention of Teller and Oppenheimer; surely they were involved too. It is in this intensely sober context that we read the full page eulogy of William Turanski (**), who died after being struck by a car the day before the 1960 conference in Paris. (*) CACM v1 #12, 1958; CACM v6 #1, 1963 (**) CACM v3 #5, 1960, p 298 Scheme is fun and happy, and a bit quirky -- or are CDR and CAR and so many relatives the ideal names for those procedures? Scheme is as serious as LAMBDA, but as casual as CAR. Alas, what has become of dear PROGN? The names are arbitrary and incidental; CAR and CDR remind us. Scheme is as much an approach as a detailed concrete specification. But to be taken seriously, for Scheme to be widely used, we must have the details and concretions; they are essential but unimportant. The Algol 60 report is almost ludicrous in its sobriety. If we use the form of Algol 60 to present happy little Scheme, we cannot avoid the parody; try as we might. Still, I think there is good reason to use the form. Presenting Scheme in the form of the Algol 60 report may capture the attention of those who clump together and ignore all Lisp-like languages because the culture is so different from what they know. The contrast with @i(Chine Nual) and @i(CLtL) is important. Perhaps Lisp can be other than a bag of features of a metastasizing runtime environment. Perhaps it can even be described in the style of the day! Following the model of Algol 60 exactly points out that the form of description is itself an arbitrary convention; and the point is made in perfect Scheme style. Just as Scheme can provide the "their" control constructs, it can be described in "their" form. The parody pokes fun at all those essential but unimportant details. It is the perfect couch for Scheme. So for all this, I find a serious dedication inappropriate. Algol 60's dedication was grave; to an Algol soldier, killed in his prime (he was 35). Scheme's dedication should be to something unimportant. "Dedicated to the memory of dynamic binding.", as Jonathan once suggested, fits well. It seems to me so much better than to try to be as somber and important as Algol 60. I think we would look foolish in the attempt. -Norman -------  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 14 Jul 86 05:52:54 EDT Received: from tektronix by csnet-relay.csnet id aa01226; 14 Jul 86 5:49 EDT Received: by tektronix.TEK (5.31/6.16) id AA28438; Sun, 13 Jul 86 10:01:39 PDT Received: by tekchips.TEK (5.31/6.16) id AA21626; Sun, 13 Jul 86 10:04:09 PDT Date: Sun, 13 Jul 86 10:04:09 PDT From: Norman Adams Message-Id: <8607131704.AA21626@tekchips.TEK> Subject: Flaws of form To: rrrs-authors@MC.LCS.MIT.EDU I would prefer to see no dedication in preference to making the dedication serious. I think a serious dedication would read as insincere because the Scheme report is an obvious parody of the Algol 60 report. As much for my asusement as for anything else, I wrote this explanation: The Algol 60 report is gravely earnest. Among its many firsts, Algol was first to use a grammar-like construct to define its syntax. The first report -- "Preliminary report - International Algebraic Language" -- as well as the revision, were published as cover stories in the @i(Communucations of the ACM) (*). The report was the culmination of an international effort, followed with international attention. In the style of world war commentary, the reader learns of the Zurich meeting, the Paris meeting, and of the seven European representatives who held a final prepatory meeting in Mainz in December 1959. And let us not forget the seven American representatives with a similar quest, in Boston that same year. We are spared the details of the lunch meats; judged, with Ph.D. precision I am certain, to be expendable from the accounting. In each re-reading, I look (in vain) for the mention of Teller and Oppenheimer; surely they were involved too. It is in this intensely sober context that we read the full page eulogy of William Turanski (**), who died after being struck by a car the day before the 1960 conference in Paris. (*) CACM v1 #12, 1958; CACM v6 #1, 1963 (**) CACM v3 #5, 1960, p 298 Scheme is fun and happy, and a bit quirky -- or are CDR and CAR and so many relatives the ideal names for those procedures? Scheme is as serious as LAMBDA, but as casual as CAR. Alas, what has become of dear PROGN? The names are arbitrary and incidental; CAR and CDR remind us. Scheme is as much an approach as a detailed concrete specification. But to be taken seriously, for Scheme to be widely used, we must have the details and concretions; they are essential but unimportant. The Algol 60 report is almost ludicrous in its sobriety. If we use the form of Algol 60 to present happy little Scheme, we cannot avoid the parody; try as we might. Still, I think there is good reason to use the form. Presenting Scheme in the form of the Algol 60 report may capture the attention of those who clump together and ignore all Lisp-like languages because the culture is so different from what they know. The contrast with @i(Chine Nual) and @i(CLtL) is important. Perhaps Lisp can be other than a bag of features of a metastasizing runtime environment. Perhaps it can even be described in the style of the day! Following the model of Algol 60 exactly points out that the form of description is itself an arbitrary convention; and the point is made in perfect Scheme style. Just as Scheme can provide the "their" control constructs, it can be described in "their" form. The parody pokes fun at all those essential but unimportant details. It is the perfect couch for Scheme. So for all this, I find a serious dedication inappropriate. Algol 60's dedication was grave; to an Algol soldier, killed in his prime (he was 35). Scheme's dedication should be to something unimportant. "Dedicated to the memory of dynamic binding.", as Jonathan once suggested, fits well. It seems to me so much better than to try to be as somber and important as Algol 60. I think we would look foolish in the attempt. -Norman -------  Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 13 Jul 86 18:29:06 EDT Date: Sat, 12 Jul 86 19:07:07 PDT From: andy@sun3.ads.ARPA (Andy Cromarty) To: rrrs-authors%mit-mc@ads.arpa Subject: Scheme's DO construct Cc: andy@ads.arpa, gls%think@ads.arpa Reply-To: andy@ADS.arpa Hmm, I seem to have generated some controversy. I'll attempt to provide clarifications and responses separately on each topic to help keep the discussions distinct. I'll start with "DO." ------------------------------------------------------------------------ I cannot refrain from observing that DO is truly ugly.... [asc] I strongly disagree. DO is a construct that emphasizes the notion that an iteration can proceed by initializing some state variables and then repeatedly transforming them while maintaining some invariant until a condition is reached. ... [gls] I think Guy misguessed the source of my displeasure with DO. So I'll clarify. (Warning: not a short message.) I have no prima facie objection to the use of iterative constructs, and in particular, none to supporting iteration in Scheme. Indeed, I think that it is often very effective to think procedurally and iteratively rather than functionally and recursively. (I understand these are apples and oranges, but the styles are usually associated with each other.) There may be interesting extremist arguments in favor of relying solely on recursion for repetition, presumably based on strict minimalism and some arguments concerning the elegance of recursion. But I probably wouldn't buy them, and in any case that's not what my complaint is about. If we were going to be minimalism extremists, we wouldn't provide IF, COND, and CASE in the same language. Instead, I think we are trying to design an effective programming environment while remaining "reasonably" elegant. The touchstone for the appropriate degree of minimalism is that we provide the constructs that a programmer will need, separating functionality out when the programmer's abstraction of the control process is different (as opposed to merely the underlying computation being different; hence CASE, IF, and COND). So given the assumption that we are going to have one or more iteration constructs, what should they look like and how should we select them? My claim is that the DO we are using is a poor choice, and moreover, that it probably reflects a correspondingly poor choice in selection criteria. In a nutshell, DO does too much. It creates variables, binds them, provides iteration, rebinds variables at tactically pleasing times, tests a conditional expression, applies an implicit SEQUENCE to most of its arguments, returns the result of evaluating an optionally present expression... whew! I submit that we have CommonLisp's DO (which is in use in other LISPS too, of course) principally because it was being used by other LISPs and no one really stopped to think what a good iteration construct for Scheme would look like starting from first principles. We just grabbed what (some) (LISP) programmers currently are using without treating this as an important design problem. I also submit that DO is too complex and that this complexity violates two fundamental principles of good programming language construct design: 1. Keep constructs simple so people can learn, understand, read, debug, and maintain them easily. 2. Each function should do one thing, and do it well. (No pun intended.) Just to take a few pot shots at DO: we don't need variable binding and creation, since we already have the LET family to do that nicely for us. We don't need to confuse conditional exit from an iteration (i.e. using a predicate expression) with FOR-class iteration that occurs, e.g., a predictable number of times and/or over a predictable set of values. Certainly it's nice to have all these things around when you want them; my point is simply that an iteration construct doesn't need to provide all of them, that we can make intelligent choices about which ones a given construct is to provide, and that if DO needs to contain all of them, then the burden of proof is on those who would make that claim. To reframe the challenge, the question is not whether you can come up with times when you need conditional exit, and times when you need FOR-style iteration, and... etc.; but rather, whether you can convincingly demonstrate that all are needed in one iteration construct that appears in the language definition. Let me pose a few alternatives. Bear in mind that these are strawman options, for illustrative purposes. If you don't like keywords in your control constructs, imagine the examples without them. (FOR i IN DO ) -- Evaluates , to which an implicit SEQUENCE is applied, with i bound to successive values of . [This is like FOR-EACH except that you have the current value bound to a lexically apparent locally-created locally-bound variable i. This is about as similar to FOR-EACH as, say, COND and CASE are to each other.] (VARYING i FROM n TO m BY s DO ) -- Binds i to n, n+s, n+2s, ... and evaluates , to which an implicit SEQUENCE is applied, for each such binding, until i>m. Returns the result of the last evaluation of . [This is the classic FOR-loop construct used when you know the range of values in advance, e.g. when you are stepping through a vector.] (REPEAT n TIMES ) -- Evaluates , to which an implicit SEQUENCE is applied, n times. Returns the result of the last evaluation of . [Not frequently used, but highly perspicuous on those occasions when this is exactly what you want to do.] (WHILE DO ) -- Repeatedly evaluates , to which an implicit SEQUENCE is applied, until evaluates to #F, like Pascal's WHILE. [There's some interesting research by Jeff Bonar, among others, with empirical results suggesting that Pascal's WHILE loop is actually a dangerous, hard-to-learn construct. This is because (a) the classic phase problem that occurs when you use a WHILE loop in a PROCESS,READ paradigm is harder to learn than the more intuitive READ,PROCESS model, and (b) beginners often think that WHILE really means "while," i.e. "whenever is true, do " or "the moment would become false, exit the loop." I also dislike the cooption of this word for this iterative processing application, since its more intuitive meanings actually might be useful in concurrent processing applications. In any case, when not used in a PROCESS,READ paradigm, the construct (whatever its name) is often quite useful.] Hmm, that's a lot of extra stuff in a language to take the place of one DO construct, isn't it? But that's precisely the point. DO is a microcosm of MacLisp's and, by inheritance, Common Lisp's invasive featurism. In the extreme, we could create a function F(x) and specify which entire program we wanted simply by feeding F the proper number. Many people would regard such a Goedlization of programs as a positive step, if only they could determine which number to feed F. But: we wouldn't call it programming; we wouldn't call F a "control construct" in the sense that we normally use the word; and perhaps most importantly, we wouldn't know how to meaningfully specify the x. Forgiving the hyperbole, that is also true of DO: it is an expert's construct with options sticking out all over and no coherent design principles underneath, hard to learn and remember and even harder to read and understand quickly on sight. I have performed the following informal experiment. I had one or two of the people working with me who were true devotees of LOOP and DO go back and recode fairly large (5000-15000 lines) LISP programs, ripping out LOOP and DO and putting in DOLIST, DOTIMES, and mapping functions. I should say that they did it "kicking and screaming," not because of the work involved but because they so loved all the features that LOOP offered. But a couple weeks later, they came back and said: "You know, LOOP is really evil!" "My code is infinitely easier to read and maintain now." "I had no idea how ugly and impenetrable all that DO and LOOP code was from all those `features' of DO and LOOP I was using." "You have to have something seriously wrong with your head to be able to use DO fluently." "I'm not going to use LOOP again!" I should say that the principal guy I have in mind here got his degree at MIT. We're talking the hardest of sells, and when the dust had cleared, he came to the conclusion that DO and LOOP are morally reprehensible. We need to remember that programs are written not only to be executed, but also to be read; and that well over 50% of programmer time is spent maintaining existing code. Clear, clean, well-designed control constructs can go a long way towards easing this burden. DO does not seem to qualify as such a construct; rather, it seems like the incidental union of numerous such constructs. We might be able to make a major contribution to the utility of LISP in "practical" programming applications by updating Scheme's iteration constructs so they provide better, cleaner, more direct support for the variety of iteration models that are already implicit in the code we write. asc  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 12 Jul 86 21:37:07 EDT Date: 12 Jul 86 1835 PDT From: Dick Gabriel Subject: Compatibility with Common Lisp: A meta comment To: rrrs-authors@MC.LCS.MIT.EDU Andy Cromarty comments that it is ``the very act of being concerned with compatibility at all that is gratuitous.'' I regard it as lucky that this message only went to RRRS-authors, because it represents a low point in political thinking. Although I am not an active participant in the Scheme design, many of you know that I use Scheme in my teaching, my research papers, and my research. When put on the spot regarding the future of Lisp - in any forum - I point to Scheme as the hope for the future. However, I regard myself as a member of the Common Lisp community, and I had a fair amount to do with its design and acceptance. When I read Andy's message I felt insulted. Perhaps someone less sympathetic to the Scheme movement would be completely turned away from Scheme by reading his message. If Andy wants to battle the dark forces, they are indeed lined up at the perimeter. To the vast audience, Common Lisp and Scheme are indistinguishable. The alternative is C. If Lisp cannot make a go of it because other languages are seen as `better,' there will be less interest in learning Lisp, and fewer people will be able to see the beauty of Scheme. The battle is to win people over to `lisp programming,' which in its best clothes is Scheme programming. To an outsider, a `gratuitious' difference between Common Lisp and Scheme is seen as evidence that the Lisp world is too religious to understand real-world concerns. Unless there is a compelling reason to vary from Common Lisp, I think compatibility is wise. The Common Lisp community has learned and is learning a lot about how people are won over to a new standard, and this community has many members who are Scheme lovers. Perhaps it is a smart move to avoid alienating them with comments like Andy's? Perhaps the Scheme community would like to enlist the aid of the large Common Lisp community in advocating Scheme? Don't let anyone outside this list see Andy's message. -rpg- ps. To be a pissant about it. I guess Andy feels that, because the goals of Common Lisp were nearly the opposite of Scheme's, the goals of Scheme are to be: non-common non-portable inconsistent inexpressive incompatible inefficient not powerful unstable Common Lisp's goals were not bad. They were the stated ones, plus several others: gain support among competing dialects, gain advocates from the commercial Lisp programming world, and develop compromises among enemies. The stated goals plus these three are such that we are lucky that the result is as reasonable as it is.