Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 11 Jul 86 14:42:04 EDT Received: from ti-csl by csnet-relay.csnet id ab20493; 11 Jul 86 14:24 EDT Received: by tilde id AA08236; Fri, 11 Jul 86 11:05:52 cdt Date: Fri 11 Jul 86 10:59:37-CDT From: David Bartley Subject: Re: My comments on the R^RS To: andy%sun3.ads@CSNET-RELAY.ARPA, jar%mit-mc%ads@CSNET-RELAY.ARPA Cc: rrrs-authors%mit-mc%ads@CSNET-RELAY.ARPA, Bartley%ti-csl.csnet@CSNET-RELAY.ARPA In-Reply-To: Message from "Andy Cromarty " of Fri 11 Jul 86 04:08:40-CDT Message-Id: <12221852261.67.BARTLEY@CSC60> >Date: Thu, 10 Jul 86 12:39:26 PDT >From: Andy Cromarty > [...] >2. As you might expect, I would like to see a somewhat more vigilant > attitude in warding off the dark forces of Common Lisp. It is not > compatibilities or incompatibilities that are gratuitous; it is > the very act of being concerned with compatibility at all that is > gratuitous. ... I feel that this point of view is not in Scheme's best interest. Although many potential converts to Scheme are unsullied by contact with lesser lisps, others must either be won away from Common Lisp or must live with both. Gratuitous differences in syntax and in the naming of standard procedures make it much more difficult for them to give Scheme a fair trial. Also, many of us are working on implementations in which Scheme and Common Lisp programs want to share data and call each other. Gratuitous differences in the data types and in the syntax of numbers (for example) can make this very frustrating. I fear that Scheme will usually be the one that loses if a development team decides the two languages are not sufficiently compatible. > ... We should have our own standards of what a good LISP > looks like and stick to them. The first job of a good language is > to be a good language, not to be just like another bad language > that's familiar (nor even just like another good language that's > familiar). Common Lisp's goals were nearly the opposite of > Scheme's, and however good a job the CL committee did, we owe them > no homage. ... Although a certain amount of compromise is necessary in agreeing on what is "gratuitous", it certainly is true that any compromise that changed Scheme from a "good" language to a "bad" one would not be gratuitous. > ... I recognize that this is more an issue of the design > of Scheme than of its documentation in a report, but there seems > to me to be entirely too much concern for similarities and > dissimilarities w.r.t. Common Lisp in the report. It may be > appropriate to discuss the topic of Scheme vs. CL briefly in the > historical section, but there should be a very clear message to the > reader that CL followed Scheme -- and continues to, in the sense > that Scheme is meant to be a progressive attempt at (LISP) language > design rather than a codification and standardization of existing > ideas in prior LISPs. The CL people should be writing reports > that compare their work to ours, not the other way around. ``Let > them eat cake.'' [OK, flame off.] I think we've all agreed that explicit references to Common Lisp in the Report should be minimized. Regards, David Bartley -------  Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 11 Jul 86 12:21:28 EDT Received: from botolph by Godot.Think.COM via CHAOS; Fri, 11 Jul 86 12:18:24 edt Date: Fri, 11 Jul 86 12:19 EDT From: Guy Steele Subject: My comments on the R^RS To: andy@sun3.ads.ARPA, jar%mit-mc@ads.ARPA Cc: rrrs-authors%mit-mc@ads.ARPA, gls@AQUINAS.ARPA In-Reply-To: <8607101959.AA12928@Zarathustra.Think.COM> Message-Id: <860711121914.1.GLS@BOTOLPH.THINK.COM> Date: Thu, 10 Jul 86 12:39:26 PDT From: andy@sun3.ads.ARPA (Andy Cromarty) Jonathan, I've enclosed my comments on the R^3RS in this note separately from my answers to your specific questions you asked. Hope this helps. By the way, I know that putting this all together involves a lot of work (and sometimes a lot of refereeing), and you should be aware that your contribution isn't going unappreciated. Thanks for all the hard work you're putting in, and my apologies in advance if I err here due to an insufficiently detailed reading of the report. Hear, hear! ... 2. As you might expect, I would like to see a somewhat more vigilant attitude in warding off the dark forces of Common Lisp. It is not compatibilities or incompatibilities that are gratuitous; it is the very act of being concerned with compatibility at all that is gratuitous. We should have our own standards of what a good LISP looks like and stick to them. The first job of a good language is to be a good language, not to be just like another bad language that's familiar (nor even just like another good language that's familiar). Common Lisp's goals were nearly the opposite of Scheme's, and however good a job the CL committee did, we owe them no homage. I recognize that this is more an issue of the design of Scheme than of its documentation in a report, but there seems to me to be entirely too much concern for similarities and dissimilarities w.r.t. Common Lisp in the report. It may be appropriate to discuss the topic of Scheme vs. CL briefly in the historical section, but there should be a very clear message to the reader that CL followed Scheme -- and continues to, in the sense that Scheme is meant to be a progressive attempt at (LISP) language design rather than a codification and standardization of existing ideas in prior LISPs. The CL people should be writing reports that compare their work to ours, not the other way around. ``Let them eat cake.'' [OK, flame off.] [a] I think that many papers on Common Lisp have correctly attributed its debt to Scheme. [b] I disagree that concern with compatibility is gratuitous. Perhaps that concern should be subordinate to other concerns, but when everything else is truly equal then compatibility is a reasonable criterion for breaking ties. This is because it is better to be able to tie a feature to something already familiar than to make a user learn something new. [c] There should be a very clear message to the reader that Scheme certainly does owe debts to other sources, and one of them is Common Lisp. While Scheme certainly has been the pioneer in the treatment of closures and functional programming in a Lisp framework, I think it is fair to say that Common lisp pioneered a rational (forgive the pun) treatment of numeric data types in a Lisp framework, and my impression is that Scheme learned something in this area from the Common Lisp experience. [d] Don't forget that there are some people who worked on both Scheme and Common Lisp at the same time (I do not count myself as one, by the way), to whom I am grateful because they learned certain lessons in both contexts at once and served to transfer ideas in both directions. 12. I cannot refrain from observing that DO is truly ugly, a veritable pig of a construct, and we could have done better. We are indeed fortunate that its use under practical circumstances is rarely necessary. 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. In particular, it emphasizes the fact that outputs of the iteration as well as inputs can and should be expressed as iterator-controlled variables. This is a lesson that the "algebraic" languages ought to learn. It is an abomination to see sum = 0 do i = 1 to 10 by 1 sum = sum + a(i) end do instead of do i = 1 to 10 by 1; sum = 0 by a(i); result sum od 23. NOTES, p.35ff.: This material should stay somehow. We need to make it clear that R^3 Scheme is not being touted as Yet Another Ultimate Solution To The Programming Language Problem, but rather as a snapshot of a *process* of good design, for which not all answers have yet been found. We also ought to use the opportunity for publicity afforded us by SIGPLAN to advertise some of the thorny unsolved problems that need further research, and encourage language designers to work on them. Yes. --Guy  Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 10 Jul 86 18:30:06 EDT Date: Thu, 10 Jul 86 15:31:12 PDT From: andy@sun3.ads.ARPA (Andy Cromarty) To: jar%mit-mc@ads.arpa Subject: My answers to your thirty questions on R^RS Cc: rrrs-authors%mit-mc@ads.arpa Jonathan, Here is my list of answers to the specific report-related questions you posed to the group. I've only answered the ones I have strong opinion on. 1. The presence of BEGIN in Scheme is frankly somewhat of an embarrasment. It really should be flushed, but politically it's probably too late. Still, I vote (b). 2. Keep the >? forms. All predicates should end in ? for uniformity. This kind of consistency is much more important for pedagogical purposes than is similarity to CL, Pascal, or any other existing language. 4. Substring-move-*: flush. I think I have simple Scheme definitions for these, if anyone needs them once they're flushed. 5. Simply make it clear that evaluation order is unspecified (and should not be depended on); to guarantee sequential evaluation of a collection of combinations, use SEQUENCE. 7. Port = port. Safer that way. 11. Yes, PROCEDURE? would be welcome. 12. (if x 1) vs. (cond ((x 1)): I suggest (if x 1) => 1 iff x, else (cond ((x 1))) => 1 iff x, else (case (not (not x)) ((#t) 1)) => 1 iff x, else This follows the general principle that if you fall off the end of a control construct, the results are not guaranteed. If you want a guaranteed return value in your program, you specify one using ELSE or the two-armed IF as appropriate; that's what they're there for. This should be phrased to say that ``it is an error'' to rely on the result of a control construct that returns an result. 13. Flush (define ((((a b) c) d) e) ...) syntax. 14. To me, INCLUDE means "include." If we want the effect to be equivalent to having the loaded text be lexically present, INCLUDE is an excellent name, and helps avoid some of the concerns people have had about what it means to have a dynamic programming environment for a lexically scoped language. I would, however, want to see a resolution to such problems as (IF X (INCLUDE "FOO")) If this evaluation depends on the dynamics of the binding environment, then "LOAD" is more appropriate. INCLUDE would have to be a non-expression statement, e.g. the above example would only be syntactically correct if "FOO" happened to contain exactly one or two expressions at the top level of the file, and the INCLUDE would always get performed regardless of X's value. 21. One-based sections. 24. I guess some people don't like to type and have bad editors, or maybe bad pretty-printers. CALL/CC is scarcely an intuitive name; its chief virtue seems to be the number of characters it contains. But it seems to be regionally entrenched; keep it "informally optional" to the standard CALL-WITH-CURRENT-CONTINUATION if necessary. (It will not appear in our Scheme implementations.) 26. FORCE and DELAY are new ideas to most readers of the report, at least for its SIGPLAN incarnation. Good pedagogy suggests they be put together if possible. 27. Yes for () in 3.0.2. 30. I thought the question of immutable objects was lightly treated overall. Rather than remove the reference on p. 14 SS 5.1, I'd prefer to see more detail, and perhaps (a) something explicitly noting that set-car! and set-cdr! are destructors (or mutators if you prefer) and (b) the explicit assertion that destructors end in ``!'' in Scheme. ------------------------------------------------------------------------ Other topics: -1+ : I prefer to see this kept, in inessential status. When I first saw it, it struck me as the first time any LISP had gotten this right. It says exactly what it means. Better no decrement function at all, however, than using "1-" to mean decrement; "1-" says exaactly what it *doesn't* mean. Since there was a complaint, I might suggest ``minus one plus'' as the pronunciation for "-1+", as in "minus one plus 3" for (-1+ 3) (or "negative one plus three," if you prefer). I scarcely find SUCC pronounceable in any socially acceptable way, and it certainly doesn't seem to me to be a serious alternative. WHEN: This probably seems like a good idea to people who don't do concurrent programming. When you deal with time in your programs, ``when'' already has a confusing enough meaning without overloading it to mean IF. For that matter, a couple years from now we may want to use WHEN for event management. S&ICP: I do not know what it means to (as one person admonished) ``fix the book''; in particular, I don't know how you recall thousands of copies. Independent of the quality of the presentation and choices reflected in S&ICP, which I admit to admiring tremendously, I believe that this book has done more for Scheme than any other single force in Scheme's history, and I believe we should endeavor to support a Scheme compatible with it. Most of my colleages who own the book have it because they were interested in obtaining a good book on LISP or a good book on programming, and to a person every one with whom I've spoken agrees that it is probably the best available for both purposes. Let's not kill the goose that lays our golden eggs.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 10 Jul 86 16:09:15 EDT Received: from indiana by csnet-relay.csnet id ah09559; 10 Jul 86 15:54 EDT Date: Thu, 10 Jul 86 14:06:35 est From: Perry Wagle To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA Subject: Re: Remaining questions & remarks (2) Cc: wagle%iuvax.indiana.edu@CSNET-RELAY.ARPA (2) <, >, etc are composed solely of "special symbols", and classically are predicates. With this view in mind, perhaps the exception is not so big as naive application of Occam's Razor would suggest. I support essential <, >, etc, and the removal of their "xxx?" counterparts. (5) Many otherwise portable Scheme programs would die under unrestrained interleaving. I claim that a Scheme should have the semantics of a single logical processor no matter what the underlying architecture is. I think that mention of parallelism should be left out altogether, as any mention would call for ad hoc measures (synchronization primitives? bleagh!), and restraint to a "single logical processor" is probably an obituary (within ten years or so?). (7) I would like to guard input and output commands with INPUT-PORT? and OUTPUT-PORT? respectively. I think closed ports SHOULD be ports, but not input or output ports; I support the predicate: PORT?. (11) I would very much like PROCEDURE? and consider continuation objects to be procedures. While appealing, I don't support APPLICABLE? as it would be the only type predicate that doesn't name the type its checking for. (12) I oppose one-armed IFs. I've been happy with WHEN and UNLESS that return NIL when the condition isn't met. (14) I have "meta"-procedures that invoke LOAD. I *demand* that you not cut my arms and legs off for "esthetic reasons". (15) I think that *all* ASCII characters should be "legibly typable" (e.g. #\null, etc), but then I only run on ASCII machines.  Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 10 Jul 86 15:38:51 EDT Date: Thu, 10 Jul 86 12:39:26 PDT From: andy@sun3.ads.ARPA (Andy Cromarty) To: jar%mit-mc@ads.arpa Subject: My comments on the R^RS Cc: rrrs-authors%mit-mc@ads.arpa Jonathan, I've enclosed my comments on the R^3RS in this note separately from my answers to your specific questions you asked. Hope this helps. By the way, I know that putting this all together involves a lot of work (and sometimes a lot of refereeing), and you should be aware that your contribution isn't going unappreciated. Thanks for all the hard work you're putting in, and my apologies in advance if I err here due to an insufficiently detailed reading of the report. asc ------------------------------------------------------------------------ 1. I am concerned that we have multiple conflicting goals in the design of the document. Sometimes it is a reference manual, and sometimes it is a technical report, and sometimes it is a users' guide. Perhaps we must live with this if there is to be only one report, but it might be a good idea to try to separate out (say) the history from the reference manual parts. This is reflected in the discussions about moving or removing the history section, for example. 2. As you might expect, I would like to see a somewhat more vigilant attitude in warding off the dark forces of Common Lisp. It is not compatibilities or incompatibilities that are gratuitous; it is the very act of being concerned with compatibility at all that is gratuitous. We should have our own standards of what a good LISP looks like and stick to them. The first job of a good language is to be a good language, not to be just like another bad language that's familiar (nor even just like another good language that's familiar). Common Lisp's goals were nearly the opposite of Scheme's, and however good a job the CL committee did, we owe them no homage. I recognize that this is more an issue of the design of Scheme than of its documentation in a report, but there seems to me to be entirely too much concern for similarities and dissimilarities w.r.t. Common Lisp in the report. It may be appropriate to discuss the topic of Scheme vs. CL briefly in the historical section, but there should be a very clear message to the reader that CL followed Scheme -- and continues to, in the sense that Scheme is meant to be a progressive attempt at (LISP) language design rather than a codification and standardization of existing ideas in prior LISPs. The CL people should be writing reports that compare their work to ours, not the other way around. ``Let them eat cake.'' [OK, flame off.] 3. On p.2 you list me as a Brandeis participant. Would that it were true. I will leave to your judgement whether I should be listed in the acknowledgements, as an author, or otherwise. 4. I agree with both your observations on the Syntax section (0.1) -- that it makes sense to have one there and that it isn't clear what it should say. Perhaps a fairly terse or brief description of Scheme's simple syntax would do, e.g. The syntax of Scheme, like that of most LISPs, provides for great expressive power, largely due to its simplicity. An important consequence of this simplicity is the susceptibility of Scheme programs and data to uniform treatment by other Scheme programs. As with other LISPs, the ``read'' function actually parses its input; that is, it performs syntactic as well as lexical decomposition of what it reads, rendering input in a uniform internal representation and making it particularly easy to manipulate Scheme programs and data in a correspondingly direct and uniform fashion. Scheme employs a parenthesized-list Polish notation to describe programs and (other) data, with lists recursively defined as being composed of lists and what are sometimes referred to as ``atomic'' objects (numbers, symbols, etc.) \foot{Unlike most LISPs, Scheme does not explicitly provide a predicate for assessing atomicity, although it does contain predicates for determining whether an object is a list, symbol, number, etc.} The syntax of Scheme expressions is described formally in greater detail later in this report. 5. Identifiers & keywords: Sections 1.0 and 2.0 gave me pause, because I have been concerned for some time with the keyword problem in Scheme (and I admit to being dissatisfied with the most common solution). The statement ``Any identifier which is not a syntactic keyword may be used as a variable....'' which appears in both sections implies that there are keywords in the language, although (a) there aren't guaranteed to be and (b) you haven't said anything previously about keywords in the document. The astute reader will then turn to the index to find out what she has missed, only to discover that there is no entry at all for keywords. Later on there is a discussion of keywords, but it is essentially an afterthought, and by now the reader may have decided that Scheme really is Pascal after all (Andrew, bite your tongue). Something needs to be done to clear up the potential confusion from the initial presentation of identifiers vs. keywords. The inline "Note:" on p.6 probably does not serve to clarify things as much as it might. 6. P. 6, SS 2.0: Yes, mention that there are no guarantees that a ``top-level'' exists. (Then encourage the rest of the RRRRS authors read that paragraph....) 7. SS 2.1, p.6 implies that there are other values besides #f that count as false. Except for the optional #!false, I'm not sure I see what these are. Perhaps you count things like (NOT #T) as false for the purposes of this section? 8. p. 7, SS3.0.2 -- Typo at bottom of page, ``combinations. .'' 9. p.7 SS 3.0.2: It may not be clear to non-LISPophiles what ``+`` evals to, or why ``+'' gets evaluated in the example (+ 3 4) => 7 ((if #f + *) 3 4) => 12 The idea of a function name evaluating to a functional object will not be intuitive for most readers, who probably think in languages that don't have first-class procedures. Perhaps something can be done to make this clearer. 10. There are a few minor report points that reflect major underlying problems we really have yet to solve in the design of Scheme, involving things like COND, IF, and perhaps LET. The syntax definitions provided earlier on in the report make (COND ((X))) a legal expression, and we've already had the n-armed IF argument. Similarly, (LET () (DOSOMETHING)) is legal, although perverse and not obviously useful. (The latter expression actually appears in the report, at the top of p.10 col2, although I can see no reason to have used it -- the example would have worked fine without it.) I think what has happened is that we never resolved the issue of ``functions'' that don't return values. Instead we developed, or permitted the random evolution of, a hodgepodge of mutually inconsistent local solutions: DEFINE is not an expression, IF may (or may not) have an undefined return value, (COND ((X))) returns (X), etc. We still have design work to do. 11. On a related syntax (or is it design?) point, on p.9, SS3.1.0, the expression (CASE TEST (() (FOO))) is permitted. It's not clear to me why we want to permit this, nor what it means if we do. Strictly, it would always be ignored, in which case it's spurious. Similarly, (CASE TEST) is legal; strictly it returns but seems senseless nonetheless. 12. I cannot refrain from observing that DO is truly ugly, a veritable pig of a construct, and we could have done better. We are indeed fortunate that its use under practical circumstances is rarely necessary. 13. The Note: on p.11 about DO in which you describe assignment vs. rebinding is guaranteed to be lost on the majority of readers. An example of how it differs from other LISPs' DO might help. 14. On p.12 where QUASIQUOTE is introduced, as a purely typographic observation, we really need a better backquote character. It's very hard to read the character at all in the copy of the report I have, especially at that point size. At first glance I thought in all honesty that it was a speck of ink on my copy. (I believe my hardcopy came from MIT, although its route was sufficiently mysterious that it might have been printed at Berkeley instead.) 15. SS 4.0 talk about the ``top level,'' as if there is one; cf. my point #6 above. 16. SS 4.1, p.12, first sentence: I find this ambiguous: Definitions are not valid in all contexts where expressions are allowed; they are only valid at the top level [sic] of a and at the beginning of a lambda body. This could mean any of several things, e.g.: Definitions are invalid in all contexts where expressions are allowed (i.e. there are no contexts in which definitions are valid where expressions are allowed).... or Definitions are invalid in some contexts where expressions are allowed (i.e. there exist contexts where expressions are allowed but wherein definitions are not allowed).... This probably needs to be rephrased for people who don't already know what it's trying to say. 17. Top of p.13 col1: You have ``(. ) would be understood to mean simply .'' Why permit this? It offers no additional functionality and strikes me as an unclean misfeature. 18. p.14, SS 5.1: Misspelling, ``distint'' => ``distinct''. 19. p.17, SS5.2: Misspelling, ``decsription'' => ``description''. 20. Predicates: As far as I could see, we never actually commit to putting ``?'' at the end of predicates, although we do mention on p.18 that functions like ASSV don't end in ``?'' because they aren't predicates. This convention would be a good thing to assert. (It also would blow the people who dislike >? out of the water, I'm afraid.) 21. p. 18, SS 5.3, First sentence: ``entirely'' is massive overstatement here. There are lots of bases for the utility of symbols -- like their use as printable undoublequoted objects, which seems to me to have been lost almost entirely [sic] on the Scheme community (hence the rejection of upper/lower case distinction). (Incidentally, CommonLisp also gets control of UC/LC terribly wrong, to my eternal annoyance when I build distributed multiprocessing mostly-LISP-based systems that want to communicate by passing case-varying symbol tokens instead of strings.) 22. p.28, SS 5.8: What happened to TeX in the middle of column 2 where it says ``The escape procedure''? Misplaced manual linebreak, perhaps. 23. NOTES, p.35ff.: This material should stay somehow. We need to make it clear that R^3 Scheme is not being touted as Yet Another Ultimate Solution To The Programming Language Problem, but rather as a snapshot of a *process* of good design, for which not all answers have yet been found. We also ought to use the opportunity for publicity afforded us by SIGPLAN to advertise some of the thorny unsolved problems that need further research, and encourage language designers to work on them. -------------------------------------------------------------------------  Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 10 JUL 86 12:58:04 EDT Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 3969; Thu 10-Jul-86 12:59:10-EDT Date: Thu, 10 Jul 86 13:00 EDT From: Jonathan A Rees Subject: call-with-*put-file --> call-with-*put-port To: rrrs-authors@MIT-MC.ARPA Message-ID: <860710130002.6.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU> Date: Fri, 27 Jun 86 11:37:13 edt From: ramsdell%linus at mitre-bedford.ARPA To: rrrs-authors%mc.lcs.mit.edu at mitre-bedford.ARPA Re: r3rs presentation [pg. 29] If call-with-current-continuation calls its argument with the current continuation, should the I/O routines call-with-input-file and call-with-output-file be renamed call-with-input-port and call-with-output-port? I think this is a good idea. Does anyone object? Jonathan  Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 10 JUL 86 12:07:13 EDT Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 3966; Thu 10-Jul-86 12:08:18-EDT Date: Thu, 10 Jul 86 12:09 EDT From: Jonathan A Rees Subject: number syntax To: David Bartley cc: rrrs-authors@MIT-MC.ARPA Message-ID: <860710120911.5.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU> Date: Tue 17 Jun 86 16:00:31-CDT From: David Bartley To: RRRS-Authors%mit-mc at CSNET-RELAY.ARPA cc: Bartley%ti-csl.csnet at CSNET-RELAY.ARPA Re: Number syntax Message-Id: <12215615581.31.BARTLEY@CSC60> 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. The R^3RS doesn't make clear which subset of the syntax of numbers is essential and what is optional. As implementors of systems in which Scheme and Common Lisp must co-exist, we're faced with two potential compatibility issues: (1) going with an ``extended subset'' of the Report's number syntax that is compatible with Common Lisp, or (2) going with the full number syntax in the Report to be compatible with all other Scheme implementations. 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. Our motivation, of course, is that we'd like programmers to feel free to use either language and exchange files of data without irritating obstacles being thrown in their path. If we can't agree on a consistent syntax for numbers, then we'll have to provide each language with two readers and the user will have to know which one to use. (There are other problems, of course, such as whether `:' is a constituent of an identifier or associated with Common Lisp package designations. We may have to go with separate readers/modes anyway.) 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  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 JUL 86 06:39:47 EDT Date: Wed, 9 Jul 1986 06:37 EDT Message-ID: From: HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: rrrs-authors@MC.LCS.MIT.EDU Subject: mitch wand's comments In-reply-to: Msg of 8 Jul 1986 14:43-EDT from MITCHELL WAND I second the vote for Strachey  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 9 Jul 86 02:46:51 EDT Received: from northeastern by csnet-relay.csnet id af28296; 9 Jul 86 2:44 EDT Date: Tue, 8 Jul 86 13:43 EST From: MITCHELL WAND To: rrrs-authors@MC.LCS.MIT.EDU Subject: remaining questions & remarks (2) My comments on the "remaining questions" and a few other things: I. I second Chris Haynes's comments on the title "R^3RS..". It is not only too cutesy, but also suggests an aura of impermanence: these guys are going to keep going until.... II. Kent Dybvig should be an author, on the same basis as Kent Pitman. Comments on the numbered issues: 1. (a) leave BEGIN essential, SEQUENCE optional. 2. (b) flush To: jar@MC.LCS.MIT.EDU Subject: display and write-char Cc: rrrs-authors@MC.LCS.MIT.EDU DISPLAY writes characters like WRITE-CHAR does. It seems to me that this only works if the character type is distinct from other types. I would not want display to print an integer that happens to be a character (assuming integers are used to represent characters) as the character value instead of the expected sequence of numerals. For example, if the character #\A is equivalent to the integer 65, then it seems that either 1) (write-char #\A) prints A and (display 65) prints A, or 2) (display 65) prints 65 and (write-char #\A) prints 65. I think the original intent was that (write-char #\A) print A and (display 65) print 65, even if #\A and 65 are the same. Am I missing something? Kent  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 7 Jul 86 15:51:53 EDT Received: from indiana by csnet-relay.csnet id ai12245; 7 Jul 86 15:44 EDT Date: Mon, 7 Jul 86 12:50:06 est From: Chris Haynes To: rrrs-authors@MC.LCS.MIT.EDU Subject: votes and things Cc: dfried%indiana.csnet@CSNET-RELAY.ARPA The 3 in R^3RALS is clever, but it looks just like a footnote reference when the Report is cited. Such puns hurt others more than they entertain us. How about just "Report on the Algorithmic Language Scheme". That's different enough from all the previous report names to avoid confusion, and brevity is a particular virtue in things, such as titles, that are refered to repeatedly. I strongly second John Ramsdell's comments about the introduction. If not religated to the end, the historical material should at least be in a seperate section following the introduction. I also agree with him that call-with-{input,output}-PORT is better than ...-FILE now that we have the ...-PORT? predicates. I've used the words KEYWORD and IDENTIFIER for what Jonathan is calling IDENTIFIER and VARIABLE, respectively. I agree with Dan that VARIABLE is confusing, because it is often used to mean LOCATION. But I don't feel strongly. However, it is best not to have one word for both: if you ever mean "keyword and identifier" (or "identifier and variable"), and not just "symbol", then say so. My votes follow (I care most about the first and last): 1. (a) leave BEGIN alone 2. (b) flush Subject: Remaining questions & remarks (2) To: JMiller@OZ.AI.MIT.EDU cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA, RRRS-Authors@MC.LCS.MIT.EDU In-reply-to: Msg of 2 Jul 1986 08:13-EDT from JMILLER at MIT-OZ Message-ID: <[AI.AI.MIT.EDU].64955.860702.JAR> Date: 2 Jul 1986 08:13-EDT From: JMILLER at MIT-OZ I suggest the name APPLICABLE? instead of PROCEDURE?. I personally do not regard continuations as procedures, but I completely understand and empathize with people on the other side. I think the notion of applicable is a legitimate generalization and probably would solve Bill's portable printer problem just as well. It never occurred to me that the two words could mean anything different. Certainly whatever the name is, the predicate would return true of all applicable things, including CAR, things created by CALL-WITH-CURRENT-CONTINUATION, and values of LAMBDA-expressions. If the term for this kind of object changes, then the word "procedure" must be replaced by "applicable object" throughout the entire report. The term "procedure," which everyone has been so careful to use so far, would become useless for any purpose I can think of, e.g. describing the domains of procedures. That would be unfortunate.  Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 2 Jul 86 08:54:07 EDT Organization: The MITRE Corp., Bedford, MA Received: from jymme.sun.uucp by linus.MENET (1.1/4.7) id AA16445; Wed, 2 Jul 86 08:55:09 EDT Posted-Date: Wed, 2 Jul 86 08:56:47 edt Received: by jymme.sun.uucp (2.0/SMI-3.0DEV3) id AA03112; Wed, 2 Jul 86 08:56:47 edt Date: Wed, 2 Jul 86 08:56:47 edt From: ramsdell%linus@mitre-bedford.ARPA Message-Id: <8607021256.AA03112@jymme.sun.uucp> To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA Subject: Call-with-current-continuation I told a white lie. My worry about the way continuations are perceived was generated from opinions expressed by a knowledgeable computer scientist from Harvard, not by myself. This person showed a good understanding of continuations, but worried about the runtime overhead incurred even when continuations are used to express control patterns that can be implemented using constant space (or a stack). Agreeing with Kent, I cannot think of any way to promise something about the execution of certain simple uses of continuations. I guess we should leave the topic of how to use continuations to another document. We've heard reviews of r3rs from knowledgeable users of Scheme, has anyone received an opinion of the document from a reader that is representative of the general programming language community? John PS. Sorry about being sloppy about T's continuations. T of 1981 restricted continuations to those that allowed stack allocation of control structure. You could not return from a continuation twice or pass a continuation out of its defining environment. Thus, a more correct statement is that CATCH and call of a T continuation was syntax for stack-based continuations. In the interpreter, CATCH was expanded to a lambda expression and a call to a procedure like call-with-current-continuation, but the same restriction on the continuations applied.  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 JUL 86 08:14:17 EDT Date: 2 Jul 1986 08:13-EDT Sender: JMILLER@MIT-OZ Subject: Re: Remaining questions & remarks (2) From: JMILLER@MIT-OZ Reply-To: JMiller%OZ@MC To: Bartley%ti-csl.csnet@CSNET-RELAY Cc: RRRS-Authors@MC Message-ID: <[MIT-OZ] 2-Jul-86 08:13:05.JMILLER> In-Reply-To: <12218999275.23.BARTLEY@CSC60> I suggest the name APPLICABLE? instead of PROCEDURE?. I personally do not regard continuations as procedures, but I completely understand and empathize with people on the other side. I think the notion of applicable is a legitimate generalization and probably would solve Bill's portable printer problem just as well. --Jim  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 1 Jul 86 17:28:39 EDT Received: from tektronix by csnet-relay.csnet id ad03875; 30 Jun 86 19:09 EDT Received: by tektronix.TEK (5.31/6.15) id AA15265; Mon, 30 Jun 86 14:39:28 PDT Received: by tekchips.TEK (5.31/6.15) id AA08024; Mon, 30 Jun 86 14:41:11 PDT Message-Id: <8606302141.AA08024@tekchips.TEK> To: JAR@AI.AI.MIT.EDU Cc: rrrs-authors@MC.LCS.MIT.EDU, willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Subject: Re: Remaining questions & remarks (2) In-Reply-To: Your message of Thu, 26 Jun 86 19:03 EDT. <"860626190326.1.jar@AI"@JOE-LOUIS.LCS.MIT.EDU> Date: 30 Jun 86 14:41:09 PDT (Mon) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 1. BEGIN vs. SEQUENCE... (a) leave things as they are (BEGIN essential with non-essential synonym SEQUENCE), (b) remove BEGIN and make SEQUENCE essential (noting in the Notes section that BEGIN, like #!TRUE etc., should be supported by those implementations which care about running code written in the past year). *****> (a). Fix the book so we can get rid of SEQUENCE. 2. (a) leave things as they are (b) flush the alternative names ? >=? =? *****> (b). MacScheme will continue to support the alternative names. 3. REC and NAMED-LAMBDA... (a) Keep both (b) Flush both *****> (b). 4. SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT!... *****> Flush them, but encourage Chris Hanson to publish his suite of operations in a separate document. 5. *****> Drop the comment. (I use call-without-interrupts, but that might not be so sweet on some multiprocessors.) 6. Number input exactness: two proposals have been advanced to decide whether a number is exact or inexact if it has no #I or #E prefix and contains no trailing #'s. (a) Inexact if there are digits following a decimal point, or if exponential notation is used. Otherwise exact. (This makes exctness similar to "floatness" in CL.) (b) A proposal which Will advanced, which I'm unable to locate right now, so he'll have to re-send it. I'll additionally advance another alternative, and you can make up more of your own: (c) Always exact. E.g. "1.2" is exact. *****> (b). The proposal was that exponents be treated as shorthand, so for example 1.2e3 would be treated as though it had been written 1200, 1.2000e3 would be treated as though it had been written 1200.0, and so on; if, after getting rid of the exponent in this way, there are digits following a decimal point, then assume inexact; otherwise assume exact. (a) is also ok. I think scientists and engineers would quickly become exasperated by (c), however. 7. Must a port still be a port...after being closed? *****> No, but we shouldn't make a big issue of whatever we decide. 8. Apparently there's no difference between ABS and MAGNITUDE. Should we keep both? If so, should I change the presentation in any way? *****> Flush MAGNITUDE. Talk about ABS where MAGNITUDE is now talked about. 9. ANGLE is what Common Lisp calls PHASE; any interest in changing the name? ... *****> I don't care. 10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)). Do we apply Occam's razor and remove it? If it's retained, then I'll just document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)). *****> PLEASE don't flush two-argument ATAN, because an implementation that supports flonums but not complexnums is going to have a hard time with (ANGLE (MAKE-RECTANGULAR X Y)). 11. ...Is anyone opposed to having an essential procedure PROCEDURE?... *****> I very much want one. I agree with Dan that (call-with-current-continuation (lambda (k) (procedure? k))) must be true. 12. (if x 1) vs. (cond (x 1)) -- this is inconsistent... (a) Change IF expressions so that they return the value of the second form if the first form evaluates to [true]. (b) Change COND and CASE so that they return an unspecified value if there is no ELSE clause. *****> (a). 13. Many people would like to see the (define ((((a b) c) d) e) ...) feature go away. *****> Flush. MacScheme will continue to support it. 14. Status of LOAD not resolved. If, as I suggested, LOAD is only to be syntactically valid at top level of a file, shouldn't it be renamed to be INCLUDE ? *****> LOAD should be syntactically valid only at the top level of a file. I suppose it should be renamed to INCLUDE, but I don't want to. LOAD seems a more appropriate name for something that will in fact be used interactively, even though we don't talk about interactive programming in the report. 15. Page breaks and tabs are mentioned in the report (actually I guess I added them - sorry), but there are no #\PAGE or #\TAB characters... *****> Please neutralize the places that mention tabs and page breaks. Let's not get hung up about characters. 16. If page breaks are documented, should [they] terminate comments? *****> I think so. 17. Bartley says: "the second sentence of the description of EQUAL? should say that EQV? is used for all objects except pairs, vectors, and strings." Forcing it to use EQV? seems kind of random to me. This would of course make my notion of "apparent equivalence" useless, destroying what I deluded myself into thinking was an elegant symmetry between EQV? and EQUAL?; maybe it's a bogus idea anyhow. I intentionally wanted to be silent on this point, allowing EQUAL? to return true more often than EQV? perhaps, but I don't care that much. *****> I think your "apparent equivalence" was a valiant effort on behalf of a lost cause. I think Bartley's suggestion will simplify the report and will make the language easier to understand and use. ----- Presentation questions: 18. Several people have complained about Clinger's perhaps overly accurate description of what happens when variables become bound. To be accurate, we have to say that locations are created and the initial value is stored in the location, but this doesn't sit well with the desire to have Scheme sound like an almost-functional language. What to do? *****> Admit that Scheme isn't functional. Add a note to the effect that in programs without side effects one can safely pretend that the variables are bound directly to the arguments. 19. What should the dedication be? Sussman suggested the PDP-6, which was the world's first Lisp machine, but some people didn't like this joke. I have changed it to Christopher Strachey in the draft. *****> The abstract from the RRRS was a better joke, because it said something serious. A dedication to DEC PDP-6 Serial Number 2 could well offend the memory of the person to whom the Algol 60 Report was dedicated, so I think we'd better flush it. Do we have to have a dedication? I'm not sure how many of us actually met Christopher Strachey. I remember Alonzo Church from the 1982 Lisp Conference, and he might be better; maybe we could dedicate the report to both. I believe that Church died a couple of years ago, but I might be thinking of Haskell Curry instead. Dan? Mitch? 20. Is it OK to replace "Lazy ML" with "SASL"... *****> Yes. 21. Should section numbers be zero-based? *****> I've decided that zero-based numbering is perceived as cutesy. I've found it helpful to have an unnumbered introductory section at the beginning of a chapter, which I think of as section 0 of that chapter, but I think it's best not to number it that way. My apologies for setting the precedent in the RRRS. 22. Was Scheme the first programming language to have first-class lexical closures? Can we say anything edifying along these lines? *****> I don't think Scheme was the first. Scheme is unique not because it was the first to have anything (except full continuations, and even there it was anticipated by one of Reynolds's unimplemented languages), but because it was nearly the first at many things and succeeded in integrating those avant garde features. 23. I flushed the historical note "CATCH could be provided by a procedure" sentence (again, because two or three people thought it was random and I agreed), but some of you have complained about this. Why should this bit of history be present, but not others that are at least as important? *****> Something needs to be said about the evolution of the special form into a procedure having a different name. As the paragraph stands in the 3 June draft, it makes no connection between the operators mentioned in the paragraph and call-with-current-continuation. The typical reader will wonder why the paragraph is there. The reason that history is called for in this instance is that the concepts are completely new to most readers, and they will need help to appreciate their significance. Someday the rationale will be unnecessary, but by then the R3RS will be a standard reference cited by people who want to talk about the history of continuations. I favor adding a sentence such as "CALL-WITH-CURRENT-CONTINUATION is equivalent in power to the 1975 CATCH, but is a procedure rather than a special syntax." 24. CALL/CC was mentioned in a sentence in a rationale in the RRRS. I flushed the reference because (a) a number of people find the name CALL/CC quite distasteful and (b) it is inconsistent to mention here that some scheme implementations provide an alternate name for this but not also do so for LABELS, BLOCK, and a zillion other things. *****> As someone who writes manuals for a mass audience, I find the name CALL/CC quite distasteful. It was in the RRRS to placate those who objected to the length of CALL-WITH-CURRENT-CONTINUATION. This was a political compromise; I suggest we leave the RRRS wording alone rather than try to achieve a new compromise. 25. How best to resolve the inconsistencies between terminology in text and semantics? Namely: "I", "Ide", "identifier" in semantics vs. "variable" in text; "Com", "command" in semantics vs. "statement" in text. *****> In the abstract syntax, say "identifiers (variables)" and "commands (statements)". 26. FORCE & DELAY are still problematic... *****> I don't care. 27. Is 3.0.2 (description of procedure calls) a good place to take note that () is not a valid procedure call? *****> Ok with me. 28. In section 0.0, 2nd paragraph, before the terms "variable" and "identifier" have been defined, it should say "variable" instead of "identifier" to be consistent with the rest of the report. Is that OK? *****> Yes. Dan points out that the semantics of "variable" is highly variable, but we have an advantage over most authors in that people can turn to the formal syntax and semantics if they want to know what's really going on. Section 2.0 is a pretty good informal description. I think people can deal with a few loaded terms in an overview like section 0.0. 29. There are two nonterminals in the BNF that need names. Currently they are called and which was never intended to be a serious suggestion (I put it there to see if anyone would actually read the BNF!). Actually one or both of these can go away if NAMED-LAMBDA and/or (DEFINE ((( ...) ...) ...) ...) go away. Can someone who likes these things take a look at the BNF and suggest names for these? *****> I hope NAMED-LAMBDA and the complicated DEFINE syntax depart from the report, but even if they do we still have to deal with in the (DEFINE (FOO . X) ...) syntax; perhaps the possibilities could be expanded in-line. 30. Someone wanted me to avoid discussion of immutable objects in the discussion of operational equivalence in the 2nd paragraph before entry for EQV? . I want to mention immutability there because I think it's important to warn users that this might be the case, otherwise they can easily end up writing unportable code. *****> In my opinion, the paragraph in question is too little to deal with the problem. It uses "immutable" without explaining what it means; worse, it appears that the typical reader is supposed to know as a matter of course that "mutation procedures" (whatever they are) can't be applied to immutable objects. As to which objects are immutable, all we have is the suggestion that objects returned by literal expressions may be immutable. I believe the paragraph at the end of 3.0.1 is sufficient. The report is a definition, not a tutorial. ----- DISPLAY writes characters like WRITE-CHAR does. *****> I assume it's ok for an implementation that represents characters as imaginary numbers to have (DISPLAY #\a) print "-97i"? Peace, Will  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 1 Jul 86 17:21:32 EDT Received: from ti-csl by csnet-relay.csnet id aa02302; 30 Jun 86 15:51 EDT Received: by tilde id AA19055; Mon, 30 Jun 86 13:55:24 cdt Date: Mon 30 Jun 86 13:47:42-CDT From: David Bartley Subject: Re: Remaining questions & remarks (2) 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: <"860626190326.1.jar@AI"@JOE-LOUIS.LCS.MIT.EDU> Message-Id: <12218999275.23.BARTLEY@CSC60> =======> Here are my comments. I don't care all that much about the items =======> I've skipped over. --David Bartley 1. BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report [...] (a) leave things as they are (BEGIN essential with non-essential synonym SEQUENCE), (b) remove BEGIN and make SEQUENCE essential (noting in the Notes section that BEGIN, like #!TRUE etc., should be supported by those implementations which care about running code written in the past year). =======> I strongly prefer (a). BEGIN is the traditional name and is easy =======> to understand (even without END). SEQUENCE is a *type* in Common =======> LISP and is likely to cause confusion. I thought Hal and Gerry =======> had indicated at Brandeis that they were willing to revise the =======> book to use BEGIN instead of SEQUENCE. (Is my memory faulty?) 2. Similarly but less glaringly, we have a problem with the numeric comparisons. Again, many people have said they don't care but they only want one set, with or without question marks. Thus I offer the choices (a) leave things as they are (b) flush the alternative names ? >=? =? =======> (b) 3. REC and NAMED-LAMBDA : Again, I sense capitulation on the part of some who have been stubborn. The only options permitted are: (a) Keep both (b) Flush both =======> (b). 4. SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT! : =======> Flush them. 5. Should we say anything about the possibility of parallel or interleaved argument evaluation? Remembering something I thought I heard Will once say, I added the innocent little phrase "or perhaps in parallel" to the description of procedure calling. Richard Kelsey quickly pointed out that if it's mentioned as being a possibly legal implementation, many otherwise valid scheme programs may fail to run in implementations which do this, because they won't do necessary synchronization. I agree; this is acceptable only if we provide synchronization primitives. =======> Flush the reference to parallel evaluation. Keep random order =======> evaluation. 6. Number input exactness: =======> I haven't come to terms with exactness yet, so I don't have an =======> opinion. Has anyone implemented this yet? 7. Must a port still be a port (i.e. answer true to INPUT-PORT? or OUTPUT-PORT?) after being closed? =======> Yes. (Maybe. (I don't know. (What a question!))) 8. Apparently there's no difference between ABS and MAGNITUDE. Should we keep both? If so, should I change the presentation in any way? =======> Flush MAGNITUDE; keep ABS. 9. ANGLE is what Common Lisp calls PHASE; any interest in changing the name? ... =======> Use PHASE. 10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)). Do we apply Occam's razor and remove it? If it's retained, then I'll just document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)). =======> Is there any problem with precision here? I'll go with the =======> consensus. 11. JINX says: if PROCEDURE? exists, then a portable printer can be written. =======> As Dan points out, we need to make it clear whether a =======> continuation object is a "procedure" in the sense of this =======> predicate. If we call it CLOSURE?, as someone (Kent Dybvig?) =======> suggested, then it should perhaps discriminate against =======> continuations. Since it is implementation-dependent whether =======> continuations are easily distinguished from closures, I prefer a =======> PROCEDURE? that is true of both closures and continuations. 12. (if x 1) vs. (cond (x 1)) (a) Change IF expressions so that they return the value of the second form if the first form evaluates to false. [TRUE] (b) Change COND and CASE so that they return an unspecified value if there is no ELSE clause. =======> (a), as amended. 13. Many people would like to see the (define ((((a b) c) d) e) ...) feature go away. S&ICP doesn't use it, and it has a rather complicated syntax (look at the BNF for evidence). Vote keep or flush. =======> Flush. 14. Status of LOAD not resolved. If, as I suggested, LOAD is only to be syntactically valid at top level of a file, shouldn't it be renamed to be INCLUDE ? =======> I'm not sure what INCLUDE means to people. My intuition is that =======> INCLUDE is a conditional LOAD---it is ignored if the specified =======> files has already been loaded. LOAD is unconditional and more =======> appropriate as a building block for smarter capabilities. 15. Page breaks and tabs are mentioned in the report (actually I guess I added them - sorry), but there are no #\PAGE or #\TAB characters. Can this be made consistent by documenting #\PAGE and #\TAB, or [...] =======> Lump these under "other whitespace". I intend to treat them as =======> in Common LISP. 16. If page breaks are documented, should the terminate comments? I think they should (but of course they don't in Common Lisp). =======> They won't if they are just whitespace. 17. Bartley says: "the second sentence of the description of EQUAL? should say that EQV? is used for all objects except pairs, vectors, and strings." Forcing it to use EQV? seems kind of random to me. This would of course make my notion of "apparent equivalence" useless, destroying what I deluded myself into thinking was an elegant symmetry between EQV? and EQUAL?; maybe it's a bogus idea anyhow. I intentionally wanted to be silent on this point, allowing EQUAL? to return true more often than EQV? perhaps, but I don't care that much. =======> I think that explicitly mentioning EQV? would clarify things. =======> In particular, people want to understand how EQ?, EQV?, and =======> EQUAL? are related. I think its easier to understand them if =======> they monotonically become less discriminating; thus all things =======> that are EQ? are also EQV? and EQUAL? and all things that are =======> EQV? are also EQUAL?. 18. Several people have complained about Clinger's perhaps overly accurate description of what happens when variables become bound. To be accurate, we have to say that locations are created and the initial value is stored in the location, but this doesn't sit well with the desire to have Scheme sound like an almost-functional language. What to do? =======> Keep Will's description. 21. Should section numbers be zero-based? I'm beginning to think this looks unprofessional; and it just doesn't look right in several places. It worked well in the previous version of the report, and it's clearly more consistent with the language (which is zero-based), but it doesn't work the way I've reorganized things. If you like zero-based section numbers, speak up. =======> One-based. 23. I flushed the historical note "CATCH could be provided by a procedure" sentence (again, because two or three people thought it was random and I agreed), but some of you have complained about this. Why should this bit of history be present, but not others that are at least as important? =======> We need to explain that CALL/CC is more than CATCH. 24. CALL/CC was mentioned in a sentence in a rationale in the RRRS. I flushed the reference because (a) a number of people find the name CALL/CC quite distasteful and (b) it is inconsistent to mention here that some scheme implementations provide an alternate name for this but not also do so for LABELS, BLOCK, and a zillion other things. =======> Keep CALL/CC. Language: Only one empty list, period. (eq? '() '()) returns true. =======> Yes. A port does not become closed as a side effect of reaching end of file. After end of file, you'll continue to read end of file objects as long as the port is open. It's an error to read from or write to a closed port. =======> Yes. Yes. Yes. DISPLAY writes characters like WRITE-CHAR does. =======> Yes. =======> Regards, =======> David Bartley -------  Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 1 Jul 86 13:18:51 EDT Organization: The MITRE Corp., Bedford, MA Received: from jymme.sun.uucp by linus.MENET (1.1/4.7) id AA02064; Tue, 1 Jul 86 13:19:55 EDT Posted-Date: Tue, 1 Jul 86 13:21:34 edt Received: by jymme.sun.uucp (2.0/SMI-3.0DEV3) id AA02532; Tue, 1 Jul 86 13:21:34 edt Date: Tue, 1 Jul 86 13:21:34 edt From: ramsdell%linus@mitre-bedford.ARPA Message-Id: <8607011721.AA02532@jymme.sun.uucp> To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA Subject: Call-with-current-continuation I told a white lie. My worry about the way continuations are perceived was generated from opinions expressed by a knowledgeable computer scientist from Harvard, not by myself. This person showed a good understanding of continuations, but worried about the runtime overhead incurred even when continuations are used to express control patterns that can be implemented using constant space (or a stack). Agreeing with Kent, I cannot think of any way to promise something about the execution of certain simple uses of continuations. I guess we should leave the topic of how to use continuations to another document. We've heard reviews of r3rs from knowledgeable users of Scheme, has anyone received an opinion of the document from a reader that is representative of the general programming language community? John PS. Sorry about being sloppy about T's continuations. T of 1981 restricted continuations to those that allowed stack allocation of control structure. You could not return from a continuation twice or pass a continuation out of its defining environment. Thus, a more correct statement is that CATCH and call of a T continuation was syntax for stack-based continuations. In the interpreter, CATCH was expanded to a lambda expression and a call to a procedure like call-with-current-continuation, but the same restriction on the continuations applied.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 30 Jun 86 10:39:57 EDT Received: from indiana by csnet-relay.csnet id aa04496; 30 Jun 86 10:37 EDT Date: Mon, 30 Jun 86 03:46:12 est From: Kent Dybvig To: ramsdell%linus@MITRE-BEDFORD.ARPA Subject: Re: r3rs presentation (long) Cc: rrrs-authors@MC.LCS.MIT.EDU On less significant presentation issues, I would like to present a view that a less sophisicated user of Scheme may get about continuations. That is, this reader may conclude that continuations are very powerful and always expensive to use. I know that the T compiler of 1981 generated goto's from the a catch and throw expression that exited a loop from within a loop. (Catch and throw is old syntax for using continuations.) Since we promise that tail-recursive procedures are executed in constant space, can't we promise something about certain simple uses of continuations? Otherwise, they may avoided by programmers for the wrong reasons. The T compiler of 1981 did not support continuations, just Lisp-style catch and throw. However, simple uses can be compiled into jumps or not much more. For instance, a smart compiler can tell that (call/cc (lambda (k) (if (zero? x) (k x) (/ 1 x)))) requires nothing more than a goto for (k x). The ability to perform this improvement is easily lost; if k is returned, placed somewhere, or invoked from within a closure that is returned or placed somewhere, etc., the full continuation must be made. Recursion makes things a little more difficult, since it requires not just a goto but some way of recording the depth of the stack. What's more, it takes a fairly sophisticated compiler (or some special-casing) not to trip on (call/cc (lambda (return) (letrec ([g (lambda (l a) (cond [(null? l) a] [else (when (zero? (car l)) (return 'oops)) (g (cdr l) (/ a (car l)))]))]) (g some-list-of-numbers 1)))) because it appears that return is closed over even though g can be implemented as a simple loop (but couldn't be, for example, if the closure g itself were returned instead of 'oops). But this may be just what the "do" expression below turns into. (call/cc (lambda (return) (do ([l some-list-of-numbers (cdr l)] [a 1 (/ a (car l))]) ((null? l) a) (when (zero? (car l)) (return 'oops))))) (Actually, it's worse than that, since letrec is itself a derived form and really appears as a convoluted combination of lambda and set! expressions.) Making a guarantee that call/cc produces essentially gotos in simple situations might backfire, too, resulting in convoluted code to take advantage of the faster call/cc. For instance, a programmer might abandon map in favor of hand-coded loops, or not take full advantage of closures and recursion. Another problem with making such a guarantee is that call/cc is a function, not a special form, and its value might change, e.g., for tracing or "constraining control". Certainly, it would be possible to generate code for the first example something like (if (eq? call/cc *primitive-call/cc*) {fancy goto code for (if (zero? x) (k x) (/ 1 x))} {normal application of call/cc to (lambda (k) ...)}), but this would be clumsy and wasteful of code space. Some implementations of Scheme currently promote some or all primitive functions almost to special form status... if the identifier's binding is the expected one at compile time, assume it will be at run time and generate inline code. For example, car and cdr might be inlined this way. In these systems, call/cc could presumably be nailed down too. But it cannot be guaranteed so in the RRRS without implying that some primitives are really special forms. Since I have brought the issue up, how does everyone feel about this special treatment for primitives? Should it be explicitly allowed or disallowed? All of the arguments against allowing extra special forms come in to play here as well, plus others, so I'd say it should be disallowed, at least by default. I have no problem with some sort of flag controlling this behavior, e.g., (set! *benchmark-mode* #t). Or perhaps we want to say that all primitives are special forms or that primitive identifiers are not assignable (I don't think so). How about making call/cc a special form? I've often wondered if it should be even though its evaluation rule would be the same as for function application. Call/cc is basic to any system, and support for it must be provided by the compiler, at least in the way it represents things. Why should something be a function and not a special form just because its evaluation rule coincides with the evaluation rule for function applications? (By the way, what about "not"? How many times have you seen someone turn a conditional expression around to avoid the extra call?) Kent  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 30 Jun 86 00:37:18 EDT Received: from indiana by csnet-relay.csnet id ab01297; 30 Jun 86 0:37 EDT Date: Sun, 29 Jun 86 19:58:16 est From: Kent Dybvig To: jar@MC.LCS.MIT.EDU Subject: Re: Remaining questions & remarks (2) Cc: rrrs-authors@MC.LCS.MIT.EDU 1. BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report; ... (a) leave things as they are (BEGIN essential with non-essential ... (b) remove BEGIN and make SEQUENCE essential (noting in the Notes ... (b) [I hate the name begin... I am always looking for a corresponding end] 2. Similarly but less glaringly, we have a problem with the numeric ... (a) leave things as they are (b) flush the alternative names ? >=? =? ... (b) 3. REC and NAMED-LAMBDA : Again, I sense capitulation on the part of some who have been stubborn. ... (a) Keep both (b) Flush both My editorial sense is that we should be able to achieve (b). Remember, ... (b) 4. SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT! : Many people have suggested removing these. Anyone who wants them ... remove them 5. Should we say anything about the possibility of parallel or ... remove mention of parallel argument evaluation 7. Must a port still be a port (i.e. answer true to INPUT-PORT? or OUTPUT-PORT?) ... I would prefer if it was but not strongly 9. ANGLE is what Common Lisp calls PHASE; any interest in changing the name? ... call it phase 10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)). Do we apply Occam's razor and remove it? If it's retained, then I'll just document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)). are they not different in implementations without complex numbers? 11. JINX says: if PROCEDURE? exists, then a portable printer can be written. JAR replies (in jest): (define procedure? (lambda (obj) (not (or (pair? obj) (null? obj) (symbol? obj) (number? obj) ...)))) Seriously however, I was the only holdout at Brandeis against having ... it should be included---I would much prefer the name "closure?" 12. (if x 1) vs. (cond (x 1)) -- this is inconsistent, as a couple of people ... (a) Change IF expressions so that they return the value of the ... (b) Change COND and CASE so that they return an unspecified value if ... ... (c) require if to have a consequent and include WHEN as required---this gets rid of the whole mess and is much cleaner. 13. Many people would like to see the (define ((((a b) c) d) e) ...) ... flush it 14. Status of LOAD not resolved. If, as I suggested, LOAD is only ... renamed to be INCLUDE ? no... load implies run time, include implies compile time, if they are different 15. Page breaks and tabs are mentioned in the report (actually I guess I ... leave them out where possible 17. Bartley says: "the second sentence of the description of EQUAL? should ... I agree with David Presentation questions: 18. Several people have complained about Clinger's perhaps overly accurate ... I'd say leave Will's description. 19. What should the dedication be? Sussman suggested the PDP-6, which was ... how about Haskell B. Curry? 20. Is it OK to replace "Lazy ML" with "SASL" (last paragraph of section ... it does seem more appropriate; SASL predates lazy ML. 21. Should section numbers be zero-based? I'm beginning to think this looks ... 1-based seems best 22. Was Scheme the first programming language to have first-class lexical closures? Can we say anything edifying along these lines? ISWIM (Burge) had them about ten years prior to Scheme. might want to refer to Burge, W.H. ``ISWIM Programming Manual,'' IBM Research Report RA129, Yorktown Heights, New York (November 1981). 23. I flushed the historical note "CATCH could be provided by a procedure" ... I agree, flush it. 24. CALL/CC was mentioned in a sentence in a rationale in the RRRS. I ... definitely keep call/cc. call/cc has appeared in several papers, and it is much easier to type in without making mistakes---the other name compromises did not end us up with names 5 times as long 25. How best to resolve the inconsistencies between terminology in text and semantics? Namely: "I", "Ide", "identifier" in semantics vs. "variable" in text; "Com", "command" in semantics vs. "statement" in text. I prefer identifier for all symbols, such as keywords and lexical identifiers, and variable for lexical identifiers. 26. FORCE & DELAY are still problematic. About half of respondents said it was better to put FORCE up front with DELAY, and the other half thought it was fine as it was. No one gave convincing arguments. they should be together, I would say where FORCE now is 27. Is 3.0.2 (description of procedure calls) a good place to take note that () is not a valid procedure call? it should be obvious from the syntax 28. In section 0.0, 2nd paragraph, before the terms "variable" and "identifier" have been defined, it should say "variable" instead of "identifier" to be consistent with the rest of the report. Is that OK? yes Changed variable name "loop" to "recur" in the call-with-current-continuation example. please don't---recur is the name of a special form in Chez Scheme and is used by lots of people---I'd like to avoid confusion As for grandfathering, unless the original RRRS report was distributed much more widely than I figure it was, I would rather see no mention of the incompatibilities. It is not worthwhile to support old features when the affected group of people is fairly small (particularly for new implementations). Besides, the various language manuals for existing implementations with all their differing syntaxes were much more widely distributed in total, and their features are not being grandfathered. Kent  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 Jun 86 15:49:47 EDT Received: from indiana by csnet-relay.csnet id aa28825; 28 Jun 86 15:37 EDT Date: Sat, 28 Jun 86 11:50:33 est From: Dan Friedman To: rrrs-authors@MC.LCS.MIT.EDU Subject: Grandfathering response 1. BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report; it's obvious to the world we couldn't get consensus on this one. Many people have told me that they don't care which one is there, so long as there's only one. SEQUENCE was used heavily in S&ICP and for that reason I think it should be retained; thus the options I offer are (a) leave things as they are (BEGIN essential with non-essential synonym SEQUENCE), (b) remove BEGIN and make SEQUENCE essential (noting in the Notes section that BEGIN, like #!TRUE etc., should be supported by those implementations which care about running code written in the past year). Let me know your vote if you haven't done so already. *****>> (a) 2. Similarly but less glaringly, we have a problem with the numeric comparisons. Again, many people have said they don't care but they only want one set, with or without question marks. Thus I offer the choices (a) leave things as they are (b) flush the alternative names ? >=? =? [The ones without question marks were used in S&ICP; moreover, they exist in other Lisp dialects. The argument in favor of the ?'s is that it allows the simple statement: "names of predicates end in question mark".] Send me your vote. ******>> (b) 3. REC and NAMED-LAMBDA : Again, I sense capitulation on the part of some who have been stubborn. The only options permitted are: (a) Keep both (b) Flush both My editorial sense is that we should be able to achieve (b). Remember, the language also doesn't have EVAL, environments, or macros, so if you want to keep these features please say how they're different from other "indispensible" features that the language DOESN'T have. Named-lambda is totally unacceptable. Letrec is often overkill and without macros we will be left with using it. Rec is an incredibly powerful tool. I'd hate to lose it from my repertoire. However, named-lambda is an ugly so I am forced, given these choices, to opt for (b). 4. SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT! : Many people have suggested removing these. Anyone who wants them retained MUST provide a convincing rationale, for inclusion in the report. Otherwise I'll remove them. ****>> Remove them 5. Should we say anything about the possibility of parallel or interleaved argument evaluation? Remembering something I thought I heard Will once say, I added the innocent little phrase "or perhaps in parallel" to the description of procedure calling. Richard Kelsey quickly pointed out that if it's mentioned as being a possibly legal implementation, many otherwise valid scheme programs may fail to run in implementations which do this, because they won't do necessary synchronization. I agree; this is acceptable only if we provide synchronization primitives. ****>> Yes, either provide synchonization primitives or flush the comment 8. Apparently there's no difference between ABS and MAGNITUDE. Should we keep both? If so, should I change the presentation in any way? *****>> don't keep both. 9. ANGLE is what Common Lisp calls PHASE; any interest in changing the name? ... *****>> I agree with the consensus. 10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)). Do we apply Occam's razor and remove it? If it's retained, then I'll just document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)). *****>> follow Occam's razor here. 11. JINX says: if PROCEDURE? exists, then a portable printer can be written. JAR replies (in jest): (define procedure? (lambda (obj) (not (or (pair? obj) (null? obj) (symbol? obj) (number? obj) ...)))) Seriously however, I was the only holdout at Brandeis against having this predicate. After thinking about this further I think it's not such a bad idea, even though it is of limited use. Is anyone opposed to having an essential procedure PROCEDURE?, to round out the set of type predicates? *****> include procedure?, but be sure that (call/cc (lambda (k) (k (procedure? k)))) --> #t. 12. (if x 1) vs. (cond (x 1)) -- this is inconsistent, as a couple of people have pointed out. I would expect these two expressions to have the same meaning, but they don't. The first is defined to always return an unspecified value. The second is defined to return the value 1 if x is true, and an unspecified value otherwise. I would like to make this consistent, and there are two ways to do. Take your pick: (a) Change IF expressions so that they return the value of the second form if the first form evaluates to false. (b) Change COND and CASE so that they return an unspecified value if there is no ELSE clause. Here are some arguments in favor of (a): - It removes the possibility of inferring that an implementation might not be tail-recursive through an alternate-less IF. - Similarly, it makes (IF #T ) mean the same as , and removes doubt about the meaning of things like (if x (if y 1) z). - It simplifies the macro expansion of COND as compared with (b). - Option (b) is obviously undesirable (consider the case of mutually exclusive test expressions in a COND). ****>> I favor including a "(when pred val) as the proper special form for two branch-if's. That way two branch-if's would be syntactically illegal. I've used them for about a year and I find less bugs creeping into other's and my own programs. 13. Many people would like to see the (define ((((a b) c) d) e) ...) feature go away. S&ICP doesn't use it, and it has a rather complicated syntax (look at the BNF for evidence). Vote keep or flush. *****>> flush it. Presentation questions: 18. Several people have complained about Clinger's perhaps overly accurate description of what happens when variables become bound. To be accurate, we have to say that locations are created and the initial value is stored in the location, but this doesn't sit well with the desire to have Scheme sound like an almost-functional language. What to do? ****> Realize that Scheme is not "almost"-functional, it's almost Algol! I agree wholeheartedly agree with Will's characterization. The best that can be said with respect to the functionality of Scheme is that it contains a coherent subset that is "functional". 19. What should the dedication be? Sussman suggested the PDP-6, which was the world's first Lisp machine, but some people didn't like this joke. I have changed it to Christopher Strachey in the draft. ****> I prefer Christopher Strachey. 21. Should section numbers be zero-based? I'm beginning to think this looks unprofessional; and it just doesn't look right in several places. It worked well in the previous version of the report, and it's clearly more consistent with the language (which is zero-based), but it doesn't work the way I've reorganized things. If you like zero-based section numbers, speak up. *****> 1-based seems better. 22. Was Scheme the first programming language to have first-class lexical closures? Can we say anything edifying along these lines? *****> Landin's ISWIM was the first well-known one back in the early 60's. However, I would guess that the use of "function" in the "Lisp 1.5 Programmming Language Manual" should count as a first-class closure. If all "lambda"'s were surrounded by (function ...) then LISP 1.5 would model them. Furthermore, call/cc can be written with Landin's J operat. 23. I flushed the historical note "CATCH could be provided by a procedure" sentence (again, because two or three people thought it was random and I agreed), but some of you have complained about this. Why should this bit of history be present, but not others that are at least as important? *****> I won't argue for the history. However, the implementor who thinks that catch (as in Common Lisp) and call/cc are the same is in for a shock. That should perhaps be pointed out. 24. CALL/CC was mentioned in a sentence in a rationale in the RRRS. I flushed the reference because (a) a number of people find the name CALL/CC quite distasteful and (b) it is inconsistent to mention here that some scheme implementations provide an alternate name for this but not also do so for LABELS, BLOCK, and a zillion other things. ****> Carolyn Talcott in her dissertation suggested the term "note". I could live with that. If call-with-current-continuation is the only term, this will make those of us who write about this object uncomfortable. I think we agreed that "call/cc" would be an acceptable abbreviation and I would prefer to keep that name in the report. Those who don't like the name can choose not to use it. In a sense I agree with your argument, but "call-with-current -continuation has 30 characters in it!, "labels" and "letrec", and "block" and "begin" each have the same number of characters. 25. How best to resolve the inconsistencies between terminology in text and semantics? Namely: "I", "Ide", "identifier" in semantics vs. "variable" in text; "Com", "command" in semantics vs. "statement" in text. ****> "variable" is a "dangerous" word, try to expunge it. Opinions differ as to what a variable is. 26. FORCE & DELAY are still problematic. About half of respondents said it was better to put FORCE up front with DELAY, and the other half thought it was fine as it was. No one gave convincing arguments. ****> I favor join them. I don't much care where they are joined. 28. In section 0.0, 2nd paragraph, before the terms "variable" and "identifier" have been defined, it should say "variable" instead of "identifier" to be consistent with the rest of the report. Is that OK? ****> See comment on 26. 29. There are two nonterminals in the BNF that need names. Currently they are called and which was never intended to be a serious suggestion (I put it there to see if anyone would actually read the BNF!). Actually one or both of these can go away if NAMED-LAMBDA and/or (DEFINE ((( ...) ...) ...) ...) go away. Can someone who likes these things take a look at the BNF and suggest names for these? ****> I hope they go away. Language: Removed non-essential features from examples (including the big one) where possible: (1+ x) --> (+ x 1), (-1+ x) --> (- x 1), (define (foo ...) ...) --> (define foo (lambda ...)), 1-armed if --> cond, named let --> letrec. ****> I'd still prefer "add1" or "succ" and "sub1" or "pred" to the abuse of punnery "-1+", and its slightly weaker sibling "1+". The cuteness of "-1+" should go. In writing for a mass audience I have learned that there is a time and a place for clever un-pronouceable function names. Please remove them and find pronounceable words  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 JUN 86 12:37:38 EDT Date: Sat, 28 Jun 86 12:36:57 EDT From: Jonathan A Rees Subject: variable vs. identifier To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].62926.860628.JAR> From the messages I've recieved, it apparently wasn't clear why two distinct words are needed. I want to make sure that the grammar reflects the decision that we will leave it up to implementations (i.e. leave it "unspecified") just what things like (let ((if ...)) ...) would mean. So at the very least these expressions have to be excluded from the grammar. Therefore one word is needed for things that are lexically like symbols (and can appear inside of QUOTE expressions), and another is needed for those things that can be bound and referred to. I chose "identifier" for the first and "variable" for the second. Thus IF is an identifier but not a variable. I like the way this turned out, and can't think of anything else that would work as well.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 Jun 86 00:38:15 EDT Received: from indiana by csnet-relay.csnet id aa23894; 28 Jun 86 0:36 EDT Date: Fri, 27 Jun 86 11:09:20 est From: Dan Friedman To: rrrs-authors@MC.LCS.MIT.EDU Subject: Grandfathering Responses 1. BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report; it's obvious to the world we couldn't get consensus on this one. Many people have told me that they don't care which one is there, so long as there's only one. SEQUENCE was used heavily in S&ICP and for that reason I think it should be retained; thus the options I offer are (a) leave things as they are (BEGIN essential with non-essential synonym SEQUENCE), (b) remove BEGIN and make SEQUENCE essential (noting in the Notes section that BEGIN, like #!TRUE etc., should be supported by those implementations which care about running code written in the past year). Let me know your vote if you haven't done so already. *****>> (a) 2. Similarly but less glaringly, we have a problem with the numeric comparisons. Again, many people have said they don't care but they only want one set, with or without question marks. Thus I offer the choices (a) leave things as they are (b) flush the alternative names ? >=? =? [The ones without question marks were used in S&ICP; moreover, they exist in other Lisp dialects. The argument in favor of the ?'s is that it allows the simple statement: "names of predicates end in question mark".] Send me your vote. ******>> (b) 3. REC and NAMED-LAMBDA : Again, I sense capitulation on the part of some who have been stubborn. The only options permitted are: (a) Keep both (b) Flush both My editorial sense is that we should be able to achieve (b). Remember, the language also doesn't have EVAL, environments, or macros, so if you want to keep these features please say how they're different from other "indispensible" features that the language DOESN'T have. Named-lambda is totally unacceptable. Letrec is often overkill and without macros we will be left with using it. Rec is an incredibly powerful tool. I'd hate to lose it from my repertoire. However, named-lambda is an ugly so I am forced, given these choices, to opt for (b). 4. SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT! : Many people have suggested removing these. Anyone who wants them retained MUST provide a convincing rationale, for inclusion in the report. Otherwise I'll remove them. ****>> Remove them 5. Should we say anything about the possibility of parallel or interleaved argument evaluation? Remembering something I thought I heard Will once say, I added the innocent little phrase "or perhaps in parallel" to the description of procedure calling. Richard Kelsey quickly pointed out that if it's mentioned as being a possibly legal implementation, many otherwise valid scheme programs may fail to run in implementations which do this, because they won't do necessary synchronization. I agree; this is acceptable only if we provide synchronization primitives. ****>> Yes, either provide synchonization primitives or flush the comment 8. Apparently there's no difference between ABS and MAGNITUDE. Should we keep both? If so, should I change the presentation in any way? *****>> don't keep both. 9. ANGLE is what Common Lisp calls PHASE; any interest in changing the name? ... *****>> I agree with the consensus. 10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)). Do we apply Occam's razor and remove it? If it's retained, then I'll just document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)). *****>> follow Occam's razor here. 11. JINX says: if PROCEDURE? exists, then a portable printer can be written. JAR replies (in jest): (define procedure? (lambda (obj) (not (or (pair? obj) (null? obj) (symbol? obj) (number? obj) ...)))) Seriously however, I was the only holdout at Brandeis against having this predicate. After thinking about this further I think it's not such a bad idea, even though it is of limited use. Is anyone opposed to having an essential procedure PROCEDURE?, to round out the set of type predicates? *****> include procedure?, but be sure that (call/cc (lambda (k) (k (procedure? k)))) --> #t. 12. (if x 1) vs. (cond (x 1)) -- this is inconsistent, as a couple of people have pointed out. I would expect these two expressions to have the same meaning, but they don't. The first is defined to always return an unspecified value. The second is defined to return the value 1 if x is true, and an unspecified value otherwise. I would like to make this consistent, and there are two ways to do. Take your pick: (a) Change IF expressions so that they return the value of the second form if the first form evaluates to false. (b) Change COND and CASE so that they return an unspecified value if there is no ELSE clause. Here are some arguments in favor of (a): - It removes the possibility of inferring that an implementation might not be tail-recursive through an alternate-less IF. - Similarly, it makes (IF #T ) mean the same as , and removes doubt about the meaning of things like (if x (if y 1) z). - It simplifies the macro expansion of COND as compared with (b). - Option (b) is obviously undesirable (consider the case of mutually exclusive test expressions in a COND). ****>> I favor including a "(when pred val) as the proper special form for two branch-if's. That way two branch-if's would be syntactically illegal. I've used them for about a year and I find less bugs creeping into other's and my own programs. 13. Many people would like to see the (define ((((a b) c) d) e) ...) feature go away. S&ICP doesn't use it, and it has a rather complicated syntax (look at the BNF for evidence). Vote keep or flush. *****>> flush it. Presentation questions: 18. Several people have complained about Clinger's perhaps overly accurate description of what happens when variables become bound. To be accurate, we have to say that locations are created and the initial value is stored in the location, but this doesn't sit well with the desire to have Scheme sound like an almost-functional language. What to do? ****> Realize that Scheme is not "almost"-functional, it's almost Algol! I agree wholeheartedly agree with Will's characterization. The best that can be said with respect to the functionality of Scheme is that it contains a coherent subset that is "functional". 19. What should the dedication be? Sussman suggested the PDP-6, which was the world's first Lisp machine, but some people didn't like this joke. I have changed it to Christopher Strachey in the draft. ****> I prefer Christopher Strachey. 21. Should section numbers be zero-based? I'm beginning to think this looks unprofessional; and it just doesn't look right in several places. It worked well in the previous version of the report, and it's clearly more consistent with the language (which is zero-based), but it doesn't work the way I've reorganized things. If you like zero-based section numbers, speak up. *****> 1-based seems better. 22. Was Scheme the first programming language to have first-class lexical closures? Can we say anything edifying along these lines? *****> Landin's ISWIM was the first well-known one back in the early 60's. However, I would guess that the use of "function" in the "Lisp 1.5 Programmming Language Manual" should count as a first-class closure. If all "lambda"'s were surrounded by (function ...) then LISP 1.5 would model them. Furthermore, call/cc can be written with Landin's J operat. 23. I flushed the historical note "CATCH could be provided by a procedure" sentence (again, because two or three people thought it was random and I agreed), but some of you have complained about this. Why should this bit of history be present, but not others that are at least as important? *****> I won't argue for the history. However, the implementor who thinks that catch (as in Common Lisp) and call/cc are the same is in for a shock. That should perhaps be pointed out. 24. CALL/CC was mentioned in a sentence in a rationale in the RRRS. I flushed the reference because (a) a number of people find the name CALL/CC quite distasteful and (b) it is inconsistent to mention here that some scheme implementations provide an alternate name for this but not also do so for LABELS, BLOCK, and a zillion other things. ****> Carolyn Talcott in her dissertation suggested the term "note". I could live with that. If call-with-current-continuation is the only term, this will make those of us who write about this object uncomfortable. I think we agreed that "call/cc" would be an acceptable abbreviation and I would prefer to keep that name in the report. Those who don't like the name can choose not to use it. In a sense I agree with your argument, but "call-with-current -continuation has 30 characters in it!, "labels" and "letrec", and "block" and "begin" each have the same number of characters. 25. How best to resolve the inconsistencies between terminology in text and semantics? Namely: "I", "Ide", "identifier" in semantics vs. "variable" in text; "Com", "command" in semantics vs. "statement" in text. ****> "variable" is a "dangerous" word, try to expunge it. Opinions differ as to what a variable is. 26. FORCE & DELAY are still problematic. About half of respondents said it was better to put FORCE up front with DELAY, and the other half thought it was fine as it was. No one gave convincing arguments. ****> I favor join them. I don't much care where they are joined. 28. In section 0.0, 2nd paragraph, before the terms "variable" and "identifier" have been defined, it should say "variable" instead of "identifier" to be consistent with the rest of the report. Is that OK? ****> See comment on 26. 29. There are two nonterminals in the BNF that need names. Currently they are called and which was never intended to be a serious suggestion (I put it there to see if anyone would actually read the BNF!). Actually one or both of these can go away if NAMED-LAMBDA and/or (DEFINE ((( ...) ...) ...) ...) go away. Can someone who likes these things take a look at the BNF and suggest names for these? ****> I hope they go away. Language: Removed non-essential features from examples (including the big one) where possible: (1+ x) --> (+ x 1), (-1+ x) --> (- x 1), (define (foo ...) ...) --> (define foo (lambda ...)), 1-armed if --> cond, named let --> letrec. ****> I'd still prefer "add1" or "succ" and "sub1" or "pred" to the abuse of punnery "-1+", and its slightly weaker sibling "1+". The cuteness of "-1+" should go. In writing for a mass audience I have learned that there is a time and a place for clever un-pronouceable function names. Please remove them and find pronounceable words Dan  Received: from VAIL.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 JUN 86 22:28:27 EDT Date: Fri, 27 Jun 86 22:29 EDT From: Jonathan A Rees Subject: typo To: rrrs-authors@MIT-MC.ARPA Message-ID: <860627222941.1.JAR@VAIL.LCS.MIT.EDU> Of course I meant "return the value of the second form if the first evaluates to *true*," not false.  Received: from Godot.Think.COM by MC.LCS.MIT.EDU 27 Jun 86 13:39:25 EDT Received: from boethius by Godot.Think.COM via CHAOS; Fri, 27 Jun 86 13:36:07 edt Date: Fri, 27 Jun 86 13:37 EDT From: Guy Steele Subject: Remaining questions & remarks (2) To: JAR@MIT-AI.ARPA, rrrs-authors@MIT-MC.ARPA Cc: gls@AQUINAS In-Reply-To: <"860626190326.1.jar@AI"@JOE-LOUIS.LCS.MIT.EDU> Message-Id: <860627133714.3.GLS@BOETHIUS.THINK.COM> Date: Thu, 26 Jun 86 19:03 EDT From: Jonathan A Rees 1. BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report; it's obvious to the world we couldn't get consensus on this one. Many people have told me that they don't care which one is there, so long as there's only one. SEQUENCE was used heavily in S&ICP and for that reason I think it should be retained; thus the options I offer are (a) leave things as they are (BEGIN essential with non-essential synonym SEQUENCE), (b) remove BEGIN and make SEQUENCE essential (noting in the Notes section that BEGIN, like #!TRUE etc., should be supported by those implementations which care about running code written in the past year). (b) 2. Similarly but less glaringly, we have a problem with the numeric comparisons. Again, many people have said they don't care but they only want one set, with or without question marks. Thus I offer the choices (a) leave things as they are (b) flush the alternative names ? >=? =? (b) 22. Was Scheme the first programming language to have first-class lexical closures? Can we say anything edifying along these lines? Don't forget, of course, to say that Algol 60 came real close. I think you should research the languages GEDANKEN (Reynolds) and ISWIM (Landin), as one of those might have had closures. I believe ISWIM was described in CACM in the mid-1960's. Kelsey asks: why does ROUND round to even? Answer: Common Lisp does it this way. Ask Steele. Probably this has to do with statistical niceness. ROUND rounds to even because the integer "rounding modes" (floor, ceiling, round, truncate) were chosen to correspond to the rounding modes required by the IEEE floating point standard. That standard in turn mandates rounding to even for what indeed amounts to statistical niceness: on the average the effects of rounding tend to cancel out. Why round to even instead of odd? Then further operations on those results are more likely to be exactly representable and therefore not require further loss of accuracy due to rounding. --Guy  Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 27 Jun 86 12:44:13 EDT Full-Name: Organization: The MITRE Corp., Bedford, MA Received: from jymme.sun.uucp by linus.MENET (1.1/4.7) id AA00559; Fri, 27 Jun 86 11:38:01 EDT Posted-Date: Fri, 27 Jun 86 11:37:13 edt Received: by jymme.sun.uucp (2.0/SMI-3.0DEV3) id AA19250; Fri, 27 Jun 86 11:37:13 edt Date: Fri, 27 Jun 86 11:37:13 edt From: ramsdell%linus@mitre-bedford.ARPA Message-Id: <8606271537.AA19250@jymme.sun.uucp> To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA Subject: r3rs presentation I went on vacation and then I had trouble getting the r3rs.tar file. By the time I sat down to read the report, I found my Scheme mail had grown to 100 printed pages! We have a solid group of committed people. I would like to make a few comments on presentation. The most important comment is about section organization. Newspaper writers spend most of their time writing the first three paragraphs of any article. This part of the article is often the only part read by readers, and is important in enticing readers to continue. In the same way, The first page is most likely to be the only page read by many SIGPLAN readers. If I had my choice of what I would ask them to read, it would be the material in Section 0.0, the Semantics section that notes that scheme is lexically scoped, tail recursive, weakly typed, ... etc. I would expand on the discussion on continutations, as they represent one important difference between Scheme and other languages. The Introduction, with its history of scheme, its history of scheme reports and meetings, and acknowledgements giving names of people that the reader will not likely know, is not that one page I would like all to read. I suggest moving the history to the back of the report, and use the first couple of pages to convince the reader that the language documented in this report is worth studying. On less significant presentation issues, I would like to present a view that a less sophisicated user of Scheme may get about continuations. That is, this reader may conclude that continuations are very powerful and always expensive to use. I know that the T compiler of 1981 generated goto's from the a catch and throw expression that exited a loop from within a loop. (Catch and throw is old syntax for using continuations.) Since we promise that tail-recursive procedures are executed in constant space, can't we promise something about certain simple uses of continuations? Otherwise, they may avoided by programmers for the wrong reasons. Random notes [pg. 6, col. 2, +15] In the term "meta-program" well known? [pg. 30, col. 1] Some note is needed explaining why there are two different close procedures. [pg. 29] If call-with-current-continuation calls its argument with the current continuation, should the I/O routines call-with-input-file and call-with-output-file be renamed call-with-input-port and call-with-output-port? John  Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 JUN 86 00:16:04 EDT Received: from LIVE-OAK.LCS.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 27 JUN 86 00:14:00 EDT Received: from JOE-LOUIS.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 3220; Thu 26-Jun-86 19:04:00-EDT Date: Thu, 26 Jun 86 19:03 EDT From: Jonathan A Rees Subject: Remaining questions & remarks (2) To: rrrs-authors@MIT-MC.ARPA Message-ID: <"860626190326.1.jar@AI"@JOE-LOUIS.LCS.MIT.EDU> Almost no one answered my query about grandfathering. Think about it while answering the questions below. I propose listing incompatibilites in the "notes" section, and otherwise not worrying too much about the incompatibilities we're introducing. I'll send out a list of known language changes in a separate message. Here is the second list of remaining questions and remarks. Some of these may be duplicates. 1. BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report; it's obvious to the world we couldn't get consensus on this one. Many people have told me that they don't care which one is there, so long as there's only one. SEQUENCE was used heavily in S&ICP and for that reason I think it should be retained; thus the options I offer are (a) leave things as they are (BEGIN essential with non-essential synonym SEQUENCE), (b) remove BEGIN and make SEQUENCE essential (noting in the Notes section that BEGIN, like #!TRUE etc., should be supported by those implementations which care about running code written in the past year). Let me know your vote if you haven't done so already. 2. Similarly but less glaringly, we have a problem with the numeric comparisons. Again, many people have said they don't care but they only want one set, with or without question marks. Thus I offer the choices (a) leave things as they are (b) flush the alternative names ? >=? =? [The ones without question marks were used in S&ICP; moreover, they exist in other Lisp dialects. The argument in favor of the ?'s is that it allows the simple statement: "names of predicates end in question mark".] Send me your vote. 3. REC and NAMED-LAMBDA : Again, I sense capitulation on the part of some who have been stubborn. The only options permitted are: (a) Keep both (b) Flush both My editorial sense is that we should be able to achieve (b). Remember, the language also doesn't have EVAL, environments, or macros, so if you want to keep these features please say how they're different from other "indispensible" features that the language DOESN'T have. 4. SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT! : Many people have suggested removing these. Anyone who wants them retained MUST provide a convincing rationale, for inclusion in the report. Otherwise I'll remove them. 5. Should we say anything about the possibility of parallel or interleaved argument evaluation? Remembering something I thought I heard Will once say, I added the innocent little phrase "or perhaps in parallel" to the description of procedure calling. Richard Kelsey quickly pointed out that if it's mentioned as being a possibly legal implementation, many otherwise valid scheme programs may fail to run in implementations which do this, because they won't do necessary synchronization. I agree; this is acceptable only if we provide synchronization primitives. 6. Number input exactness: two proposals have been advanced to decide whether a number is exact or inexact if it has no #I or #E prefix and contains no trailing #'s. (a) Inexact if there are digits following a decimal point, or if exponential notation is used. Otherwise exact. (This makes exctness similar to "floatness" in CL.) (b) A proposal which Will advanced, which I'm unable to locate right now, so he'll have to re-send it. I'll additionally advance another alternative, and you can make up more of your own: (c) Always exact. E.g. "1.2" is exact. 7. Must a port still be a port (i.e. answer true to INPUT-PORT? or OUTPUT-PORT?) after being closed? 8. Apparently there's no difference between ABS and MAGNITUDE. Should we keep both? If so, should I change the presentation in any way? 9. ANGLE is what Common Lisp calls PHASE; any interest in changing the name? ... 10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)). Do we apply Occam's razor and remove it? If it's retained, then I'll just document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)). 11. JINX says: if PROCEDURE? exists, then a portable printer can be written. JAR replies (in jest): (define procedure? (lambda (obj) (not (or (pair? obj) (null? obj) (symbol? obj) (number? obj) ...)))) Seriously however, I was the only holdout at Brandeis against having this predicate. After thinking about this further I think it's not such a bad idea, even though it is of limited use. Is anyone opposed to having an essential procedure PROCEDURE?, to round out the set of type predicates? 12. (if x 1) vs. (cond (x 1)) -- this is inconsistent, as a couple of people have pointed out. I would expect these two expressions to have the same meaning, but they don't. The first is defined to always return an unspecified value. The second is defined to return the value 1 if x is true, and an unspecified value otherwise. I would like to make this consistent, and there are two ways to do. Take your pick: (a) Change IF expressions so that they return the value of the second form if the first form evaluates to false. (b) Change COND and CASE so that they return an unspecified value if there is no ELSE clause. Here are some arguments in favor of (a): - It removes the possibility of inferring that an implementation might not be tail-recursive through an alternate-less IF. - Similarly, it makes (IF #T ) mean the same as , and removes doubt about the meaning of things like (if x (if y 1) z). - It simplifies the macro expansion of COND as compared with (b). - Option (b) is obviously undesirable (consider the case of mutually exclusive test expressions in a COND). 13. Many people would like to see the (define ((((a b) c) d) e) ...) feature go away. S&ICP doesn't use it, and it has a rather complicated syntax (look at the BNF for evidence). Vote keep or flush. 14. Status of LOAD not resolved. If, as I suggested, LOAD is only to be syntactically valid at top level of a file, shouldn't it be renamed to be INCLUDE ? 15. Page breaks and tabs are mentioned in the report (actually I guess I added them - sorry), but there are no #\PAGE or #\TAB characters. Can this be made consistent by documenting #\PAGE and #\TAB, or should I try to neutralize or remove the places where I mention tabs and page breaks, by saying something to the effect that there may be other whitespace characters, and some of these characters might terminate comments? In Common Lisp, #\PAGE and #\TAB aren't "standard", they're only semi-standard; and I don't believe that 16. If page breaks are documented, should the terminate comments? I think they should (but of course they don't in Common Lisp). 17. Bartley says: "the second sentence of the description of EQUAL? should say that EQV? is used for all objects except pairs, vectors, and strings." Forcing it to use EQV? seems kind of random to me. This would of course make my notion of "apparent equivalence" useless, destroying what I deluded myself into thinking was an elegant symmetry between EQV? and EQUAL?; maybe it's a bogus idea anyhow. I intentionally wanted to be silent on this point, allowing EQUAL? to return true more often than EQV? perhaps, but I don't care that much. ----- Presentation questions: 18. Several people have complained about Clinger's perhaps overly accurate description of what happens when variables become bound. To be accurate, we have to say that locations are created and the initial value is stored in the location, but this doesn't sit well with the desire to have Scheme sound like an almost-functional language. What to do? 19. What should the dedication be? Sussman suggested the PDP-6, which was the world's first Lisp machine, but some people didn't like this joke. I have changed it to Christopher Strachey in the draft. 20. Is it OK to replace "Lazy ML" with "SASL" (last paragraph of section 0.0)? This is Dan Friedman's suggestion and I approve; SASL is more widely known. I've never heard of Lazy ML (although I can imagine what it is). 21. Should section numbers be zero-based? I'm beginning to think this looks unprofessional; and it just doesn't look right in several places. It worked well in the previous version of the report, and it's clearly more consistent with the language (which is zero-based), but it doesn't work the way I've reorganized things. If you like zero-based section numbers, speak up. 22. Was Scheme the first programming language to have first-class lexical closures? Can we say anything edifying along these lines? 23. I flushed the historical note "CATCH could be provided by a procedure" sentence (again, because two or three people thought it was random and I agreed), but some of you have complained about this. Why should this bit of history be present, but not others that are at least as important? 24. CALL/CC was mentioned in a sentence in a rationale in the RRRS. I flushed the reference because (a) a number of people find the name CALL/CC quite distasteful and (b) it is inconsistent to mention here that some scheme implementations provide an alternate name for this but not also do so for LABELS, BLOCK, and a zillion other things. 25. How best to resolve the inconsistencies between terminology in text and semantics? Namely: "I", "Ide", "identifier" in semantics vs. "variable" in text; "Com", "command" in semantics vs. "statement" in text. 26. FORCE & DELAY are still problematic. About half of respondents said it was better to put FORCE up front with DELAY, and the other half thought it was fine as it was. No one gave convincing arguments. 27. Is 3.0.2 (description of procedure calls) a good place to take note that () is not a valid procedure call? 28. In section 0.0, 2nd paragraph, before the terms "variable" and "identifier" have been defined, it should say "variable" instead of "identifier" to be consistent with the rest of the report. Is that OK? 29. There are two nonterminals in the BNF that need names. Currently they are called and which was never intended to be a serious suggestion (I put it there to see if anyone would actually read the BNF!). Actually one or both of these can go away if NAMED-LAMBDA and/or (DEFINE ((( ...) ...) ...) ...) go away. Can someone who likes these things take a look at the BNF and suggest names for these? 30. Someone wanted me to avoid discussion of immutable objects in the discussion of operational equivalence in the 2nd paragraph before entry for EQV? . I want to mention immutability there because I think it's important to warn users that this might be the case, otherwise they can easily end up writing unportable code. ----- For your information, here are changes I've made that either don't seem controversial or reflect what I judged to be the consensus: Language: Only one empty list, period. (eq? '() '()) returns true. Kelsey asks: why does ROUND round to even? Answer: Common Lisp does it this way. Ask Steele. Probably this has to do with statistical niceness. A port does not become closed as a side effect of reaching end of file. After end of file, you'll continue to read end of file objects as long as the port is open. It's an error to read from or write to a closed port. DISPLAY writes characters like WRITE-CHAR does. ----- Presentation: "Iterative process" --> "iterative computation" on page 3 (this change is an example of "desussmanization"). Inserted the following sentence in section 1.0: "In addition, \ide{+}, \ide{-}, \ide{1+}, and \ide{-1+} are identifiers." At Dan Friedman's request, I removed Perlis from the list of authors. Changed ? to < and > in all examples. Removed non-essential features from examples (including the big one) where possible: (1+ x) --> (+ x 1), (-1+ x) --> (- x 1), (define (foo ...) ...) --> (define foo (lambda ...)), 1-armed if --> cond, named let --> letrec. Changed variable name "loop" to "recur" in the call-with-current-continuation example. "iff" --> "if" in section 5.1. ----- That's all for now, folks... Jonathan  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 23 JUN 86 17:13:15 EDT Date: Mon, 23 Jun 86 17:11:43 EDT From: Jonathan A Rees Subject: Bibliography To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].60539.860623.JAR> I would like to update the "bibliography and references" section of the report. If you have published new papers on Scheme-related topics in the past year, or if you will have done so within the next few weeks, or if you're aware of something which ought to be included, please send me a complete, accurate reference, or an incomplete reference and enough information for me to be able to track it down. Already on my list of things to include are: - Felleison et al, Reasoning with Continuations (Logic in CS conf) - Kranz et al, ORBIT compiler (Compiler Construction conf) - Feeley, Deux approches a l'implantation du langage Scheme (masters thesis, Montreal) but I'm sure there are many others. Also, send your index entry suggestions. Jonathan  Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 19 JUN 86 23:02:27 EDT Received: from OZ.AI.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 19 JUN 86 23:01:11 EDT Date: 18 Jun 1986 14:33 EDT (Wed) Message-ID: From: Bill Rozas To: Jonathan A Rees Cc: rrrs-authors@MX.LCS.MIT.EDU Subject: Policy on change-making In-reply-to: Msg of 17 Jun 1986 22:08-EDT from Jonathan A Rees My feelings: - Don't be unneccessarily radical, but fix things which are broken, and change things to reflect the new consensus (if there is one). - I would like the incompatibilities mentioned in the notes section.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 19 Jun 86 00:44:37 EDT Received: from indiana by csnet-relay.csnet id ac01244; 19 Jun 86 0:38 EDT Date: Wed, 18 Jun 86 17:53:13 est From: Kent Dybvig To: bartley%ti-csl.csnet@CSNET-RELAY.ARPA, jar@MC.LCS.MIT.EDU Subject: Re: Number syntax Cc: rrrs-authors@MC.LCS.MIT.EDU I'm all for the modifications David and Mark suggest...the same issues have been annoying me, although I have no stake in Common Lisp. I suggest that David send out another letter with the wording/syntax he wants to make things easier for Jonathan.  Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JUN 86 22:10:52 EDT Received: from AI.AI.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 17 JUN 86 22:10:08 EDT Date: Tue, 17 Jun 86 22:08:58 EDT From: Jonathan A Rees Subject: Policy on change-making To: rrrs-authors@MX.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].58425.860617.JAR> A number of suggestions for incompatible changes are currently on the floor. Before I start polling y'all about these various questions (mostly removals), I would like to see if we can reach concensus on what our policy should be for making such incompatible changes. I think the policy we adopt will bear on the changes we decide we want to make. Questions that should be answered: - How radical ought we to be? That is, how important is compatibility with last summer's report? - Given that there will be incompatible changes, how should these be indicated in the report? Should I clutter the main text with little notes; should I make a list of all the changes; if I make such a list, where should it appear --- in the "notes" section, in the introduction, somplace else? Should the list include rationales I guess my current bias is either to omit the list entirely or relegate it to the notes section, in pursuit of a "crisper" [Dan Friedman's word] document. However, I again have nothing at stake, and don't care too much, so people with real implementations should speak up. Changes and removals (as opposed to clarifications or extensions) so far agreed upon include the omission of the "object table" chapter, the omission of all the #!foo constants, and the change in meaning of (define (foo ...) ...) [from using named-lambda to using lambda]. We have already decided on some others, and may decide on others still, in the coming weeks. What other documents do: The Revised Report on Scheme has pretty thorough notes about how the language changed, with complete rationales. The revised Algol 60 report merely enumerates, in a footnote, the section numbers of sections that were changed at the 1962 conference. The Algol 68 report has a comparison with Algol 60 (3 pages) as part of its introduction, and the Revised Algol 68 report also has a comparison with the non-revised Algol 68 report (4 pages). Jonathan  Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JUN 86 21:46:55 EDT Received: from AI.AI.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 17 JUN 86 21:46:13 EDT Date: Tue, 17 Jun 86 21:44:45 EDT From: Jonathan A Rees Subject: Number syntax To: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA cc: RRRS-Authors@MX.LCS.MIT.EDU In-reply-to: Msg of Tue 17 Jun 86 16:00:31-CDT from David Bartley Message-ID: <[AI.AI.MIT.EDU].58406.860617.JAR> Date: Tue 17 Jun 86 16:00:31-CDT From: David Bartley Does anyone agree with us? Is there time to make such a change before R^3RS goes to press? I agree with you, but I don't have anything at stake. If we can come to an agreement to change, I'd be happy to make the change. As far as time goes, I have yet to call Wexelblat again to find out the next deadline, buI imagine it will be the first week of July (for the September issue). I need to get a clean copy out to everyone at least, say, 10 days before SIGPLAN's deadline, so that means we should try to get stability by circa June 25. I'll aim for that, but of course my aim has not been good in the past. Jonathan  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 17 Jun 86 19:19:56 EDT Received: from ti-csl by csnet-relay.csnet id ao17298; 17 Jun 86 18:51 EDT Received: by tilde id AA27184; Tue, 17 Jun 86 17:08:11 cdt Date: Tue 17 Jun 86 16:00:31-CDT From: David Bartley Subject: Number syntax To: RRRS-Authors%mit-mc@CSNET-RELAY.ARPA Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Message-Id: <12215615581.31.BARTLEY@CSC60> 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. The R^3RS doesn't make clear which subset of the syntax of numbers is essential and what is optional. As implementors of systems in which Scheme and Common Lisp must co-exist, we're faced with two potential compatibility issues: (1) going with an ``extended subset'' of the Report's number syntax that is compatible with Common Lisp, or (2) going with the full number syntax in the Report to be compatible with all other Scheme implementations. 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. Our motivation, of course, is that we'd like programmers to feel free to use either language and exchange files of data without irritating obstacles being thrown in their path. If we can't agree on a consistent syntax for numbers, then we'll have to provide each language with two readers and the user will have to know which one to use. (There are other problems, of course, such as whether `:' is a constituent of an identifier or associated with Common Lisp package designations. We may have to go with separate readers/modes anyway.) Does anyone agree with us? Is there time to make such a change before R^3RS goes to press? Regards, David Bartley, Mark Meyer -------  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 13 Jun 86 12:33:09 EDT Received: from ti-csl by csnet-relay.csnet id ao20650; 13 Jun 86 12:26 EDT Received: by tilde id AA27555; Fri, 13 Jun 86 10:44:00 cdt Date: Fri, 13 Jun 86 10:44:00 cdt From: Mark Meyer To: RRRS-authors%mit-mc@CSNET-RELAY.ARPA Subject: Revised^3 Draft Comment Cc: mmeyer%ti-csl.csnet@CSNET-RELAY.ARPA In going over the grammar in the Revised^3 Report for numbers in Scheme, I noticed a possible omission. According to the production --> + #* / + #* the production of rationals, 1/2e3 is legal syntax while 1e3/2 is not. Shouldn't the production be amended to --> + #* / + #* so that the numerator as well as the denominator may carry a suffix? In that case, 1/2e3 would mean 1/2000 and 1e3/2 would be 1000/2 (=500). Mark Meyer (mmeyer@ti-csl)  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 10 Jun 86 10:40:50 EDT Received: from indiana by csnet-relay.csnet id a005144; 10 Jun 86 10:36 EDT Date: Tue, 10 Jun 86 01:43:10 est From: Kent Dybvig To: bartley%ti-csl.csnet@CSNET-RELAY.ARPA, jar@MC.LCS.MIT.EDU Subject: Re: portability Cc: rrrs-authors@MC.LCS.MIT.EDU I don't think this issue is as cut and dried as all that. Jonathan is right on the one hand; it is ``absurd'' to write portable programs if any identifier might be taken away by a particular implementation. However, it is not clear to me what the most practical solution is at this point for systems that have additional special forms or user- defined macros. It is certainly not practical to stay away from all special forms but those appearing in the report. Nor is it practical to invalidate a macro when a binding is found; as Jonathan points out, forward references become a problem. Perhaps it is practical to complain when a binding is found; this does not allow portable code but it does provide some level of sanity. And I'm not sure it is practical to have a "vanilla" mode; although the issue is worthy of consideration, what happens when someone wants a basically portable piece of code to use a system-specific special form? If I had to take a stand one way or another, I would probably favor a more liberal definition of keyword---rather than saying that all of the keywords are enumerated in the report, I would allow for the inclusion of additional keywords by any particular implementation, with the requirement that any implementation must provide a warning when a keyword is used as a variable. Writing portable code would be an iterative process, but it would be relatively painless. But I don't really want to take a stand at this point. I would rather leave this topic, along with the whole topic of macros, out of the report. That way we could experiment with various ways of doing things and at some point agree on the most practical way of dealing with the situation. (I was going to suggest that we require keywords to begin with an upper-case letter so that portable code could be written by employing only lower-case variable names, but I remembered that Scheme is case- insensitive. Sigh...) Kent  Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 JUN 86 19:43:14 EDT Date: Mon, 9 Jun 86 19:27:34 EDT From: Jonathan A Rees Subject: portability To: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA cc: RRRS-AUTHORS@MX.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].925333.860609.JAR> OK, my message seems to have confused a lot of people. I'll try to be clearer. For the purposes of this message I'll only consider system-supplied special form types, not user-supplied ones, although the problems are I think the same. Jim Miller said originally that he didn't see any way to write portable programs which used variables, because implementations were free to preempt arbitrary variable names for use as syntactic keywords. I just wanted to reply that on the contrary, the report is clear on what the set of allowable variable names is. The BNF describes a as being any which isn't a , and the are enumerated. E.g. according to my reading of the report, the sequence (define block (lambda (x) (extend x 3))) (define extend (lambda (a b) (list b a))) (block 1) has a perfectly well-defined meaning: BLOCK and EXTEND are variable names (unconditionally!); these names become bound to values; the value of BLOCK is applied to the number 1; etc. I didn't see anything in the report which allowed any implementation to assign any other meaning to this program fragment. Any implementation which did something different with this code fragment (e.g., T, which has BLOCK-expressions, and independent namespaces for variables and keywords) would not be implementing the language described in the report. I don't think this is a departure from the previous report, although of course my edits have made the *description* follow my world view more closely. The way so-called "syntactic extensions" usually (not always) work, however, is that they pre-empt certain identifiers for use as variable names. E.g. an implementation might make BLOCK or EXTEND unavailable. Or, worse, the variables remain available, but expressions whose cars are these names are no longer treated as procedure calls. Then the above program wouldn't have the expected meaning. I say that such modifications to the language aren't syntactic extensions, since they incompatibly change the meanings of programs, rather than just defining what would otherwise be an error situation. If the implementation is clever enough that program fragments like these still work, i.e. the extensions are only seen when the variable is undefined (a situation which would otherwise be an error), then that's fine, but I don't think that's how most scheme implementations out there actually implement their additional special form types. (Correct me if I'm wrong. Consider forward references.) Implementations can support macros (they can also support Algol 60 mode, or any other incompatible change, if they want -- it's not as if it's a sin to program in something other than reportified-scheme), so long as there's some way to run programs written in the language described in the report. Several existing implementations are already structured to make it easy to support multiple such modes or incompatible dialects; so what's the big deal? In short: why should the report say anything at all about this issue? To warn implementors not to do the wrong thing? Do we want to change the report to explicitly ALLOW the preemption of arbitrary variable names? I think Jim's question originated from a belief that implementations were free to do this and still claim to be adhering to the report. I think that's absurd. How should the report's examples, much less portable programs in general, be written in that case? Jonathan  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 7 Jun 86 21:19:58 EDT Received: from indiana by csnet-relay.csnet id a003864; 7 Jun 86 13:46 EDT Date: Fri, 6 Jun 86 15:43:12 est From: Kent Dybvig To: rrrs-authors@MC.LCS.MIT.EDU Subject: Re: add1 and sub1 Another alternative might be to make `1+' and `-1+' optional, since they aren't necessary in any sense. Then there would be no need to describe them to students at all. These are already innessential, in both RRRS and the draft RRRRS. Chez Scheme will support add1 and sub1 for Dan (and the Little LISPer), but I don't care if they appear in the report or not. I will also support 1- as an alternative for -1+; if ever there was a gratuitous difference from Common Lisp, -1+ is it. Actually, I'd prefer flushing 1+ and -1+ from the report, but it doesn't seem worth worrying about.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 7 Jun 86 21:18:13 EDT Received: from tektronix by csnet-relay.csnet id ad00288; 7 Jun 86 1:47 EDT Received: by tektronix.TEK (5.31/6.14) id AA19278; Fri, 6 Jun 86 09:06:33 PDT Received: by tekchips (5.31/5.14) id AA26553; Fri, 6 Jun 86 09:11:02 PDT Date: Fri, 6 Jun 86 09:11:02 PDT From: Norman Adams Message-Id: <8606061611.AA26553@tekchips> Subject: Re: named-lambda and rec To: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: Dan Friedman , Wed, 4 Jun 86 23:47:27 est I too would prefer to see both NAMED-LAMBDA and REC removed. -Norman -------  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 7 Jun 86 19:49:27 EDT Received: from indiana by csnet-relay.csnet id a005487; 7 Jun 86 19:00 EDT Date: Sat, 7 Jun 86 15:25:24 est From: Dan Friedman To: rrrs-authors@MC.LCS.MIT.EDU Subject: macros. Our programming relies heavily on the safe use of macros. No one here would be willing to remove the option of having them in the language. Dan  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 6 Jun 86 16:25:39 EDT Received: from ti-csl by csnet-relay.csnet id ad03178; 6 Jun 86 16:24 EDT Received: by tilde id AA18136; Fri, 6 Jun 86 14:06:53 cdt Date: Fri 6 Jun 86 13:55:31-CDT From: David Bartley Subject: Re: portability To: JAR%MX.LCS.MIT.EDU%mc.lcs.mit.edu@CSNET-RELAY.ARPA, JMiller%oz.ai.mit.edu@CSNET-RELAY.ARPA Cc: RRRS-Authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA, Bartley%TI-CSL@a In-Repl <[MX.LCS.MIT.EDU].924918.860606.JAR> Message-ID: <12212709243.41.BARTLEY@CSC60> From JAR: >I would say that a strict reading of the new draft, and perhaps even of >the RRRS, would say that ANY identifier other than those explicitly >listed as syntactic keywords (reserved words) may be used as a variable. >In other words, a correct implementation of the report would already >have the property that there are no other special forms other than the >ones explicitly listed in the report (the complete list is somewhere >inside the BNF). So that a program which does (define trace ...) or >(let ((loop ...)) ... (loop ...) ...) would already be portable. The >addition of ANY special form is an incompatible change to Scheme. Several implementations, including Chez Scheme, PC Scheme, and Scheme-84, allow user-specified syntactic extensions. I doubt if we could get a consensus that this is to be disallowed. When you (JAR) speak of special forms, are you including macros and the like? >[Actually, if in a particular implementation special-form-ness is >cancelled out by DEFINE and lambda-binding, then it would probably be OK >in that implementation to have extra special forms/macros lying around, >since a program which used those identifiers for variables would still >be correct. But let's not think about this possibility.] Is there an alternative possibility? (This paragraph seems to say that you are speaking of macros as well as special forms.) Regards, David Bartley -------  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 6 JUN 86 13:38:58 EDT Date: Fri, 6 Jun 86 13:38:45 EDT From: Chris Hanson Subject: add1 and sub1 To: dfried%indiana.csnet@CSNET-RELAY.ARPA cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Fri 6 Jun 86 09:57:13 est from Dan Friedman Message-ID: <[AI.AI.MIT.EDU].52665.860606.CPH> Date: Fri, 6 Jun 86 09:57:13 est From: Dan Friedman When describing arithmetic I find the symbols "1+" and "-1+" very harmful. Purely for pedagogical reasons I would like to see "add1" and "sub1" be optional. Another alternative might be to make `1+' and `-1+' optional, since they aren't necessary in any sense. Then there would be no need to describe them to students at all. In fact, there's no need to teach them even if they are essential.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 6 Jun 86 11:05:34 EDT Received: from indiana by csnet-relay.csnet id aa00907; 6 Jun 86 11:04 EDT Date: Fri, 6 Jun 86 09:57:13 est From: Dan Friedman To: rrrs-authors@MC.LCS.MIT.EDU Subject: add1 and sub1 When describing arithmetic I find the symbols "1+" and "-1+" very harmful. The function + is denoted by the symbol "+" and this confuses people who are trying to understand the primitive recursive definition of +. Purely for pedagogical reasons I would like to see "add1" and "sub1" be optional. I know that macscheme & PC-Scheme have included them. I don't like multiple names for the same construct, but we have a few instances already in the report. Dan  Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 6 JUN 86 10:59:40 EDT Date: Fri, 6 Jun 86 10:59:26 EDT From: Jonathan A Rees Subject: portability To: JMiller@OZ.AI.MIT.EDU cc: RRRS-Authors@MC.LCS.MIT.EDU In-reply-to: Msg of 5 Jun 1986 08:42-EDT from JMILLER at MIT-OZ Message-ID: <[MX.LCS.MIT.EDU].924918.860606.JAR> I would say that a strict reading of the new draft, and perhaps even of the RRRS, would say that ANY identifier other than those explicitly listed as syntactic keywords (reserved words) may be used as a variable. In other words, a correct implementation of the report would already have the property that there are no other special forms other than the ones explicitly listed in the report (the complete list is somewhere inside the BNF). So that a program which does (define trace ...) or (let ((loop ...)) ... (loop ...) ...) would already be portable. The addition of ANY special form is an incompatible change to Scheme. [Actually, if in a particular implementation special-form-ness is cancelled out by DEFINE and lambda-binding, then it would probably be OK in that implementation to have extra special forms/macros lying around, since a program which used those identifiers for variables would still be correct. But let's not think about this possibility.] I wouldn't say that all implementations would have to start up with the stripped-down syntax, omitting all their favorite features, but I think that supplying a mode in which this was the case, rather than saying only a certain class of identifiers can be used as variables, is the right thing. Would any implementors have any problem providing a report-syntax-only mode? I know this is trivial in MIT Scheme and T, but we haven't heard from other implementors. If there are problems, then one way to cope would be to add to the report's list of syntactic keywords some or all of the things which such implementations would like to have be special forms, e.g. define-macro, trace, make-environment, etc., simply saying that these are reserved for use by particular implementations as syntactic keywords, but have no meaning according to the report. This is sort of the dual of Jim's original suggestion. It's pretty gross, but I thought I'd mention it. How should this situation be explained in the report, if at all? Jonathan  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 5 JUN 86 13:54:39 EDT Date: Thu, 5 Jun 86 13:54:25 EDT From: Chris Hanson Subject: named-lambda and rec To: dfried%indiana.csnet@CSNET-RELAY.ARPA cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Wed 4 Jun 86 23:47:27 est from Dan Friedman Message-ID: <[AI.AI.MIT.EDU].52205.860605.CPH> Date: Wed, 4 Jun 86 23:47:27 est From: Dan Friedman Jinx recently suggested that he could live without either. I second jinx's suggestion. I `third' it.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 5 Jun 86 12:34:21 EDT Received: from indiana by csnet-relay.csnet id aa07465; 5 Jun 86 12:21 EDT Date: Wed, 4 Jun 86 23:47:27 est From: Dan Friedman To: rrrs-authors@MC.LCS.MIT.EDU Subject: named-lambda and rec Jinx recently suggested that he could live without either. I second jinx's suggestion. Dan  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 5 Jun 86 12:34:17 EDT Received: from indiana by csnet-relay.csnet id a007465; 5 Jun 86 12:21 EDT Date: Wed, 4 Jun 86 23:44:17 est From: Dan Friedman To: rrrs-authors@MC.LCS.MIT.EDU Subject: Will's proposal We are satisfied with Will's proposal re "set!". Dan  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 5 JUN 86 08:43:44 EDT Date: 5 Jun 1986 08:42-EDT Sender: JMILLER@MIT-OZ Subject: Re: portability From: JMILLER@MIT-OZ Reply-To: JMiller%OZ@MC To: RRRS-Authors@MC Message-ID: <[MIT-OZ] 5-Jun-86 08:42:33.JMILLER> In-Reply-To: <8606041651.AA28499@tekchips> I'd be happy with Will's suggestion, and it does make the writing of portable code considerably easier than my suggestion. I'm only concerned that this may require unanimous consent. I believe that the MIT system already includes the necessary hooks (we would supply an RRRS-Essential syntax table). --Jim  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 4 Jun 86 19:23:00 EDT Received: from tektronix by csnet-relay.csnet id ae02282; 4 Jun 86 18:58 EDT Received: by tektronix.TEK (5.31/6.14) id AA25894; Wed, 4 Jun 86 09:46:37 PDT Received: by tekchips (5.31/5.14) id AA28499; Wed, 4 Jun 86 09:51:05 PDT Message-Id: <8606041651.AA28499@tekchips> To: JMiller%OZ@MC.LCS.MIT.EDU Cc: RRRS-Authors@MC.LCS.MIT.EDU Subject: Re: portability In-Reply-To: Your message of 4 Jun 1986 08:51-EDT. <[MIT-OZ] 4-Jun-86 08:51:16.JMILLER> Date: 04 Jun 86 09:51:03 PDT (Wed) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Jim Miller writes: >I urge you to think, again, about including some formal and >mutually agreeable statement which limits the implementors choice >of names for special forms. I believe that this is the sole >requirement necessary to permit a person intent on writing a >totally portable program to succeed. Suppose every implementation of Scheme were required to supply a "vanilla" mode in which all reserved words are among those that appear in the report? Peace, Will  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 4 JUN 86 08:52:11 EDT Date: 4 Jun 1986 08:51-EDT Sender: JMILLER@MIT-OZ Subject: Re: portability From: JMILLER@MIT-OZ Reply-To: JMiller%OZ@MC To: RRRS-Authors@MC Message-ID: <[MIT-OZ] 4-Jun-86 08:51:16.JMILLER> In-Reply-To: <[MX.LCS.MIT.EDU].924086.860603.JAR> Well, I agree in principle with all that was said. But I think you have missed one important point: it is not possible, even with all the care in the world, to write portable code in the current design. I don't want to contort the language design in any way (and neither of my suggestions do that) but I DO want some statement which makes the possibility of portable code feasible. I urge you to think, again, about including some formal and mutually agreeable statement which limits the implementors choice of names for special forms. I believe that this is the sole requirement necessary to permit a person intent on writing a totally portable program to succeed. --Jim  Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 JUN 86 23:22:06 EDT Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 2325; Tue 3-Jun-86 23:22:23-EDT Date: Tue, 3 Jun 86 23:21 EDT From: Jonathan A Rees Subject: ftp-able r3rs.dvi To: rrrs-authors@MIT-MC.ARPA Message-ID: <860603232145.2.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU> I put the DVI file for the report on host MIT-PREP. The filename is /u/jar/r3rs.dvi - Jonathan  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 3 Jun 86 18:50:57 EDT Received: from tektronix by csnet-relay.csnet id ai02667; 3 Jun 86 18:43 EDT Received: by tektronix.TEK (5.31/6.14) id AA00979; Tue, 3 Jun 86 10:00:01 PDT Received: by tekchips (5.31/5.14) id AA14582; Tue, 3 Jun 86 10:04:26 PDT Message-Id: <8606031704.AA14582@tekchips> To: jar%mx.lcs.mit.edu@MC.LCS.MIT.EDU, dyb%indiana.csnet@CSNET-RELAY.ARPA Cc: rrrs-authors@MC.LCS.MIT.EDU Subject: Is BEGIN primitive? Date: 03 Jun 86 10:04:25 PDT (Tue) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Whether you think BEGIN must be a primitive expression depends on your cultural heritage. If you have grown up believing that syntax is fully checked before macro expansion, then (BEGIN X Y ...) ==> ((LAMBDA () X Y ...)) works fine. If you have grown up believing that macros do the least amount of syntax checking they can get away with (or less), then (BEGIN (DEFINE ...) ...) ==> ((LAMBDA () (DEFINE ...) ...)) does not detect the syntax error. I like the term "derived expression" because it expresses the fact that the semantics of BEGIN can be expressed in terms of primitive expressions without implying that a macro mechanism is used. Though the word "statement" ought to signify a declarative assertion, the American programming language community long ago corrupted it to signify a command. I prefer the English "command", but I prefer even "statement" to the phrase "expression evaluated solely for effect". Peace, Will  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 3 Jun 86 14:20:34 EDT Received: from northeastern by csnet-relay.csnet id a000357; 3 Jun 86 14:19 EDT Date: Tue, 3 Jun 86 11:29 EST From: MITCHELL WAND To: rrrs-authors@MC.LCS.MIT.EDU Subject: define 1. I think the discussion has clarified, at least for me, the difference between "internal" and "incremental" define. I was certainly thinking about "incremental" define, which happens conceptually at run-time. As I gather it, the idea is that internal define is JUST SYNTAX, which might be formalized as something like (define-equivalent-syntax ;; hypothetical pseudocode! ( (define name1 body1) ... ) (letrec ((name1 body1) ...) )) The only place where "internal" define acts truly incrementally is at the top level. If this is correct, then my objections are considerably lessened. The major complication of internal define, then, is sorting out in exactly which contexts this syntax is permissable. This is a matter on which I think there can be reasoned debate. 2. Will's proposal looks OK to me. 3. (make-local-variable 'foo) was a joke. No one seemed to get it. Sorry 'bout that. 4. Thanks to jinx and to jar for their thoughtful replies. In particular thanks to jar (I think) for extracting the historical record. I say "jar (I think)" because I've managed to lose my copy ($%^&! VMS mailer); could someone retransmit it? Tnx. Mitch  Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 JUN 86 13:08:08 EDT Date: Tue, 3 Jun 86 13:08:20 EDT From: Jonathan A Rees Subject: portability To: RRRS-AUTHORS@MX.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].924086.860603.JAR> The following is in response to Jim Miller's message about portability, which raises an important question I've been hoping to repress. But Freud tells us that the repressed always returns. - Jonathan Date: Sat, 31 May 86 21:32:00 EDT From: Jonathan A Rees To: GJC%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU cc: JAR at MX.LCS.MIT.EDU Re: revised^n report In-reply-to: Msg of Sat 31 May 86 13:16:32 EDT from George J. Carrette Message-ID: <[MX.LCS.MIT.EDU].923398.860531.JAR> Date: Sat, 31 May 86 13:16:32 EDT From: George J. Carrette To: JAR%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU One should be able to show that clever underspecification in a language spec is eventually a losing proposition. Example: in CL (make-array 3) => #(0 0 0) (e.g. in VAX-NIL) or #(NIL NIL NIL) in at least the LISPM environments I'm aware of. The idea is to make the guy say (make-array :initial-element ) if he is depending on the initial value. Supposed to be a big efficiency win. (now, I've just spent a few hours tracking down a bug in the DOE-MACSYMA plot package that had to do with the initial element of an array screw). A few days ago you had a note to the CL list about a similar underspecification screw in defstruct. Well, revised^n has its share of clever underspecification too. But, is this really a win in a language spec? Or is it just a way of showing (forcing down everybodies neck...) how much the language designers know about different implementation tricks? You dont see this kind of stuff in other language specs. Back to the array example. Is it reasonable to argue that in lisp there are good natural default values? The empty list as default for an array? I think it is. On the other hand, if you know that there might be machine dependancies in these defaults, (in fact it is usually operating system dependancies. VMS goes to some trouble to make sure pages allocated to users are filled with zero's) then why not have: (make-array 10 :initial-element *:system-prefered-initial-array-element). I argue that clever underspecifications for the purpose of elicidating implementation tricks know by the language designers causes: * "dating" of the language. * frustration for users of the language * eventual lack of portability. This is all too true. I think that if I were designing another language now I would try to get rid of all underspecifications, since they lead to so much confusion. I hope that as many underspecifications as possible will disappear from Common Lisp. Let me try to figure out why I think it's OK for Scheme to be underspecified and not for Common Lisp to be underspecified. Scheme's underspecifications don't generally have anything to do with "implemetation tricks." Political expediency demands that the report leave a lot of room for local variation. We wouldn't be able to get agreement on all these little things. Some differences between versions result from differing implementation demands, but mostly it's that the different groups have incompatible ideologies, so each group would have its own idea of what the "right" thing is for each situation. The goals of Revised^n Scheme differ from those of Common Lisp, I think. Mostly we want to be able to read each others' code when it appears in the literature, and relieve people from the pain of there being incompatible languages all calling themselves "scheme". Portability is only a secondary consideration, and we're not so concerned that all non-erroneous programs should port, only that "well-written" programs should port. I think there's the feeling that people who write in Scheme don't just play around until their code just happens to work (often the only programming technique available in some systems which will remain nameless) -- they actually write "clean" code which observes data abstractions and doesn't depend on things it shouldn't depend on (like the initial value of vector components). So while it's very easy to write unportable code, people who do so have somehow missed the point, and probably ought to be programming in CLU or Ada (or the language I have yet to design?) instead. If we really want to aim for airtight portability then we've got to start making a lot of changes. Jonathan.  Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 JUN 86 12:52:26 EDT Date: Tue, 3 Jun 86 12:37:27 EDT From: Jonathan A Rees Subject: APPEND! To: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Mon 2 Jun 86 18:46:15-CDT from David Bartley Message-ID: <[MX.LCS.MIT.EDU].924078.860603.JAR> Maybe we should just flush APPEND! altogether? It's easy enough to do (SET-CDR! (LAST-PAIR list1) list2). I think Sussman was the one who really wanted APPEND! in the language, but I forget why. Jonathan  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 2 Jun 86 21:02:04 EDT Received: from ti-csl by csnet-relay.csnet id a014023; 2 Jun 86 20:52 EDT Received: by tilde id AA20278; Mon, 2 Jun 86 19:00:17 cdt Date: Mon 2 Jun 86 18:46:15-CDT From: David Bartley Subject: Re: definitions; APPEND!; etc To: willc%tekchips.tek@CSNET-RELAY.ARPA, rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA Cc: jar%mc.lcs.mit.edu@CSNET-RELAY.ARPA, Bartley%TI-CSL@CSNET-RELAY.ARPA, 605301901283@tekchips MMDF-Warning: Parse error in original version of preceding line at CSNET-RELAY.ARPA Message-Id: <12211713593.48.BARTLEY@CSC60> [Bartley:] >>APPEND! always side-effects all but its last argument. [Clinger:] >No, APPEND! should not be required to perform side effects. This is not >as silly as it may sound. In an implementation using the Hewitt-Lieberman >gc algorithm, for example, side effects to sufficiently old structures are >likely to be more expensive than consing. APPEND! should be free to decide >for itself which technique is fastest. My point of view is that APPEND! is used to ensure sharing of structure and APPEND is used to ensure that structure is NOT shared (except in the clearly specified case of the last argument). >I would feel differently if APPEND! returned an unspecified value, as >does VECTOR-SET!. Perhaps that would be more consistent. Perhaps we should call it SET-LAST-CDR! instead! Seriously, I could go either way, but I'm sure some of my code would fail to work on a system in which APPEND! did not share structure. Are there any others we should be discusssing? --db-- -------  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 2 Jun 86 18:57:59 EDT Received: from tektronix by csnet-relay.csnet id an13197; 2 Jun 86 18:51 EDT Received: by tektronix.TEK (5.31/6.14) id AA09219; Mon, 2 Jun 86 13:19:31 PDT Received: by tekchips (5.31/5.14) id AA05517; Mon, 2 Jun 86 13:23:57 PDT Message-Id: <8606022023.AA05517@tekchips> To: rrrs-authors@MC.LCS.MIT.EDU Cc: jar%mx.lcs.mit.edu@MC.LCS.MIT.EDU, wand%northeastern.edu@CSNET-RELAY.ARPA, dfried%indiana.csnet@CSNET-RELAY.ARPA Subject: DEFINE -- a concrete proposal Date: 02 Jun 86 13:23:55 PDT (Mon) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA I propose that section 4.1.0 of the 22 May 1986 draft be clarified to read as follows: At the top level of a program, a definition (define ) has essentially the same effect as the assignment expression (set! ) if is bound. If is not bound, however, then the definition will bind before performing the assignment, whereas it would be an error to perform a set! on an unbound variable. [examples go here] Top level definitions are essential; all Scheme implementations must support them. Some implementations of Scheme use an initial environment in which all possible variables are bound to locations, most of which contain undefined values. Top level definitions in such an implementation are truly equivalent to assignments. In my opinion, this is merely a clarification because the draft does not say that the initial environment must contain only the variables mentioned in the report, and it is in fact the case that most implementations supply variables that don't appear in the report. Furthermore, even if unbound variables exist, the phrase "it would be an error" indicates that implementations are not required to complain when one is assigned, so an implementation is free to do something random (like bind the variable and do an assignment) instead of signalling the error. The phrase "Some implementations of Scheme" is the very same neutral phrase used at the beginning of Section 4.2 on internal definitions. Thus the report would be neutral between those who for whatever reason want to assign variables before they declare them and those who for whatever reason prefer the internal definition syntax to LETREC. Since this is only a clarification of what is already implicit in the report, I believe this proposal should satisfy those who prefer the status quo. I believe it should also satisfy those who with Mitch are arguing for the following: An implementation may have a top level (initial, whatever) environment in which every possible identifier is bound (though only some are initialized). This would allow programs in that implementation to do a set! on a global variable (excuse me, a variable in the current top-level environment) from an internal scope without having to explicitly bind the variable in the initial scope. It would also allow MIT-style define to proceed, as it does not require the existence of a distinguished global environment. Mitch is entirely right that his proposal retains the spirit of the Brandeis agreement on this issue. Though Jonathan said in his reply to Mitch that he wouldn't have too much problem with adding this clarification to the report, he insisted that it should be "accompanied by some mention of the fact that some implementations have principled reasons for not having this feature". I say that stipulation is unfair -- the report doesn't contain any of the principled arguments against internal definitions or against the fancy DEFINE syntax or against REC or against NAMED-LAMBDA or against NIL or against the behavior of EQ? on procedures or against hexadecimal notation... Dan Friedman had some very reasonable things to say about the importance of simplicity and elegance, particularly with regard to ease of implementation by students. My answer is that students should implement "Essential Scheme" instead of worrying about how to get ASIN to work with complex numbers. Essential Scheme does not have internal definitions, and it is perfectly all right to use an initial environment in which all variables are bound and to implement DEFINE as assignment. I must admit that Essential Scheme is a more elegant language than full Scheme. I second Bill Rozas's objections to MAKE-LOCAL-VARIABLE as a procedure for performing incremental definitions. Let us seek peace, William Clinger ---------------------------------------------------------------- [Because of one mailer error, the local postmaster has suggested that people send me mail at willc@tekchips.tek.csnet instead of at willc%tekchips@tektronix.csnet, which had worked fine until now. If one doesn't work, please try the other.]  Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 JUN 86 18:56:44 EDT Date: Mon, 2 Jun 86 18:41:25 EDT From: Jonathan A Rees Subject: sentiments To: dyb%indiana.csnet@CSNET-RELAY.ARPA cc: dfried%indiana.csnet@CSNET-RELAY.ARPA, rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Sun 1 Jun 86 16:21:30 est from Kent Dybvig Message-ID: <[MX.LCS.MIT.EDU].923886.860602.JAR> Date: Sun, 1 Jun 86 16:21:30 est From: Kent Dybvig That begin must be a core special form results from the fact that in the report, (begin (define ...) ...) must not open up a new scope; i.e., (begin x y ...) must not be defined as ((lambda () x y ...)), or the more traditional form ((lambda (t) (begin y ...)) x) where t does not appear free in (begin y ...). I think of this as the "usual expansion". I get the feeling you haven't read the report. According to NEITHER Will's RRRS, NOR the draft I sent out, is (begin (define ...) ...) a syntactically valid expression! Look again at the BNF and at the text. The usual expansion ((lambda (t) (begin y ...)) x) works perfectly well since can't produce anything of the form (define ...), s can only occur in 's and 's, and the syntax of s is (begin +), not (begin ). The RRRS says that definitions are expressions, which isn't exactly wrong, but it seemed a little misleading to me, since they aren't legitimate in all places where expressions are supposed to be. (Again, only the details of the description have changed, not the language described!) Maybe you're misled by the statement in the RRRS that "(lambda (var1 ...) expr1 expr2 ...) is equivalent to (lambda (var1 ...) (begin expr1 expr2 ...))". This can be seen to be technically true if either (a) you take this statement to be only about the essential subset or (b) definitions aren't expressions (so that the statement wouldn't apply in the case of (begin (define ...) ...)). The BNF in the draft makes the error of classifying (begin ...) as primitive instead of derived. This is an error. (At one point I too was confused and thought that begin had to be primitive, but Sussman straightened me out). Sorry if this bug confused you. I will fix it. I wouldn't brag about this! Having already expanded Scheme from expressions and functions to statements and procedures, we are now adding declarations. What happened to simplicity? "Now"? The fact that definitions weren't valid in copntexts other than top level and the beginnings of "bodies" was agreed on Brandeis and hasn't been challenged until now. Introducing the term "statement" to mean an expression whose value is thrown away seems harmless to me; I was inspired to do this by the abstract syntax that Will sent me for the denotational semantics (which sets Com = Exp). Using "* " instead of "+" also gives a rationale for requiring at least one expression in LAMBDA, BEGIN, etc. If there's general sentiment that this is a bad idea, I'll flush it, but I thought it was reasonable. We all know why we use "procedure" instead of "function". I don't understand how this makes the language more complex. Your question about simplicity is pure propaganda, so I won't answer it beyond the above remarks. As has been explained innumerable times, there is no way to avoid this and have a language which is at all coherent with T and MIT Scheme. Note that in all programming languages of the Algol/Pascal/C variety it is an error to assign to an undeclared variable. That MIT Scheme and T (and thus RRRS Scheme) also have this property is not coincidence. Algol, Pascal, and C are not (typically) interactive languages, nor do they have such nice features as first-class functions that allow one to form modules of functions sharing local state/help functions. I think that it would be possible in any system to have a notion of a "top-level" lexical environment which implicitly contains bindings for all things not bound elsewhere. This could be a per-user or per-module thing; it need not be the outermost lexical environment. I repeat: "there is no way to avoid [requiring that variables be bound before they're assigned] and have a language which is at all coherent with T and MIT Scheme." I never said it would be impossible to implement. And interactiveness has nothing to do with it. ... I don't either, but I think what he means is that only a handful of experienced implementors will understand how a full Scheme system is implemented. ... Dan was referring, I'm sure, to the core of the language, which he feels must now not only include lambda, set!, quote, if, identifiers, and applications but also begin and define, not to mention the added complexity of lambda. Do I need to mail out a complete evaluator in order to drive the point home? I think you misunderstood his point completely here. He was merely wondering of what use internal define is if you have letrec, and noted that you can get letrec trivially with lambda and set!, if you like. No one ever said internal defines were linguistically necessary. They are obviously redundant. They are there because it's very important to be compatible with something so central to S&ICP. Like I say, talk to Sussman and Abelson if you dispute this. I agree in principle with this idea. It makes sense that define at top level should be treated specially, and nested definitions such as those given throughout S&ICP are quite handy and encourage modularity in a nice way. Since this treatment would not affect lambda or let, it would be easy to understand and easy to implement. How does its not affecting lambda or let have anything to do with how easy it is to implement? Implementing internal defines involves one trivial loop, and it doesn't matter whether you put this loop in the code for lambda or define, although it DOES matter if you have to invoke it two places. I would agree to using something totally different for definitions or perhaps use the define/set! combinations for our interpretation of internal define if we all agreed that define were only to be used at top level, with the nested syntax. I would even agree to making top-level, nested define a required feature, and to requiring that define not be used anywhere else. I don't understand this paragraph at all. Note that no one has ever wanted internal defines to be essential in any context. ... We have an exceptionally tight community of people working on/with Scheme and it is not good for us to put each other at odds by publishing a feature that some of us strongly dislike in its current form. Like I say, talk to Abelson and Sussman. I think a lot has and can be done to make internal definitions minimally ugly and intrusive. It is not good to confuse many innocent bystanders and put your community at odds with MIT's by permitting an incompatible meaning for DEFINE. Jonathan.  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 JUN 86 10:28:49 EDT Date: 2 Jun 1986 10:28-EDT Sender: JMILLER@MIT-OZ Subject: Another Can of Worms? From: JMILLER@MIT-OZ Reply-To: JMiller%OZ@MIT-MC To: rrrs-authors@MC Message-ID: <[MIT-OZ] 2-Jun-86 10:28:16.JMILLER> I've withheld this one for a long time on the theory that new problems with the language should be discussed AFTER the imminent publication of the standard. Since we appear to have stalled that yet again, I'd like to mention it. I am very concerned about the fact that the document we are promulgating as a language standard permits of no way to write truly portable code. This arises from the lack of a convention which would permit me to choose the names of variables which will guarantee me that no implementation has used those names as special forms. I know of two solutions: (a) a gentleman's agreement to the effect that every implementation will support some well-publicized mechanism for absorbing foreign portable code (in MIT Scheme, for example, we could provide a portable syntax table for this purpose); or (b) as in BCPL, make a formal statement as part of the language design that certain names will never be used as the names of built-in special forms. I am in favor of option (b) since it prevents the current implementors from becoming a select small clique which has more knowledge than outsiders. One such proposal would be that we insert a statement somewhere to the effect that "No implementation shall supply by default a special form with ":" in its name". Thus portable code uses variables with ":" in them somewhere and all is well. [FYI, the BCPL statement was that reserved words were all lower-case and more than one letter long.] -- Jim Miller  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 2 Jun 86 00:59:17 EDT Received: from indiana by csnet-relay.csnet id a005855; 2 Jun 86 0:57 EDT Date: Sun, 1 Jun 86 16:21:30 est From: Kent Dybvig To: jar@MC.LCS.MIT.EDU Subject: Re: sentiments Cc: dfried%indiana.csnet@CSNET-RELAY.ARPA, rrrs-authors@MC.LCS.MIT.EDU Date: Fri, 30 May 86 15:34:53 est From: Dan Friedman Sent-by: Kent Dybvig First, let me apologize that the note from Dan looked like it was coming from me. I did "su dfried" and resent the note for him after his first try failed. I thought that it would put his name on the note. I also apologize for the length of this note, which is due primarily to the fact that I have included the entirety of Jonathan's response to Dan's note. ... define was merely an alias for set! ... This is how things were prior to the Brandeis meeting. This is how things were AT INDIANA prior to the Brandeis meeting. At Yale and MIT they somewhat different (although not as different as you suppose) and had been since at least 1981. Your quest for elegance is noble but please try not to equate your own version of Scheme with Scheme. This is how things were in the first two Scheme reports, in several Indiana Schemes, in one North Carolina Scheme, and probably in other Schemes as well as of the Brandeis meeting. As I recall the feeling at the Brandeis meeting most of us were willing to go along with the idea of limiting the use of "define" internally to the semantics of SI&CP. This was in the interest of good feeling about not undermining their book. I hope everyone understands that I do not want to undermine their book, although I would like to see them rewrite it without internal defines. However, when I went along with this view I had underestimated how damaging this decision would be to the characterization of Scheme being a simple language. I was expecting a "comment" in the report that stated that "use of define within the text of a program would be restricted to the use as given in SI&CP." Instead, the definition of "lambda" got changed. I don't understand. Is it really the case that S&ICP never ever uses internal defines in the body of a lambda? I'll check. In any case, if internal definitions exist at all, LAMBDA is the ONLY form that's affected, after macro expansion. I quickly scanned S&ICP and I found two uses of define within let (pp. 234 and 238), and a mention of the use of a lambda-expression translator to support internal definitions (p. 440). The obvious implication to the thoughtful reader is that the authors intend to allow definitions at the front of a lambda body; however, it might also be reasonable to only effect "define" (and "let" if the few uses are considered enough reason to complexify it). Instead, begin must be added to the list of special forms. Not true, and I'm don't understand why you think so. Note that I clearly put BEGIN in the "derived expression types" section. I will include the usual expansion of it in a future draft; I forgot to note that this was on my list of things to do. That begin must be a core special form results from the fact that in the report, (begin (define ...) ...) must not open up a new scope; i.e., (begin x y ...) must not be defined as ((lambda () x y ...)), or the more traditional form ((lambda (t) (begin y ...)) x) where t does not appear free in (begin y ...). I think of this as the "usual expansion". Instead the macro for "letrec" must be conscious of it by having the body be "(let () )" where it should be . I proposed flushing internal definitions in the body of a letrec for exactly this reason. But I don't see this as increasing the complexity of LETREC significantly, and I was wrong to draw attention to it. I'll try to figure out how to make this smoother. You are right, it is not much, but any added complexity is a shame, especially when the added complexity is to support an innessential feature (other than the one being described, of course). Instead define must be added to the list of special forms. What do you mean? Definitions aren't even expressions! I wouldn't brag about this! Having already expanded Scheme from expressions and functions to statements and procedures, we are now adding declarations. What happened to simplicity? Instead the semantics of "set!" are weakened so that it is not possible to just get by with "set!" and ignore "define". As has been explained innumerable times, there is no way to avoid this and have a language which is at all coherent with T and MIT Scheme. Note that in all programming languages of the Algol/Pascal/C variety it is an error to assign to an undeclared variable. That MIT Scheme and T (and thus RRRS Scheme) also have this property is not coincidence. Algol, Pascal, and C are not (typically) interactive languages, nor do they have such nice features as first-class functions that allow one to form modules of functions sharing local state/help functions. I think that it would be possible in any system to have a notion of a "top-level" lexical environment which implicitly contains bindings for all things not bound elsewhere. This could be a per-user or per-module thing; it need not be the outermost lexical environment. Instead we must do something "special" with "lambda", "named-lambda", "let", "let*", and "letrec". Certainly the report is muddled, and I must accept the blame for some of this muddle. I introduced a lot of the nonsense you're complaining about into this version of the report in a quest for accuracy. I agree with your complaint that internal definitions are intrusive, and I'll do what I can to remedy the situation. We have taken a rather elegant language and made it elitest. I don't understand this use of that term. I don't either, but I think what he means is that only a handful of experienced implementors will understand how a full Scheme system is implemented. I wanted all of my students to be able to implement "Scheme" when they walked out of my course, now that is no longer possible. This is false. Internal defines are not essential. If by "Scheme" you mean absolutely everything described in the report, I would expect that internal definitions (which can be implemented with a very small amount of code) would be the least of any implementor's worries. What about number I/O? Dan was referring, I'm sure, to the core of the language, which he feels must now not only include lambda, set!, quote, if, identifiers, and applications but also begin and define, not to mention the added complexity of lambda. It was a great beauty of Scheme that the four mentioned special forms along with identifiers and application were the only syntax. It was wonderful that a CPS interpreter for Scheme was all that was necessary to come to grips with in order to understand the run-time architecture of Scheme. Why isn't this still true? My argument with internal-define is not that it is good or bad, but that the subtlety of its definition is unnecessary with judicious use of letrec and letrec should be a trivial macro. What happened? How do internal definitions make LETREC more complicated? The (LET () ...) (which would otherwise be a (BEGIN ...)) is trivial compared to the rest of what LETREC has to do, and doesn't even have to be there at all if you're not implementing the full language. I think you misunderstood his point completely here. He was merely wondering of what use internal define is if you have letrec, and noted that you can get letrec trivially with lambda and set!, if you like. I have never liked internal defines. Thanks for telling me, I hadn't figured this out. I thought they were harmless until I saw what havoc they introduced to the Report. I am trying desperately to convince everyone that we made a mistake and we should do everything in our power before we go public on this Report to wait until we impose internal defines on everyone. I'll do what I can to fix the presentation; I can at least certainly make internal definitions less intrusive than they were in the RRRS. I hope that will be sufficient. Personally, I wouldn't mind removing internal definitions from the language, although special treatment of definitions at top level of a file (which is another story altogether) must stay. I agree in principle with this idea. It makes sense that define at top level should be treated specially, and nested definitions such as those given throughout S&ICP are quite handy and encourage modularity in a nice way. Since this treatment would not affect lambda or let, it would be easy to understand and easy to implement. I would agree to using something totally different for definitions or perhaps use the define/set! combinations for our interpretation of internal define if we all agreed that define were only to be used at top level, with the nested syntax. I would even agree to making top-level, nested define a required feature, and to requiring that define not be used anywhere else. If you can convince everyone, including Sussman and Abelson, that internal definitions should be flushed, then I'll flush them. If you must persue this, I suggest you talk to Sussman on the telephone about this; he isn't reachable by electronic mail until June 20, I think. I'll try to find his phone number at Princeton or HP or wherever he is. Why does this question arise at this moment? I am angered by the untimeliness of this debate. Why didn't it come up when the idea of printing the report in SIGPLAN was first mentioned? This part of the language hasn't changed. We are all very sorry for the lateness of the debate, but it has taken time to absorb everything (and we have brought it up before publicly and privately, perhaps not as loudly). None of us had used a system with the internal definitions until after the RRRS (not R3S) came out, so we must plead a certain amount of ignorance in earlier discussions. On the other hand, it is more important on the eve of SIGPLAN publication than at any previous time, since that will be the first wide distribution of a Scheme report, and we must come together on this issue. We have an exceptionally tight community of people working on/with Scheme and it is not good for us to put each other at odds by publishing a feature that some of us strongly dislike in its current form. We ask your forgiveness and patience; please realize that we understand and very much appreciate all of your time and effort that has gone gone into this report. Jonathan Kent  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 JUN 86 23:49:28 EDT Date: Sun, 1 Jun 86 23:49:21 EDT From: Chris Hanson Subject: schedule To: JAR@AI.AI.MIT.EDU cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Thu 29 May 86 14:36 EDT from Jonathan A Rees Message-ID: <[AI.AI.MIT.EDU].49879.860601.CPH> I would vote for waiting a little longer before publishing, to get it done right. It's not terribly important to me that it happen immediately.  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 JUN 86 11:13:41 EDT Date: 1 Jun 1986 11:10 EDT (Sun) Message-ID: From: Bill Rozas To: Jonathan A Rees Cc: rrrs-authors@MC.LCS.MIT.EDU, WAND%northeastern.edu@CSNET-RELAY.ARPA Subject: define -- a modest proposal In-reply-to: Msg of 1 Jun 1986 02:03-EDT from Jonathan A Rees In Algol 60 a is a or a , so Algol 60 has the property you want, that regions are always fully parenthesized (by BEGIN ... END). I always rationalized Scheme's lack of "outermost parentheses" by the fact that there would be no point in having them if you would always have to write them -- they would be redundant. I imagine that those parentheses are there, just outside the edge of my files, providing a region for my files' top level bindings to live in. (The T compiler actually puts the parentheses there, treating a file boundary as a sort of a macro.) In MIT Scheme, the syntaxer (a program which translates s-expressions into Scode, shared by the interpreter and the compiler) "puts" the parantheses there by building an Scode object called an open-block around the "top level". The main unpleasantness I see is the syntactic oddity that a is a sequence of intermixed s and s (it's very important that s aren't s!), whereas a is a sequence of s followed by a sequence of s. I think I suggested fixing this a while ago (whether to people at MIT or to RRRS-Authors I don't remember), so that s and s could have the same syntax and semantics (if internal definitions were supported at all, that is), but this suggestion was not well received. This change would make Scheme like Algol 68, which also allows one to intersperse statements and declarations within a "series" (the region ("range") of a declaration includes previous statements and declarations in its "series"). The other way to resolve the inconsistency is to be like Algol 60 and require that all the definitions in a program go at the top, before any statements (expressions), but somehow I don't think people would buy that. I object to mixing internal definitions and expressions. I also object to mixing top level definitions and expressions although I admit to being guilty of laziness and occasionally doing the latter. I never (as far as I can remember) mix them internally, and try to avoid mixing top level ones also. I would not mind (and might even applaud) a decision forcing top-level definitions to come first, which would make the intenal and external cases more symmetric. [Perhaps we should separate DEFINE into two procedures: (make-local-variable 'foo) (set! foo value) A reasonable idea. In MIT Scheme, (make-local-variable 'foo) is written (define foo). (Or do you really mean a procedure?) If people like this feature (which causes the variable to become bound but unassigned, like in LETREC) I'd be happy to see it go into the report. It is bothersome that one has to specify an initial value, and this seems as good a way as any to avoid having to do so. It is completely unacceptable if it is a procedure (which was my understanding given the wording and the QUOTE). This would imply runtime definition (INCREMENTAL DEFINE), rather than static definition (INTERNAL DEFINE). It also has the problem that if it is a procedure, it needs the environment where the definition must occur as an argument. Procedures cannot pick it up at run time. If it is a special form, the QUOTE is not needed (nor the environment, which is available at evaluation time), and it could be made static (as I would expect everyone to want), but then it is exactly internal DEFINE, so why change names? I agree that (define foo) is reasonable, although only needed at top level. I use it often in MIT-Scheme. In particular I use it as an idiom indicating that the this variable is going to be assigned. I specify an initial value only when it will not change. It is not needed elsewhere (in MIT Scheme) because (let ((foo)) ...) gives me a local binding for FOO which I can then assign. Note: no one at Indiana replied to Hanson's message, even though it isn't conclusive. (I don't even think it's true; there could be multiple "global" environments, and SET!'s could be associated with them lexically.) Did they assume that SET! would be changed? JAR, I can't believe YOU have the bad taste to consider this (using SET! to bind) seriously. One of the features that I dislike the most from MacLisp and Franz (which is a poor clone of MacLisp), is that SETQ is used to bind variables. I always use DEFCONST and DEFVAR before assigning anything. Making this the standard (eliminating DEFINE) would guarantee that I would never write in the standard dialect. I'm sure that other people at MIT find this proposal as distasteful as I do. I don't object to a system (like MacScheme, for example) where SET! "works", but under no circumstances will I accept a situation where it is the only way to do it. On such systems, top-level DEFINE would be a NO-OP, which is fine with me, as long as it is available.  Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 JUN 86 02:18:12 EDT Date: Sun, 1 Jun 86 02:03:01 EDT From: Jonathan A Rees Subject: define -- a modest proposal To: WAND%northeastern.edu@CSNET-RELAY.ARPA cc: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].923455.860601.JAR> Date: Fri, 30 May 86 10:40 EST From: MITCHELL WAND I think it is clear that we do not have a consensus on the semantics of internal DEFINE. This isn't clear to me. I thought we had always agreed that internal definitions were just sugar for LETREC (see Will's message of 11 November 84, excerpted below). My understanding of the compromise reached at Brandeis was that lexically nested DEFINE would retain the MIT semantics, whereas the IU semantics could be obtained by using DEFINE! . The current report does not appear to be compatible with that compromise, because it would appear necessary to do a (define foo 'hunoz) at top-level before one can legally do a set! on foo from an interior scope. At first I thought that you had misremembered, but I just went back to the archives, and you are right. However, DEFINE! was later flushed -- without any liberalization of SET! . The discussion was obviously incomplete (as you can tell by reading it), and we're completing it now. Will did the right thing since he flushed features that not everyone wanted, namely (a) DEFINE! and (b) an environment in which SET! could cause unbound variables to become bound. See the Appendix to this message for the exchange. I was moderately happy with how that turned out and implicitly assumed that if people had serious troubles with the RRRS they would have spoken up ages ago. My attempts to clarify things have apparently drawn attention to issues which have been peacefully asleep for over a year. Analyzing this situation, there are two operations involved in a define: 1. Binding the identifier to some location. 2. Storing a value in that location. The latter operation is clearly doable by set!, so the only issue is #1. The MIT semantics has DEFINE performing #1 on the current scope. The advantage of this proposal is that it is uniform on both "top-level" and interior scopes. The disadvantage is that it essentially creates a new scope (region) in the program which is not delimited by parentheses. This is true, the region is only the of the LET or whatever expression, not the entire expression, so the region isn't delimited by left and right parentheses. The region of a definition at top level of a file is similarly not delimited by parentheses, although for a slightly different reason. I wouldn't say the definition creates the scope, I'd say that the scope is created by the expression in whose body the definition appears. But what is so unusual about this? The region of a binding created by LET is also not delimited by parentheses; it's not the entire LET expression. [Perhaps the grammar could be fixed to recognize this new, non-list-structure phrase?]. What change do you suggest? Why don't and foot the bill? A is exactly the region of the bindings specified by internal definitions which begin it. A (which, I suppose, is the concatenation of all the files comprising a running Scheme program, or something like that) is the region of bindings created by top level definitions. This is an unpleasantness at the top level which I do not think we understand. I guess I'm losing track of what you're saying. I agree that there is much unpleasantness, but to which one are you referring? In Algol 60 a is a or a , so Algol 60 has the property you want, that regions are always fully parenthesized (by BEGIN ... END). I always rationalized Scheme's lack of "outermost parentheses" by the fact that there would be no point in having them if you would always have to write them -- they would be redundant. I imagine that those parentheses are there, just outside the edge of my files, providing a region for my files' top level bindings to live in. (The T compiler actually puts the parentheses there, treating a file boundary as a sort of a macro.) The main unpleasantness I see is the syntactic oddity that a is a sequence of intermixed s and s (it's very important that s aren't s!), whereas a is a sequence of s followed by a sequence of s. I think I suggested fixing this a while ago (whether to people at MIT or to RRRS-Authors I don't remember), so that s and s could have the same syntax and semantics (if internal definitions were supported at all, that is), but this suggestion was not well received. This change would make Scheme like Algol 68, which also allows one to intersperse statements and declarations within a "series" (the region ("range") of a declaration includes previous statements and declarations in its "series"). The other way to resolve the inconsistency is to be like Algol 60 and require that all the definitions in a program go at the top, before any statements (expressions), but somehow I don't think people would buy that. [Perhaps we should separate DEFINE into two procedures: (make-local-variable 'foo) (set! foo value) A reasonable idea. In MIT Scheme, (make-local-variable 'foo) is written (define foo). (Or do you really mean a procedure?) If people like this feature (which causes the variable to become bound but unassigned, like in LETREC) I'd be happy to see it go into the report. It is bothersome that one has to specify an initial value, and this seems as good a way as any to avoid having to do so. [Another, separate, argument against including internal define as an optional feature in the report is that, unlike the other optional features in the report, it requires pervasive modifications in many other sections of the report]. I agree that the presentation is bad. This is a real problem which, as I said in my message to Dan, I think I can fix, by going back to something closer to Will's approach, which was much less intrusive. I take full responsibility for having screwed this up. What I will argue for is the following: An implementation may have a top level (initial, whatever) environment in which every possible identifier is bound (though only some are initialized). This would allow programs in that implementation to do a set! on a global variable (excuse me, a variable in the current top-level environment) [Can you define "current"?] from an internal scope without having to explicitly bind the variable in the initial scope. It would also allow MIT-style define to proceed, as it does not require the existence of a distinguished global environment. I think this proposal retains the spirit of the Brandeis agreement on this issue. If people generally think it's OK if this is documented as an optional language feature (as was DEFINE! previously), I don't have too much problem with putting it in the report, if it's accompanied by some mention of the fact that some implementations have principled reasons for not having this feature. (Dan has complained to me, however, that he doesn't want the report to contain advertisements for random features of various dialects, so I wouldn't know quite how to do this.) My main complaint is that it would be nice to be able to support as many as possible of the report's non-essential features in T and MIT Scheme, and it would be a substantial amount of work to implement this particular feature in T and MIT Scheme; causing assigned variables to become bound in an appropriate contour involves a bothersome non-local code transformation. The MIT Scheme and T designers have worked hard to implement truly block-structured languages which, like Algol, have no distinguished top-level environments. (Algol 68's "standard prelude" and its mechanism of "particular-programs" is block structure to the max -- can someone tell me what would correspond to the proposed SET! extension in Algol 68?) Legitimizing binding-from-a-distance (or environments in which all variables are bound, which amounts to the same thing) in the Scheme report is a threat to the pedagogical and engineering effort we've put in. Of course, de-legitimizing unprepared SET!'s is apparently a threat to your investment. I thought the compromise in the RRRS was a good one considering how different our world views were. With apologies to you and Dan for the angry tone & the abundance of parenthetical remarks. I'm tired. Jonathan. ------ APPENDIX. Historical record of the DEFINE! and SET! debate. Clinger, 11 Nov 84, preliminary report on the workshop: (DEFINE id expr) allows top-level definitions of variables. Its semantics at top level are similar to the semantics of (SET! id expr). The difference is that if id is not already bound to a location, then the DEFINE form binds id before performing the assignment, whereas it would be a mistake to perform a SET! on an unbound identifier. Optionally, (DEFINE! id expr) is equivalent to (DEFINE id expr) when typed at the top level. Within code, (DEFINE! id expr) is equivalent to (SET! id expr) unless id is unbound, in which case the DEFINE! form creates a new top level binding for id before performing the assignment. Optionally, DEFINE may be used for internal definitions as in MIT Scheme and in the book by Abelson and Sussman. If allowed at all, internal definitions are permitted only in the bodies of LAMBDA, LET, LETREC, and similar binding constructs. Furthermore they must precede the rest of the body. With these restrictions, the semantics of internal definitions can be explained in terms of LETREC. For example, ... Pitman, 6 Dec 84: The term "top-level binding" is ... completely vague in DEFINE!'s definition. Rees, 14 March 85: ... And incidentally, I don't remember the rationale for having both DEFINE! and DEFINE. I understand why DEFINE shouldn't have hairy syntax, but what does DEFINE! give you that the stripped-down DEFINE doesn't? Clinger, 18 March 85, "final" draft of report: (define! var expr) special form If var is bound, then the define! form is equivalent to the corresponding set!. If var is unbound, however, define! binds var in the global environment before performing the assignment. Haynes and Friedman, 27 Mar 85: DEFINE! and DEFREC! should go away. (Yes, We were among those who wanted them originally, but they aren't worth it.) We're not fond of DEFINE either and wish it could go the same way, or at least be optional. Bartley, 29 March 85: I'm willing to lose DEFINE! and DEFREC!, as Chris and Dan suggest. Rozas, 27 March 85: How am I supposed to define things if both DEFINE! and DEFINE go away? Haynes, 29 March 85, answering Rozas: With SET!, provided one assumes that all identifiers are initially bound in the global environment, or that SET! can extend the global environment. With the exception of MIT's Scheme, this is what existing systems do. If MIT is unwilling to change this, then we are reluctantly stuck with DEFINE. Hanson, 30 March 85, answering Haynes: This is a terrible idea. It seems that the ability to have many different environments in which to perform incremental definitions has been consistently overlooked by almost everyone except MIT Scheme and T. Anyone who has ever tried to program a BIG system, and by that I mean something over 500-1000 pages of code, knows that this kind of packaging is **ESSENTIAL**!! So please don't try to take this away. Haynes, 31 March 85, answering Hanson: We grant the importance of such a facility, and are not trying to take it way; but there is no concensus on how to provide such a facility, so it is too soon to standardize on one. (Similarly, syntactic extensions are **ESSENTIAL** to the kind of thing we do here; but it is also too soon to standardize on a syntactic extension mechanism.) We were simply debating whether SET! should be required to extend the global environment if its identifier is unbound (or equivalently, have everything bound in the global environment to begin with). This would make DEFINE unessential, though it might still be optional. It has nothing to do with multiple environments for incremental definition, except that MIT uses DEFINE for both purposes. Hanson, 2 April 85, answering Haynes: What I wanted to say was: if SET! extends the "global" environment, then that environment has become special in that it is the ONLY environment that can be extended by interactive definition. This would seem to preclude the existence of many such environments. DEFINE eliminates the problem, because it specifies, very precisely, the environment in which the name is bound. Clinger, 20 April 85: define! and defrec! will be flushed altogether. Note: no one at Indiana replied to Hanson's message, even though it isn't conclusive. (I don't even think it's true; there could be multiple "global" environments, and SET!'s could be associated with them lexically.) Did they assume that SET! would be changed?  Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 MAY 86 19:07:29 EDT Date: Sat, 31 May 86 18:53:02 EDT From: Jonathan A Rees Subject: sentiments To: dfried%indiana.csnet@CSNET-RELAY.ARPA cc: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].923375.860531.JAR> Date: Fri, 30 May 86 15:34:53 est From: Dan Friedman Sent-by: Kent Dybvig ... define was merely an alias for set! ... This is how things were prior to the Brandeis meeting. This is how things were AT INDIANA prior to the Brandeis meeting. At Yale and MIT they somewhat different (although not as different as you suppose) and had been since at least 1981. Your quest for elegance is noble but please try not to equate your own version of Scheme with Scheme. As I recall the feeling at the Brandeis meeting most of us were willing to go along with the idea of limiting the use of "define" internally to the semantics of SI&CP. This was in the interest of good feeling about not undermining their book. I hope everyone understands that I do not want to undermine their book, although I would like to see them rewrite it without internal defines. However, when I went along with this view I had underestimated how damaging this decision would be to the characterization of Scheme being a simple language. I was expecting a "comment" in the report that stated that "use of define within the text of a program would be restricted to the use as given in SI&CP." Instead, the definition of "lambda" got changed. I don't understand. Is it really the case that S&ICP never ever uses internal defines in the body of a lambda? I'll check. In any case, if internal definitions exist at all, LAMBDA is the ONLY form that's affected, after macro expansion. Instead, begin must be added to the list of special forms. Not true, and I'm don't understand why you think so. Note that I clearly put BEGIN in the "derived expression types" section. I will include the usual expansion of it in a future draft; I forgot to note that this was on my list of things to do. Instead the macro for "letrec" must be conscious of it by having the body be "(let () )" where it should be . I proposed flushing internal definitions in the body of a letrec for exactly this reason. But I don't see this as increasing the complexity of LETREC significantly, and I was wrong to draw attention to it. I'll try to figure out how to make this smoother. Instead define must be added to the list of special forms. What do you mean? Definitions aren't even expressions! Instead the semantics of "set!" are weakened so that it is not possible to just get by with "set!" and ignore "define". As has been explained innumerable times, there is no way to avoid this and have a language which is at all coherent with T and MIT Scheme. Note that in all programming languages of the Algol/Pascal/C variety it is an error to assign to an undeclared variable. That MIT Scheme and T (and thus RRRS Scheme) also have this property is not coincidence. Instead we must do something "special" with "lambda", "named-lambda", "let", "let*", and "letrec". Certainly the report is muddled, and I must accept the blame for some of this muddle. I introduced a lot of the nonsense you're complaining about into this version of the report in a quest for accuracy. I agree with your complaint that internal definitions are intrusive, and I'll do what I can to remedy the situation. We have taken a rather elegant language and made it elitest. I don't understand this use of that term. I wanted all of my students to be able to implement "Scheme" when they walked out of my course, now that is no longer possible. This is false. Internal defines are not essential. If by "Scheme" you mean absolutely everything described in the report, I would expect that internal definitions (which can be implemented with a very small amount of code) would be the least of any implementor's worries. What about number I/O? It was a great beauty of Scheme that the four mentioned special forms along with identifiers and application were the only syntax. It was wonderful that a CPS interpreter for Scheme was all that was necessary to come to grips with in order to understand the run-time architecture of Scheme. Why isn't this still true? My argument with internal-define is not that it is good or bad, but that the subtlety of its definition is unnecessary with judicious use of letrec and letrec should be a trivial macro. What happened? How do internal definitions make LETREC more complicated? The (LET () ...) (which would otherwise be a (BEGIN ...)) is trivial compared to the rest of what LETREC has to do, and doesn't even have to be there at all if you're not implementing the full language. I have never liked internal defines. Thanks for telling me, I hadn't figured this out. I thought they were harmless until I saw what havoc they introduced to the Report. I am trying desperately to convince everyone that we made a mistake and we should do everything in our power before we go public on this Report to wait until we impose internal defines on everyone. I'll do what I can to fix the presentation; I can at least certainly make internal definitions less intrusive than they were in the RRRS. I hope that will be sufficient. Personally, I wouldn't mind removing internal definitions from the language, although special treatment of definitions at top level of a file (which is another story altogether) must stay. If you can convince everyone, including Sussman and Abelson, that internal definitions should be flushed, then I'll flush them. If you must persue this, I suggest you talk to Sussman on the telephone about this; he isn't reachable by electronic mail until June 20, I think. I'll try to find his phone number at Princeton or HP or wherever he is. Why does this question arise at this moment? I am angered by the untimeliness of this debate. Why didn't it come up when the idea of printing the report in SIGPLAN was first mentioned? This part of the language hasn't changed. Jonathan  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 31 May 86 10:37:01 EDT Received: from indiana by csnet-relay.csnet id aa06940; 31 May 86 10:36 EDT Date: Fri, 30 May 86 15:34:53 est From: Kent Dybvig To: rrrs-authors@MC.LCS.MIT.EDU Subject: sentiments Cc: jar@MC.LCS.MIT.EDU I believe I must explain to you why I am as upset about internal-define as I am. This report has been a long time in coming and as it approaches its final form, it begins to look quite splendid. So much so that I believe that its potential for generating converts will be quite substantial. That was, in fact, one of its goals. However, we Schemer's have had the freedom for several years of writing code for papers and books in just about any dialect we felt the audience could/would follow. Scheme has been a fabulous tool for that purpose. The simplicity of the language and the elegance of its definition attracted us and I am sure many of you towards it. How simple was it? In the presence of macro expansion, we needed the following 4 special forms: "quote", "lambda", "if", and "set!". Many implementations began to exist on micros. One of my students, Mark Meyer, implemented an entire Scheme system including engines, macros, a compiler, the run time support in 5k bytes on a IBM PC. He did this as an undergraduate in the 5 weeks following my undergraduate programming languages course. Now it was the case that "set!" assigned to the closest lexical "rib" and we assumed that the bottom rib had all known identifers assigned to either "unbound" or, in the case of +, to some value. This really was simple. With this view, define was merely an alias for set!. However, define's value was its first argument and set!'s value was its second argument. This is how things were prior to the Brandeis meeting. As I recall the feeling at the Brandeis meeting most of us were willing to go along with the idea of limiting the use of "define" internally to the semantics of SI&CP. This was in the interest of good feeling about not undermining their book. I hope everyone understands that I do not want to undermine their book, although I would like to see them rewrite it without internal defines. However, when I went along with this view I had underestimated how damaging this decision would be to the characterization of Scheme being a simple language. I was expecting a "comment" in the report that stated that "use of define within the text of a program would be restricted to the use as given in SI&CP." Instead, the definition of "lambda" got changed. Instead, begin must be added to the list of special forms. Instead the macro for "letrec" must be conscious of it by having the body be "(let () )" where it should be . Instead define must be added to the list of special forms. Instead the semantics of "set!" are weakened so that it is not possible to just get by with "set!" and ignore "define". Instead we must do something "special" with "lambda", "named-lambda", "let", "let*", and "letrec". We have taken a rather elegant language and made it elitest. I wanted all of my students to be able to implement "Scheme" when they walked out of my course, now that is no longer possible. It was a great beauty of Scheme that the four mentioned special forms along with identifiers and application were the only syntax. It was wonderful that a CPS interpreter for Scheme was all that was necessary to come to grips with in order to understand the run-time architecture of Scheme. My argument with internal-define is not that it is good or bad, but that the subtlety of its definition is unnecessary with judicious use of letrec and letrec should be a trivial macro. What happened? I have never liked internal defines. I thought they were harmless until I saw what havoc they introduced to the Report. I am trying desperately to convince everyone that we made a mistake and we should do everything in our power before we go public on this Report to wait until we impose internal defines on everyone. Dan  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 MAY 86 00:34:03 EDT Date: 31 May 1986 00:32 EDT (Sat) Message-ID: From: Bill Rozas To: MITCHELL WAND Cc: rrrs-authors@MC.LCS.MIT.EDU Subject: define -- a modest proposal In-reply-to: Msg of 30 May 1986 11:40-EDT from MITCHELL WAND I may have misunderstood your message, but I'm afraid you are still confusing (local static) INTERNAL DEFINE with (dynamic, horrible semantically) INCREMENTAL DEFINE. They have nothing in common (except sharing the keyword). INTERNAL DEFINE does NOT create a new scope. The scope is created by the surrounding LAMBDA, LET, or LETREC expression, and is therefore bounded by parentheses. (let () (define foo ...) (define bar ...) ) should be exactly equivalent to (letrec ((foo ...) (bar ...)) ) As a matter of fact, I originally implemented LETREC in MIT-Scheme (and it is still implemented in this way in MIT CScheme, I believe), by transforming the second expression into the first. Thus, the (INTERNAL) DEFINEs do not establish the context. The context is established by LET. Your proposal of separating DEFINE into (make-local-variable 'foo) (set! foo value) seems to violate this semantics. It appears to be advocating for INCREMENTAL DEFINE, which is NOWHERE on the report. Indeed, MIT Scheme has a primitive procedure which implements INCREMENTAL DEFINE, on top of which MAKE-LOCAL-VARIABLE could be implemented trivially, but we are certainly not advocating for a feature we don't feel comfortable with ourselves. INTERNAL DEFINE is purely declarative, it does not involve ANY side effects. INCREMENTAL DEFINE, on the other hand, is mostly imperative, and involves side effecting environments. As far as I know (please correct me on this), INTERNAL DEFINE has no semantic problems, its only problem is purely syntactic: it makes the evaluator (compiler, syntaxer, code walker, whatever) harder to write since it has to collect all the definitions which occur in a scope before processing the expressions. Since the report only allows definitions as the very first thing in a block (it's the only place where they make sense), collecting them is trivial.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 30 May 86 19:59:54 EDT Received: from northeastern by csnet-relay.csnet id ae01577; 30 May 86 19:49 EDT Date: Fri, 30 May 86 10:40 EST From: MITCHELL WAND To: rrrs-authors@MC.LCS.MIT.EDU Subject: define -- a modest proposal I think it is clear that we do not have a consensus on the semantics of internal DEFINE. My understanding of the compromise reached at Brandeis was that lexically nested DEFINE would retain the MIT semantics, whereas the IU semantics could be obtained by using DEFINE! . The current report does not appear to be compatible with that compromise, because it would appear necessary to do a (define foo 'hunoz) at top-level before one can legally do a set! on foo from an interior scope. Analyzing this situation, there are two operations involved in a define: 1. Binding the identifier to some location. 2. Storing a value in that location. The latter operation is clearly doable by set!, so the only issue is #1. The MIT semantics has DEFINE performing #1 on the current scope. The advantage of this proposal is that it is uniform on both "top-level" and interior scopes. The disadvantage is that it essentially creates a new scope (region) in the program which is not delimited by parentheses. [Perhaps the grammar could be fixed to recognize this new, non-list-structure phrase?]. This is an unpleasantness at the top level which I do not think we understand. [Perhaps we should separate DEFINE into two procedures: (make-local-variable 'foo) (set! foo value) [shades of GNU Emacs-Lisp!!]] [Another, separate, argument against including internal define as an optional feature in the report is that, unlike the other optional features in the report, it requires pervasive modifications in many other sections of the report]. Nevertheless, I am not yet arguing for elimination of internal defines from the report, in keeping with the compromise reached at Brandeis. What I will argue for is the following: An implementation may have a top level (initial, whatever) environment in which every possible identifier is bound (though only some are initialized). This would allow programs in that implementation to do a set! on a global variable (excuse me, a variable in the current top-level environment) from an internal scope without having to explicitly bind the variable in the initial scope. It would also allow MIT-style define to proceed, as it does not require the existence of a distinguished global environment. I think this proposal retains the spirit of the Brandeis agreement on this issue. Mitchell Wand  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 30 May 86 19:57:43 EDT Received: from northeastern by csnet-relay.csnet id ac01577; 30 May 86 19:48 EDT Date: Fri, 30 May 86 10:04 EST From: MITCHELL WAND To: rrrs-authors@MC.LCS.MIT.EDU Subject: procedure (Tnx) Thanks to Jonathan for so promptly accepting my suggestion that we delay publication until these issues are resolved. -- Mitch  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 30 May 86 19:48:45 EDT Received: from ti-csl by csnet-relay.csnet id ab01528; 30 May 86 19:37 EDT Received: by tilde id AA15347; Fri, 30 May 86 17:50:20 cdt Date: Fri 30 May 86 17:42:25-CDT From: Don Oxley Subject: Re: Embedded DEFINE forms To: gls%Think.COM@CSNET-RELAY.ARPA, rrrs-authors%mc@CSNET-RELAY.ARPA In-Reply-To: <8605290514.AA08588@Godot.Think.COM> Message-Id: <12210915540.62.OXLEY@CSC60> I have generally avoided getting into these discussions as David has represented our viewpoints very effectively. However, I am becoming concerned about what looks like a potentially destructive argument over DEFINE. It seems to me that it is unlikely that very many users outside of the aficionados at MIT and IU are likely to use embedded DEFINE at all - except as they may have seen it in S&ICP. I would hate to see "outsiders" back away from using SCHEME because they see a religious war going on within the community. My first suggestion is to leave it as we decided at Brandeis - based on the notion that we had agreement (even if grudging) and we do not have an agreement on a change. Possibly better is Guy's suggestion to leave it undefined (which I think is roughly equivalent to letting the dominant dialect win). I would be very hesitant for us to have to change PC Scheme in an incompatible direction. I'll hazard a guess that PCS is or is close to becoming the most widely used Scheme today, so we are trying to be somewhat careful about compatibility (although as I said, I doubt if this will affect very many users). Either leaving the position as it is or making it undefined would leave PCS alone. Please, let's not let this become a divisive issue that hurts the spread of Scheme to those who don't care about so technical an issue and merely what to know what the langauge does and does not do. --Don -------  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 30 May 86 17:30:31 EDT Received: from tektronix by csnet-relay.csnet id ac00463; 30 May 86 17:19 EDT Received: by tektronix.TEK (5.31/6.12) id AA16726; Fri, 30 May 86 12:04:15 PDT Received: by tekchips (5.31/5.14) id AA21283; Fri, 30 May 86 12:08:30 PDT Message-Id: <8605301908.AA21283@tekchips> To: rrrs-authors@MC.LCS.MIT.EDU Cc: jar@MC.LCS.MIT.EDU Subject: definitions; APPEND!; etc Date: 30 May 86 12:08:29 PDT (Fri) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Since the report won't appear in SIGPLAN Notices until after the Lisp conference, I too favor waiting another month. ---------------------------------------------------------------- At Brandeis we agreed that (BEGIN (DEFINE ...) (DEFINE ...)) would be flattened when it appeared at the beginning of a lambda body, but I forgot to mention that in the RRRS. It seems simplest to extend that flattening to apply to the top level as well by changing the formal syntax of to be --> (define ) | (define ( ) ) | (begin +) This still rules out things like (begin (define up) (define down) (let ((n 0)) (set! up (lambda () (set! n (1+ n)) n)) (set! down (lambda () (set! n (-1+ n)) n)))) After writing the new syntax for that would be needed to allow this, I decided it isn't worth it. ---------------------------------------------------------------- I prefer dropping both NAMED-LAMBDA and REC to leaving them both in. ---------------------------------------------------------------- I have a few remarks to add to some of David Bartley's comments. >Add "in the same order" at the end of "Two procedures are >operationally equivalent iff ... they return the same value and >perform the same side-effects." (Or is that implied by `having the >same side-effects'?) There is still considerable research directed toward formulating a satisfactory notion of operational equivalence for procedures with side effects in the presence of concurrency, or even in the presence of asynchronous interrupts. To see that the definition on page 14 is inadequate, consider that (lambda (x) (set! x (1+ (1+ x))) x) and (lambda (x) (set! x (1+ x)) (set! x (1+ x)) x) are operationally equivalent but (lambda (y) (set! x (1+ (1+ y))) x) and (lambda (y) (set! x (1+ y)) (set! x (1+ x)) x) are not. >APPEND! always side-effects all but its last argument. No, APPEND! should not be required to perform side effects. This is not as silly as it may sound. In an implementation using the Hewitt-Lieberman gc algorithm, for example, side effects to sufficiently old structures are likely to be more expensive than consing. APPEND! should be free to decide for itself which technique is fastest. I would feel differently if APPEND! returned an unspecified value, as does VECTOR-SET!. >Rephrase "to make all user populations happy". >I'm< not happy with >having both forms (e.g., both = and =?) and I'd settle for EITHER ONE! I have been one of the main holdouts here, but I too am now willing to settle for either one. >If we only have SUBSTRING-MOVE-RIGHT! to support text editors, let's >flush it! This is only the tip of the iceberg when it comes to handy >little utility functions for building editors. I agree. I think we should write other documents, however, to describe the portable Scheme libraries that people have written, and we should work on improving portability and availability. peace, Will  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 May 86 18:47:48 EDT Received: from tektronix by csnet-relay.csnet id a003857; 29 May 86 18:45 EDT Received: by tektronix.TEK (5.31/6.12) id AA25806; Thu, 29 May 86 15:24:54 PDT Received: by tekchips (5.31/5.14) id AA13361; Thu, 29 May 86 15:29:04 PDT Message-Id: <8605292229.AA13361@tekchips> To: rrrs-authors@MC.LCS.MIT.EDU Cc: willc%tekchips.tektronix.csnet@CSNET-RELAY.ARPA Subject: Re: global definitions Date: 29 May 86 15:29:02 PDT (Thu) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Though I spent time in Indiana, I must join with JINX and Andy in protest against the very idea of global definitions. If we must have global definitions, I propose that the syntax be (SETF (SYMBOL-FUNCTION 'FOO) ...) so as to avoid gratuitous differences between Scheme and Common Lisp. As prelude to more serious comments, let me summarize the status quo: INCREMENTAL DEFINE: Not in the report, but appears in S&ICP. Supported only by MIT Scheme, though T has something similar. INTERNAL DEFINE: Optional in the report, pervasive in S&ICP. Alternative syntax for LETREC. Supported by MIT Scheme, PC Scheme, and MacScheme. TOP-LEVEL DEFINE: Essential in the report. It is up to the programming environment whether top-level definitions are implemented as global bindings, incremental bindings, or assignments; it makes very little semantic difference. Supported by everyone. I don't want to give in to Guy's suggestion that internal definitions be dropped entirely because it would return us to the days when we couldn't read each other's code. The implementations that support internal definitions for compatibility with S&ICP would go on supporting them, while people using Chez Scheme and Scheme-84 would write syntactically identical code that does something completely different. If everyone could agree not to use DEFINE except at top level I might agree with Guy, but that just isn't going to happen. (For instance, the idea of dropping internal DEFINE wouldn't even have come up if the people at Indiana weren't so insistent on using the word DEFINE at places other than top level.) Though I once programmed in the Indiana style, I have found it easy to switch to the new idiom: (define foo) (define bar) (let () (set! foo ...) (set! bar ...)) I am partly in the dark because I have not yet received Chris Haynes's message, but I suspect that folks at Indiana have not really given the above idiom a chance because the one message I have received says only that both "define!" and "global-define" were tried. In short, I'm not a fan of the internal definition syntax, but I vote in favor of keeping it in the report so as to prevent the syntax from being used with two incompatible semantics. Peace, Will  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 MAY 86 18:42:11 EDT Date: Thu, 29 May 86 18:42:02 EDT From: Jonathan A Rees Subject: R3RS draft -- procedural To: WAND%northeastern.edu@CSNET-RELAY.ARPA cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Thu 29 May 86 10:32 EST from MITCHELL WAND Message-ID: <[AI.AI.MIT.EDU].48143.860529.JAR> Date: Thu, 29 May 86 10:32 EST From: MITCHELL WAND In view of this situation, I think it would be a serious mistake to "mail it to SIGPLAN June 1 come hell or high water". I think those of us whose names will appear as authors of the report deserve to see a CLEAN draft before it is submitted. The document is too important not to get it right. OK.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 May 86 17:40:28 EDT Received: from [30732002700] by CSNET-RELAY.ARPA id a003087; 29 May 86 16:54 EDT Received: from BOETHIUS.THINK.COM by Godot.Think.COM; Thu, 29 May 86 16:50:11 edt Date: Thu, 29 May 86 16:50 EDT From: Guy Steele Subject: hash-consing To: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA, RRRS-Authors%mit-mc@CSNET-RELAY.ARPA Cc: gls@AQUINAS.THINK.COM In-Reply-To: <12210304495.60.BARTLEY@CSC60> Message-Id: <860529165056.1.GLS@BOETHIUS.THINK.COM> Dr. Eiichi Goto has done the greatest amount of work on hash-consing; I think he may have invented the idea. See the bibliography of the paper by Goto et al. in the 1982 Lisp conference. --Guy  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 May 86 17:40:14 EDT Received: from northeastern by csnet-relay.csnet id a001585; 29 May 86 14:20 EDT Date: Thu, 29 May 86 10:32 EST From: MITCHELL WAND To: rrrs-authors@MC.LCS.MIT.EDU Subject: R3RS draft -- procedural I have been looking at the draft of the R3RS which was distributed (dated 22 May). There are certainly a number of issues (some serious) which need to be resolved. In addition, there are many places in the report (marked by open brackets) which have not yet been filled in, and where the completion is substantive, rather than presentational. In view of this situation, I think it would be a serious mistake to "mail it to SIGPLAN June 1 come hell or high water". I think those of us whose names will appear as authors of the report deserve to see a CLEAN draft before it is submitted. The document is too important not to get it right. I will send out my other comments in some other messages. Mitch Wand  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 May 86 17:39:12 EDT Received: from ti-csl by csnet-relay.csnet id aa00976; 29 May 86 13:21 EDT Received: by tilde id AA23409; Thu, 29 May 86 11:09:54 cdt Date: Thu 29 May 86 10:35:51-CDT From: David Bartley Subject: define To: RRRS-Authors%mit-mc@CSNET-RELAY.ARPA Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Message-Id: <12210575742.48.BARTLEY@CSC60> There is clearly no chance of a consensus on the meaning of an internal DEFINE. It seems fair to let the current draft go through without changes from the previous one, since that was the understanding at Brandeis. The only viable solutions for the future are to remove internal DEFINEs entirely (as Guy suggests) or to persuade the Indiana folk to choose a new name. (I thought `DEFINE!' was appropriate--whatever happened to it?) I prefer the second option. Now that Scheme systems are being broadly distributed, it is important for us to show a united front. I would understand a user's anger if he could not find compatible implementations for his range of machines. I understand IU's feelings, but I think a compromise with DEFINE! or DEF or whatever is in the same spirit as all of us have solved similar inconsistencies in the past. Regards, David Bartley -------  Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 MAY 86 17:35:14 EDT Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 29 MAY 86 14:37:56 EDT Date: Thu, 29 May 86 14:36 EDT From: Jonathan A Rees Subject: schedule To: rrrs-authors@MIT-MC.ARPA Message-ID: <"860529143648.3.jar@AI"@ROCKY-GRAZIANO.LCS.MIT.EDU> Thanks to everyone who has read the draft report so carefully. But don't stop -- keep those cards and letters coming. I called Wexelblat about the production schedule for August and September SIGPLAN. He said he has to have it in his hands by June 13 (needs a page count sooner) if it's to go into the August issue (which gets mailed out the first week of August). So this gives us a little more time. However: the August issue is getting to be pretty full; if we think it's urgent that it be published, it's possible to get it in, but he would prefer if it waited for the September issue. I told him that some of the coauthors were ancy to get the thing published and that I'd ask them what they thought. Note that it won't get out to people before the Lisp conference in any case. I'm inclined to try to push and get it into the August issue, but if people think we should spend more time arguing about things (I had no idea so much controversy would arise at this late date), then we can wait. Jonathan  Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 MAY 86 17:04:56 EDT Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 29 MAY 86 16:14:05 EDT Date: Thu, 29 May 86 16:13 EDT From: Jonathan A Rees Subject: define To: cth%indiana.csnet@CSNET-RELAY.ARPA, rrrs-authors@MIT-MC.ARPA In-Reply-To: The message of 27 May 86 13:20-EDT from Chris Haynes Message-ID: <"860529161305.5.jar@AI"@ROCKY-GRAZIANO.LCS.MIT.EDU> I didn't want to make any changes to the report as fundamental as this. A change to DEFINE also seems infeasible given how constroversial the topic is and always has been. I am trying to sidestep controversies right now, so that I can get something done. Maybe in next year's revision (??) we can address this question. As we agreed at Brandeis, few of us wholeheartedly like internal definitions, but they should be described ("nonessentially") because S&ICP uses them. This was a difficult compromise for us to arrive at, and I think it would be much too painful at this point to retract it. And now we have another reason to leave them in, which is compatibility with the RRRS. T originally had the semantics that you prefer for DEFINE (although definitions aren't "globally" effective, they're scoped to the innermost lexical contour which is willing to accept it). Many users found it to be a very nice feature, for the same reasons you do. However, I have recommended to the current T implementors that they remove the feature, for several reasons: (a) It makes it more difficult for humans & programs to scan a file to find its definitions. (b) It's not always obvious which environment it is intended the definitions go in; like MIT Scheme, T has no notion of "top level." (c) It really confuses anyone who has ever seen S&ICP or MIT Scheme. The old meaning will be retained in T, probably under some other name (or anonymously, since T has anonymous special form types). Kent and others still stand by the old meaning. Here is how I think I would put the functionality that "global define" provides into a language like Scheme. (A better language than Scheme might do it better.) Invent a special form (or macro) called something like EXPORT or PROVIDE or MODULE which works as follows: (provide ...) is equivalent to (lambda () (case (() ) (() ) ... (else ))) where is a variable different from , , .... Then instead of (let ((state ...)) (define-global reader ...) (define-global writer ...) ...) you can write (define i/o-system (letrec ((state ...) (reader ...) (writer ...) ...) (provide reader writer ...))) (define reader (i/o-system 'reader)) (define writer (i/o-system 'writer)) ... The PROVIDE special form would be useful for many other applications as well (e.g. object-oriented programming). If this is too verbose for you, I think other kinds of macros could almost as easily be designed which like the above raise no new semantic questions. - Jonathan  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 May 86 16:06:56 EDT Received: from ti-csl by csnet-relay.csnet id aa00186; 29 May 86 11:51 EDT Received: by tilde id AA21997; Thu, 29 May 86 10:35:56 cdt Date: Thu 29 May 86 10:19:27-CDT From: David Bartley Subject: response to new draft report (long) To: RRRS-Authors%mit-mc@CSNET-RELAY.ARPA Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA, JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA Message-Id: <12210572757.48.BARTLEY@CSC60> Here are my (hasty) comments on the new draft Report. COMMENTS ON THE TEXT OF THE DOCUMENT: [page 1] My name is "David Bartley", but "D.H.Bartley" is better than "D.Bartley". Why use zero-origin indexing for section numbers? [page 2] Use italics and capitalization for consistency in "revised report [29]" in 2nd paragraph of Background. The term "coalescing" in the 2nd-to-last paragraph is not defined anywhere. [page 4] Remove "will" from "Italicized names will stand for..." Pluralize "argument" in "the append procedure is being passed zero or more list argument." Add "be" in "this report explicitly does not specify what value should [be] returned." at end of 0.2.2. Change "Upper and lower case letters are never distinguished..." in 1 to something like "Upper and lower case forms of a letter are never distinguished...". Surely `A' is distinct from `b'. Are #t and #f considered identifiers? [page 5] In 1st paragraph of 1.1: "Whitespace may occur..., but not within a token." Is a string containing a space a token? The character `#\ '? Typo: change `occuring' to `occurring'. The statement "Backslash isn't used by Scheme except within string constants" is awkward and negative. Remove "are not used in Scheme right now but" from "... curly braces are not used in Scheme right now but are reserved...". Change "Like Algol or Pascal" to "Like Algol and Pascal". [page 6] In 2.1, the words "most values count as true, but a few--notably #f-- count as false" should be tightened up, since section 5.0 on page 13 makes it clear that only #f and the empty list count as false IN CONDITIONAL EXPRESSIONS. (Is "in conditional expressions" a qualifier???) [page 7] Fix "see section refdefine" in 3.0.2. Is 3.0.2 a good place to take note that () is not a good procedure call? What is meant by "here we will ASSUME that is simply a sequence of one or more expressions" in 3.0.3? [page 8] Please change the descriptions of COND and CASE to be what they were in the RRRS (modulo the small changes we seem to have consensus on). I see no reason to get carried away with describing the permissible types for in a CASE key list. Just define CASE as using MEMV (or EQV?) and let the implications hang out! [page 10] The first LET* example at the top left of the page is confusing, since the first is decomposed into and and the others are not. At the bottom of the first column, change the second instances of and to have subscript 2. The words "... are variables which do not occur in the original LETREC expression..." are confusing. Would a new binding of the identifier (or is it variable) be an occurrence of ? Similar wording appears elsewhere in the document (e.g. with DO). [page 11] Specify that in named LET must be an identifier (or is it "variable"). [page 12] Section 3.1.4: The wording "(for example, by a call to the FORCE procedure)" begs for elaboration. I think it makes sense to postpone most of the discussion to page 27ff, as JAR does, so let's use a "white lie" here and mention only FORCE as a way to collect on a promise. All other ways are extensions. [page 13] Change the last line of 4.1.0 from "Global definitions are essential; all Scheme implementations must support them." to something like "This semantics for top level definitions is essential." What does "global definition" mean? The clause after the ";" is redundant. I feel uncomfortable about using the term "lambda body" to include the "body" of a LET or DEFINE expression, as is done in 4.2. Why not retitle section 5 to be something like "Standard Procedures" instead of "Initial Environment"? The text makes it clear that these procedures are the standard bindings of variables in the initial environment, so it doesn't have to be emphasized in the title. A person looking at the table of contents on page 1 is likely to be confused. [page 14] How about adding (EQ? NIL 'NIL) ==> #F as another example at the end of 5.0 to hammer the point home? Add "in the same order" at the end of "Two procedures are operationally equivalent iff ... they return the same value and perform the same side-effects." (Or is that implied by `having the same side-effects'?) The wording "it will always err on the conservative side" seems to say that EQV? tries to do the "right" "wrong thing"! [page 15] Change "Objects of distinct types WILL NEVER BE operationally equivalent, BUT FALSE and the empty list are permitted to be identical..." to "Objects of distinct types ARE NEVER operationally equivalent, EXCEPT THAT #F and the empty list are permitted to be identical...". The second sentence of the description of EQUAL? should say that EQV? is used for all objects except pairs, vectors, and strings. [page 16] Change "same" to "equivalent" in the comparison of (a b c d e) and its dotted form. [page 17] APPEND! always side-effects all but its last argument. [page 18] Change "(in the sense of EQV? and EQ?)" to "(in the sense of EQ?)" or "(in the sense of EQV?)". (Why mention both?) What is meant by "returned" in the second and third sentences of the description of SYMBOL->STRING? How about "created"? [page 19] The previous Report used all caps for the words NUMBER, COMPLEX, ..., for EXACT and INEXACT, and [page 23ff] INT, RAT, FIX, FLO, ... . I think that is less confusing than using the same typeface used for Scheme identifiers. [page 20] Change the title of 5.4.2 from "Syntax" to something like "Number syntax". Rephrase "to make all user populations happy". >I'm< not happy with having both forms (e.g., both = and =?) and I'd settle for EITHER ONE! [page 25] JAR has omitted an important paragraph in the previous Report's discussion of strings. The sixth paragraph on page 51 of the RRRS, beginning "In phrases such as...", clarified in one place how substring START and END work. The descriptions of SUBSTRING (etc) don't make this clear at all. [page 26] If we only have SUBSTRING-MOVE-RIGHT! to support text editors, let's flush it! This is only the tip of the iceberg when it comes to handy little utility functions for building editors. [page 27] The dual use of VECTOR in the example starting (LET ((VECTOR (VECTOR... is confusing. For consistency, change ELTS in LIST->VECTOR to LIST. [page 28] Change "they" to "to" in "but they illustrate the property that the value of a promise is computed at most once." The second "bullet" at the top of the second column is not an extension but an implementation issue (I think). [page 29] Restore the mention of the alternate name CALL/CC at the end of the rationale for CALL-WITH-CURRENT-CONTINUATION. [page 39ff] Add index entries for `identifier' and `variable'. ------------------------------------------------ [Following are my responses to JAR's specific questions on language and presentation. His question is left adjusted, my response is preceded by ` ******* '.] I've omitted some questions/proposals I agree with or have no comment on. Questions on LANGUAGE I left CASE as is, using EQV? as the comparison, and I explicitly stated that the object ought to be boolean, character, number, or symbol. But shouldn't it allow empty lists, vectors, and strings, too? ******* Define it in terms of EQV? and define (EQV? '() '()) ==> #T. ******* This is consistent with Common Lisp's CASE, which uses EQL. May structure be shared in cases like (APPEND '(A B) '()) , or should APPEND be Common Lisp compatible? [Bartley says sharing would be a gratuitous incompatibility with CL, I'm invlined to agree.] ******* Don't share structure with any argument but the last. Should APPEND and APPEND! explicitly allow any object as last argument (CL compatible)? ******* Yes. Should APPEND! disallow () as other than last argument? ******* No. Can we specify that DISPLAY of a character does the same thing as WRITE-CHAR? ******* Yes. What should be said, if anything, about the desirability and/or legality of EQUAL? failing to terminate? Rozas thinks an implementation with this property is in error. ******* Leave it as it is. It is `an error' not to terminate. In light of the vagaries of CALL-WITH-xxPUT-FILE, perhaps it would be a good idea to explicitly state that closing a closed port should be a no-op instead of an error. ******* Yes. ----- Questions on PRESENTATION Should the various examples which use DEFINE be changed to use the (define (foo ...) ...) syntax instead of (define foo (lambda ...))? Several people have told me that all those LAMBDA's could unnecessarily intimidate SIGPLAN readers. ******* LAMBDA is what it's all about; but I don't really care. There are two places (in descriptions of let* and letrec) where it is necessary to create a lambda body in a context (such as the tail of a BEGIN) where there isn't one already. What is the cleanest way to do this? Is (let () ...) ok, or would ((lambda () ...)) or something else be better? ******* Use (LET () ...). Should the complete presentation of FORCE appear up front with DELAY, or delayed until the place where the entry for FORCE appears? ******* It's OK where it is, but see my comments above. ----- Notes on LANGUAGE The selectors in a CASE expression must be distinct. ******* OK. I have left CASE and COND syntax as in RRRS: there must be at least one clause, but it may be an ELSE clause. ******* Yes--I don't like the rewrite in the new draft. BOOLEAN? is essential. ******* I suppose so. No agreement on COND or BEGIN. I have left them as in RRRS. [To do: fix the BNF to agree!] ******* Yes, but keep `test' instead of `guard'. The RRRS explicitly allows internal definitions in the body of a LETREC. They are scoped to the body only, not to the entire expression. I can flush this "feature" if a movement arises to do so; it seems sufficient to me to permit only expressions (not definitions) in the body. ******* Allow them. The list to which the rest argument gets bound must be newly allocated. ******* Yes. Common Lisp screwed this up. There was strong sentiment both for removing REC and for removing NAMED-LAMBDA. However, the sentiment was not unanimous. I don't understand why it should have matterred so much, since neither is an essential feature. If these are present, shouldn't everyone's favorite features be present too? ... Supporters of REC included Kent Dybvig and Dan Friedman. Supporters of NAMED-LAMBDA included Jim Miller and Henry Wu. In addition, Bill Rozas insisted that if REC stayed, then NAMED-LAMBDA must stay too, but he was willing to see both go. ******* Keep them both. APPEND! necessarily clobbers its arguments (other than the last and empty ones). ******* Yes. It's meaningless otherwise. Many people wanted the number predicates pruned (i.e. choose between < and To: KMP@SCRC-STONY-BROOK.ARPA Cc: JAR@MC.LCS.MIT.EDU, RRRS-AUTHORS@MC.LCS.MIT.EDU, willc%tekchips.tektronix.csnet@CSNET-RELAY.ARPA Subject: Re: Notes about (^ revised 3) report In-Reply-To: Your message of Thu, 22 May 86 18:53 EDT. <860522185327.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: 27 May 86 13:07:52 PDT (Tue) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Here are the answers I prefer to KMP's starred questions; words within brackets were edited by me. * Does the [port] become closed as a side-effect of hitting eof? No. * Is it an error to read from a closed [port], or does [an eof-object] just keep getting returned? It is an error. * Can you read the eof object twice at the end of a file using READ ? How about if using READ-CHAR ? PEEK-CHAR ? Yes. Yes. Yes. * Is it possible to detect whether a [port] is closed? Impossible using only the procedures documented in R^3RS. I'd like the language to remain silent on whether a closed port is still a port. * Is it acceptable for close on certain [ports] to not really close the [port]? For example, I could imagine implementing terminal [ports] or [ports] into editor buffers in a way such that they just always claimed to be open and close was a no-op. Yes. KMP: Also on p30, it seems to me that the notion of CHAR-READY? is not a useful one. It's subject to timing errors in multi-processed systems and/or systems which allow asynchronous interrupts. The Lisp Machine's TYI-NO-HANG paradigm is much better, since it has a more test-and-set feel to it and is more easy to use reliably. I suggest that CHAR-READY? should be flushed and replaced by a READ-CHAR? which returns either a character if one is ready, or NIL otherwise. This gets you out of the bind with rubbing out stuff that CHAR-READY? has noticed, which is really an awful crock. I believe that TYI-NO-HANG will interact satisfactorily with Lispm-style rubout handlers. To some extent I agree with this, but I don't think READ-CHAR? by itself is any better for multi-processing than CHAR-READY?. Peace, Will  Received: from Godot.Think.COM by MC.LCS.MIT.EDU 29 May 86 01:14:55 EDT Received: by Godot.Think.COM; Thu, 29 May 86 01:14:45 edt Date: Thu, 29 May 86 01:14:45 edt From: gls@Think.COM (Guy Steele) Message-Id: <8605290514.AA08588@Godot.Think.COM> To: rrrs-authors@mc Subject: Embedded DEFINE forms I have watched the controversy going on for quite some time, and it seems to me that at this late date, on the eve, apparently, of widespread publication of a standard for SCHEME, that there is not consensus in the SCHEME community on the subject of embedded DEFINE forms. If the community cannot agree, nor even agree to agree on some arbitrary choice, then the matter should not be standardized. I see no harm in the standard not defining what happens to embedded DEFINE forms. This would allow the various camps to be upward-compatible extensions of the standard (though of course not with each other in this regard). RRRS might even have, as a footnote or appendix, descriptions of the competing proposals. --Guy  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 MAY 86 20:34:54 EDT Date: 28 May 1986 20:34 EDT (Wed) Message-ID: From: Bill Rozas To: Kent Dybvig Cc: rrrs-authors@MC.LCS.MIT.EDU Subject: define (resend) (long) (short) In-reply-to: Msg of 28 May 1986 14:30-EDT from Kent Dybvig What it boils down to is that (1) the same name should be used inside as out to define global variables and (2) the right name is define. Again, this does not make any sense in MIT Scheme, where user code runs by default in an environment which inherits the "global" bindings, rather than the one were the bindings actually exist. Top level DEFINEs do not define in the global environment, but in whatever environment the code is loaded. The default top level environment is an environment with an empty top frame, and whose parent frame contains the initial accessible bindings of the system. Our system (local and incremental DEFINE) is perfectly consistent, since DEFINE always acts on the environment where the definition is evaluated. There is no difference between top level and inner environments. As a matter of fact, top level is changed at various times, and thus top level DEFINE acts on different environments at different times. Indiana style DEFINE sounds horrendous to me because the evaluation happens in one environment, while the "assignment" happens in another, without making this explicitely visible. Nevertheless, I'm willing to have it added it to the report as long as it has a different name (DEF?). Note that if DEF is implemented, it will also "work" at top level, so you can always use the same name. You mentioned the possibility of omitting internal define altogether. We would be satisfied with that. The report should say something to the effect of portable code should only use the define/set! form (or appropriate sugaring). This seems to be the only viable solution. Again, this is being gratuitously different from the previous version of the report, and S&ICP. We are keeping T and NIL, #!TRUE and #!FALSE, just to be backwards compatible. Removing DEFINE would allow implementations (like you) to have semantics completely incompatible with the previous report. Look guys, I hate BEGIN with all my guts. I am not fighting against it. We had a vote at Brandeis and it WON (I cast the only vote against it). I (and JAR, and GJS, who hate it almost as much as I do) abide by that decision (although I occasionally grumble about it, as well as about REC). I would very much like to see it out, but if everybody does this we will never agree on anything, because everybody will find something they do not like. I'm afraid that DEFINE must stay the way it is, and I (and the rest of the Scheme people at MIT, plus others, I'm sure) will oppose any changes to it. You are reopening a can of worms which was closed at Brandeis. Since we are at it, why don't we argue again about when CALL-WITH-INPUT-FILE closes the file or whether the name should be LETREC or LABELS?  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 May 86 15:40:20 EDT Received: from indiana by csnet-relay.csnet id ab19262; 28 May 86 15:35 EDT Date: Wed, 28 May 86 13:30:30 est From: Kent Dybvig To: jinx@MC.LCS.MIT.EDU Subject: Re: define (resend) (long) (short) Cc: rrrs-authors@MC.LCS.MIT.EDU It is too much to ask everyone who has learned to use "define" the way we know and love it here to switch to either a new word or a new meaning for internal definitions. We feel that we have given it our best shot over the past year, having tried both "define!" and "global-define". What it boils down to is that (1) the same name should be used inside as out to define global variables and (2) the right name is define. You mentioned the possibility of omitting internal define altogether. We would be satisfied with that. The report should say something to the effect of portable code should only use the define/set! form (or appropriate sugaring). This seems to be the only viable solution.  Received: from ads-grape.ARPA by MC.LCS.MIT.EDU 28 May 86 14:36:14 EDT Date: Wed, 28 May 86 08:04:09 pdt From: andy@aids-unix (Andy Cromarty) To: JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, cth%indiana.csnet@CSNET-RELAY.ARPA Subject: Re: define Cc: rrrs-authors@MC.LCS.MIT.EDU If we are casting votes on DEFINE, I would observe that of the half-dozen or so of us here who are directly involved in our Scheme effort, only one of us favors any legitimate status for "global" DEFINEs. (He happens to come from Indiana, BTW, and we may have succeeded in changing even his mind on this issue.) The rest of us have from the outset found Scheme-84's global DEFINE semantics to be an abhorrent violation of the principles of lexical scope. In fact, we assumed it was a compiler bug when we first ran across it. Even where there is a most global environment, we are hard-pressed to see what could justify advocacy of a special form that reaches into it specially from an enclosed scope to destructively manipulate its state. If we (collectively) need an extension of Scheme to achieve this effect, let's promote binding environments to first-class objects and define a destructor that treats them uniformly. (I believe, however, that it is possible to write substantive, efficient, and above all, elegant Scheme programs without the inclusion of such a destructor.) I have always felt that the global DEFINE in Scheme-84 was a profound design flaw that must be attributable to the unfortunate influence of the Franz environment (both software and intellectual) in which Scheme-84 was constructed. I understand that there is a substantial difference of opinion on this issue, but we find it difficult to see how global DEFINEs are even arguably compatible with what we take to be fundamental design principles of Scheme. In fact, as evidence of our objection to Scheme-84's global DEFINE semantics, we have done some work on ripping this feature out of a copy of the Scheme-84 compiler, replacing it with S&ICP's internal DEFINE. asc p.s. My apologies for blitzing you with such a strong opinion; we hashed this one out locally until it was beaten to death some time ago, and our opinions have admittedly become somewhat calcified....  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 May 86 11:33:21 EDT Received: from ti-csl by csnet-relay.csnet id aj17147; 28 May 86 11:08 EDT Received: by tilde id AA18724; Wed, 28 May 86 09:55:46 cdt Date: Wed 28 May 86 09:45:51-CDT From: David Bartley Subject: hash-consing To: RRRS-Authors%mit-mc@CSNET-RELAY.ARPA Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Message-Id: <12210304495.60.BARTLEY@CSC60> Has anyone had any experience with systems that use hashing CONS? I remember the idea was in vogue 15 or 20 years ago as a way to lower memory consumption, speed up EQUAL, and for theoretical (heretical?) reasons. The idea is to use hashing techniques to make pairs that are EQUAL? also be EQ?. The disadvantages seem to be (1) slower CONS, (2) unclear semantics for SET-CAR! and SET-CDR!, (3) separate spaces or tags (or something) if both hashed and regular CONS exist, and (4) GC complications. Are there any experimental results that demonstrate any significant compensating advantages? If so, what are the circumstances? The definition of CONS in the RRRRS guarantees that every pair returned is unique, so hashing would seem to be out of the question. However, I wonder if a HASH-CONS procedure has any merit. Regards, David Bartley -------  Received: from Godot.Think.COM by MC.LCS.MIT.EDU 28 May 86 11:21:41 EDT Received: from KATHERINE.THINK.COM by Godot.Think.COM; Wed, 28 May 86 10:42:51 edt Date: Wed, 28 May 86 10:43 EDT From: Guy Steele Subject: Remaining questions & remarks (1) To: JAR@MIT-AI.ARPA Cc: rrrs-authors@MIT-MC.ARPA In-Reply-To: <"860527141917.1.jar@AI"@ROCKY-GRAZIANO.LCS.MIT.EDU> Message-Id: <860528104332.1.GLS@KATHERINE.THINK.COM> Date: Tue, 27 May 86 14:19 EDT From: Jonathan A Rees ... There are at least sixteen different references to Common Lisp. I'm going to try to remove some of them. We have to make it very clear that Scheme is 11 years old and originated some of CL's ideas --- not the other way around! That's right! Good for you. --Guy  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 MAY 86 21:44:00 EDT Date: 27 May 1986 21:43 EDT (Tue) Message-ID: From: Bill Rozas To: Chris Haynes Cc: rrrs-authors@MC.LCS.MIT.EDU Subject: define (resend) (long) In-reply-to: Msg of 27 May 1986 13:20-EDT from Chris Haynes I'm afraid that we have a real disagreement here. Much has been said about the pros and cons of the "MIT style" local define, and it is clear that a consensus is not possible, so a compromise is in order. I disagree. Much has been said about MIT's INCREMENTAL DEFINE (which T also has), but not much has been said at all about (static and local) INTERNAL DEFINE, which is the only one which appears on the report. This happened mostly for compatibility with S&ICP, not because the people from MIT were trying to force it on anybody else (after all, we cheerfully accepted LETREC, which we did not have before). Using a different keyword, such as DEFINE-GLOBAL, to make global definitions from lexically nested positions is not acceptible to us. We have tried to live with such arrangements for some months now, and have found them intolerable. DEFINE-GLOBAL does not make sense for either T or MIT-Scheme. Neither really has a global environment distinguished from the rest, thus there is no environment where these definitions could be made. The closest we (MIT) can come to this is making the definition occur in the innermost environment created by means of MAKE-ENVIRONMENT (the innermost locale in the case of T), but this seems arbitrary in our case, to say the least, since all environments are created equal. In T this is not the case, so this is a viable option. We would still do it if everybody else agreed to it, but we'd rather not, since there are other options (see below). The idea is that it should be possible, in any "standard" Scheme that supports some kind of macro package, to get *either* style of lexical DEFINE by simply loading the appropriate macro package. What about Schemes that do not have macros at all? Does this mean that they have to choose one of the two styles, and thus have no possibility of running the "portable" code written using the other? I disagree very strongly with having a feature with two possible inconsistent semantics. The only option would be to remove its optional status, and therefore remove it from the report completely. Thus nobody would be able to use DEFINE at all in portable code. Changing semantics now, besides being unacceptable to us, would mean being purposely incompatible with S&ICP, and gratuitously incompatible with the previous version of the report. What is it that you do not like about DEFINE-GLOBAL? The name is too long? Use DEFINE! or DEF instead. The first was suggested at the meeting in Brandeis. Is the problem that it is not even in the report, so you can't use it because it is not portable? I'm pretty convinced that we (MIT) could be convinced of accepting it for the sake of consensus after a little arm twisting (very little needed). Note that there is a portable way of achieving the effect of DEFINE-GLOBAL: (define foo) ; or (define foo '*) (define bar) ; or (define bar '*) (let (()) (set! foo )) (set! bar ))) We often do this (although we have and use alternatives) to "export" values to outer environments, but this gives us more control than DEFINE-GLOBAL, since we can just place the DEFINEs in the environment where we want the definitions to occur. If you do not like the assignments, there is the following alternative: (with-exports (foo bar) (let (()) (define-export foo ) (define-export bar ))) which would just be pretty syntax for the previous choice. Note that DEFINE-EXPORT (or DEFINE!, or anything you want to call it) is nothing special, since it trivially turns into SET!. Note that the (FOO BAR) list could be made optional, meaning "trap" all DEFINE-EXPORTs.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 27 May 86 16:37:57 EDT Received: from indiana by csnet-relay.csnet id a009297; 27 May 86 15:40 EDT Date: Tue, 27 May 86 12:20:15 EST From: Chris Haynes To: rrrs-authors@MC.LCS.MIT.EDU Subject: define (resend) We have one great difficulty with the RRRS as it stands: DEFINE can not make global bindings when used locally and still be consistent with the report. Much has been said about the pros and cons of the "MIT style" local define, and it is clear that a consensus is not possible, so a compromise is in order. Simply making MIT style optional is not acceptible: optional syntax, if implemented, must conform to a single semantics. Thus DEFINE semantics is preempted as the report is currently written. Using a different keyword, such as DEFINE-GLOBAL, to make global definitions from lexically nested positions is not acceptible to us. We have tried to live with such arrangements for some months now, and have found them intolerable. A compromise position would be to include a form such as DEFINE-GLOBAL in the report, hopefully as a required special form, and make an explicit exception in the case of DEFINE to the rule that optional features, if implemented, always have a single semantics. The idea is that it should be possible, in any "standard" Scheme that supports some kind of macro package, to get *either* style of lexical DEFINE by simply loading the appropriate macro package. Failing that, it should at least be *possible* for a Scheme implementation to provide such packages, and allow either package to be loaded without stepping outside of the "standard". This compromise is not something that anyone would love, but it is most sincerely hoped that it is something that everyone can live with. Then no one will feel bad about being associated with the RRRS. Chris Haynes Dan Friedman Kent Dybvig  Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 MAY 86 14:18:40 EDT Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 1808; Tue 27-May-86 14:18:17-EDT Date: Tue, 27 May 86 14:19 EDT From: Jonathan A Rees Subject: Remaining questions & remarks (1) To: rrrs-authors@MIT-MC.ARPA Message-ID: <"860527141917.1.jar@AI"@ROCKY-GRAZIANO.LCS.MIT.EDU> I included the following with the reports I sent and gave out. Here it is again for those people who don't have it already. It enumerates most of the remaining nits I have. Don't be intimidated by the number of items; none are serious. Many of these questions have been discussed and some have been resolved already. For those items that stay unresolved, I'll take the conservative position and leave the new report in agreement with the old report. I'll send a second, more recent set of nits separately. - Jonathan ----- Questions on LANGUAGE I left CASE as is, using EQV? as the comparison, and I explicitly stated that the object ought to be boolean, character, number, or symbol. But shouldn't it allow empty lists, vectors, and strings, too? May structure be shared in cases like (APPEND '(A B) '()) , or should APPEND be Common Lisp compatible? [Bartley says sharing would be a gratuitous incompatibility with CL, I'm invlined to agree.] Should APPEND and APPEND! explicitly allow any object as last argument (CL compatible)? Should APPEND! disallow () as other than last argument? I decided that allowing GCD, etc. of Gaussian integers was probably premature. I'll put them in if someone writes the documentation (including examples). Can we decide on what to do about number exactness on input? How about: inexact if there are digits following a decimal point, or if exponential notation is used. Otherwise exact. Can we specify that DISPLAY of a character does the same thing as WRITE-CHAR? What should be said, if anything, about the desirability and/or legality of EQUAL? failing to terminate? Rozas thinks an implementation with this property is in error. In light of the vagaries of CALL-WITH-xxPUT-FILE, perhaps it would be a good idea to explicitly state that closing a closed port should be a no-op instead of an error. ----- Questions on PRESENTATION Should the various examples which use DEFINE be changed to use the (define (foo ...) ...) syntax instead of (define foo (lambda ...))? Several people have told me that all those LAMBDA's could unnecessarily intimidate SIGPLAN readers. There are two places (in descriptions of let* and letrec) where it is necessary to create a lambda body in a context (such as the tail of a BEGIN) where there isn't one already. What is the cleanest way to do this? Is (let () ...) ok, or would ((lambda () ...)) or something else be better? Is the word ``promise'' all right for objects returned by DELAY? Should the complete presentation of FORCE appear up front with DELAY, or delayed until the place where the entry for FORCE appears? ----- Notes on LANGUAGE The selectors in a CASE expression must be distinct. I have left CASE and COND syntax as in RRRS: there must be at least one clause, but it may be an ELSE clause. BOOLEAN? is essential. No agreement on COND or BEGIN. I have left them as in RRRS. [To do: fix the BNF to agree!] The RRRS explicitly allows internal definitions in the body of a LETREC. They are scoped to the body only, not to the entire expression. I can flush this "feature" if a movement arises to do so; it seems sufficient to me to permit only expressions (not definitions) in the body. The list to which the rest argument gets bound must be newly allocated. Making LET* be essential was suggested, but there was resistance to this, so I left it as is. There was strong sentiment both for removing REC and for removing NAMED-LAMBDA. However, the sentiment was not unanimous. I don't understand why it should have matterred so much, since neither is an essential feature. If these are present, shouldn't everyone's favorite features be present too? ... Supporters of REC included Kent Dybvig and Dan Friedman. Supporters of NAMED-LAMBDA included Jim Miller and Henry Wu. In addition, Bill Rozas insisted that if REC stayed, then NAMED-LAMBDA must stay too, but he was willing to see both go. APPEND! necessarily clobbers its arguments (other than the last and empty ones). Many people wanted the number predicates pruned (i.e. choose between < and , UNQUOTE, and UNQUOTE-SPLICING, are reserved and may not be used as variable names. I hope this is OK with everyone. Note that the grammar for numbers allows one to write things like 23## for inexact numbers. This was implicit in last summer's report, and I thought it wouldn't make sense if this was allowed on output but not on input. The case sensitivity issue was a very sensitive one (so to speak). I did not change the report's stance of symbol case insensitivity. ----- Notes on PRESENTATION I listed myself as "editor" of this version. I probably should just remain a coauthor, but the report needs an editor in order to look like the Algol 60 report. I eliminated the term ``special form.'' I introduced phrases like ``IF expression'' in a couple of places; things like IF and CASE are not referred to as active agents (keywords don't refer to particular things---it's the evaluator that actively interprets expressions having certain special syntactic forms). I removed statements like `` is evaluated but is not.'' At Pitman's request, I changed ``guard'' to ``test'' in the description of COND because ``guard'' has inappropriate connotations; COND doesn't really implement a Dijkstra guarded conditional. The term "variable" now refers the name itself, not the binding or the location. This is in accordance with the way logicians (including Alonzo Church) use the term. I decided not to add an appendix describing S&ICP differences. The most important difference, I think, was RRRS's lack of DELAY and FORCE. I no longer find the presence of SEQUENCE distasteful. I removed the apologetic statement that went with the description of T and NIL. (Some people actually like T and NIL.) The sentence ``This procedure can be very confusing if used indiscriminately'' in the descriptions of set-car! and set-cdr! was struck at Chris Hanson's request; it seemed gratuitous. There are at least sixteen different references to Common Lisp. I'm going to try to remove some of them. We have to make it very clear that Scheme is 11 years old and originated some of CL's ideas --- not the other way around!  Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 MAY 86 18:54:42 EDT Date: Mon, 26 May 86 18:54:00 EDT From: Jonathan A Rees Subject: R^3RS draft To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].921583.860526.JAR> I have mailed / given out copies of the latest draft of the report (22 May). People in Boston and New Haven should have either received one from me or should stop by and pick one up. A copy went to Tektronix by special courier. People with Internet access AND Latex AND something that will read Unix "tar" files should FTP to MIT-PREP, using user Scheme and null password if necessary, and get the file "/u/jar/r3rs.tar". If FTP doesn't seem to work, then try telnetting to PREP and logging in as Scheme (no password needed). The login shell is FTP. Send the abovementioned file to your machine. Extract all the files somewhere and run Latex on the file "rrrs.tex". If you don't have something that will read tar files, use FTP to get all the files on the directory /u/jar/r3rs. On Friday I mailed one copy to Dan Friedman and one copy to Dave Bartley, so people at Indiana and TI should get extra copies from them. Anyone else who wants one mailed should let me know right away (although I think that everyone has been taken care of). There is a cover letter, too, relevant parts of which I'll send electronically. Jonathan.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 23 May 86 13:08:09 EDT Received: from ti-csl by csnet-relay.csnet id ab04166; 23 May 86 12:36 EDT Received: by tilde id AA21281; Fri, 23 May 86 10:06:37 cdt Date: Fri 23 May 86 09:54:59-CDT From: David Bartley Subject: Re: LOAD 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: <"860522115129.3.jar@AI"@JOE-LOUIS.LCS.MIT.EDU> Message-Id: <12208995440.23.BARTLEY@CSC60> My first thought is that LOAD should be retained, but not as an essential procedure. That would help a programmer avoid some name conflicts, since most implementations of Scheme and Lisp have a LOAD. My second thought is to wonder why we have included non-essential procedures in the Report. Is it to warn a programmer that the given identifier should be considered "reserved" or is it to guide implementors toward consistent extensions to the essential language? In the first case, I'd say that the programmer should be referring primarily to the manual for his implementation, not to the Report, and that that manual should take care to warn him of portability issues. In the second case, I'd say that our coverage of "suggested" extensions is so patchy that it's almost irrelevant whether LOAD is mentioned or not. After all, where are COMPILE and EVAL, two obvious names for extended features? So, my inclination is to let JAR do whatever he likes. This is a pragmatic issue. Ideally, we'd have an appendix that discusses these things, but that may be Pandora's box. --db-- -------  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 23 May 86 12:54:49 EDT Received: from ti-csl by csnet-relay.csnet id a004166; 23 May 86 12:35 EDT Received: by tilde id AA21938; Fri, 23 May 86 10:21:49 cdt Date: Fri 23 May 86 10:06:06-CDT From: David Bartley Subject: Re: H, E, S, B, O, D, X 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: <"860522111800.2.jar@AI"@JOE-LOUIS.LCS.MIT.EDU> Message-Id: <12208997463.23.BARTLEY@CSC60> We have implemented the number output formats in PC Scheme. I like the idea of spelling out the keywords and won't "vote" against it, but there are two troublesome aspects: (1) We already have a product out that supports the abbreviated style, so we'd have to grandfather it. That's always a minor pain. (2) My experience is that not one programmer in ten can spell both EXPRESSED and SUPPRESSED correctly (sorry about that!). What should NUMBER->STRING do with EXPRESED or SUPRESSED? [Of course, there are plenty of other opportunities for misspellings to trip one up!] Seriously, I recommend that we retain the single letter abbreviations as an option if we switch to full names for these keywords. Regards, David Bartley -------  Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 22 May 86 18:55:22 EDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6687; Thu 22-May-86 18:53:41 EDT Date: Thu, 22 May 86 18:53 EDT From: Kent M Pitman Subject: Notes about (^ revised 3) report To: JAR@MIT-MC.ARPA cc: KMP@SCRC-STONY-BROOK.ARPA, RRRS-AUTHORS@MIT-MC.ARPA Message-ID: <860522185327.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> On p30, while reading the description of READ, the following questions occurred to me, the answers to which are in some cases probably dependent upon the answers to the others in order to assure useful consistency: * Does the stream become closed as a side-effect of hitting eof? * Is it an error to read from a closed stream, or does eof just keep getting returned? * Can you read the eof object twice at the end of a file using READ ? How about if using READ-CHAR ? PEEK-CHAR ? * Is it possible to detect whether a file is closed? * Is it acceptable for close on certain streams to not really close the file? For example, I could imagine implementing terminal streams or streams into editor buffers in a way such that they just always claimed to be open and close was a no-op. Also on p30, it seems to me that the notion of CHAR-READY? is not a useful one. It's subject to timing errors in multi-processed systems and/or systems which allow asynchronous interrupts. The Lisp Machine's TYI-NO-HANG paradigm is much better, since it has a more test-and-set feel to it and is more easy to use reliably. I suggest that CHAR-READY? should be flushed and replaced by a READ-CHAR? which returns either a character if one is ready, or NIL otherwise. This gets you out of the bind with rubbing out stuff that CHAR-READY? has noticed, which is really an awful crock. I believe that TYI-NO-HANG will interact satisfactorily with Lispm-style rubout handlers. On p30, the issue with LOAD is that if we're going to define it, we need to give it a standard meaning so it can be usefully used on different systems. If we don't say it either types out or doesn't, then people can't use it in their programs for fear it will screw up the display (this exact problem arose in real situations in my work with Common Lisp). I feel that a LOAD which does no typeout is a useful interface to the operating system and a necessary feature for bootstrapping other code. The absence to provide it will mean that either every user will have to type in a definition of load at the keyboard or every system will have to provide it anyway. Obviously, this translates to that every system will provide one, since no one's going to force the user to type it in. If every system is going to provide it, we might as well standardize on it so people can know what they're getting. If particular dialects want to offer additional options, well, ... you're no doubt aware of my feelings on this issue and i'll spare the cc'd folks for now.  Received: from ads-grape.ARPA by MC.LCS.MIT.EDU 22 May 86 13:14:03 EDT Date: Thu, 22 May 86 10:13:20 pdt From: andy@aids-unix (Andy Cromarty) To: JAR@MIT-AI.ARPA Subject: Re: LOAD Cc: rrrs-authors@mit-mc 1. Numbers: I agree with full naming. Even when I was actively working on a full numbers package I couldn't remember what these were wiuthout looking them up. Perhaps implementations should be free to support single-letter names in "not recommended" status for the sake of downward compatibility. 2. LOAD: This is sticky. The beast probably should not exist in this or any other language, because files themselves are a bad idea left over from the early days of computer science when we didn't know any better and allowed hardware to dominate software design. The problem is that not having LOAD available requires that we have an alternative available, which means either (a) having a transparent or essentially transparent object filing system or (b) having a non-transparent object filing system with an explicit object-writing operator (e.g. WRITE or some variant would have to be able to render permanent any arbitrary object, such as functions that make lexical reference to variables from an enclosing scope and similar LISP objects that can have very messy state in a lexically scoped environment). If we have LOAD available but we don't document it, we have simply ignored the problem, rather than either solving it or admitting we can't yet. The fact is that, unlike EVAL, LOAD is something that everyone will have to use, including newcomers; it's not esoterica, even if it does interfere with intellectual cleanliness. The means to address such cleanliness issues is probably design, not selective non-documentation. A good compromise might be to add a paragraph of comment, something like what appears in the RRRS for macros, stating that this is currently a difficult area in LISP design and that LOAD is provided but that work on alternatives (e.g. object filing systems) is encouraged. asc  Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 MAY 86 11:53:10 EDT Received: from JOE-LOUIS.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 1622; Thu 22-May-86 11:51:29-EDT Date: Thu, 22 May 86 11:51 EDT From: Jonathan A Rees Subject: LOAD To: rrrs-authors@MIT-MC.ARPA Message-ID: <"860522115129.3.jar@AI"@JOE-LOUIS.LCS.MIT.EDU> I would like to either remove LOAD from the report or change the way in which it is presented. Reasons: (a) A LOAD procedure is equipotent with EVAL, and EVAL isn't documented. The same reasons that applied to kick out EVAL apply here. (b) It seems to me a perfectly reasonable idea to create Scheme systems that don't have a LOAD procedure. I can imagine at least two completely different kinds of implementations in which LOAD wouldn't make sense. One kind of implementation would be in the style of most implementations of PASCAL, FORTRAN, etc., where one runs programs by configuring entire environments at once. This avoids all the semantic stickiness of LOAD and EVAL by making configuration a meta-issue. Second, at the opposite extreme, in an Interlisp-like implementation where one actually edits "in core", and files don't generally come into play, LOAD is pretty meaningless. (c) It seems to me that LOAD is a user interface/programming environment issue. We don't talk about read-eval-print loops, or entering or exiting scheme, or logging in, or editing files; how is this different? Alternative solutions: (1) Omit it entirely without saying anything. (2) Mention somewhere (e.g. in the introduction) that Scheme is "usually" an interactive language with a read-eval-print loop and support for things like interactive debugging and dynamic program loading. (3) Reclassify LOAD as being part of the syntax of a file. I.e., like DEFINE, it can only occur at top level in a file. (4) Leave it alone, but put it in a "user interface" section along with TRANSCRIPT-ON and TRANSCRIPT-OFF (and maybe TRACE, DEBUG, and EDIT?), instead of classifying it as an input procedure. Make a disclaimer that these things are only guaranteed to work "at top level" (whatever that is). (5) Some combination of (3) and (4) [allow it both in files and at command loops]. Feedback solicited. -Jonathan ----- KMP: please send a message making a case for a (LOAD-SILENTLY x).  Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 MAY 86 11:17:45 EDT Received: from JOE-LOUIS.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 1619; Thu 22-May-86 11:18:03-EDT Date: Thu, 22 May 86 11:18 EDT From: Jonathan A Rees Subject: H, E, S, B, O, D, X To: rrrs-authors@MIT-MC.ARPA Message-ID: <"860522111800.2.jar@AI"@JOE-LOUIS.LCS.MIT.EDU> Has anyone implemented number output formats in their entirety? A number of people have requested the the following minor change: that the keywords which are now single letters be spelled out. E.g. EXPRESSED and SUPPRESSED instead of E and S. We can discuss the details separately. If some people think such a change is a bad idea at this point then the change shouldn't be made. But if no one has implemented it and people like the idea then I think it can be done pretty painlessly. The letters in question are H, E, S, B, O, D, and X. If you don't know what they mean that simply attests to the desirability of spelling them out. Jonathan  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 29 Apr 86 10:44:21 EDT Received: from OZ.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Apr 86 10:42-EDT Date: 29 Apr 1986 10:20 EDT (Tue) Message-ID: From: Bill Rozas To: willc%tekchips%tektronix.csnet@CSNET-RELAY.ARPA Cc: JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, RRRS-Authors%mit-mc@XX.LCS.MIT.EDU Subject: meaning of *global* define In-reply-to: Msg of 15 Apr 1986 15:49-EST from willc%tekchips%tektronix.csnet at CSNET-RELAY.ARPA What is the difference between having incorrect procedures all over the place and having incorrect numbers, lists, strings, or vectors all over the place? It would be possible to fix other objects if in our system all objects maintained a history of how they were created, and often I think that this would be a very nice debugging environment. Unfortunately, for efficiency reasons, they do not. Procedures, fortunately, contain the environments where they are closed, and these include most of the relevant information about their creation history. By modifying these environments we can patch a running system in a way we cannot patch it if the "wrong value" happens to be a vector or other "simple" data structure. Just because we cannot provide a more general and powerful debugging tool, it does not mean that we should not provide an extremely useful (the most useful to me) special case. In terms of implementation, there are various possible trade offs. I can easily accept a system where incremental definition (when it does not degenerate into assignment) causes a garbage-collection-like process to occur to make all the references consistent. I am perfectly willing to pay the price of a very powerful feature which I use relatively often. PS: Sorry about taking so long to answer this message. It was buried in a large pile.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 Apr 86 14:55:35 EDT Received: from ti-csl by csnet-relay.csnet id a002987; 28 Apr 86 14:49 EDT Received: by tilde id AA15512; Mon, 28 Apr 86 13:40:42 cdt Date: Mon 28 Apr 86 13:28:11-CDT From: David Bartley Subject: Re: variata To: JINX%OZ.AI.MIT.EDU%xx.lcs.mit.edu@CSNET-RELAY.ARPA Cc: JAR%mc.lcs.mit.edu@CSNET-RELAY.ARPA, RRRS-AUTHORS%mc.lcs.mit.edu@CSNET-RELAY.ARPA, Bartley%ti-csl.csnet@CSNET-RELAY.ARPA In-Reply-To: Message-Id: <12202480652.63.BARTLEY@CSC60> >Date: 26 Apr 1986 10:33 EST (Sat) >From: Bill Rozas > > [Bartley:] > -- I like warning messages for things like (MAKE-VECTOR 0 exp) more > than you do. We can probably agree to provide declarations so you > won't refuse to buy my system! > >I agree with JAR. I think that (MAKE-VECTOR 0 exp) is reasonable and >no error (warning) message should be given. I don't understand why >you object to it. Why not warn about reversing a list with less than 2 >elements also? I'm not objecting, just asking questions to clarify JAR's position and to elicit comments from others with strong opinions. Let's see if I can clarify both mine and yours: -- I agree that (MAKE-VECTOR EXP1 EXP2) shouldn't be an error or cause a warning at runtime should EXP1 evaluate to zero. I'm talking about compile-time warnings (e.g. for a COMPILE-FILE) when EXP1 is a literal zero. I oppose most, perhaps all, warnings during evaluation. Sorry I wasn't more explicit -- I tend to think in terms of separate compilation and I'm sure many of you are thinking primarily in terms of interpretation. -- Likewise, (REVERSE EXP3) obviously shouldn't cause a warning when EXP3 evaluates to a list with fewer than two elements. But a compile-time warning about (REVERSE '(A)) might be helpful (if it weren't so unlikely!). There's no real debate here. If I were to report `warnings,' as opposed to actual `errors,' I'd do it only in a compilation mode where they wouldn't be confused with the runtime behavior of the program and only if the user asked for them by setting a flag. This is a development environment issue, not a language issue. > -- We agree that (ELSE) is a no-no and that (COND) and (COND (ELSE exp)) > are valid. > > -- I feel that (BEGIN) should have the same meaning as (COND), but I > won't push the point. > >I don't like this. Unfortunately JAR did not give me choice c (status >quo, where (COND (ELSE ...)) is legal, but (COND) is not), which I >like best. I object pretty strongly to (BEGIN) and somewhat less >strongly to (COND). The usual rationale is that it makes macros >easier to write, but this is just laziness of the same sort as using >(cdr (assq )) in a Lisp where (cdr '()) -> '(). >(COND (ELSE ...)) although silly has a clear meaning (unless the ELSE >clause is empty, which should be an error, but we agree on this). Actually, JINX and I seem to agree that (BEGIN) and (COND) are equally meaningless. I offer to allow (COND) but feel (BEGIN) makes as much sense. If there's a consensus against (COND), then I'm even happier. I'm not all that motivated by wanting to write lazy macros or program- generating programs for reasons similar to JINX's. Regards, David Bartley -------  Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 27 Apr 86 17:56:56 EDT Received: from HUMMINGBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 473339; Sun 27-Apr-86 17:54:24-EDT Date: Sun, 27 Apr 86 17:55 EDT From: Kent M Pitman Subject: variata To: JAR@MIT-MC.ARPA cc: RRRS-AUTHORS@MIT-MC.ARPA In-Reply-To: <[MC.LCS.MIT.EDU].895280.860425.JAR> References: The message of 24 Apr 86 10:43-EST from Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Message-ID: <860427175526.2.KMP@HUMMINGBIRD.SCRC.Symbolics.COM> I am absolutely opposed to making (COND) or (COND (ELSE)) or (BEGIN) or (LAMBDA ()) illegal. I am content to make them return undefined values but I insist that, for example, (LAMBDA () (BEGIN) 3) is a completely well-formed expression that should neither cause the compiler to say anything nor cause an error at runtime. I am very opposed to requiring ELSE to be the last clause in a COND. It seems to me that (COND ((FOO)) (ELSE #T) ((BAR))) is like like (OR (FOO) #T (BAR)). I hope no one is going to insist that the previous form should also be illegal and/or that it should be warned about by a compiler. The call to BAR is obviously not going to get reached for pragmatic reasons, but there may be legitimate situations where program-writing programs could want to construct something like this and I think we'd be shooting ourselves in the foot to disallow such things. Also, I think it tends to make the grammar look more graceful if ELSE can occur anyway. The particular case of interest is: `(COND ,@FORMS (ELSE FOO)) where FORMS may be allowed to contain an ELSE clause. I object to having to write: `(COND ,@FORMS ,@(IF (AND FORMS (NOT (EQ (CAR (LAST FORMS)) 'ELSE))) `((ELSE FOO)) `())) If you decide to make any of the above forms legal, I wish to have my reasons for disagreement cited. I think CASE should be changed to use EQUAL?, which I think is in agreement with a recent suggestion by you. This will get around a lot of confusion that could otherwise result from the recent trend toward wanting to intern quoted structure. I'm fairly satisfied with the way things seem to be going in the EQ? and EQV? discussion so will mostly decline from any comment for now on that subject. JAR: If people believe that it's important to be able to parse Scheme's read syntax using only standard Common Lisp reader features, then by all means we must allow (eq? '#() '#()) to be false, but we also have to change the syntax of numbers, and make colon not be a constituent character. But Scheme's eqv? could still deal with #() and "" as I propose even if eq? doesn't. Right. JAR: It looks like I'll lose on this point, so I won't push it too hard. I'm just resisting adding yet another clause which basically says "we did this for compatibility with Common Lisp." I am sympathetic to this position. I strongly oppose requiring APPEND to do gratuitous copying. It's trivial to adopt Bartley (about APPEND): ... I'd like some discussion on this. It sounds like something a LISP programmer could trip up on, especially those who use (APPEND X '()) to copy X. Steele's book specifically mentions that APPEND will work that way in Common LISP, but implies that it is poor style. My inclination is to be compatible with Common LISP in order to minimize frustration for the poor people we're trying to win over to Scheme. JAR: If this is what other people want I'm happy with it too (except again for the fact that I'll have to insert another apology and another reference to Common Lisp). The fact that CL provides COPY-LIST is enough for me. I am strongly opposed to continuing this lossage of forcing APPEND to do gratuitous copying. You're falling down on your let's-not-be-gratuitously-compatible-with-CL maxim. CL itself is really only doing it for compatibility, too. This is a case where we're clearly right and ought not give in. JAR: What about (let ((x (list 'a))) (eq? x (reverse x))) ? Bartley: I feel strongly that REVERSE should always copy (unless its argument is the empty list), since it is easier to remember that rule than that it does so only when there's more than one element in the list. Pragmatically, I often do something like (APPEND! (REVERSE X) Y), and wouldn't want to side effect the original list in X if it had exactly one element. (Note that this works correctly when X is the empty list, so this is a pretty unusual boundary condition.) JAR: I agree. (Except note that it doesn't copy empty lists....) I am receptive to the idea of permitting the result of REVERSE to share with its input. The idiom (APPEND! (REVERSE X) Y) should just be named. CL has REVAPPEND and NRECONC. I believe we should just have APPEND-REVERSE and APPEND-REVERSE! which do these common operations. This would reduce the need to rely on copying. I think we should take a consistent stand on the idea that REVERSE, APPEND, do not have to copy and that that's why we provide COPY-LIST. People can always write their own COPY-LIST-REVERSE, COPY-LIST-APPEND, etc. if they really need to intertwine the two operations for some efficiency reason. The dumb routines are so easy to write yourself, after all. The ones provided by the system should be the messy-to-write super-optimizing ones.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 26 Apr 86 21:16:52 EST Received: from 5400000012 by CSNET-RELAY.ARPA id a000769; 26 Apr 86 21:04 EST Received: from OZ.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 26 Apr 86 10:33-EST Date: 26 Apr 1986 10:33 EST (Sat) Message-ID: From: Bill Rozas To: David Bartley Cc: JAR%mc.lcs.mit.edu@CSNET-RELAY.ARPA, RRRS-AUTHORS%mc.lcs.mit.edu@CSNET-RELAY.ARPA Subject: variata In-reply-to: Msg of 25 Apr 1986 19:04-EST from David Bartley To summarize: -- We agree that (ELSE) is a no-no and that (COND) and (COND (ELSE exp)) are valid. -- I feel that (BEGIN) should have the same meaning as (COND), but I won't push the point. I don't like this. Unfortunately JAR did not give me choice c (status quo, where (COND (ELSE ...)) is legal, but (COND) is not), which I like best. I object pretty strongly to (BEGIN) and somewhat less strongly to (COND). The usual rationale is that it makes macros easier to write, but this is just laziness of the same sort as using (cdr (assq )) in a Lisp where (cdr '()) -> '(). (COND (ELSE ...)) although silly has a clear meaning (unless the ELSE clause is empty, which should be an error, but we agree on this). -- We agree on using EQV? for CASE. I like JAR's proposal too. -- We agree that (EQV? "" "") and (EQV? #() #()) are true, but I worry about confusion when I mix Scheme and Common LISP programs. I'm worried about gratuitous differences between EQ? and EQV?. I would object (although not terribly strongly) to making (eq? '#() '#()) be #T, but I think it is silly to have EQ? and EQV? behave differently on this. The reason I object to (eq? '#() '#()) being #T is that inline coding of make-vector would become more expensive. Make-vector is very cheap in our implementation and a good candidate for inline coding (although we don't currently do it), and having it intern 0 length vectors (strings) would make it more expensive. -- I like warning messages for things like (MAKE-VECTOR 0 exp) more than you do. We can probably agree to provide declarations so you won't refuse to buy my system! I agree with JAR. I think that (MAKE-VECTOR 0 exp) is reasonable and no error (warning) message should be given. I don't understand why you object to it. Why not warn about reversing a list with less than 2 elements also? -- I'm not apologetic about trying to avoid ``gratuitous'' differences with Common LISP, but I don't want to burden the description of Scheme with constant references to it either. I agree. Unless there is strong reason to do otherwise, we should not differ from Common Lisp. This should probably be stated early (if we all agree, of course), and assumed afterwards. A reference to this remark in various places might be appropriate.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 25 Apr 86 21:03:28 EST Received: from ti-csl by csnet-relay.csnet id a007721; 25 Apr 86 19:49 EST Received: by tilde id AA06418; Fri, 25 Apr 86 18:10:57 cst Date: Fri 25 Apr 86 18:04:04-CST From: David Bartley Subject: Re: variata To: JAR%mc.lcs.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: <[MC.LCS.MIT.EDU].895280.860425.JAR> Me-Id: <12201755365.13.BARTLEY@CSC60> My thanks to Jonathan for his comprehensive reply to my questions about his `variata'. (1) I have no argument with your analysis of (COND) vs. (COND (ELSE))... > [...] So I want to give you the two >choices: > (a) (COND) and (COND (ELSE foo)) are both necessarily legal (compatible > with RRRS since it's more liberal). > (b) (COND) and (COND (ELSE foo)) are both not necessarily legal > (incompatible with RRRS in a way which I wouldn't expect people > to be too bothered about). >but not the choice (status quo): > (c) (COND (ELSE foo)) is legal but (COND) isn't. >You've almost convinced me that (b) is the better choice than (a). I >really don't care as much as the volume of my words would indicate, so >advise me. I actually prefer choice (a)--I wasn't advocating anything like (b) earlier, just asking for the rationale. I dislike (b) because I often code something like (COND (ELSE ...)) when I know I'm going to fill in the other cases later but I want to get the COND in there to remind me (and to get the indentation for the ELSE right). >I guess no one read my BNF carefully, or this would have been discussed >earlier. Guilty! (2) I also have no argument with (BEGIN) being not-OK. But it seems intuitive to me that if (COND) is OK with no obvious semantics, then (BEGIN) might mean the same thing. Your explanation for (COND) is that it's easier to specify, not that it's particularly meaningful. Given that we agree that (COND) is OK, it seems that (BEGIN) should be OK. Do those who object to that also object to (COND)? I'm not inclined to make life difficult for you on such a minor point, so do what you think best. (3) No disagreement on using EQV? for CASE. I had thought you were suggesting that we change the definition to use EQUAL?. (4) I accept your rationale for (EQV? "" "") and (EQV? #() #()). (5) If you consider (MAKE-VECTOR 0 ) valid, then presumably you consider (LAMBDA (X Y) X) to be valid also, along with other expressions that aren't *provably* wrong but might be. If I argue this one the debate will go on indefinitely until everyone agrees to add more declarations to their systems, so I'll drop it! Of course, I agree with the word "valid", I'm just discussing whether a development environment for Scheme may issue warning messages about such things. (6) If we say that two objects are EQV? if there is no predicate that can distinguish them, then a requirement in RRRRRRS that two objects are EQV? effectively prohibits an implementation from including such a predicate as an extension. The only example that comes to mind is trivial, so maybe this comment is too, but here it is: (let ((x (make-vector 0 3)) (y (make-vector 0 4))) (eqv? x y)) Since these are both empty vectors, am I *prohibited* from adding a predicate that determines what fill character a vector was created with? Are there any non-trivial examples of this? (7) I agree that Scheme will need a different reader than Common LISP. However, if a Common LISP routine calls a Scheme routine with "" as an argument, will it be EQV? to a constant "" in the Scheme routine? It's just one more pitfall of trying to mix languages, and not necessarily one we can hope to solve unilaterally. (8) I see no compelling reason to ``insert apologies and references to Common LISP'' unless you are trying hard to give full rationales for everything you do. In fact, I'd prefer just a simple mention in the introduction to the effect that there are no ``gratuitous'' differences with Common LISP---that any you find were put there after due deliberation! If that's not true, then I (for one) think it ought to be, since we agreed on that at Brandeis. (We can argue on RRRS-AUTHORS whether something is ``gratuitous,'' but I see no reason to expose all that in the RRRRRRRRRRS.) (9) And to end on a positive note: > >What about (let ((x (list 'a))) (eq? x (reverse x))) ? > > I feel strongly that REVERSE should always copy (unless its argument > is the empty list), since it is easier to remember that rule than that > it does so only when there's more than one element in the list. > Pragmatically, I often do something like (APPEND! (REVERSE X) Y), and > wouldn't want to side effect the original list in X if it had exactly > one element. (Note that this works correctly when X is the empty > list, so this is a pretty unusual boundary condition.) > >I agree. (Except note that it doesn't copy empty lists....) Of course. The ``this'' in ``Note that this works correctly when X is the empty list, so this is a pretty unusual boundary condition'' refers to the action of APPEND!, not REVERSE. ----- To summarize: -- We agree that (ELSE) is a no-no and that (COND) and (COND (ELSE exp)) are valid. -- I feel that (BEGIN) should have the same meaning as (COND), but I won't push the point. -- We agree on using EQV? for CASE. -- We agree that (EQV? "" "") and (EQV? #() #()) are true, but I worry about confusion when I mix Scheme and Common LISP programs. -- I like warning messages for things like (MAKE-VECTOR 0 exp) more than you do. We can probably agree to provide declarations so you won't refuse to buy my system! -- I'm concerned that defining certain objects to be EQV? prohibits language extensions that might be able to distinguish them on the basis of the context at their creation, but I haven't come up with a non-trivial example. -- I'm not apologetic about trying to avoid ``gratuitous'' differences with Common LISP, but I don't want to burden the description of Scheme with constant references to it either. -- We agree on REVERSE. Sorry for yet another long message, but I'm finding this interchange very useful and I hope others do too. I don't see anything of sufficient importance to hold up the latest revision, so please don't drop the ball on my account! Regards, David Bartley -------  Received: from ads-grape.ARPA by MC.LCS.MIT.EDU 25 Apr 86 18:38:08 EST Date: Fri, 25 Apr 86 15:36:27 pst From: andy@aids-unix (Andy Cromarty) To: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA, JAR@MC.LCS.MIT.EDU Subject: Re: variata Cc: RRRS-AUTHORS@MC.LCS.MIT.EDU The difficulty with expressions like (COND) and (BEGIN) is not that it is difficult to define a semantics for them, but rather that it is difficult to *intuit* a semantics for them. We can generate any of several arcane rules to cover such special cases. It would be much nicer if no special rules were necessary, and if instead we could apply some very small number of general principles in figuring out what such aberrant constructs mean when we run across them. At the very least, if they must be included, perhaps we could come up with one rule, uniformly applied, to define their semantics -- preferably one consistent with (what most Scheme programmers would take to be) the "reasonable principles" of Scheme programming. (An informal example of such a rule -- not that I necessarily endorse it -- would be, "Any special-form control construct (LET, COND, LAMBDA, CASE, IF, BEGIN, LETREC, DO, etc.) that normally contains combinations-to- evaluate in its main body may contain a null body, in which case its return value is undefined.") If the principal argument in favor of such vacuous constructs is that some programs might generate them automatically -- and that strikes me as a prima facie legitimate concern -- then we should consider what is involved in making such programs generate only "intuitive" code instead. Quite frankly, this doesn't seem to me to be a case where the author of a program-writing program would be significantly constrained if uses of BEGIN and COND are restricted to non-vacuous applications. There are lots of cases that are much worse about which no one has yet expressed concern, such as the RRRS permitting special forms to be "syntax" objects instead of making them shadowable first-class bindings. asc  Date: Fri, 25 Apr 86 16:31:01 EST From: Jonathan A Rees Subject: variata To: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA cc: RRRS-AUTHORS@MC.LCS.MIT.EDU In-reply-to: Msg of Thu 24 Apr 86 09:43:04-CST from David Bartley Message-ID: <[MC.LCS.MIT.EDU].895280.860425.JAR> Date: Thu 24 Apr 86 09:43:04-CST From: David Bartley >Date: Wed, 23 Apr 86 23:13:58 EST >From: Jonathan A Rees >Subject: variata I'm in general agreement with JAR's proposals, but... > - (ELSE) isn't a legal clause. [If it is, what does it return, and why?] > - (COND) and (CASE x) are syntactically legal expressions. [No one > objected to this liberalization when I raised the question before.] What is the difference between (COND (ELSE)) and (COND)? Why is one wrong but the other OK? (COND (ELSE)) is the same as (COND (ELSE (BEGIN))), so it's OK iff (BEGIN) is OK. But we established that (BEGIN) isn't OK, because it's not OK in the RRRS and several people have objected to its being OK. (COND) is OK because because (COND (test expr)) and (COND (ELSE expr)) are both OK, and that's because I proposed that the syntax of COND be (COND ). I don't really care about this, but I would rather NOT want to see the syntax of COND be (COND ), which is what the RRRS says, because I think that's somewhat inelegant. An alternative, however, is to make the syntax be (COND ). I guess that would be more compatible with IF. So I want to give you the two choices: (a) (COND) and (COND (ELSE foo)) are both necessarily legal (compatible with RRRS since it's more liberal). (b) (COND) and (COND (ELSE foo)) are both not necessarily legal (incompatible with RRRS in a way which I wouldn't expect people to be too bothered about). but not the choice (status quo): (c) (COND (ELSE foo)) is legal but (COND) isn't. You've almost convinced me that (b) is the better choice than (a). I really don't care as much as the volume of my words would indicate, so advise me. I guess no one read my BNF carefully, or this would have been discussed earlier. > - (BEGIN) and (LAMBDA (X)) are not necessarily syntactically legal. > [Several people objected to this extension.] What is the difference between (BEGIN) and (COND)? Why is one wrong but the other OK? (BEGIN) is not ok for reasons explained above. I suggested that (COND) be OK because it seemed consistent with (COND (ELSE exp)) already being legal, but I think maybe you've convinced me that neither ought to be necessarily legal. > - It's not specified what happens if the constants in a CASE are > objects other than numbers, symbols, characters, or booleans. > [This allows implementations to decide for themselves what > happens in other situations - EQV?, EQUAL?, etc.] I think CASE should continue to be defined in terms of EQV?. This is consistent with Common LISP's CASE, which is defined in terms of EQL. There's also the issue of program-generated programs, which could conceivably have weird CASE keys (like closure objects) that are known to be EQ? or EQV? to other constants in the same procedure. It's bizarre, but I'd like to know what to expect. I don't think we don't disagree here. If the keys are restricted to be numbers, symbols, characters, or booleans, EQV? and EQUAL? will give exactly the same result, so it doesn't matter at all which predicate the manual decides to explain CASE in terms of; so I would leave the description to be in terms of EQV?. But observe that if it's not specified what happens when there are constants other than numbers, symbols, characters, or booleans, then the fact that the description is in terms of EQV? doesn't rule out implementations extending it to use EQUAL?. > - EQ? and EQV? must both return true if their arguments are both > empty strings or both empty vectors. [...] What about those of us contemplating extending Scheme to include other compound types? What happens with the following? (EQ? (MAKE-VECTOR 0) (MAKE-ARRAY '(0))) I would expect this to return false if either (a) the dimension of an array can be changed dynamically or (b) VECTOR? never returns true of an array or (c) there are procedures defined to work on arrays that aren't defined to work on vectors. My principles are: EQV? should implement the operationally-indistinguishable relation as closely as possible, and EQ? should be as much like EQV? as possible given that it has to be implementable as pointer comparison. (EQ? (MAKE-VECTOR 0) (MAKE-ARRAY '(0 0))) If there's a primitive like ARRAY-RANK or ARRAY-DIMENSIONS then these are clearly distinct. (EQ? (MAKE-ARRAY '(0 0)) (MAKE-ARRAY '(0 0))) This probably depends on whether arrays are non-adjustable by default. I forget whether or not they are. and my favorite, (EQ? (MAKE-VECTOR 0 3) (MAKE-VECTOR 0 4)) What standard primitive could distinguish these? The RRRS explains EQ? and EQV? in terms the notion of operational equivalence; I'm just trying to make this idea precise. I should probably send out my proposed text in advance of the rest of the report, since I think it manages to be simultaneously elegant, precise, and compatible (except, apparently, with implementations which have multiple empty strings & vectors). If there's a way to operationally distinguish objects, they aren't EQV?; if there isn't a way, I want the exceptions to be spelled out plainly, with justifications. Why should (EQV? '() '()) be true, but not (EQV? "" "") or (EQV? '#() '#()) ? What's the difference between an empty list and an empty vector or empty string? Or do you want to allow there to be more than one empty list? If operational equivalence must allow for all possible extensions to Scheme, then it is a completely meaningless concept (e.g. numerically equal numbers could be distinguishable from each other, if numbers had property lists - whatever that means), and I'm at a loss for any other way to explain EQV?. By the way, is (MAKE-VECTOR 0 ) valid? Is it reasonable to issue a warning message? I think it's perfectly meaningful (see above), and there should be no warning message. What if an implementation of Scheme extends it with adjustable arrays, as in Common LISP? (LET ((X (MAKE-ARRAY '(0) :ADJUSTABLE 'T))) (EQ? X (MAKE-ARRAY '(0)))) [I'm not advocating Common LISP's messy syntax, just using it for clarity.] Seems to me that since "essential" vectors are simple (non-adjustable, etc.), an adjustable vector is a very different beast. Empty simple vectors can't be distinguished from each other (i.e. there's only one), but adjustable empty vectors have local state, so they can be. If vectors can be adjustable, shouldn't lists be too? (MAKE-LIST 0 :ADJUSTABLE T) could return an empty list whose length can be changed. (Not a serious suggestion.) Common LISP says that strings are the same as simple vectors with elements of type STRING-CHAR. Is the empty string "" EQV? to a non-simple vector with elements of type STRING-CHAR? Not if there's a predicate which will distinguish simple vectors from non-simple ones; and in Common Lisp there is. These questions are particularly pertinent for those of implementing both Scheme and Common LISP in the same name space (or one on top of the other). It's certainly easy enough to create unique empty strings and vectors and make Scheme's MAKE-STRING and MAKE-VECTOR return them when appropriate. I don't know whether it would be acceptable for a Common Lisp implementation to do this when creating non-adjustble vectors of length zero (don't have CLtL handy, will check later). The only other time when these things are created out of Scheme's control is by the reader, but -- as I've discovered by doing a Scheme in CL myself -- Scheme really wants its own reader anyhow, to deal with the number syntax and with colon being a constituent character. If people believe that it's important to be able to parse Scheme's read syntax using only standard Common Lisp reader features, then by all means we must allow (eq? '#() '#()) to be false, but we also have to change the syntax of numbers, and make colon not be a constituent character. But Scheme's eqv? could still deal with #() and "" as I propose even if eq? doesn't. It looks like I'll lose on this point, so I won't push it too hard. I'm just resisting adding yet another clause which basically says "we did this for compatibility with Common Lisp." Sorry to stir up the muck again. >The RRRS says nothing at all about whether the result of APPEND sharing >structure with its arguments. Common Lisp says explicitly that all >arguments but the last are copied, and the last one never is. I think >this is wrong, and maybe incompatible with existing implementations. T >permits sharing (not clobbering) whenever that makes sense, e.g. > (let ((x (list 1 2))) > (eq? x (cdr (append '(a) x '() '())))) >might be true. Is it OK if I make this explicitly OK? I'd like some discussion on this. It sounds like something a LISP programmer could trip up on, especially those who use (APPEND X '()) to copy X. Steele's book specifically mentions that APPEND will work that way in Common LISP, but implies that it is poor style. My inclination is to be compatible with Common LISP in order to minimize frustration for the poor people we're trying to win over to Scheme. If this is what other people want I'm happy with it too (except again for the fact that I'll have to insert another apology and another reference to Common Lisp). >What about (let ((x (list 'a))) (eq? x (reverse x))) ? I feel strongly that REVERSE should always copy (unless its argument is the empty list), since it is easier to remember that rule than that it does so only when there's more than one element in the list. Pragmatically, I often do something like (APPEND! (REVERSE X) Y), and wouldn't want to side effect the original list in X if it had exactly one element. (Note that this works correctly when X is the empty list, so this is a pretty unusual boundary condition.) I agree. (Except note that it doesn't copy empty lists....) Jonathan  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 25 Apr 86 07:07:02 EST Received: from ti-csl by csnet-relay.csnet id ag08862; 24 Apr 86 11:36 EST Received: by tilde id AA19587; Thu, 24 Apr 86 09:50:31 cst Date: Thu 24 Apr 86 09:43:04-CST From: David Bartley Subject: Re: variata To: JAR%mc.lcs.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: <[MC.LCS.MIT.EDU].893236.860423.JAR> Message-Id: <12201402017.13.BARTLEY@CSC60> >Date: Wed, 23 Apr 86 23:13:58 EST >From: Jonathan A Rees >Subject: variata I'm in general agreement with JAR's proposals, but... > - (ELSE) isn't a legal clause. [If it is, what does it return, and why?] > - (COND) and (CASE x) are syntactically legal expressions. [No one > objected to this liberalization when I raised the question before.] What is the difference between (COND (ELSE)) and (COND)? Why is one wrong but the other OK? > - (BEGIN) and (LAMBDA (X)) are not necessarily syntactically legal. > [Several people objected to this extension.] What is the difference between (BEGIN) and (COND)? Why is one wrong but the other OK? > - It's not specified what happens if the constants in a CASE are > objects other than numbers, symbols, characters, or booleans. > [This allows implementations to decide for themselves what > happens in other situations - EQV?, EQUAL?, etc.] I think CASE should continue to be defined in terms of EQV?. This is consistent with Common LISP's CASE, which is defined in terms of EQL. There's also the issue of program-generated programs, which could conceivably have weird CASE keys (like closure objects) that are known to be EQ? or EQV? to other constants in the same procedure. It's bizarre, but I'd like to know what to expect. > - EQ? and EQV? must both return true if their arguments are both > empty strings or both empty vectors. [...] What about those of us contemplating extending Scheme to include other compound types? What happens with the following? (EQ? (MAKE-VECTOR 0) (MAKE-ARRAY '(0))) (EQ? (MAKE-VECTOR 0) (MAKE-ARRAY '(0 0))) (EQ? (MAKE-ARRAY '(0 0)) (MAKE-ARRAY '(0 0))) and my favorite, (EQ? (MAKE-VECTOR 0 3) (MAKE-VECTOR 0 4)) By the way, is (MAKE-VECTOR 0 ) valid? Is it reasonable to issue a warning message? What if an implementation of Scheme extends it with adjustable arrays, as in Common LISP? (LET ((X (MAKE-ARRAY '(0) :ADJUSTABLE 'T))) (EQ? X (MAKE-ARRAY '(0)))) [I'm not advocating Common LISP's messy syntax, just using it for clarity.] Common LISP says that strings are the same as simple vectors with elements of type STRING-CHAR. Is the empty string "" EQV? to a non-simple vector with elements of type STRING-CHAR? These questions are particularly pertinent for those of implementing both Scheme and Common LISP in the same name space (or one on top of the other). >The RRRS says nothing at all about whether the result of APPEND sharing >structure with its arguments. Common Lisp says explicitly that all >arguments but the last are copied, and the last one never is. I think >this is wrong, and maybe incompatible with existing implementations. T >permits sharing (not clobbering) whenever that makes sense, e.g. > (let ((x (list 1 2))) > (eq? x (cdr (append '(a) x '() '())))) >might be true. Is it OK if I make this explicitly OK? I'd like some discussion on this. It sounds like something a LISP programmer could trip up on, especially those who use (APPEND X '()) to copy X. Steele's book specifically mentions that APPEND will work that way in Common LISP, but implies that it is poor style. My inclination is to be compatible with Common LISP in order to minimize frustration for the poor people we're trying to win over to Scheme. >What about (let ((x (list 'a))) (eq? x (reverse x))) ? I feel strongly that REVERSE should always copy (unless its argument is the empty list), since it is easier to remember that rule than that it does so only when there's more than one element in the list. Pragmatically, I often do something like (APPEND! (REVERSE X) Y), and wouldn't want to side effect the original list in X if it had exactly one element. (Note that this works correctly when X is the empty list, so this is a pretty unusual boundary condition.) Regards, David Bartley -------  Date: Wed, 23 Apr 86 23:13:58 EST From: Jonathan A Rees Subject: variata To: RRRS-AUTHORS@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].893236.860423.JAR> Anyone who wants to receive a copy of the "Revised^3 Report on the Algorithmic Language Scheme" should make sure that I have his or her US mail address. I'll also make the LaTeX sources available via Internet FTP. I'm aiming to get it to SIGPLAN by May 1 so it can be in the July issue, but somehow I have managed to misplace a week or two (illness & general procrastination) so there is beginning to be a shadow of a doubt on this proposition, since this gives practically no time for me to get everyone's comments on the draft. I'll mail out a draft as soon as I can (but not immediately) and we'll see what happens. It's in two-column format and is currently about 38 pages long (only a little more than twice the size of the Algol 60 report!), including index, formal semantics, and formal syntax (each of which is 2 pages). Here are a few more little editorial decisions. Please let me know if you have serious objections. I don't believe any of the ones not previously discussed should matter much to anyone in any practical sense, and nearly all of them serve to shorten and simplify the report. - Rest-argument lists are always freshly consed (semantically speaking). [All h*** breaks loose if not.] - An ELSE clause must be last in a COND or CASE. [If implementations want to allow it elsewhere that's fine, but why should arbitrary position be essential?] - (ELSE) isn't a legal clause. [If it is, what does it return, and why?] - (COND) and (CASE x) are syntactically legal expressions. [No one objected to this liberalization when I raised the question before.] - (BEGIN) and (LAMBDA (X)) are not necessarily syntactically legal. [Several people objected to this extension.] - CASE selectors must all be distinct. [This is as in Common Lisp; it assists error checking; and it means nothing has to be said about the order in which clauses are processed.] - It's not specified what happens if the constants in a CASE are objects other than numbers, symbols, characters, or booleans. [This allows implementations to decide for themselves what happens in other situations - EQV?, EQUAL?, etc.] - BOOLEAN? is a new essential procedure. [For symmetry with other type predicates. I didn't ask previously whether or not it should be essential; I hope it's OK if it is.] - EQ? and EQV? must both return true if their arguments are both empty strings or both empty vectors. [I believe that this is implicit in the RRRS. I guess making it explicit might require implementations which don't already do so to special case (MAKE-STRING 0) and (MAKE-VECTOR 0) -- is that OK? If not, then the documentation for EQ? and EQV? has to have yet another special case in it (since zero-length vectors aren't operationally distinguishable from each other), and I'll have to add yet another implementation rationale -- ugh. Also, if (MAKE-STRING 0) and (MAKE-VECTOR 0) are REQUIRED to return new objects, then the formal semantics becomes significantly hairier.] The RRRS says nothing at all about whether the result of APPEND sharing structure with its arguments. Common Lisp says explicitly that all arguments but the last are copied, and the last one never is. I think this is wrong, and maybe incompatible with existing implementations. T permits sharing (not clobbering) whenever that makes sense, e.g. (let ((x (list 1 2))) (eq? x (cdr (append '(a) x '() '())))) might be true. Is it OK if I make this explicitly OK? What about (let ((x (list 'a))) (eq? x (reverse x))) ? Jonathan  Date: Thu, 17 Apr 86 15:26:16 EST From: Jonathan A Rees Subject: early binding To: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA cc: RRRS-AUTHORS@MC.LCS.MIT.EDU In-reply-to: Msg of Thu 17 Apr 86 10:52:41-CST from David Bartley Message-ID: <[MC.LCS.MIT.EDU].887368.860417.JAR> Date: Thu 17 Apr 86 10:52:41-CST From: David Bartley If only the top level forms get macro expanded, then a DEFINE at the top level of a macro called FOO would not be recognized in the top level form (BEGIN (FOO A)(FOO B)), right? That is, if (FOO A) macro-expands into (DEFINE A 42), we'd have (BEGIN (DEFINE A 42)(DEFINE B 42)), but you'd not catch these particular ``top level'' defines? Similarly, suppose (BAR X Y Z) were a macro that expanded into (BEGIN X Y Z). What would happen to (BAR (FOO A)(FOO B))? Would it be fully expanded into (BEGIN (DEFINE A 42)(DEFINE B 42)) in order to catch the definitions? The same question applies to macro expanding the bodies of lambdas in order to detect ``top level'' DEFINEs to be collected into a LETREC. To be honest, I'm not sure how deep my own PC Scheme goes in macro expansion to detect such definitions. Sorry I wasn't clear. All of these define's are found by CLSCH. Bodies of begins are considered to be top level if the begin is at top level. But only enough macro expansion is done to be able to find all possible defines and begins. Since exactly the same scanner is used for lambda-expressions, the same answers apply. Jonathan  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 17 Apr 86 12:10:51 EST Received: from ti-csl by csnet-relay.csnet id ab06099; 17 Apr 86 12:03 EST Received: by tilde id AA00173; Thu, 17 Apr 86 10:55:13 cst Date: Thu 17 Apr 86 10:52:41-CST From: David Bartley Subject: Re: early binding To: JAR%mc.lcs.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: <[MC.LCS.MIT.EDU].886327.860416.JMessage-ID: <12199579682.13.BARTLEY@CSC60> You've pretty well answered my questions, thanks... I have one last (small) question and comment on the following: >Date: Wed, 16 Apr 86 20:57:31 EST >From: Jonathan A Rees > > Date: Tue 15 Apr 86 13:17:22-CST > From: David Bartley > > (1) What do you do if Fi is a BEGIN? For example, in > > (FILE F1 F2 ... (BEGIN (DEFINE A ...)(FOO)(DEFINE B ...)) ... Fn), > > are the DEFINEs for both A and B collected into a BIND by your pre-pass? > >Yes -- this is an extra bonus feature. > > (2) Do you expand macros during the pre-pass? What if a macro expands > into a DEFINE or a BEGIN containing a DEFINE? > >Yes, macros get expanded in the pre-pass, so it "works" for a macro to >expand into (begin (define ...) ...). Only the top level forms get >macro expanded, not their subforms (lazy macroexpansion). If only the top level forms get macro expanded, then a DEFINE at the top level of a macro called FOO would not be recognized in the top level form (BEGIN (FOO A)(FOO B)), right? That is, if (FOO A) macro-expands into (DEFINE A 42), we'd have (BEGIN (DEFINE A 42)(DEFINE B 42)), but you'd not catch these particular ``top level'' defines? Similarly, suppose (BAR X Y Z) were a macro that expanded into (BEGIN X Y Z). What would happen to (BAR (FOO A)(FOO B))? Would it be fully expanded into (BEGIN (DEFINE A 42)(DEFINE B 42)) in order to catch the definitions? The same question applies to macro expanding the bodies of lambdas in order to detect ``top level'' DEFINEs to be collected into a LETREC. To be honest, I'm not sure how deep my own PC Scheme goes in macro expansion to detect such definitions. Regards, David Bartley -------