Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 28 Mar 88 14:27:22 EST Received: from Semillon.ms by ArpaGateway.ms ; 28 MAR 88 10:43:39 PST Date: Mon, 28 Mar 88 10:43:18 PST From: Pavel.pa@Xerox.COM Subject: More for R4RS To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <880328-104339-3618@Xerox> A little while ago, Jon asked for any other subjects to be included in R4RS. Jon, did you mention Will's proposal to make the empty list (optionally) true? Also, as a new proposal, I'd like to see the functions CHAR?, INTEGER->CHAR, and CHAR->INTEGER renamed to CHARACTER?, INTEGER->CHARACTER, and CHARACTER->INTEGER. The reason has to do with the contrast between predicate names like BOOLEAN?, INTEGER?, and RATIONAL? (as opposed to BOOL?, INT?, and RAT?) and the name CHAR?. I had a bit of trouble recently trying to find a predicate for character-ness because I naturally wanted to use the full name of the type, consistently with the rest of Scheme. I was mildly disgusted when I discovered that the name was actually the abbreviation, not the full name. I don't suggest changing the names of the other character operations because they don't seem to be naming the type itself as explicitly. I know this sounds fuzzy, but it seems alright to me to have the names CHARACTER->INTEGER and CHAR-NUMERIC? side-by-side. Comments? Pavel  Received: from SAIL.Stanford.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 28 Mar 88 14:12:26 EST Date: 28 Mar 88 1039 PST From: Dick Gabriel Subject: CLOS Error Terminology To: rrrs-authors@MC.LCS.MIT.EDU The following is the current section on error terminology in the CLOS document. I should point out that this section is currently under debate. The areas of debate are the definitions of ``undefined'' and ``unspecified,'' along with the general philosophy that extensions are disallowed by default (which is the opposite to Common Lisp): \beginSection{Error Terminology} The terminology used in this document to describe erroneous situations differs from the terminology used in {\it Common Lisp: The Language}, by Guy L. Steele Jr. This terminology involves {\bit situations}; a situation is the evaluation of an expression in some specific context. For example, a situation might be the invocation of a function on arguments that fail to satisfy some specified constraints. In the specification of the \CLOS, the behavior of programs in all situations is described, and the options available to the implementor are defined. No implementation is allowed to extend the syntax or semantics of the \OS\ except as explicitly defined in the \OS\ specification. In particular, no implementation is allowed to extend the syntax of the \OS\ in such a way that ambiguity between the specified syntax of \OS\ and those extensions is possible. ``When situation $S$ occurs, an error is signaled.'' This terminology has the following meaning: \beginlist \item{\bull} If this situation occurs, an error will be signaled in the interpreter and in code compiled under all compiler safety optimization levels. \item{\bull} Valid programs may rely on the fact that an error will be signaled in the interpreter and in code compiled under all compiler safety optimization levels. \item{\bull} Every implementation is required to detect such an error in the interpreter and in code compiled under all compiler safety optimization levels. \endlist ``When situation $S$ occurs, an error should be signaled.'' This terminology has the following meaning: \beginlist \item{\bull} If this situation occurs, an error will be signaled at least in the interpreter and in code compiled under the safest compiler safety optimization level. \item{\bull} Valid programs may not rely on the fact that an error will be signaled. \item{\bull} Every implementation is required to detect such an error at least in the interpreter and in code compiled under the safest compiler safety optimization level. \item{\bull} When an error is not signaled, the results are undefined (see below). \endlist ``When situation $S$ occurs, the results are undefined.'' This terminology has the following meaning: \beginlist \item{\bull} If this situation occurs, the results are unpredictable. The results may range from harmless to fatal. \item{\bull} Implementations are allowed to detect this situation and signal an error, but no implementation is required to detect the situation. \item{\bull} No valid program may depend on the effects of this situation, and all valid programs are required to treat the effects of this situation as unpredictable. \endlist ``When situation $S$ occurs, the results are unspecified.'' This terminology has the following meaning: \beginlist \item{\bull} The effects of this situation are not specified in the \OS, but the effects are harmless. \item{\bull} Implementations are allowed to specify the effects of this situation. \item{\bull} No portable program can depend on the effects of this situation, and all portable programs are required to treat the situation as unpredictable but harmless. \endlist ``The \CLOS\ may be extended to cover situation $S$\negthinspace.'' The meaning of this terminology is that an implementation is free to treat situation $S$ in one of three ways: \beginlist \item{\bull} When situation $S$ occurs, an error is signaled at least in the interpreter and in code compiled under the safest compiler safety optimization level. \item{\bull} When situation $S$ occurs, the results are undefined. \item{\bull} When situation $S$ occurs, the results are defined and specified. \endlist In addition, this terminology has the following meaning: \beginlist \item{\bull} No portable program can depend on the effects of this situation, and all portable programs are required to treat the situation as undefined. \endlist ``Implementations are free to extend the syntax $S$\negthinspace.'' This terminology has the following meaning: \beginlist \item{\bull} Implementations are allowed to define unambiguous extensions to syntax $S$\negthinspace. \endlist The \CLOS\ specification may disallow certain extensions while allowing others. \endSection%{Error Terminology}  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 22 Mar 88 09:58:25 EST Date: Tue, 22 Mar 88 09:58:55 EST From: Jonathan A Rees Subject: editing To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <345726.880322.JAR@AI.AI.MIT.EDU> This message is to inform everyone that I'm willing to edit the Revised^4 Report, even if it has to be put into a form constrained by some standards organization. I'm keeping track of changes, typos, and other edits that need to be made. The main language changes on which I perceive consensus so far are (1) addition of PEEK-CHAR (2) changes to number syntax (GJS, GLS, and others have already made appropriate edits to numbers section) (3) changes to description & semantics of EQ? and EQV? to allow multiple empty vectors & strings Have I forgotten anything? I also intend to add a more precise description of quasiquote, which of course will have to be approved first.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 21 Mar 88 12:57:33 EST Date: 21 Mar 88 0954 PST From: Dick Gabriel Subject: Meeting To: rrrs-authors@MC.LCS.MIT.EDU The Chairman and Vice Chairman of X3J13 have asked me to attend the upcoming Scheme meeting in Indiana. As some of you know, I am the US representative to ISO/IEC JTC1/SC22/WG 16, which is the ISO Lisp standardization working group. I was named US representative by ANSI after nomination by X3. As the US representative, I am required to represent the entire US Lisp community. Because I had no instructions or direction from the Scheme community, my representation of it consisted of these actions: 1. declaring to WG 16 that I had no instructions from the Scheme community 2. announcing my belief that the Scheme community was considering a formal standardization process 3. declaring that the US had an interest in either Scheme or Common Lisp as a departure point for ISLISP (the name of ISO Lisp) 4. lobbying against the use of the name ISO Common Lisp as the name of ISO Lisp 5. lobbying against any actions or statements by WG 16 that would jeopardize or constrain the activities of the Scheme community were they to pursue standardization The next ISO meeting will immediately follow the Lisp and Functional Programming Conference, at Snowbird, Utah. At working group meetings I am required to report on national standardization activities. Furthermore, if there are any actions that the Scheme community wishes to take in the working group, those actions must be taken by me. Therefore, my attendance at this meeting is intended to accomplish the following: 1. I can report on the working group meeting 2. I can report on X3J13 activities and responses to the working group meeting 3. I can gather comments that you wish made at the next working group meeting 4. I can accept requests for attendance of the next working group meeting (though I cannot guarantee such requests can be honored until there is an ANSI-recognized standardization group for Scheme) 5. I can accept suggestions for the US position at the working group meetings 6. I will takes notes and prepare a report to WG 16 on the activities at the Scheme meeting See you in Bloomington. -rpg-  Received: from silver.bacs.indiana.edu (TCP 30003147002) by MC.LCS.MIT.EDU 20 Mar 88 15:24:59 EST Date: Sun, 20 Mar 88 15:22:26 est From: R. Kent Dybvig To: rrrs-authors@mc.lcs.mit.edu Subject: meeting I have sent a schedule for this weekend's meeting along with directions from the airport to Bloomington to everyone I have heard from who is planning to attend. If you do not receive this note and you are planning to attend, please call me at 812/333-8653 or 812/335-6486. Electronic mail to me is not reliable, but it will probably reach me if you send it to both "dyb@iuvax.cs.indiana.edu" and "dybvig@silver.bacs.indiana.edu". Kent  Received: from murren (TCP 2206400263) by MC.LCS.MIT.EDU 18 Mar 88 08:26:10 EST Received: by MURREN.AI.MIT.EDU; Fri, 18 Mar 88 08:30:27 est Date: Fri, 18 Mar 88 08:30:27 est From: hal@MURREN.AI.MIT.EDU (Hal Abelson) Message-Id: <8803181330.AA00533@murren> To: rrrs-authors@mc Subject: standardization meeting Reply-To: hal@ai.ai.mit.edu I have invited Dick Gabriel to attend the meeting this weekend.. I think we need to understand what's been happening with the Lisp ISO mess and what implications this has for Scheme. With Bartley, Clinger, and Gabriel there, we should get a good idea.  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 15 Mar 88 16:37:05 EST Received: from relay2.cs.net by RELAY.CS.NET id ab04828; 15 Mar 88 15:54 EST Received: from tektronix.tek.com by RELAY.CS.NET id aj05874; 15 Mar 88 15:43 EST Received: by tektronix.TEK.COM (5.51/6.24) id AA16747; Tue, 15 Mar 88 11:41:36 PST Received: by tekchips.CRL.TEK.COM (5.51/6.24) id AA28467; Tue, 15 Mar 88 11:40:13 PST Message-Id: <8803151940.AA28467@tekchips.CRL.TEK.COM> To: rrrs-authors@mc.lcs.mit.edu Cc: willc%tekchips.crl.tek.com@RELAY.CS.NET Subject: Re: false, (symbol #t), etc Date: 15 Mar 88 11:40:11 PST (Tue) From: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET Reply to Alan Bawden: In terms of Alan's (define (false-test) (list (eq? '() '#f) (not '()))), my proposal was to allow (#F #F) as well as (#T #T) and (#F #T). Reply to Jonathan Rees: I was aware of the representation trick that Jonathan pointed out, but in the implementation I am maintaining it is more important that Scheme fixnums have the same representation as integers and pointers used by the Macintosh Toolbox in ROM. Such is life. Reply to Jonathan Rees and Kent Dybvig: Type inference is a concern, but it will always be heuristic. (You can of course restrict to the domain of the heuristics, which is how you obtain a statically typed language). I think I could live with #t as the only true value, and I might like it better. Regardless, the existence of two false values seems more random than having all but one value count as true, and that intuition is backed up by the complexity of implementation, so the problem of two false values seems more urgent. Furthermore people seem more confused about #f and the empty list than about #t, so non-#t true values seem less troublesome in practice. Reply to Morry Katz and Kent Dybvig: The R3RS is generally silent on disjointness because we have never agreed on what is disjoint, mainly because we wanted to "grandfather" existing implementations of Scheme. It would have been embarrassing to have admitted, for example, that pairs are not required to be disjoint from numbers, so the R3RS was deliberately written in a way that encourages readers to jump to possibly false but reasonable conclusions about disjointness. We expected that implementations would take the hint and change over time so that we could be more explicit in future reports. As I recall, the main reason we failed to specify disjointness was that several implementations needed time to fix problems such as: 1. vectors implemented as lists 2. characters implemented as integers or strings 3. #f implemented as the empty list These "grandfather" provisions were discussed in October 1984, and sins #2 and #3, being the most widespread, were explicitly pardoned by the RRRS and R3RS. I think five years is plenty of warning as well as a good round number, so I think 1989 would be a good year to add disjointness to the report. You should suspect my timetable, though, because it's awfully convenient that while MacScheme currently has problems #2 and #3, I expect them to be fixed early in 1989. I think the best way to get these changes made is for users of Scheme to complain about implementations that haven't made them. Implementors are likely to choose the status quo unless users' complaints about their current system are much more serious than the complaints feared from users whose code will break if the system changes. That's why a number of very smart people designed something like Common Lisp (which broke everyone's code anyway). Kent is right that the cost of delaying a needed change is greater than the cost of making it. It's like delaying a trip to the dentist. Reply to Morry Katz and Daniel Weise: (Weise may have been saying this.) I see no reason why the intensional, implementation-dependent predicates deserve recognition as part of the language. Reply to John Ramsdell: As Jonathan pointed out, the R3RS clearly prohibits the behavior you abhor. The language designers can't do much about implementation bugs. I think I speak for all implementors when I say: Please report bugs! (While MacScheme handles your test case ok, its COND macro still special-cases the variable t. This was a patch installed four years ago to ease the transition from t to #t, and I thank you for reminding me that I forgot to take it out. No one has ever reported it. I'm surprised I haven't run across it myself, since I often use t as a variable.) Peace, William Clinger  Received: from chamarti (TCP 2206400253) by MC.LCS.MIT.EDU 15 Mar 88 12:41:19 EST Received: by CHAMARTIN.AI.MIT.EDU; Tue, 15 Mar 88 12:49:29 est Date: Tue, 15 Mar 88 12:49:29 est From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas) Message-Id: <8803151749.AA27754@chamarti> To: JAR@AI.AI.MIT.EDU Cc: daniel@MOJAVE.STANFORD.EDU, MKATZ@A.ISI.EDU, rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: Jonathan A Rees's message of Mon, 14 Mar 88 22:15:54 EST <341753.880314.JAR@AI.AI.MIT.EDU> Subject: Types in Scheme Reply-To: jinx@zurich.ai.mit.edu I'm sorry, can you tell me again why you'd want to ask the unportable ("intensional") question in portable code, or in any code, for that matter? As someone trying to write good code, I want my program to be as insensitive as possible to the Scheme implementor's representation decisions I think you are being too "nitpicky" here. Just because a piece of code is not portable it does not mean it is not good. To get some efficiency (or detailed control of precision and accuracy), it may be necessary, for example, to inquire whether a number (which might otherwise be COMPLEX?, REAL?, RATNUM?, and INTEGER?) is a FIXNUM? in a particular implementation. I'm not advocating for implementation-specific predicates in the language, but it is clear to me that they are necessary for certain pieces of admittedly non-portable code. Each implementation should provide a set of predicates about representation because it MAY matter to someone, and s/he may have a valid use for them.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Mar 88 10:58:05 EST Date: Tue, 15 Mar 88 10:57:29 EST From: Jonathan A Rees Subject: t and nil To: ramsdell%linus@MITRE-BEDFORD.ARPA cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 15 Mar 88 07:22:46 EST from John D. Ramsdell Message-ID: <342005.880315.JAR@AI.AI.MIT.EDU> Date: Tue, 15 Mar 88 07:22:46 EST From: John D. Ramsdell On another subject, I would like to see that the variables T and NIL not be treated specially. In particular, a user should be able to type: (let ((t '#f)) t) ==> #f You can already do this, and indeed I do it often. T and NIL are treated no differently from CAR or LENGTH, which you can also rebind. The report doesn't mention this case explicitly because it doesn't really need to; I think it's implied. An example to this effect should probably be added somewhere, though, perhaps under the description of LAMBDA. I don't particularly care whether T and NIL remain. The fact that you thought NIL was initially bound to () instead of to #F is a good argument in favor of flushing NIL.  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 15 Mar 88 07:26:23 EST Posted-From: The MITRE Corp., Bedford, MA Received: from darwin.sun.uucp by linus.research (3.2/4.7) id AA01458; Tue, 15 Mar 88 07:22:49 EST From: John D. Ramsdell Posted-Date: Tue, 15 Mar 88 07:22:46 EST Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3) id AA20533; Tue, 15 Mar 88 07:22:46 EST Date: Tue, 15 Mar 88 07:22:46 EST Message-Id: <8803151222.AA20533@darwin.sun.uucp> To: rrrs-authors@mc.lcs.mit.edu Cc: ramsdell@mitre-bedford.ARPA In-Reply-To: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET's message of 10 Mar 88 14:39:25 PST (Thu) <8803102239.AA26765@tekchips.CRL.TEK.COM> Subject: t and nil I support Will's suggestion to not specify whether the empty list counts as true or as false. I think now is the time for making (not '()) ==> #f. On another subject, I would like to see that the variables T and NIL not be treated specially. In particular, a user should be able to type: (let ((t '#f)) t) ==> #f I like using a local variable named "T". Experience shows that it is not portable to do so. I think it should be. I'm not sure why the standard suggests that T and NIL may have initial values. Those writing portable code which uses T and NIL should start there code with (define t '#t) (define nil '()) I suggest r^xrs drop any reference to the variables T and NIL. Let T and NIL be special only in that they have the same name as some Lisp dialects.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Mar 88 22:16:43 EST Date: Mon, 14 Mar 88 22:15:54 EST From: Jonathan A Rees Subject: Types in Scheme To: daniel@MOJAVE.STANFORD.EDU cc: MKATZ@A.ISI.EDU, rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Mon 14 Mar 88 10:11:20 PST from Daniel Weise Message-ID: <341753.880314.JAR@AI.AI.MIT.EDU> Date: Mon, 14 Mar 88 10:11:20 PST From: Daniel Weise ... The portable type predicates want to be extensional (does this object behave as a pair?), the unportable type predicates are intensional (is this object a pair?). We obviously want to ask both types of questions, ... I'm sorry, can you tell me again why you'd want to ask the unportable ("intensional") question in portable code, or in any code, for that matter? As someone trying to write good code, I want my program to be as insensitive as possible to the Scheme implementor's representation decisions -- we all know how perverse implementors can be. Thus I should never want to use the "intensional" predicates. It seems like this is more of an argument for eliminating the CHAR? predicate (which doesn't seem to mean much or me, since character is an "abstract type", at least as the report stands) than an argument in favor of introducing a PRIMITIVE-PAIR? predicate (which would be just as useless). Abstract types may be good for static type checking and program verification, but I assume we're not talking about that, we're talking about the dynamic semantics of a dynamically typed language. The only use I can think of for predicates like CHAR? and PRIMITIVE-PAIR? is explicit run-time type checking in user code: (if (not (char? x)) (error "X isn't a character" ...)) This kind of thing always seems kind of fishy to me; how does one decide when to put these checks in and when not to? The Scheme programmer can't really do this in any case, because ERROR isn't standard... And speaking of CHAR?: I notice that CHAR? is an essential procedure. To be consistent with my remarks above, I would like to suggest that if characters are to remain not necessarily distinguishable from numbers, pairs, etc., then this procedure should be made non-essential, and that it should be present iff the implementation has a distinct (extensional?) character type.  Received: from mojave.stanford.edu (TCP 4402400016) by MC.LCS.MIT.EDU 14 Mar 88 13:20:57 EST Received: by mojave.stanford.edu; Mon, 14 Mar 88 10:11:20 PST Date: Mon, 14 Mar 88 10:11:20 PST From: Daniel Weise To: MKATZ@a.isi.edu Cc: rrrs-authors@mc.lcs.mit.edu Subject: Types in Scheme It is with some regret and with anticipation of a barrage of heated replies that I make the following statements. If the goals of our type predicates are to enable the writing of portable code and to make the writing of some other forms of code easier, then I believe that we really need two sets of type predicates: one based on the functionlity intended for an object and the other based on its representation. I agree. This is the old intensional versus extensional dichotomy, made clear by Andy's message in which pairs could be implemented as vectors and vice versa. The portable type predicates want to be extensional (does this object behave as a pair?), the unportable type predicates are intensional (is this object a pair?). We obviously want to ask both types of questions, and it is important that we keep their differences clear. Daniel  Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 14 Mar 88 12:50:50 EST Received: by ZOHAR.AI.MIT.EDU; Mon, 14 Mar 88 11:59:15 est Date: Mon, 14 Mar 88 11:59:15 est From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman) Message-Id: <8803141659.AA26241@zohar> To: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET Cc: rrrs-authors@mc.lcs.mit.edu, willc%tekchips.crl.tek.com@RELAY.CS.NET In-Reply-To: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET's message of 10 Mar 88 14:39:25 PST (Thu) <8803102239.AA26765@tekchips.CRL.TEK.COM> Subject: false I agree with Will that we no longer need to specify this crock.  Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 14 Mar 88 12:40:59 EST Date: Mon 14 Mar 88 12:38:07-EST From: Morris Katz Subject: Types in Scheme To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <12382302321.36.MKATZ@A.ISI.EDU> It is with some regret and with anticipation of a barrage of heated replies that I make the following statements. If the goals of our type predicates are to enable the writing of portable code and to make the writing of some other forms of code easier, then I believe that we really need two sets of type predicates: one based on the functionlity intended for an object and the other based on its representation. I will prefix the predicates of the latter type with the word primitive in the following examples for expository purposes. (symbol? 'a) ==> #t (number? 'a) ==> #f (primitive-number? 'a) ==> unspecified (depends on whether this implementation represents symbols as numbers) Such a type system allows complete flexibility in terms of implementation while still supporting a maximum amount of type safety. It also allows the programmer to specify exactly what he means when he uses a type predicate. Does he care about how the object is being used or what its actual representation is. These a two quite different things. Morry Katz -------  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 12 Mar 88 14:22:46 EST Received: by iuvax.cs.indiana.edu; id AA12351; Sat, 12 Mar 88 14:00:58 EST Date: Sat, 12 Mar 88 14:00:58 EST From: R. Kent Dybvig Message-Id: <8803121900.AA12351@iuvax.cs.indiana.edu> To: rrrs-authors@mc.lcs.mit.edu Subject: travel plans Our arpanet link was down for four days last week, from Monday to Thursday. If anyone tried to send me mail, and it bounced, please resend. To be safe, you might want to send mail via uucp as well as arpanet; my arpanet address is dyb@iuvax.cs.indiana.edu and my uucp address is dyb@iuvax. The following people have informed me that they are coming to the meeting from out of town: Hal Abelson, Will Clinger, Gary Brooks, Clyde Camp, and John Ramsdell. I have also heard that Gerry Sussman and Bill Rozas are coming. So far I have Will, Gary, and John signed up for rooms at the Bloomington Ramada Inn. I was supposed to tell the Ramada Inn the list of names yesterday, but they are willing to give us a few more days. Please let me know if you plan to attend and about your travel plans. If you are interested in sharing a rental car with others who are travelling to Bloomington, please let me know your flight times and I'll try to hook you up. More later...  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 12 Mar 88 00:07:17 EST Received: by iuvax.cs.indiana.edu; id AA20531; Sat, 12 Mar 88 00:07:30 EST Date: Sat, 12 Mar 88 00:07:30 EST From: R. Kent Dybvig Message-Id: <8803120507.AA20531@iuvax.cs.indiana.edu> To: rrrs-authors@mc.lcs.mit.edu Subject: Re: false I agree with Will that we should make the falseness of () unspecified, if we can't do better. But why don't we go all the way on this one, and require that () be distinct from #f and that only #t and #f be treated as booleans in conditional expressions? Yes, it would affect a lot of code and a few books, but only a fraction of what is yet to be written, unless we are are wasting our time. It is a shame we didn't do it right a long time ago. Surely it would have been less painful three years ago than now, and surely it will be less painful now than in another three years. If we can't agree that it is a good idea to treat only #t and #f as boolean values, then maybe we can agree that it is a good idea to require that () be distinct from #f.  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 12 Mar 88 00:05:40 EST Received: by iuvax.cs.indiana.edu; id AA19307; Fri, 11 Mar 88 23:35:42 EST Date: Fri, 11 Mar 88 23:35:42 EST From: R. Kent Dybvig Message-Id: <8803120435.AA19307@iuvax.cs.indiana.edu> To: JAR@mc.lcs.mit.edu, Pavel.pa@XEROX.COM Subject: Re: (SYMBOL? #t) ==> ? Cc: andy%hobbes@ADS.COM, rrrs-authors@mc.lcs.mit.edu I believe there are two uses for type predicates: (1) to determine if an object is of a given type, and (2) to determine if an object is *not* of a given type. (1) is useful for writing type-safe code, since it allows us to verify, for example, that an object is a pair before calling "car". In this case it doesn't matter whether the object happens also to be a string or symbol, so under Andy's proposal the type predicates would still be useful. ("doesn't matter" may be a little strong---since it would matter if I want to be sure not to apply "car" to a string represented as a list of characters. Therefore, "useful" may be a little strong, at least if a predicate such as "pair?" returns true for all objects. The point is we can still use the predicates to write "type-safe" code, though maybe not "type-sensible" code). (2) is useful when the type itself determines what operation we want to perform, as with "write" and "display". It would not be friendly if a system printed all objects as integers, as it might if they were all considered integers by "integer?". (I already dislike that I can enter #\a and receive 97 back.) One might argue that printing objects is for the system to worry about, but what if I want to write a portable pretty printer or editor? Or a generic "sequence" mapping procedure, defined something like: (define gmap (lambda (proc seq) (cond [(list? seq) ... code for mapping over lists ...] [(vector? seq) ... code for mapping over vectors ...] [(string? seq) ... code for mapping over strings ...] [else 'error]))) I'm likely to get burned if vectors are represented as tagged lists. If a "minimal" implementation is to be built from pairs using the first element of the list as a tag, then it should have a tag for pairs as well as for symbols, vectors, strings, etc. In this way, it can maintain the illusion of disjoint types, even though the underlying structure (at one level) is the same. The "pair?", "cons", "car", and "cdr" procedures provided to the programmer would have to take account of the tag, of course. This is no different from a standard tagged object typing system at the machine level. Kent  Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 11 Mar 88 23:05:25 EST Received: from Salvador.ms by ArpaGateway.ms ; 11 MAR 88 20:03:13 PST Date: Fri, 11 Mar 88 20:03:09 PST From: Pavel.pa@Xerox.COM Subject: Re: (SYMBOL? #t) ==> ? In-reply-to: <340292.880311.JAR@AI.AI.MIT.EDU> To: Jonathan A Rees Cc: andy%hobbes@ADS.COM, rrrs-authors@MC.LCS.MIT.EDU Message-ID: <880311-200313-1033@Xerox> Jon asks: ``Tell me how to write a symbolic differentiation program, or an evaluator, that operates on the "obvious" s-expression inputs (e.g. the list (/ 1 (sqrt (+ 1 x)))) in a world where the types number, pair, symbol are not disjoint.'' Suppose that my only two disjoint types are characterized by the predicates NULL? and PAIR?. Then I can certainly define other types by making them lists with various internal structures and unique, particular cons cells as ``tags'' in the car of the top-level cons-cell of the value. Then my other predicates, SYMBOL? and NUMBER?, simply check for PAIR? first and then test that the CAR is the special cons cell for that type. Thus, in such an implementation (please, please keep in mind that I'm not necessarily in favor of the proposal and certainly not in favor of this implementation; my reputation is at stake here...) we would have the following implications: (number? x) => (pair? x) (symbol? x) => (pair? x) (number? x) => (not (symbol? x)) (pair? x) => (not (null? x)) and no others not deducible from these. I claim that in such a system I could write the code you describe by simply checking number? and symbol? before checking pair? at each point. Note however, that while I've written (in the sense of a mathematician) the code you requested, that code would not be portable to an implementation in which any of the implications above were reversed. In particular, if an implementation represented symbols and pairs in terms of numbers (never mind about how they get the right semantics for set-car!), my code would fail because I would be testing for things in the wrong order. Hmm. This is a very persuasive argument against all kinds of things not being disjoint. I think I just firmly moved into the anti-proposal camp. I think that the issue is unrelated to questions of ``the type'' of an object and is much more related to the question of which types I want to be able to distinguish and treat differently. In particular, Andy proposed that one implementation might want to represent vectors by pairs and another might want to do the reverse. By the kind of portability argument I've just given, the Scheme spec would have to specify that at least one of these was not legal, so that I could figure out the proper portable order in which to test things. However, I can see no reason to prefer one of these representation choices to the other, so I would be forced to forbid both of them, since I certainly want to be able to distinguish pairs and vectors. Hmm. I guess I'm really firmly in the disjointness camp. I hope no one gets whiplash reading this note... Pavel  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Mar 88 22:42:27 EST Date: Fri, 11 Mar 88 22:41:43 EST From: Jonathan A Rees Subject: (SYMBOL? #t) ==> ? To: Pavel.pa@XEROX.COM cc: andy%hobbes@ADS.COM, rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Fri 11 Mar 88 19:10:23 PST from Pavel.pa at Xerox.COM Message-ID: <340292.880311.JAR@AI.AI.MIT.EDU> Date: Fri, 11 Mar 88 19:10:23 PST From: Pavel.pa at Xerox.COM The type predicates are not useless in general, their use is simply unnecessary in *that* implementation of Scheme. They are still necessary for the writing of portable code. I must be missing something. How could a predicate that might always return true be at all useful in portable code? Tell me how to write a symbolic differentiation program, or an evaluator, that operates on the "obvious" s-expression inputs (e.g. the list (/ 1 (sqrt (+ 1 x)))) in a world where the types number, pair, symbol are not disjoint.  Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 11 Mar 88 22:19:55 EST Received: from Salvador.ms by ArpaGateway.ms ; 11 MAR 88 19:10:32 PST Date: Fri, 11 Mar 88 19:10:23 PST From: Pavel.pa@Xerox.COM Subject: Re: (SYMBOL? #t) ==> ? In-reply-to: <340276.880311.JAR@AI.AI.MIT.EDU> To: Jonathan A Rees Cc: andy%hobbes@ADS.COM, rrrs-authors@MC.LCS.MIT.EDU Message-ID: <880311-191032-2412@Xerox> Mind you, I'm not sure that I like Andy's proposal, but I thought that I should correct one of Jon's statements. Jon says: ``As I understand your message, you are saying that a Scheme implementation in which, say, ALL type predicates returned #T ALWAYS, would be a correct one. For example, it could be the case that (symbol? '(a b)) => #t and (pair? 'a) => #t. (I guess it would also have to have no type errors, but that's a detail.) It seems to me that this makes the type predicates nearly useless.'' The type predicates are not useless in general, their use is simply unnecessary in *that* implementation of Scheme. They are still necessary for the writing of portable code. Some implementations, such as Cedar Scheme so long as I'm involved with it, would have all of the disjointness properties you could ask for and so code written to run under it would need all of those predicates. Michael Plass here pointed out that one benefit of allowing the various types to share members is that a very small conforming implementation could be written in which, for example, all of lists, vectors and strings were implemented as cons cells (vectors and strings would, of course, use some special marker in the first CAR). I'm not particularly impressed with this argument, but it does seem to be valid. Pavel  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Mar 88 21:55:21 EST Date: Fri, 11 Mar 88 21:55:03 EST From: Jonathan A Rees Subject: (SYMBOL? #t) ==> ? To: andy%hobbes@ADS.COM cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Fri 11 Mar 88 12:31:28 PST from andy%hobbes at ads.com (Andy Cromarty) Message-ID: <340276.880311.JAR@AI.AI.MIT.EDU> Date: Fri, 11 Mar 88 12:31:28 PST From: andy%hobbes at ads.com (Andy Cromarty) This suggests that if v is a vector and p a pair, then (VECTOR? v) and (PAIR? p) should be true, but (VECTOR? p) and (PAIR? v) should be undefined in the Report (i.e. considered to be implementation-dependent). I knew this topic would spark a lively debate. As I understand your message, you are saying that a Scheme implementation in which, say, ALL type predicates returned #T ALWAYS, would be a correct one. For example, it could be the case that (symbol? '(a b)) => #t and (pair? 'a) => #t. (I guess it would also have to have no type errors, but that's a detail.) It seems to me that this makes the type predicates nearly useless. In that case, they should be eliminated from the language, making Scheme more like ML (and C and FORTRAN and ...). Then to make up for this absence, we should have strong typing. I think this would break a lot of programs and annoy many users. I am not an opponent of subtyping or of abstract data types. I certainly don't want to promote a notion of "the type of" an object, since an object can have many types. All I am suggesting is that we specify some set of circumstances in which the type predicates will return false. We all make some assumptions implicitly now; I just want the report to codify existing practice. Language like that in CLtL would be fine -- take a look at it, you'll notice that some things are left unspecified -- but I would hope for something a little tighter.  Received: from ads.com (TCP 20071200430) by MC.LCS.MIT.EDU 11 Mar 88 16:18:49 EST Received: from hobbes.ads.com by ads.com (5.58/1.9) id AA00697; Fri, 11 Mar 88 12:35:07 PST Received: by hobbes.ads.arpa (3.2/SMI-3.2) id AA00448; Fri, 11 Mar 88 12:31:28 PST Date: Fri, 11 Mar 88 12:31:28 PST From: andy%hobbes@ads.com (Andy Cromarty) Message-Id: <8803112031.AA00448@hobbes.ads.arpa> To: JAR@ai.ai.mit.edu Subject: Re: (SYMBOL? #t) ==> ? Cc: rrrs-authors@mc.lcs.mit.edu I am concerned that specifying type disjointedness gets us into the very messy business of (a) unintentionally and unnecessarily specifying implementation details and (b) reinforcing the distinction between system-defined and user-defined types. For example, it should be possible for an implementor to choose to implement vectors as tagged lists, if lists happen to be unusually efficient in this implementation (or vice-versa). It appears to me that we do not (yet) subscribe to the TYPEP model, in which an object "has a type," and that it is good that we don't. Instead, we treat types as attributes of an object -- consider (INTEGER? 3) and (NUMBER? 3) -- allowing us to recognize more cleanly in our code that (a) an object may have several attributes and (b) there may (or may not) be important relationships between those attributes. This suggests that if v is a vector and p a pair, then (VECTOR? v) and (PAIR? p) should be true, but (VECTOR? p) and (PAIR? v) should be undefined in the Report (i.e. considered to be implementation-dependent). If there are important counterexamples where it is necessary to know what an object's type is, as distinct from knowing whether it satisfies the criteria of a given equivalence class, I suggest we bring out those examples directly for public scrutiny and discussion. (They could lead to a more Common LISP-like type model.) My intuition is that such a change is unnecessary and that Scheme's type model gives the software more latitude in defining the relationships between different types, given that [BEGIN OPINION] the computer science community still seems to be mired in this abstract data practice of defining types in terms of other types [END OPINION], and that instead we might wish to protect and capitalize on Scheme's apparent underspecification of the types of objects and the relationships that obtain between those type classes. asc p.s. I suspect this represents an argument that (if '() #t #f) should be undefined in the Report (i.e. implementation-dependent). Of course, good programming practice would dictate the use of NULL? where the test-object is a (possibly-empty) list in either case.  Received: from chamarti (TCP 2206400253) by MC.LCS.MIT.EDU 11 Mar 88 14:50:51 EST Received: by CHAMARTIN.AI.MIT.EDU; Fri, 11 Mar 88 14:59:02 est Date: Fri, 11 Mar 88 14:59:02 est From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas) Message-Id: <8803111959.AA23113@chamarti> To: mcvax!diku.dk!danvy@uunet.UU.NET Cc: rrrs-authors@mc.lcs.mit.edu In-Reply-To: Olivier Danvy's message of Tue, 8 Mar 88 20:18:15 +0100 <8803081918.AA22809@diku.dk> Subject: next report on Scheme Reply-To: jinx@zurich.ai.mit.edu Finally, has someone proposed already a call-with-current-environment similar in spirit to call-with-current-continuation? (1) The environment could be a function Variable --> Value to model the evaluation of a variable and/or Bound-Variable * Value ---> Unspecified to model set! (2) Or it could be a function Variable --> Location although it would introduce the concept of location, and of accessing and updating a location. Similarly to define a new location, at the top level or internally. Anyway it would functionalize the environments got from THE-ENVIRONMENT in CScheme. This procedure has been proposed in the past. There are a few problems with it, some political and some technical: 1) Not all implementations support first class environments. Furthermore, some designers/implementors abhor them. It is therefore unlikely that consensus will be reached on anything involving them. 2) The semantics of a procedural CALL-WITH-CURRENT-ENVIRONMENT are not clear. In particular, which environment is handed to the receiver? Many possibilities come to mind, including the following: 1: The environment where CALL-WITH-CURRENT-ENVIRONMENT is closed. 2: The environment where the variable CALL-WITH-CURRENT-ENVIRONMENT is evaluated. 3: The environment where the combination which results in an application of the value of CALL-WITH-CURRENT-ENVIRONMENT is evaluated. 4: The environment where the receiver is closed. 5: The environment where the body of the receiver will be evaluated. None of these are really adequate: 1: Pretty useless. May as well define it as a constant. 2: It makes some variables special, hard to handle by compiler/interpreter. Furthermore, it probably does not have the desired effect in cases like (define (foo) call-with-current-environment) (let ((x 3)) ((foo) (lambda (env) env))) 3: This is probably the desired semantics. It has the nice property that THE-ENVIRONMENT can expand trivially into ((absolute call-with-current-environment) (lambda (env) env)) Unfortunately, it forbids certain kinds of EVLIST tail recursion. 4: This is pretty good. The same expansion that works in 3 above works here too. Unfortunately it forbids certain kinds of environment optimization. For example in, (call-with-current-environment (generate-proc 2 3)) GENERATE-PROC must return a procedure whose format can be understood by CALL-WITH-CURRENT-ENVIRONMENT. Since GENERATE-PROC might be compiled out of line, this forces the compiler to avoid environment optimization in most environments. 5: This has the same problems that 4 does and it harms incremental definition as well: The environment obtained is most likely not the one where the definitions are desired (the parent environment frame is the one the user probably wants). The real issue is that by being a special form, the correct things "happen": The environment where the special form is evaluated is the environment desired, so it is certainly available when the code is executed. A convenient syntactic marker is provided so that optimizing compilers can discriminate at compile time between environments used in a "first-class" way, and those which cannot be examined by the user in a similar way (modulo debuggers, etc, which are always special). The compiler has full freedom to implement these other environments, since only code generated by the compiler at that time (or the debugger) will ever need to examine them. In order to understand my point, please consider the following (somewhat forced) analogy: Eliminate LAMBDA as a special form from the language in favor of a procedural constructor: (lambda (x y z) ) becomes (make-procedure '(x y z) ') The "bad" cases arise from things similar to (foo ') where FOO is compiled in a separate file and is defined as (define (foo code) (make-procedure '(a b c) code)) or (make-procedure (generate-arg-list) ')  Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 11 Mar 88 13:17:29 EST Date: Fri 11 Mar 88 13:15:38-EST From: Morris Katz Subject: Re: false To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <12381522718.29.MKATZ@A.ISI.EDU> I agree in principle with Will's suggestion regarding #f and the empty list; but, I would advocate going one step farther. I believe that it is important semantically that (null? #f) return #f and therefore whether the empty list is equivalent to #f cannot be left unspecified. While I understand the desire not to become gratuitously incompatible with either Commonlisp or old revisions of Scheme, I feel that the equivalence of #f and the empty list is a serious semantic error which should no longer be propogated. If we were able to decide that (car '()) would no longer be required to return '(), then I see no reason why we can't make this improvement as well. Morry Katz -------  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Mar 88 13:00:54 EST Date: Fri, 11 Mar 88 13:00:23 EST From: Alan Bawden Subject: false To: willc%tekchips.tek.com@RELAY.CS.NET cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Fri 11 Mar 88 12:09:07 EST from Jonathan A Rees Message-ID: <339877.880311.ALAN@AI.AI.MIT.EDU> Let me make sure I understand the proposal. (define (false-test) (list (eq? '() '#F) (not '()))) Currently a conforming Scheme implementation may return either (#T #T) or (#F #T) as the value of (FALSE-TEST). The proposal is to allow implementations in which (#F #F) is returned. It might be argued that (#T #T) and (#F #F) should be the only legal cases, and (#F #T) should be eliminated. But that is not the current proposal. Correct?  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Mar 88 12:50:18 EST Date: Fri, 11 Mar 88 12:50:11 EST From: Jonathan A Rees Subject: (SYMBOL? #t) ==> ? To: ziggy@VX.LCS.MIT.EDU cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Thu 10 Mar 88 14:12:19 est from Michael R. Blair Message-ID: <339871.880311.JAR@AI.AI.MIT.EDU> Date: Thu, 10 Mar 88 14:12:19 est From: Michael R. Blair To: jar Re: (SYMBOL? #t) ==> ? Chris Hanson and I noticed a possible non-ideality in the Revised^3 report. Specifically, (SYMBOL? #t) ==> ? We think it should be #f but the manual does not specify? I'm not sure why you single out the question of disjointness of the boolean and symbol types; the report is also mute on the question of what (pair? 3) returns. One might infer from the formal semantics that the types explicitly listed in the domain equation for expressed values are disjoint, but some uncertainty is in order since (a) the semantics of the built-in type predicates aren't given, (b) the text says that certain deviations from the domain equations are allowed (e.g. characters needn't be a distinct type, and () possibly= #f); so why not others? My interpretation is that types must be disjoint except where explcitly stated otherwise in the text of the report. In particular: (number? 'a) => #f (symbol? #t) => #f (boolean? 't) => #f (vector? #\c) => unspecified (boolean? '()) => unspecified Common Lisp: The Language addresses the question of type disjointness in a brief section devoted to that purpose. The scheme report should also say something explicit on this topic. Before the report can say something comprehensive, however, the rrrs-authors will have to decide some sticky, previously unraised questions: - Are the input-port and output-port types distinct from the others? [My opinion: yes, as long as all implementations already do this.] - Is the procedure type disjoint from others? [Yes.] - Is the type of promises disjoint from the others? [No, it's acceptable to implement them as procedures or vectors.] - Is the type of eof-objects disjoint from the others? [I don't care.] From the above it's clear that we don't really have adequate terminology to talk about this question. I want adjectives to apply to the word "type" to distinguish the class of types that are known to be disjoint from each other (and thus distinguishable using type predicates: (foo? x) = (bar? x) iff foo = bar) from the class of types that aren't (in which case you might have a foo? predicate but no claim about what other predicates return for things for which foo? returns true). Suggestions? Something like "latent" and "manifest", except that those mean something different. Fortunately, Scheme as it stands doesn't have subtyping like Common Lisp does (except among number types, which are already dealt with), so it should be possible to make the discussion tighter and less confusing than that in CLtL.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Mar 88 12:09:41 EST Date: Fri, 11 Mar 88 12:09:07 EST From: Jonathan A Rees Subject: false To: willc%tekchips.tek.com@RELAY.CS.NET cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of 10 Mar 88 14:39:25 PST (Thu) from willc%tekchips.CRL%tektronix.tek.com at RELAY.CS.NET Message-ID: <339858.880311.JAR@AI.AI.MIT.EDU> I support this change. However: Date: 10 Mar 88 14:39:25 PST (Thu) From: willc%tekchips.CRL%tektronix.tek.com at RELAY.CS.NET One of the things that discourages implementors from making the empty list distinct from #f is the fact that the empty list counts as false. On many architectures this makes it slower to test a boolean value (unless the implementor biases the representations to take this problem into account, which would probably make other operations slower). In MacScheme, for example, testing a boolean return value currently looks like cmp.l #F,RESULT beq --- but would look like cmp.l #NULL,RESULT beq --- cmp.l #F,RESULT beq --- if #f were different from the empty list. Unless I'm overlooking some vagaries of the way byte and word instructions work on the 680x0, then I think you can do better than this, if you can arrange that the low N bits (for N = 8 or 16) of #f and () are the same, and different from the low N bits of every other object. Then the false test becomes cmp.w #NO,RESULT ;Or cmb.b beq --- where NO is the distinctive false bit pattern. On the 680x0, if RESULT is not a register, then an offset of 2 or 3 must be added to the effective address. On the little-endian VAX the right thing happens automatically. "Always looking for better kludges to promote inelegance." And another nit: Having the empty list count as false makes it harder to do type inference, because for example you can't tell whether a procedure that returns the empty list is supposed to return a boolean or a list. If type inference is a concern, then it seems to me that accepting, say, the symbol T as a true value is just as much of a problem as accepting the empty list as a false one; in either case you are going to have trouble deducing that something is a boolean. Seems to me that the only way to make type inference work well is to not only separate () from #f, but make it be an error to allow anything other than a boolean as the value of a test in an IF. I suspect this position would be too radical to be accepted by most of us, perhaps even including me. In spite of these objections: as stated above, I support making the trueness or falseness of () be unspecified.  Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 10 Mar 88 20:46:03 EST Received: from Cabernet.ms by ArpaGateway.ms ; 10 MAR 88 17:45:27 PST Date: Thu, 10 Mar 88 17:44:50 PST From: Pavel.pa@Xerox.COM Subject: Re: false In-reply-to: <8803102239.AA26765@tekchips.CRL.TEK.COM> To: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET Cc: Plass.pa@Xerox.COM Cc: rrrs-authors@mc.lcs.mit.edu Message-ID: <880310-174527-2808@Xerox> I very much support this change. Cedar Scheme already has false not equal to the empty list and it would certainly make our lives easier (and our code faster) if we didn't have to treat them as though they were the same for the purposes of testing predicates. Since we are intending to push very hard towards a strong typing discipline, this will also help our type inference engine, as pointed out by Will. Since we don't have to maintain compatibility with any old Scheme/Lisp code, we are feeling free to make our implementation maximally strict about all of the other undefined values and effects; this makes it possible for code that runs in Cedar Scheme to run in any other implementation. Will's change would be a fine addition to that set of strictnesses. Pavel Curtis Xerox PARC/CSL  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 10 Mar 88 20:20:02 EST Received: from relay2.cs.net by RELAY.CS.NET id ad14661; 10 Mar 88 19:47 EST Received: from tektronix.tek.com by RELAY.CS.NET id dc01153; 10 Mar 88 19:38 EST Received: by tektronix.TEK.COM (5.51/6.24) id AA10652; Thu, 10 Mar 88 14:40:39 PST Received: by tekchips.CRL.TEK.COM (5.51/6.24) id AA26765; Thu, 10 Mar 88 14:39:27 PST Message-Id: <8803102239.AA26765@tekchips.CRL.TEK.COM> To: rrrs-authors@mc.lcs.mit.edu Cc: willc%tekchips.crl.tek.com@RELAY.CS.NET Subject: false Date: 10 Mar 88 14:39:25 PST (Thu) From: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET I would like to request that the next revision of the Scheme report not specify whether the empty list counts as true or as false. I think we all recognize that the empty list counts as false only because Scheme came out of a Lisp tradition in which NIL served as both the empty list and as the false value. When we decided to distinguish #f from the empty list, we felt that we had to make allowances for existing implementations that confuse the two. Since such implementations could not possibly have the empty list count as true, we made it count as false. This was a mistake; we should have left it unspecified, just as it was unspecified whether the empty list was distinct from #f. The R3RS states quite explicitly that the reason the empty list counts as false is "for compatibility with existing programs and implementations that assume this to be the case". As I explain later in this message, compatibility can be maintained without requiring that all implementations perpetuate this mistake; we did not realize this at the time. Existing implementations would not have to change. They could take advantage of the underspecification to have the empty list continue to count as false, just as many implementations take advantage of the loophole that lets the empty list be identical to #f. Five or ten years from now, after we've required the empty list to be distinct from #f, perhaps we can require that the empty list count as true. Not now. REASONS FOR CHANGE If we are thinking of formal standardization, we should keep things out of the standard that we might regret later. The fact that the empty list counts as false falls into that category. Having the empty list count as false makes it harder to do type inference, because for example you can't tell whether a procedure that returns the empty list is supposed to return a boolean or a list. That is why it is considered bad style for a programmer to write '() when returning a boolean value, because this makes it hard for human readers to do the "type inference". The existence of implementation modes that detect the use of the empty list as a boolean would help programmers to develop better style. (For example, my translations of the Gabriel benchmarks into Scheme have many such stylistic horrors, but it was impractical for me to track them down because I didn't have an implementation that would catch them for me.) The way that the R3RS is written encourages readers to believe that the empty list is distinct from #f. So far as I know, it goes out of its way to allow them to be the same only in the English description of NULL?. This shows that we expected future implementations of Scheme to distinguish #f from the empty list. People learning Scheme are confused if the empty list is the same as #f (unless their brains have already been addled by exposure to some other dialect of Lisp). This shows that future implementations of Scheme should distinguish #f from the empty list. One of the things that discourages implementors from making the empty list distinct from #f is the fact that the empty list counts as false. On many architectures this makes it slower to test a boolean value (unless the implementor biases the representations to take this problem into account, which would probably make other operations slower). In MacScheme, for example, testing a boolean return value currently looks like cmp.l #F,RESULT beq --- but would look like cmp.l #NULL,RESULT beq --- cmp.l #F,RESULT beq --- if #f were different from the empty list. So the change is useful to preserve our flexibility for the future, for type inference/checking, to encourage good style, and to prevent implementations that work the way we intended and the way users expect from paying a (very small) performance penalty. COMPATIBILITY Suppose I want to build an implementation in which the empty list does not count as false. (I do.) Won't I be breaking a lot of code? Surprisingly not. I can provide a compiler switch that people can use to compile their code as though the empty list counts as false. That will keep users of old code happy without penalizing writers of new code. What about the procedure library? The only standard Scheme procedure affected by the change is the NOT procedure. I will thus have to provide two versions of NOT, one for compatibility with old code and another for new code, and have the compiler switch arrange to compile in an environment which differs from the standard environment only for NOT. Not all implementors will want to take even this minimal trouble to support a compatibility mode, and that's fine. All I'm asking is that Scheme let me and like-minded implementors support a "progressive" mode in which the empty list counts as true, and let me and like-minded users write code using that mode. What do you say? BOOKS From glancing at S&ICP and TLL, I don't think they would be significantly affected by this. Both are written as though (= 3 4) returns the symbol NIL, so they would be no less accurate than before. Abelson and Sussman early define false as NIL and true as non-NIL, and use the terms "true" and "false" throughout the rest of the book, so there are only a couple of pages where a teacher would have to make a correction, and teachers have to make a correction there even now. William Clinger  Received: from uunet.UU.NET (TCP 30003106601) by MC.LCS.MIT.EDU 8 Mar 88 19:12:47 EST Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA21254; Tue, 8 Mar 88 18:50:37 EST Received: by mcvax.cwi.nl; Wed, 9 Mar 88 00:23:30 +0100 (MET) Received: by diku.dk (5.51/smail2.5/ease) id AA22809; Tue, 8 Mar 88 20:18:15 +0100 Date: Tue, 8 Mar 88 20:18:15 +0100 From: mcvax!diku.dk!danvy@uunet.UU.NET (Olivier Danvy) Message-Id: <8803081918.AA22809@diku.dk> To: rrrs-authors@mc.lcs.mit.edu Subject: next report on Scheme The denotational specification of Scheme in the r3rs does not address the mappings of variables (car, cdr, etc.) to functions (car, cdr, etc.) in the initial environment, although these functions are described. Should this be fixed in the next report? In particular, it would cover how variables shadow each other, as in ((lambda (car) (car '(1 2 3))) cdr) ---> (2 3) Also, quote is not described, and it needs some precautions because it realizes an upward connection: it translate a syntactic construct to a semantic object. Finally, has someone proposed already a call-with-current-environment similar in spirit to call-with-current-continuation? (1) The environment could be a function Variable --> Value to model the evaluation of a variable and/or Bound-Variable * Value ---> Unspecified to model set! (2) Or it could be a function Variable --> Location although it would introduce the concept of location, and of accessing and updating a location. Similarly to define a new location, at the top level or internally. Anyway it would functionalize the environments got from THE-ENVIRONMENT in CScheme. Olivier  Received: from uunet.UU.NET (TCP 30003106601) by MC.LCS.MIT.EDU 8 Mar 88 18:51:54 EST Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA21270; Tue, 8 Mar 88 18:50:48 EST Received: by mcvax.cwi.nl; Wed, 9 Mar 88 00:22:53 +0100 (MET) Received: by diku.dk (5.51/smail2.5/ease) id AA22694; Tue, 8 Mar 88 20:16:12 +0100 Date: Tue, 8 Mar 88 20:16:12 +0100 From: mcvax!diku.dk!danvy@uunet.UU.NET (Olivier Danvy) Message-Id: <8803081916.AA22694@diku.dk> To: rrrs-authors@mc.lcs.mit.edu Subject: standardization meeting Hi, I won't be able to participate to the next Scheme meeting at IU, but will attempt to come to the one around the Lisp Conference. (Coming from Europe is a bit of a long way for one Saturday.) Could it be possible to communicate the schedule of events the next 26th of March, for the absent participants? What about, in particular, voting? Olivier  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 7 Mar 88 23:00:31 EST Date: Mon, 7 Mar 88 23:00:18 EST From: Jonathan A Rees Subject: Eugene Kohlbecker's net address To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <337749.880307.JAR@AI.AI.MIT.EDU> According to the postmaster at uriecl, the address I have for Eugene, namely ihnp4!uriecl!csc2::eek@ucbvax.berkeley.edu, is not currently working, and hasn't been working for a while. If there's something you need to tell him (e.g. about the upcoming meeting(s)) you should probably use phone or US mail. Does anyone have a different, possibly working, net address for him?  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 5 Mar 88 09:38:12 EST Received: by iuvax.cs.indiana.edu; id AA11037; Thu, 3 Mar 88 10:04:42 EST Date: Thu, 3 Mar 88 10:04:42 EST From: R. Kent Dybvig Message-Id: <8803031504.AA11037@iuvax.cs.indiana.edu> To: rrrs-authors@mc.lcs.mit.edu Subject: moderator Since Mitch will not be coming to the March 26 meeting, I suggest that Hal take Mitch's place as moderator. I asked Hal if he would be willing, and he said that he would. Kent  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 28 Feb 88 21:57:39 EST Received: by iuvax.cs.indiana.edu; id AA02446; Sun, 28 Feb 88 21:57:41 EST Date: Sun, 28 Feb 88 21:57:41 EST From: R. Kent Dybvig Message-Id: <8802290257.AA02446@iuvax.cs.indiana.edu> To: rrrs-authors@mc.lcs.mit.edu Subject: standardization meeting---travel and local arrangements The meeting to discuss standardization will be held on Saturday March 26, 1988 in Bloomington, Indiana. We plan to begin the meeting at 9:00 AM, so you should arrive by Friday evening. We plan to adjourn no later than 5:00 PM on Saturday; this will allow those of you planning to depart that evening to reserve a 7:00 or later flight out of Indianapolis. It is usually best to travel into the Indianapolis airport, which is about one hour and 15 minutes from Bloomington. The Louisville airport is sometimes a reasonable alternative at two hours and 15 minutes from Bloomington. Sometimes there are nonstop flights into Louisville even when there are no nonstop flights into Indianapolis (especially from the South). Bloomington has an airport; flights connect through Chicago or Indianapolis. We rarely use the Bloomington airport since it usually takes longer to fly into Bloomington than to fly into Indianapolis and drive to Bloomington. From the Indianapolis airport, there are three possibilities: (1) rent a car, (2) take a limo, or (3) have someone pick you up. From the Louisville airport, only the first option is reasonable. The car rental is as cheap as if not cheaper than the limo, but I've heard that the limo is very nice. If you are interested in taking the limo, let me know and I'll find out how to reserve it. We have reserved a block of rooms at the Bloomington Ramada Inn. The price for one night at the Ramada is around $50. Let me know if you plan to stay at the Ramada and we will sign you up. We need to know by March 10th at the latest). We will arrange for coffee and donuts on the morning of the 26th, and lunch around noon. We will also set up an informal gathering on Friday night. On Saturday night, we're planning to have a dinner party. Please let me know as soon as possible if you will be attending. Also, we may be able to help with travel between Indy and Bloomington if we have enough advance notice. So please let us know your flight plans as soon as possible. If I can be of any assistance, don't hesitate to send mail (dyb@iuvax.cs.indiana.edu) or call (812/335-6486). Stay tuned... Kent  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 28 Feb 88 11:24:26 EST Received: from relay2.cs.net by RELAY.CS.NET id aa08163; 28 Feb 88 11:26 EST Received: from brandeis by csnet-relay.csnet id ab11679; 28 Feb 88 11:18 EST Received: by brandeis.ARPA (5.51/4.7) id AA12871; Sun, 28 Feb 88 08:18:22 EST Received: by mephi.earth1.com (3.2/SMI-3.2) id AA04308; Sun, 28 Feb 88 08:16:48 PST Date: Sun, 28 Feb 88 08:16:48 PST From: James Miller Message-Id: <8802281616.AA04308@mephi.earth1.com> To: RRRS-Authors%mc.lcs.mit.edu@RELAY.CS.NET Subject: Standards Since I won't be able to attend the meeting, I'd like to very briefly state my feelings on the subject: (1) I think standardization is now unavoidable. (2) Because of the time and expense involved in the process, I will not be able to participate except by network message. The people who will directly be involved in the process should decide what organization they would prefer to deal with. (3) The R^nS as it stands, after fixing bugs (as in numbers) is an excellent starting point. I feel it should be issued as an "interim standard" if there is such a thing. (4) Before making a final standard, however, I strongly believe that the language must have a standard and portable mechanism for extending the syntax (macros). Without this the ability to experiment with language changes and exchange code based on these changes will become quite difficult; it is already fairly severe when dealing with widely differing implementations with which one is not intimately familiar. It would be well worth a two year delay, if necessary, to work out a solution to this problem that is acceptable to the entire community. --Jim  Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 26 Feb 88 22:35:07 EST Received: from murren (murren.ai.mit.edu) by kleph.AI.MIT.EDU; Fri, 26 Feb 88 22:36:55 est Received: by MURREN.AI.MIT.EDU; Fri, 26 Feb 88 22:41:04 est Date: Fri, 26 Feb 88 22:41:04 est From: hal@MURREN.AI.MIT.EDU (Hal Abelson) Message-Id: <8802270341.AA21269@murren> To: rrrs-authors%mc@kleph.AI.MIT.EDU Subject: standardization meeting, March 26 Reply-To: hal@ai.ai.mit.edu The standardization meeting will take place on March 26 at Indiana University. Stay tuned to this station for further information from our IU hosts about specific place and times.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 25 Feb 88 15:31:31 EST Date: Thu, 25 Feb 88 15:33:38 EST From: Jonathan A Rees Subject: New Address To: kempf@SUN.COM cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Thu 25 Feb 88 09:32:09 -0800 from kempf at Sun.COM Message-ID: <331882.880225.JAR@AI.AI.MIT.EDU> Date: Thu, 25 Feb 88 09:32:09 -0800 From: kempf at Sun.COM To: rrrs-authors at mc.lcs.mit.edu Re: New Address Apologies for sending this to the entire list, but there doesn't seem to be an rrrs-authors-request list for adminstrative details, as is the usual convention. ... I have created RRRS-AUTHORS-REQUEST@MC.LCS.MIT.EDU.  Received: from Sun.COM (TCP 1201600002) by MC.LCS.MIT.EDU 25 Feb 88 12:39:07 EST Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA05538; Thu, 25 Feb 88 09:38:38 PST Received: from suntana.sun.com by snail.sun.com (4.0/SMI-3.2) id AA02868; Thu, 25 Feb 88 09:40:05 PST Received: from localhost by suntana.sun.com (3.2/SMI-3.2) id AA01672; Thu, 25 Feb 88 09:32:11 PST Message-Id: <8802251732.AA01672@suntana.sun.com> To: rrrs-authors@mc.lcs.mit.edu Subject: New Address Date: Thu, 25 Feb 88 09:32:09 -0800 From: kempf@Sun.COM Apologies for sending this to the entire list, but there doesn't seem to be an rrrs-authors-request list for adminstrative details, as is the usual convention. Please change my e-mail address to jkempf@sun.com from kempf@hplabs.hp.com. Thanks. jak  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 24 Feb 88 20:21:10 EST Received: from relay2.cs.net by RELAY.CS.NET id aa10317; 24 Feb 88 18:50 EST Received: from csc.ti.com by RELAY.CS.NET id ao16956; 24 Feb 88 18:40 EST Received: from home by tilde id AA00575; Wed, 24 Feb 88 17:11:02 CST Received: by home id AA15961; Wed, 24 Feb 88 17:09:54 CST Date: Wed, 24 Feb 88 17:09:54 CST From: Don Oxley Message-Id: <8802242309.AA15961@home> To: rrrs-authors@mc.lcs.mit.edu Subject: Standardization Mtg Sorry for the delay in responding. I'm not yet sure that I will attend. This is a combination of personal conflicts, the (non)need for additional representatives from TI, and confidence that my viewpoints are already well represented by many others. If things work out, I would like to come. Either MIT or IU is fine. I have a slight preference for IU. They have offered to host the Scheme group a number of times now and we have not accepted the invitation. I think we do need to move around. (besides I get to Boston frequently anyway, I would like to go to Bloomington!). --Don  Received: from ee.ecn.purdue.edu (TCP 20013500417) by MC.LCS.MIT.EDU 23 Feb 88 15:33:22 EST Received: by ee.ecn.purdue.edu (5.54/1.12jrs) id AA23645; Tue, 23 Feb 88 15:31:21 EST Message-Id: <8802232031.AA23645@ee.ecn.purdue.edu> Date: Tue, 23 Feb 88 15:30:12 EST From: Bruce F. Duba To: rrrs-authors@mc.lcs.mit.edu Subject: standardization meeting A: (IU) yes B: (MIT) no C: definitely IU  Received: from ee.ecn.purdue.edu (TCP 20013500417) by MC.LCS.MIT.EDU 23 Feb 88 14:43:14 EST Received: by ee.ecn.purdue.edu (5.54/1.12jrs) id AA20183; Tue, 23 Feb 88 14:11:48 EST Message-Id: <8802231911.AA20183@ee.ecn.purdue.edu> Date: Tue, 23 Feb 88 14:11:38 EST From: Chris Haynes To: rrrs-authors@mc.lcs.mit.edu Subject: standardization mtg agenda The following is offered as a tentative agenda for the proposed March standardization meeting: 1) Presentation on standardization organizations and procedures (IEEE, X3, ...). 2) Discussion of when should Scheme standardization begin. I say when, not whether, because I believe it is inevitable sooner or later, for better or for worse. If there are cogent arguments for delaying a couple of years or so, we should here them.] 3) Discussion of which official standardization organization would be best serve our purposes. This discussion can't really be separated from 2); for example, I suspect IEEE standardization would be a good thing, but doubt we should proceed if that is ruled out. 4) Develop a charter for the standardization working group. I suspect we should keep this group separate from the R*S author's group. (To avoid confusion, I suggest we call the former the "working group" and the later the "report group".) Clearly the working and report group memberships should have a large intersection, and their meetings might whenever possible be held back-to-back in the interest of those participating in both. The purpose of the charter is to clarify the respective roles of the two groups. For example, we could agree that no language feature be in the standard that is not in the report, but allow the documents to differ somewhat in style and allow the reports to include experimental features. I see the present report as somewhere in between these two documents (some features might be left out in the standard and some less tried features might be added to the report). 5) Choose officers (Chair, Vice Chair, others if necessary) for the Working Group. The umbrella standards organization actually appoints the officers (at least in the IEEE), but presumably they will accept our suggestions. 6) Discuss location, time and agenda of first working group meeting. This might be at the L&FP conference, or we might prefer to devote all the available time there to the report group meeting. 6) Discussion of the next report group agenda. 6) and 7) will be included only as time allows after the above items have been given adequate consideration. 7) Discuss possible changes to the R3RS for the standard. This is clearly beginning the work of the working group, and should only be undertaken if their is time (unlikely) or some item is thought to be important enough that it will influence the decisions above. I would rather discuss things to leave out of the standard (there are several possibilities I can think of) instead of discussing possible additions (which are more the business of the report group). 8) Final consensus on points 2)-5) above. Since the points for discussion above are tightly interwoven, we should probably conclude with a final motion for consensus. (I hope voting is not necessary, and if it is a "clear majority", not a simple majority, should be in favor of whatever action we resolve on.) -- Chris  Received: from ee.ecn.purdue.edu (TCP 20013500417) by MC.LCS.MIT.EDU 23 Feb 88 14:16:11 EST Received: by ee.ecn.purdue.edu (5.54/1.12jrs) id AA20244; Tue, 23 Feb 88 14:14:01 EST Message-Id: <8802231914.AA20244@ee.ecn.purdue.edu> Date: Tue, 23 Feb 88 14:13:49 EST From: Chris Haynes To: rrrs-authors@mc.lcs.mit.edu Subject: comments on recent remarks Hal concisely summarized the reasons I feel a standard is probably desirable. ... serious concerns have been raised about (1) some other group standardizing something called "Scheme" (2) Scheme getting overshadowed by Common Lisp (3) Scheme not being viewed as a "real language". So I think it is worthwhile to see if we can go the standards route without blowing it. ... I expect that as Scheme becomes more widely used, there will be increasing pressure to standardize it. And I am sure that as time goes on, it will be increasingly difficult to standardize it in "the right spirit." My original attempt at making the later point was criticized, with some justification, for sounding elitist. That was never my intent. Mitch clarified it nicely: As Scheme matures and its user community grows, it is no longer controlled by a group of 2 or 5 or 18 or 31. We (meaning the members of any of these sets) can no longer control or direct the growth of the language; such direction must be shared with other as yet unknown persons or institutions which may or may not share the intellectual goals of the original group. Hal continued: "Blowing it" means setting up a situation where people feel that they have to agree about large chunks of Scheme before they can work on Scheme. That turns Scheme design into a political process rather than an intellectual one. It also, unfortunately, is often the express purpose of creating a standard. You don't need a large standardized chunk of a language to do teaching and research, which are still the main applications of Scheme. These applications generally do not require a large language, and because portability is not essential it need not be completely standard. Political pressures of this sort become intense when the language is being used for large commercial applications, for which a significantly larger standardized chunk is often needed. Part of my concern is that in a few years industrial applications of Scheme will become important and standardization will then become more political. Thus I think it will be possible for us to avoid blowing it in this way if we proceed now, and much more difficult if we delay several years. In general I would like to see a VERY conservative and VERY minimal standard. I agree completely. I also like Hal's "manifesto". From: ramsdell%linus@MITRE-BEDFORD.ARPA Subject: Standardization (A conservative approach) ... My view is that informal Scheme design meetings, such as the Scheme workshop of June 1987, are the places to talk about evolutionary changes to Scheme. I agree. Are those meetings going to be replaced by formal standards meetings, I sincerely hope not. or are the standards meetings going to only codify the time tested ideas that originated in workshops and other locations? John Yes, that is the proper role of standardization (with emphasis on "time tested"). From: Hal Abelson Subject: call for standardization meeting ... My bias is that if we do decide to go ahead with a standard, then the standard itself should be essentially identical to the next version of R*S. (But I would like to hear from people who have contrary opinions.) I could live with this if the standards organizations would tolerate it (which is questionable), but I'd rather give the working group (and the report group) somewhat more scope. This scope should not be license to add things to the language, but rather to change style and perhaps remove doubtful features until we have had more confident of them. For example, I'm glad the Reports include a formal semantics, but its appropriateness for a standard is debatable; and I'd rather we didn't allow improper formal parameter lists until Dybvig and Heeb's optional argument proposal is seriously considered. -- Chris  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 22 Feb 88 13:08:02 EST Date: Mon, 22 Feb 88 13:08:20 EST From: Jonathan A Rees Subject: nonorthogonality among list/vector/string procedures To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <330081.880222.JAR@AI.AI.MIT.EDU> The answer to the below question is that we made no attempt to make the set of available sequence manipulation procedures uniform accross the various sequence types. But this doesn't mean we shouldn't consider making things more uniform, either by adding or removing procedures; doing so would make the language easier to learn. -Jonathan Date: Sun, 21 Feb 88 23:15:45 est From: Michael R. Blair To: jar Re: More RRRS questions Why are the following missing? VECTOR-COPY LIST-COPY LIST-FILL! LIST-SET! (MAKE-LIST k) ~Ziggy  Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 21 Feb 88 13:22:17 EST Received: from murren (murren.ai.mit.edu) by KLEPH.AI.MIT.EDU; Sun, 21 Feb 88 13:22:54 est Received: by MURREN.AI.MIT.EDU; Sun, 21 Feb 88 13:26:57 est Date: Sun, 21 Feb 88 13:26:57 est From: hal@MURREN.AI.MIT.EDU (Hal Abelson) Message-Id: <8802211826.AA15904@murren> To: rrrs-authors%mc@KLEPH.AI.MIT.EDU Subject: standardization meeting -- vote early, vote often Reply-To: hal@ai.ai.mit.edu The following people (listed as authors on the published version of RRRS) have not indicated their preference as to the meeting on March 26: Kohlbecker Oxley Wand Pitman Please let us know: Will you come if the meeting will be at IU? Will you come if the meeting will be at MIT? Given a choice, would you prefer to meet at IU or at MIT ? -- Hal  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 19 Feb 88 07:16:10 EST From: ramsdell%linus@mitre-bedford.ARPA Posted-From: The MITRE Corp., Bedford, MA Received: from darwin.sun.uucp by linus.research (3.2/4.7) id AA29469; Fri, 19 Feb 88 07:14:47 EST Posted-Date: Fri, 19 Feb 88 07:13:27 EST Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3) id AA00841; Fri, 19 Feb 88 07:13:27 EST Date: Fri, 19 Feb 88 07:13:27 EST Message-Id: <8802191213.AA00841@darwin.sun.uucp> To: rrrs-authors@mc.lcs.mit.edu In-Reply-To: Hal Abelson's message of Tue, 16 Feb 88 17:35:36 est <8802162235.AA11693@murren> Subject: Standardization meeting on March 26 and teleconferencing A. I will try to make it to Indiana, but I just don't know yet. B. I will come to a meeting at MIT. C. MIT is preferable. Maybe this is an issue we could decide using teleconferencing. Would someone at both MIT and Indiana find out if a teleconference is an option? John  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 18 Feb 88 13:52:16 EST Received: by iuvax.cs.indiana.edu; id AA24978; Thu, 18 Feb 88 13:51:46 EST Date: Thu, 18 Feb 88 13:51:46 EST From: Chris Haynes Message-Id: <8802181851.AA24978@iuvax.cs.indiana.edu> To: rrrs-authors@mc.lcs.mit.edu Cc: dyb@iuvax.cs.indiana.edu Subject: Scheme standardization meeting vote A. yes B. yes C. Indiana  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 18 Feb 88 10:52:29 EST Received: by iuvax.cs.indiana.edu; id AA14812; Thu, 18 Feb 88 10:51:54 EST Date: Thu, 18 Feb 88 10:51:54 EST From: Robert Hieb Message-Id: <8802181551.AA14812@iuvax.cs.indiana.edu> To: rrrs-authors@mc.lcs.mit.edu Subject: standardization meeting Cc: hieb@iuvax.cs.indiana.edu In response to Hal's survey: A: IU: yes B: MIT: no, unless I receive unexpected funding C: choice: IU Bob Hieb  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 18 Feb 88 10:42:42 EST Received: by iuvax.cs.indiana.edu; id AA05198; Thu, 18 Feb 88 08:41:45 EST Date: Thu, 18 Feb 88 08:41:45 EST From: Dan Friedman Message-Id: <8802181341.AA05198@iuvax.cs.indiana.edu> To: rrrs-authors@mc.lcs.mit.edu Subject: standardization meeting March 26 A. Will you come if the meeting is at Indiana? Yes. B. Will you come if the meeting is at MIT? Yes. C. Given a choice, would you prefer to meet at MIT or at Indiana? Bloomington. Dan  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 18 Feb 88 04:20:11 EST Received: from relay2.cs.net by RELAY.CS.NET id aa05903; 18 Feb 88 3:51 EST Received: from tektronix.tek.com by RELAY.CS.NET id ag13818; 18 Feb 88 3:40 EST Received: by tektronix.TEK.COM (5.51/6.24) id AA08019; Wed, 17 Feb 88 14:33:48 PST Received: by tekchips.CRL.TEK.COM (5.51/6.24) id AA14162; Wed, 17 Feb 88 14:34:16 PST Date: Wed, 17 Feb 88 14:34:16 PST From: Norman Adams Message-Id: <8802172234.AA14162@tekchips.CRL.TEK.COM> Subject: standardization meeting March 26 To: rrrs-authors@mc.lcs.mit.edu In-Reply-To: David Bartley , Wed, 17 Feb 88 10:00:07 CST A. Will you come if the meeting is at Indiana? B. Will you come if the meeting is at MIT? My attendance is equally likely (say about 60%) at either location. C. Given a choice, would you prefer to meet at MIT or at Indiana? If choosing a place to spend a weekend away from home next month, I would prefer Boston to Bloomington. -Norman -------  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 18 Feb 88 03:46:43 EST Received: from relay2.cs.net by RELAY.CS.NET id aa05707; 18 Feb 88 3:29 EST Received: from brandeis by csnet-relay.csnet id ab13761; 18 Feb 88 3:21 EST Received: by brandeis.ARPA (5.51/4.7) id AA23825; Wed, 17 Feb 88 20:37:47 EST Received: by mephi.earth1.com (3.2/SMI-3.2) id AA01306; Wed, 17 Feb 88 20:36:25 PST Date: Wed, 17 Feb 88 20:36:25 PST From: James Miller Message-Id: <8802180436.AA01306@mephi.earth1.com> To: rrrs-authors%mc.lcs.mit.edu@RELAY.CS.NET In-Reply-To: Hal Abelson's message of Tue, 16 Feb 88 17:35:36 est <8802162235.AA11693@murren> Subject: Standardization meeting on March 26 I can attend only if the meeting is at MIT. I would attend there. --Jim  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 17 Feb 88 21:06:18 EST Received: by iuvax.cs.indiana.edu; id AA15956; Wed, 17 Feb 88 21:05:48 EST Date: Wed, 17 Feb 88 21:05:48 EST From: R. Kent Dybvig Message-Id: <8802180205.AA15956@iuvax.cs.indiana.edu> To: rrrs-authors@mc.lcs.mit.edu Subject: Re: standardization meeting March 26 A. Will you come if the meeting is at Indiana? Yes. B. Will you come if the meeting is at MIT? I'm not sure yet. --- if you answer yes to either of the above then --- C. Given a choice, would you prefer to meet at MIT or at Indiana? Indiana. Kent  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 17 Feb 88 13:51:51 EST Date: Wed, 17 Feb 88 13:51:33 EST From: Jonathan A Rees Subject: standardization meeting March 26 To: HAL@AI.AI.MIT.EDU cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 16 Feb 88 19:14:08 EST from Hal Abelson Message-ID: <327974.880217.JAR@AI.AI.MIT.EDU> Date: Tue, 16 Feb 88 19:14:08 EST From: Hal Abelson A. Will you come if the meeting is at Indiana? Probably not. B. Will you come if the meeting is at MIT? Probably. Not that I have anything against Indiana (I'm a midwesterner myself), but the standardization issue isn't important enough to me one way or another for me to go much out of my way for it; I'm confident that someone else out there will express my views if I don't.  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 17 Feb 88 13:35:22 EST Received: from relay2.cs.net by RELAY.CS.NET id aa13779; 17 Feb 88 12:48 EST Received: from csc.ti.com by RELAY.CS.NET id aq08439; 17 Feb 88 12:35 EST Received: from home by tilde id AA21514; Wed, 17 Feb 88 10:10:36 CST Received: by home id AA23991; Wed, 17 Feb 88 10:00:07 CST Date: Wed, 17 Feb 88 10:00:07 CST From: David Bartley Message-Id: <8802171600.AA23991@home> To: HAL@mc.lcs.mit.edu Cc: rrrs-authors@mc.lcs.mit.edu In-Reply-To: Hal Abelson's message of Tue, 16 Feb 88 19:14:08 EST <327556.880216.HAL@AI.AI.MIT.EDU> Subject: standardization meeting March 26 A. Will you come if the meeting is at Indiana? Yes. B. Will you come if the meeting is at MIT? Yes. C. Given a choice, would you prefer to meet at MIT or at Indiana? No preference. -- Hal --db--  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 17 Feb 88 13:31:26 EST Received: from relay2.cs.net by RELAY.CS.NET id aa13759; 17 Feb 88 12:47 EST Received: from csc.ti.com by RELAY.CS.NET id ap08439; 17 Feb 88 12:35 EST Received: from mips by tilde id AA22231; Wed, 17 Feb 88 10:33:23 CST Received: by mips id AA15838; Wed, 17 Feb 88 10:33:19 CST Date: Wed, 17 Feb 88 10:33:19 CST From: Gary Brooks Message-Id: <8802171633.AA15838@mips> To: rrrs-authors@mc.lcs.mit.edu Cc: HAL@mc.lcs.mit.edu Subject: standardization meeting March 26 Both Indiana and MIT are fine with me. As we decided at the last RRRS meeting, I think we should meet in Bloomington. -- brooks  Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 17 Feb 88 12:03:35 EST Date: Wed 17 Feb 88 12:00:40-EST From: Morris Katz Subject: Named-let To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <12375479760.30.MKATZ@A.ISI.EDU> I apologize for my oversight on named-let. Apparently, just references to named-lambda were removed and named-let was moved from the let section of RRRS to a location where I failed to find it. Morry Katz -------  Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 17 Feb 88 09:04:57 EST Received: from ASPEN.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 123312; Wed 17-Feb-88 09:03:48 EST Date: Wed, 17 Feb 88 09:03 EST From: Robert Halstead Subject: Standardization meeting on March 26 To: hal@AI.AI.MIT.EDU cc: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: <8802162235.AA11693@murren> Message-ID: <880217090332.1.RHH@ASPEN.LCS.MIT.EDU> This will be a 1-day meeting to discuss standardization. I don't feel I have much to contribute to the process, nor do I have any very strong feelings pro or con on the standardization issue; on the other hand, it would be rewarding to have the opportunity to get together with the RRRS authors again; on the other hand, there are other things to be done and there are only so many days in a week. Therefore, A. Will you come if the meeting is at Indiana? No, I don't think I can swing that. B. Will you come if the meeting is at MIT? This is a possibility, if I'm not too snowed under with other things. C. Given a choice, would you prefer to meet at MIT or at Indiana? I think the players more central to this issue should make this decision based on their constraints, so I abstain from this decision. -Bert Halstead  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Feb 88 22:16:32 EST Date: Tue, 16 Feb 88 20:05:46 EST From: Jonathan A Rees Subject: DO in Scheme To: MKATZ@A.ISI.EDU cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 16 Feb 88 15:23:51-EST from Morris Katz Message-ID: <327582.880216.JAR@AI.AI.MIT.EDU> I like DO. I don't think I need to repeat Steele's defense of it, which was posted one of the previous times this came up. Named LET is there in the report, under a separate heading from LET (somewhere near DO, I think -- probably why you missed it, sorry). The macro proposal still needs some work. For example, it lacks a user interface.  Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 16 Feb 88 22:00:10 EST Received: from zohar (zohar.ai.mit.edu) by KLEPH.AI.MIT.EDU; Tue, 16 Feb 88 22:01:21 est Received: by ZOHAR.AI.MIT.EDU; Tue, 16 Feb 88 22:02:32 est Date: Tue, 16 Feb 88 22:02:32 est From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman) Message-Id: <8802170302.AA03068@zohar> To: hal@ai.ai.mit.edu Cc: rrrs-authors%mc@KLEPH.AI.MIT.EDU In-Reply-To: Hal Abelson's message of Tue, 16 Feb 88 17:35:36 est <8802162235.AA11693@murren> Subject: Standardization meeting on March 26 March 26th is fine with me. A. Reluctantly B. Enthusiastically and cheerfully C. I much prefer MIT because 1. To be in Indiania I have to find someone to cover my class on the 25th. 2. I will have spent altogether too much time on airplanes this year. The cost to you of me coming to Indiana is that I will be grumpy and unpleasant.  Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 16 Feb 88 21:27:05 EST Received: from Cabernet.ms by ArpaGateway.ms ; 16 FEB 88 15:00:46 PST Date: Tue, 16 Feb 88 15:00:27 PST From: Pavel.pa@Xerox.COM Subject: Re: DO in Scheme In-reply-to: <12375254602.54.MKATZ@A.ISI.EDU> To: Morris Katz Cc: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <880216-150046-4099@Xerox> Morris Katz says: ``At the risk of pushing my luck, I would suggest that with the death of DO we reintroduce named-let to at least optional status.'' Am I confused? It looks to me that the named version of LET is still in the language. In fact, its description directly follows that of DO in R3RS. Pavel  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Feb 88 20:21:58 EST Date: Tue, 16 Feb 88 19:14:08 EST From: Hal Abelson Subject: standardization meeting March 26 To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <327556.880216.HAL@AI.AI.MIT.EDU> The responses over the past week indicate a clear preference for meeting on March 26th. This will be a 1-day meeting to discuss standardization. Both MIT and Indiana have volunteered to host the meeting. Please respond within a week (to RRRS-AUTHORS, not only to me) saying A. Will you come if the meeting is at Indiana? B. Will you come if the meeting is at MIT? --- if you answer yes to either of the above then --- C. Given a choice, would you prefer to meet at MIT or at Indiana? -- Hal  Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 16 Feb 88 20:14:29 EST Received: from murren (murren.ai.mit.edu) by KLEPH.AI.MIT.EDU; Tue, 16 Feb 88 17:31:44 est Received: by MURREN.AI.MIT.EDU; Tue, 16 Feb 88 17:35:36 est Date: Tue, 16 Feb 88 17:35:36 est From: hal@MURREN.AI.MIT.EDU (Hal Abelson) Message-Id: <8802162235.AA11693@murren> To: rrrs-authors%mc@KLEPH.AI.MIT.EDU Subject: Standardization meeting on March 26 Reply-To: hal@ai.ai.mit.edu The responses over the past week indicate a clear preference for meeting on March 26th. This will be a 1-day meeting to discuss standardization. Both MIT and Indiana have volunteered to host the meeting. Please respond within a week (to RRRS-AUTHORS, not only to me) saying A. Will you come if the meeting is at Indiana? B. Will you come if the meeting is at MIT? --- if you answer yes to either of the above then --- C. Given a choice, would you prefer to meet at MIT or at Indiana?  Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 16 Feb 88 16:18:38 EST Date: Tue 16 Feb 88 15:23:51-EST From: Morris Katz Subject: DO in Scheme To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <12375254602.54.MKATZ@A.ISI.EDU> A couple of times recently I have seen suggestions that DO be removed from Scheme. I must concur in that I find DO to be one of the cruftiest and most opaque constructs in the language (and would hate to see it become part of any standard). However, it seems to me that before we can remove such constructs, we need to agree on a macro standard so that they can be reintroduced as macros through the Yellow Pages. There are undoubtedly many users within our community who make extensive use of DO, and it seems unkind and unnecessary to leave them high and dry. On the topic of macros, didn't we appoint a commity at the last Scheme meeting composed, I believe, of Chris Hanson, Jonathan Rees, et. al. to look into the macro question and report back to us. What ever happened to this effort. It actually seemed to me that they had a starting proposal which was reasonably close to being acceptable to nearly all parties concerned. At the risk of pushing my luck, I would suggest that with the death of DO we reintroduce named-let to at least optional status. Having used all of DO, named-let, and the equivalent letrec forms over several years, I have found named-let to be by far the simplest to read and therefore the most elegant. It is convenient to be able to specify the initial bindings of loop variables at loop entry (an advantage of named-let over letrec) without being forced to go to the more complex and convoluted form of DO. Morry Katz -------  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Feb 88 14:09:23 EST Date: Tue, 16 Feb 88 14:08:28 EST From: Alan Bawden Subject: (rationalize x y) To: bartley%home.csc.ti.com@RELAY.CS.NET cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Mon 15 Feb 88 17:41:29 CST from David Bartley Message-ID: <327379.880216.ALAN@AI.AI.MIT.EDU> Definition: A rational r1 is "simpler" than a rational r2, written r1 <* r2, if r1 = p1/q1 and r2 = p2/q2 (both in lowest terms) and |p1| <= |p2| and |q1| <= |q2|. So 1/2 <* 1/3 and 1/2 <* 3/2 but 1/3 and 3/2 are incomparable. This definition works for Gaussian rationals as well. Theorem: The relation <* is a partial order on rationals. Also, zero is simpler than any other rational (0 <* r for all r). Theorem: For any two incomparable (under <*) rationals r < s, there exists a rational t such that r < t < s, and t <* r and t <* s. Theorem: Any interval of the real numbers (open, half-open, or closed) contains a simplest rational number. I think that the proofs of these theorems are all straightforward enough that I don't need to give them here. Date: Mon, 15 Feb 88 17:41:29 CST From: David Bartley Ed Ferguson and I want to clarify some issues concerning the Scheme procedure "rationalize", which is documented in R3RS as follows: [...] (rationalize x y) procedure (rationalize x) procedure These procedures create integers and rationals. Their results are exact if and only if their arguments are exact. [...] With two arguments, RATIONALIZE produces the rational number with smallest denominator differing from X by no more than Y. With one argument, RATIONALIZE produces the best rational approximation to X, preserving all of the precision in its representation. (1) When Y is supplied and is non-zero, it would seem more proper to return an inexact result (unless perhaps that result is `=' to X and X is exact). The phrase "the rational number with smallest denominator" unfortunately leaves RATIONALIZE slightly underspecified. (RATIONALIZE 3/2 1) is free to be either 1 or 2, since they both have a denominator of 1. I presume that what R3RS is trying to say is that (RATIONALIZE X Y) returns the simplest rational number in the interval [X-Y, X+Y]. (When there is a unique rational number with smallest denominator it is also the simplest.) Since the theorem above guarantees the uniqueness and existence of a simplest rational, it would seem to me that if X and Y are exact, then the answer should be exact as well. It is less clear to me what R3RS is trying to say that the one argument case of RATIONALIZE is supposed to do. One possible interpretation seems to be that (RATIONALIZE X) is the same as (RATIONALIZE X #E0), since then in the case where X is an inexact floating point number, it might well return the same (inexact) rational that the Common Lisp RATIONALIZE function returns. (And if X was an exact floating point number, it might return the same (exact) rational that the Common Lisp RATIONAL function would return.) The description doesn't say what should happen if Y is negative... (2) Although the notation indicates that the argument X is real, would it be frivolous to say that (RATIONALIZE Z Y), where Z is a non-real complex number, is defined by (make-rectangular (rationalize (real-part z y)) (rationalize (imag-part z y))) ? Two objections come to mind: (2a) this discriminates against an implementation that uses polar representation, and (2b) one might want to interpret Y as a error term for the magnitude rather than for the real and imaginary parts separately. I would object because the definition doesn't work. (RATIONALIZE 2/5+1/5i 1/12) would return 1/3+1/4i. But in lowest terms 2/5+1/5i is 1/(2-i) and 1/3+1/4i is (4+3i)/12, so the input was a simpler rational than the output! (3) Do we really want an absolute error test or is a relative error test sometimes more appropriate? You can always construct the relative case given the absolute case. It's just a way of letting you specify an interval. (4) The wording ``rational number with smallest denominator differing from X by no more than Y'' seems to rule out using Euclid's algorithm and continued fractions. That is, suppose W is the first number whose difference from X is less than Y in the continued fraction series of successively better approximations to X. Euclid doesn't guarantee that there is no number within Y of X with smaller denominator than W's. Did the author of these words have a different algorithm in mind? As an example, consider (RATIONALIZE 11/16 1/4). The successive convergents to 11/16 using continued fractions are 0, 1, 2/3, and 11/16. The first number in that series which is within 1/4 of 11/16 is 2/3, but the value 1/2 is also within 1/4 of 11/16 and has a smaller denominator. What you do is compute the continued fractions of the two endpoints of the interval in question. In this case 7/16 = 0+1/(2+1/(3+1/2)) and 15/16 = 0+1/(1+1/15). Since the continued fraction of the answer has the same initial terms as the continued fractions of the endpoints, you stop the continued fraction expansion as soon as you see that the next term will differ. Then the final term is the smallest integer in the interval between the two remainders. In this case 7/16 = 0+1/(2+2/7) and 15/16 = 0+1/(1+1/15), so since the smallest integer between 2+2/7 and 1+1/15 is 2, the answer is 0+1/2 = 1/2. Since you only need to compute the continued fractions until they differ, and since you can accumulate the answer as you go, this computation isn't all that expensive.  Received: from ee.ecn.purdue.edu (TCP 20013500417) by MC.LCS.MIT.EDU 16 Feb 88 05:47:15 EST Received: by ee.ecn.purdue.edu (5.54/1.12jrs) id AA22845; Tue, 16 Feb 88 05:46:13 EST Message-Id: <8802161046.AA22845@ee.ecn.purdue.edu> Date: Sat, 13 Feb 88 10:57:19 EST From: R. Kent Dybvig To: hal@mc.lcs.mit.edu Subject: Re: call for standardization meeting Cc: rrrs-authors@mc.lcs.mit.edu * you would prefer to have the meeting somewhere else, with suggested place and dates. We would like to offer to hold the meeting here at Indiana University on March 26. I will handle local arrangements. Kent  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 15 Feb 88 20:06:20 EST Received: from relay2.cs.net by RELAY.CS.NET id aa07509; 15 Feb 88 19:43 EST Received: from csc.ti.com by RELAY.CS.NET id ak25765; 15 Feb 88 19:36 EST Received: from home by tilde id AA10951; Mon, 15 Feb 88 17:43:05 CST Received: by home id AA21446; Mon, 15 Feb 88 17:41:29 CST Date: Mon, 15 Feb 88 17:41:29 CST From: David Bartley Message-Id: <8802152341.AA21446@home> To: rrrs-authors@mc.lcs.mit.edu Subject: (rationalize x y) Ed Ferguson and I want to clarify some issues concerning the Scheme procedure "rationalize", which is documented in R3RS as follows: [...] (rationalize x y) procedure (rationalize x) procedure These procedures create integers and rationals. Their results are exact if and only if their arguments are exact. [...] With two arguments, RATIONALIZE produces the rational number with smallest denominator differing from X by no more than Y. With one argument, RATIONALIZE produces the best rational approximation to X, preserving all of the precision in its representation. (1) When Y is supplied and is non-zero, it would seem more proper to return an inexact result (unless perhaps that result is `=' to X and X is exact). (2) Although the notation indicates that the argument X is real, would it be frivolous to say that (RATIONALIZE Z Y), where Z is a non-real complex number, is defined by (make-rectangular (rationalize (real-part z y)) (rationalize (imag-part z y))) ? Two objections come to mind: (2a) this discriminates against an implementation that uses polar representation, and (2b) one might want to interpret Y as a error term for the magnitude rather than for the real and imaginary parts separately. (3) Do we really want an absolute error test or is a relative error test sometimes more appropriate? (4) The wording ``rational number with smallest denominator differing from X by no more than Y'' seems to rule out using Euclid's algorithm and continued fractions. That is, suppose W is the first number whose difference from X is less than Y in the continued fraction series of successively better approximations to X. Euclid doesn't guarantee that there is no number within Y of X with smaller denominator than W's. Did the author of these words have a different algorithm in mind? As an example, consider (RATIONALIZE 11/16 1/4). The successive convergents to 11/16 using continued fractions are 0, 1, 2/3, and 11/16. The first number in that series which is within 1/4 of 11/16 is 2/3, but the value 1/2 is also within 1/4 of 11/16 and has a smaller denominator. Regards, David Bartley  Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 FEB 88 13:12:59 EST Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ; Mon, 15 Feb 88 13:10:45 EST Received: from purdue.UUCP by gatech.edu with UUCP (5.58/7.3.GT) id AA12415; Mon, 15 Feb 88 13:05:17 EST Received: by arthur.cs.purdue.edu; (5.54/3.16) id AA01125; Mon, 15 Feb 88 12:55:16 EST Message-Id: <8802151755.AA01125@arthur.cs.purdue.edu> Date: Mon, 15 Feb 88 11:16:10 EST From: R. Kent Dybvig To: rrrs-authors@mc.lcs.mit.edu.UUCP Subject: Re: call for standardization [Please excuse me if this note is duplicated---our arpanet link went down Friday and hasn't come back yet, so I'm trying to send via uucp] --------- * you would prefer to have the meeting somewhere else, with suggested place and dates. We would like to offer to hold the meeting here at Indiana University on March 26. I will handle local arrangements. Kent  Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 15 Feb 88 10:55:02 EST Received: from murren (murren.ai.mit.edu) by KLEPH.AI.MIT.EDU; Mon, 15 Feb 88 10:56:15 est Received: by MURREN.AI.MIT.EDU; Mon, 15 Feb 88 11:00:04 est Date: Mon, 15 Feb 88 11:00:04 est From: hal@MURREN.AI.MIT.EDU (Hal Abelson) Message-Id: <8802151600.AA10418@murren> To: rrrs-authors%mc@KLEPH.AI.MIT.EDU Subject: [hudak-paul@YALE.ARPA: Re: call for standardization meeting] Reply-To: hal@ai.ai.mit.edu Date: Mon, 15 Feb 88 10:43:06 EST From: Paul Hudak Subject: Re: call for standardization meeting To: hal@ZOHAR.AI.MIT.EDU (Hal Abelson) In-Reply-To: hal@ZOHAR.AI.MIT.EDU (Hal Abelson), Thu, 11 Feb 88 10:57:35 est I would like to hold a one-day meeting of RRRS authors to address the standardization question. Hal, as you know I am not a super active member of the RRRS committee, but am very interested in Scheme and its promotion. I won't be able to attend the standardization meeting, but if you're interested, here's my opinion about the whole matter: I am morderately in favor of standarization for two simple reasons: 1) Historically the standardization of a language seems to have helped the promotion of the language. 2) In the face of CL standarization, Scheme's NOT being standarized may give the impression that the Lisp community is more confident in CL and is thus endorsing it's use in production-quality software systems, etc. With regard to the latter comment, I must say that I've been somewhat surprised by the amount of discussion about Scheme being as different from CL as Pascal is from Algol, etc. etc. I certainly agree with that argument, and it's a compelling argument against having the standarization efforts combined, but in the context of how the "real world" views things, it may be irrelevant. The fact is, "Lisps" in general offer many common advantages, and when a programmer/manager/ whomever decides that Lisp is best for a particular application, they will tend to look for the best-documented/supported/tried/standardized etc. language available. (This same kind of reasoning will be used by the software/hardware manufacturers when trying to decide what languages to support.) Ok, so they'll also ask which is best from a programming language standpoint, but my point is that there are many other, often overriding, issues that they will consider as well. The awkward conclusion I find myself making is that I think Scheme needs to be standarized primarily because CL is. Otherwise, I think (as everyone else apparently does) that it's too early. (The awkward thing about this conclusion is that I also think it's too early to standarize CL, so implicit in my conlusion is that one wrong justifies another...) -Paul P.S. I have no opinion about which of the various means for standarization is best (or worst). P.P.S. If you think it's appropriate I don't mind if you cc this to RRRS. -------  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 12 Feb 88 18:07:51 EST Received: from relay2.cs.net by RELAY.CS.NET id ad29909; 12 Feb 88 15:51 EST Received: from tektronix.tek.com by RELAY.CS.NET id ao06872; 12 Feb 88 15:46 EST Received: by tektronix.TEK.COM (5.51/6.24) id AA10898; Fri, 12 Feb 88 09:00:37 PST Received: by tekchips.CRL.TEK.COM (5.51/6.24) id AA10250; Fri, 12 Feb 88 09:01:06 PST Date: Fri, 12 Feb 88 09:01:06 PST From: Norman Adams Message-Id: <8802121701.AA10250@tekchips.CRL.TEK.COM> Subject: Re: call for standardization meeting To: rrrs-authors@mc.lcs.mit.edu In-Reply-To: Hal Abelson , Thu, 11 Feb 88 10:57:35 est I can attend the 19th or 26th. -Norman -------  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 12 Feb 88 06:57:18 EST Date: Fri, 12 Feb 88 06:57:36 EST From: Hal Abelson Subject: KMP's reply to standardizaiotn meeting note To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <325467.880212.HAL@AI.AI.MIT.EDU> From KMP@STONY-BROOK.SCRC.Symbolics.COM Thu Feb 11 15:13:32 1988 Date: Thu, 11 Feb 88 11:41 EST From: Kent M Pitman Subject: call for standardization meeting To: HAL@AI.AI.MIT.EDU Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <8802111557.AA12523@zohar> I'm am terribly worried about the whole thing. I'm interested in attending to lobby against a standard. The week of Mar 14-18 several of us (me and Bartley anyway -- maybe Will and a few others) will be at X3J13 in Palo Alto. I'd like to have both weekends adjacent to that available for spending time there. I have no times prior to that free. Mar 26 is my very strong preference.  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 11 Feb 88 18:42:28 EST Received: by iuvax.cs.indiana.edu; id AA08705; Thu, 11 Feb 88 18:20:20 EST Date: Thu, 11 Feb 88 18:20:20 EST From: Dan Friedman Message-Id: <8802112320.AA08705@iuvax.cs.indiana.edu> To: rrrs-authors@mc.lcs.mit.edu Subject: meeting The only weekend possible for me is March 26. Dan  Received: from ATHENA.CS.YALE.EDU (TCP 20011000033) by MC.LCS.MIT.EDU 11 Feb 88 14:00:55 EST Received: by ATHENA.CS.YALE.EDU; Thu, 11 Feb 88 13:55:41 EST Date: Thu, 11 Feb 88 13:55:41 EST From: James Philbin Full-Name: James Philbin Message-Id: <8802111855.AA19221@ATHENA.CS.YALE.EDU> Received: by yale-ring (node-aac0/AAC0) via WIMP-MAIL (Version 1.2/1.4) ; Thu Feb 11 13:47:35 Subject: Meeting To: rrrs-authors@mc.lcs.mit.edu In-Reply-To: hal@ZOHAR.AI.MIT.EDU (Hal Abelson), Thu, 11 Feb 88 10:57:35 est My bias is that if we do decide to go ahead with a standard, then the standard itself should be essentially identical to the next version of R*S. (But I would like to hear from people who have contrary opinions.) If we decide to standardize, then I agree that it should be identical with the next version of R*S. * you can/will come (and which dates are OK) I will come. All the dates are fine with me. - Jim -------  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 11 Feb 88 13:19:52 EST From: ramsdell%linus@mitre-bedford.ARPA Posted-From: The MITRE Corp., Bedford, MA Received: from darwin.sun.uucp by linus.research (3.2/4.7) id AA02654; Thu, 11 Feb 88 13:19:14 EST Posted-Date: Thu, 11 Feb 88 13:18:02 EST Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3) id AA13233; Thu, 11 Feb 88 13:18:02 EST Date: Thu, 11 Feb 88 13:18:02 EST Message-Id: <8802111818.AA13233@darwin.sun.uucp> To: rrrs-authors@mc.lcs.mit.edu In-Reply-To: Hal Abelson's message of Thu, 11 Feb 88 10:57:35 est <8802111557.AA12523@zohar> Subject: call for standardization meeting I will come and any Saturday in March is okay for me. John  Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 11 Feb 88 10:54:58 EST Received: by ZOHAR.AI.MIT.EDU; Thu, 11 Feb 88 10:57:35 est Date: Thu, 11 Feb 88 10:57:35 est From: hal@ZOHAR.AI.MIT.EDU (Hal Abelson) Message-Id: <8802111557.AA12523@zohar> To: rrrs-authors@mc Subject: call for standardization meeting Reply-To: hal@ai.ai.mit.edu I would like to hold a one-day meeting of RRRS authors to address the standardization question. The purpose of the meeting would be to decide whether we want to go ahead with standardization, and if so, how (what standards organization, who should be responsible for doing the work, etc.). I do not think we should make any technical decisions about Scheme at this meeting, although we might review some of the suggested changes. My bias is that if we do decide to go ahead with a standard, then the standard itself should be essentially identical to the next version of R*S. (But I would like to hear from people who have contrary opinions.) Actually producing the next version of R*S would happen at a meeting held in conjuction with the L&FP conference this summer. For purely selfish reasons, I would like to hold the meeting on a weekend in the Boston area. I volunteer MIT to host it. Here are three possible dates: Saturday, March 12 Saturday, March 19 Saturday, March 26 Please send mail within a week (to RRRS-AUTHORS) with one or more of the following responses: * you can/will come (and which dates are OK) * you don't want to have a meeting or can't come to one, but you think that standardization is a good/bad idea; any thoughts on a preferred standards organization (IEEE, X3, Better Homes and Gardens, etc.) * you would prefer to have the meeting somewhere else, with suggested place and dates. * you are bored/sick of the whole thing If there is enough response, I'll go ahead and schedule the meeting. -- Hal  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 10 Feb 88 10:22:37 EST Received: from relay2.cs.net by RELAY.CS.NET id aa22484; 10 Feb 88 9:27 EST Received: from csc.ti.com by RELAY.CS.NET id ab05631; 10 Feb 88 9:17 EST Received: from home by tilde id AA14501; Wed, 10 Feb 88 07:37:46 CST Received: by home id AA08639; Wed, 10 Feb 88 07:36:05 CST Date: Wed, 10 Feb 88 07:36:05 CST From: Don Oxley Message-Id: <8802101336.AA08639@home> To: bartley%mips.csc.ti.com@RELAY.CS.NET Cc: rrrs-authors@mc.lcs.mit.edu, Bartley%mips.csc.ti.com@RELAY.CS.NET In-Reply-To: David Bartley's message of Tue, 9 Feb 88 17:45:27 CST <8802092345.AA21412@mips> Subject: A Minimalist Standard I fundamentally agree with the minimalist notions. My point is that I would rather provide a mechanism to track "popular" but non-standard features (such as multiple values) in such a way that users who use such things have a reasonable method for learning their definition, that there be only one, and that the chosen names not preempt the use of that name in an eventual standard. In NCS today, we have preempted "values", "eval", "syntax", "macro", ... to name a few. My point is that something simple like a prefix (eg. ncs-values - non-conforming-scheme-values) would avoid preempting the identifier values and would give me a reasonable chance of writing an automatic parser to repair the damage if a standard is ever reached. It seems to me that the key is allowing Scheme to be widely used, but somehow controlling the defacto standardization through widespread usage. A purely minimalist approach seems unlikely to do that to me. --Don  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 10 Feb 88 09:28:44 EST From: ramsdell%linus@mitre-bedford.ARPA Posted-From: The MITRE Corp., Bedford, MA Received: from darwin.sun.uucp by linus.research (3.2/4.7) id AA29906; Wed, 10 Feb 88 09:25:37 EST Posted-Date: Wed, 10 Feb 88 09:24:26 EST Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3) id AA12394; Wed, 10 Feb 88 09:24:26 EST Date: Wed, 10 Feb 88 09:24:26 EST Message-Id: <8802101424.AA12394@darwin.sun.uucp> To: gls@Think.COM Cc: ramsdell@mitre-bedford.ARPA, rrrs-authors@mc.lcs.mit.edu In-Reply-To: gls@Think.COM's message of Fri, 5 Feb 88 19:09:01 EST <8802060009.AA01135@kali.think.com> Subject: Standardization (A conservative approach) Should Scheme standardization be approved, I propose the following plan for the initial draft. Limit changes to: 1) Adding Abelson's manifesto on Scheme evolution, 2) adding multiple values, 3) modifying the number syntax as previously agreed, and 4) wordsmithing. Letting each person choose *one* new feature to propose could make the standards process into a design process. I like the idea of standardizing something close to R3RS Scheme. My view is that informal Scheme design meetings, such as the Scheme workshop of June 1987, are the places to talk about evolutionary changes to Scheme. Are those meetings going to be replaced by formal standards meetings, or are the standards meetings going to only codify the time tested ideas that originated in workshops and other locations? John  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 10 Feb 88 04:24:52 EST From: ramsdell%linus@mitre-bedford.ARPA Posted-From: The MITRE Corp., Bedford, MA Received: from darwin.sun.uucp by linus.research (3.2/4.7) id AA26277; Mon, 8 Feb 88 10:02:23 EST Posted-Date: Mon, 8 Feb 88 10:01:21 EST Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3) id AA09128; Mon, 8 Feb 88 10:01:21 EST Date: Mon, 8 Feb 88 10:01:21 EST Message-Id: <8802081501.AA09128@darwin.sun.uucp> To: RPG@SAIL.Stanford.EDU Cc: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: Dick Gabriel's message of 04 Feb 88 1206 PST <8802042023.AA01455@mitre-bedford.ARPA> Subject: Standardization (meetings and relation to CL) Given the number responses to the idea of MITRE hosting a meeting about Scheme standardization, I conclude there is insufficient interest. However, I got the details of hosting meetings at MITRE. I found there are no problems, but one further constraint. Meetings held at MITRE which include non-employees, must occur during normal working hours. In other words, Saturdays and Sundays are out. For the record, I would be happy to host other Scheme related meetings in the future as long as they occur on a weekday. Dick Gabriel: >2. I am saddened by the animosity I see towards Common Lisp and by >implication towards the Common Lisp community. .... I guess Dick's comment was directed at part of one of my notes: >On the subject of confusing Scheme with Common Lisp, I follow the >practice of never mentioning Lisp while talking about Scheme unless >the person I am talking to asks about Scheme's relation to Lisp. This >practice avoids the AI baggage, as well as any negative impressions >the person has of Lisp. Of course, disowning our connection to Lisp >would be like disowning one's parents, but I see no need to tie our >fortunes to Lisp's. Thus I strongly oppose the idea of expanding >X3J13 to cover both Lisp and Scheme. If we choose to standardize >Scheme, let's do it independently of efforts to standardize other >dialects of Lisp. My point was that Scheme and any other dialect of Lisp, such as Common Lisp, should not be standardized by the same committee. Just as Ada documents acknowledge the influence of Pascal, any document on Scheme should acknowledge the influence of various Lisp dialects. I am told Ada designers maintained extensive contact with the designers of other languages. I encourage contact with the designers of other dialects of Lisp, including the designers of Common Lisp. Never think I would like to see Dick Gabriel and Guy Steele removed from this list because they are too closely connected to Common Lisp! I endorse Bartley's characterization of the relationship between Common Lisp and Scheme being in the family of Lisp-like languages, just as Ada and Pascal are in the Algol-like family. While Ada and Pascal are in the same family, they maintain their own identity. Let Scheme have its own. I hold a minority position which worries about too much connection of the name Scheme with Lisp. I believe excessive connection carries unnecessary baggage associated with AI, and unnecessary baggage associated with other dialects of Lisp. I know people who think all modern Lisp-like languages have PROG and GO. While Common Lisp is often cited as the reason a Lisp-like language is thought to be a large language, I don't single out Common Lisp as the sole source of wrong ideas about Scheme. I think it is a mistake to assume the average Lisp programmer is clear on the differences between dialects, and we should aid that programmer when we can. I respectfully oppose your proposal to broaden the scope of X3J13 because I think if Scheme is to be standardized, it should happen in a committee independent of other efforts to standardize Lisp dialects. I did not mean to imply the standardization effort should ignore the work of other efforts. In fact, I read some of the Common Lisp proposals, most recently, the CLOS proposal. I hope this clears things up. John  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 9 Feb 88 21:30:21 EST Received: from relay2.cs.net by RELAY.CS.NET id aa15125; 9 Feb 88 20:02 EST Received: from csc.ti.com by RELAY.CS.NET id au01645; 9 Feb 88 19:56 EST Received: from mips by tilde id AA02306; Tue, 9 Feb 88 17:45:33 CST Received: by mips id AA21412; Tue, 9 Feb 88 17:45:27 CST Date: Tue, 9 Feb 88 17:45:27 CST From: David Bartley Message-Id: <8802092345.AA21412@mips> To: rrrs-authors@mc.lcs.mit.edu Cc: oxley%home.csc.ti.com@RELAY.CS.NET, Bartley%mips.csc.ti.com@RELAY.CS.NET In-Reply-To: Don Oxley's message of Mon, 8 Feb 88 15:43:39 CST <8802082143.AA03731@home> Subject: A Minimalist Standard > If Scheme is to be a vehicle for research and experimentation, then I > forsee little problem, but as Scheme becomes more of a development > language for delivering other applications (eg., TI's Personal > Consultant), then there will be considerable pressure to "standardize" > the non-standard parts of the language. For example, many of us at TI > have succumbed to the use of multiple values as part of our Scheme > language - not to investigate multiple values but to use it in larger > efforts. > > I don't have a solution to this problem, but I think that something > more than a minimalist approach will become necessary. The language > must be "sufficient" for significant development as perceived by the > users. I think we can reasonably hope to have our cake and eat it too. A "minimalist" standard is necessary now because it's the only kind we can hope to get agreement on any time soon. It also establishes what kind of language Scheme is---a very important point to many of us who are fearful of any standardization. I also think it is sufficient, even for the case you mention (users writing non-trivial applications who need more features than exist in the minimalist standard). Such "features" need to be debated among the implementors and alternatives placed before the user community as parts of packaged Scheme products. They need to prove themselves before they are considered for standardization. I think the informal approach has worked so far, and should continue to be used. Macros, opaque objects, etc., can and should be worked out informally and incorporated in a later revision. One of the problems with the Common Lisp standardization process is that the existence of holes---like a real LOOP macro or a standard Object programming paradigm---has resulted in *design* going on instead of *ratification*. We don't need to do that. I support the minimalist approach, which I take to mean (roughly) blessing R3RS with minor fixup (e.g. the numbers proposal from last June, but not macros (and throw out DO??)). The segregation of essential, inessential, and "yellow pages" is already there. --db--  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 9 Feb 88 10:06:44 EST Received: from relay2.cs.net by RELAY.CS.NET id aa07252; 9 Feb 88 9:54 EST Received: from brandeis by csnet-relay.csnet id ac28762; 9 Feb 88 9:48 EST Received: by brandeis.ARPA (5.51/4.7) id AA13182; Tue, 9 Feb 88 08:44:47 EST Received: by mephi.earth1.com (3.2/SMI-3.2) id AA14967; Tue, 9 Feb 88 08:43:34 PST Date: Tue, 9 Feb 88 08:43:34 PST From: James Miller Message-Id: <8802091643.AA14967@mephi.earth1.com> To: rrrs-authors%mc.lcs.mit.edu@RELAY.CS.NET In-Reply-To: David Bartley's message of Mon, 8 Feb 88 17:33:55 CST <8802082333.AA10271@mips> Subject: Can we standardize Scheme without killing it? I haven't entered the fray yet, and I don't want to do anything about heating up the debate. My personal opinion is that I would prefer not to standardize, but I suspect that we will have to do so for a large variety of reasons. I prefer the IEEE option as I understand it now over the ANSI option, but I am afraid that costs *ARE* the single determining feature in my ability to work on this. They are one reason I prefer IEEE. I'd hate to get left out, but I am a new faculty member (first year) and have no way to afford travel expenses. Thus, the MITRE meeting has significant appeal to me; but that's very selfish. One final note: I'm scared by Don Oxley's message regarding a diversion from the minimalist standard. I'm not very much of a minimalist myself, but I see absolutely no hope of getting a standard we will all like if we don't strongly adopt a Steele-like stance against new features. I suggest that we take a fairly strong line that any proposed extension which can be implemented using Yellow Pages style be kept out of the standard entirely. I also believe that we *have* to finally agree on macros to make this philosophy reaonably workable. --Jim  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 9 Feb 88 01:08:04 EST Received: from relay2.cs.net by RELAY.CS.NET id ac29953; 8 Feb 88 20:39 EST Received: from csc.ti.com by RELAY.CS.NET id aa25077; 8 Feb 88 20:32 EST Received: from mips by tilde id AA05490; Mon, 8 Feb 88 17:33:59 CST Received: by mips id AA10271; Mon, 8 Feb 88 17:33:55 CST Date: Mon, 8 Feb 88 17:33:55 CST From: David Bartley Message-Id: <8802082333.AA10271@mips> To: rrrs-authors@mc.lcs.mit.edu In-Reply-To: Hal Abelson's message of Sat, 6 Feb 88 20:13:34 EST <322467.880206.HAL@AI.AI.MIT.EDU> Subject: Can we standardize Scheme without killing it? I can almost feel consensus in the air---although a number of people have been conspicuously silent concerning standardization. I'm prepared to go wherever and meet whomever may be necessary to help resolve the non-technical aspects of Scheme standardization. Shall we accept Ramsdell's invitation to meet at MITRE? When? If not, where? How about the rest of you? Does silence means apathy or tacit approval? (Despair?) One problem with all standards efforts is the travel costs associated with meetings. Are we likely to disenfranchise anyone on that basis? If we were to agree in advance to stick closely to R3RS, could we get by with fewer active participants doing most of the work? --db--  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 8 Feb 88 19:47:07 EST Received: from relay2.cs.net by RELAY.CS.NET id aa26766; 8 Feb 88 16:58 EST Received: from csc.ti.com by RELAY.CS.NET id as23929; 8 Feb 88 16:50 EST Received: from home by tilde id AA02132; Mon, 8 Feb 88 15:22:13 CST Received: by home id AA03169; Mon, 8 Feb 88 15:20:29 CST Date: Mon, 8 Feb 88 15:20:29 CST From: Don Oxley Message-Id: <8802082120.AA03169@home> To: rrrs-authors@mc.lcs.mit.edu Subject: Scheme Standardization [This is a little late - I sent it a week ago and went out of town - when I returned I found that my message had also] After reading rpg's arguments in support of working with the ANSI effort, I wonder if it is really possible to allow a sub-committee to sit as idly to the side as he suggests (I don't really purport to know). If ISO is interested in Scheme and is active, would the US effort not be compelled to join the fray. It seems a bit disconcerting to me to sit in the midst of a swamp full of alligators when my initial goal was a family picnic! It seems to me that whether we work with the IEEE or ANSI, Scheme can remain a reasonable language if the major implementors/researchers continue to work together and will otherwise be abandoned. If alien forces were to take control of an IEEE or ANSI effort and significantly harm Scheme or make the process intolerable, I would imagine that most researchers would ignore it and a new direction would occur. This would indeed be unfortunate, but the most likely result would be that the current implementations would define a dying "standard" until a new language evolved. If the current implementors continue working together, with or without the support of a standards group, I think that we will continue to develop a language which will gain substantial use. It seems to me that participation in one of the standards efforts *may* provide a vehicle to encourage more acceptance of Scheme and the development of a broader community (which we need). If we keep a goal of accepting only widely supported additions, then we ought to be able to manage an evolution from the R3RS (maybe even R3RS itself). Its not clear to me which is better, somehow it seems that the IEEE may have the less burdensome process. Could the ANSI committee be "formed" and sit idle as a placeholder and then maybe adopt/endorse a successful effort through the IEEE? I would vote to attempt a standardization effort - if only to encourage discussion and dissemination of the concepts. If it becomes too unwieldly, then just abandon it - there is no sense in standardizing a competitor to Common Lisp that has nothing new to offer - that would be damaging to the entire Lisp community. If Scheme is to become a widely used language, it must be something we are still proud of - otherwise it should remain a minor research tool. --Don  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 8 Feb 88 19:44:21 EST Received: from MICKEY-MOUSE.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 8 Feb 88 19:39-EST Date: Mon, 8 Feb 88 19:40 EST From: Mark A. Sheldon Subject: Scheme number notation To: DEATH@XX.LCS.MIT.EDU, SUSSMAN@G.BBN.COM, gjs@MC.LCS.MIT.EDU, JAR@AI.AI.MIT.EDU cc: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: <880208174738.0.DEATH@MICKEY-MOUSE.LCS.MIT.EDU> Message-ID: <880208194000.2.DEATH@MICKEY-MOUSE.LCS.MIT.EDU> Oops! I have to take back my complaint that R3RS underspecifies the interrelationships among values returned by CHAR->INTEGER for numeric characters. JAR pointed out to me that you can just compute a table in which to look up the values (indexed by the CHAR->INTEGER result). It wastes some space, but so what. Now my reader is completely (?) portable under R3RS. -Mark  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 8 Feb 88 18:55:59 EST Received: from relay2.cs.net by RELAY.CS.NET id ab28354; 8 Feb 88 18:38 EST Received: from csc.ti.com by RELAY.CS.NET id ae24504; 8 Feb 88 18:34 EST Received: from home by tilde id AA02672; Mon, 8 Feb 88 15:45:32 CST Received: by home id AA03731; Mon, 8 Feb 88 15:43:39 CST Date: Mon, 8 Feb 88 15:43:39 CST From: Don Oxley Message-Id: <8802082143.AA03731@home> To: rrrs-authors@mc.lcs.mit.edu Subject: A Minimalist Standard I heartily concur with Hal's philosophy on the standard. Leaving unsettled issues out of the standard and allowing good research to take place is crucial. However, I have a concern. If Scheme is to be a vehicle for research and experimentation, then I forsee little problem, but as Scheme becomes more of a development language for delivering other applications (eg., TI's Personal Consultant), then there will be considerable pressure to "standardize" the non-standard parts of the language. For example, many of us at TI have succumbed to the use of multiple values as part of our Scheme language - not to investigate multiple values but to use it in larger efforts. I don't have a solution to this problem, but I think that something more than a minimalist approach will become necessary. The language must be "sufficient" for significant development as perceived by the users. Possibly we can address this with the R*S "optional" or "extensions" parts of the language which commit definitions for features which are not part of the standard. We might even adopt a standard prefix (eg., #!@?) to avoid preempting names from a future standard. In any case, I think we should consider trying to develop an approach to recognizing and allowing "registered" extensions which could help in portability and future automated correction when a real standard is developed. This could also be used to allieviate some of the pressure to standardize a feature too early. Comments?? --Don  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 8 Feb 88 17:48:18 EST Received: from MICKEY-MOUSE.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 8 Feb 88 17:47-EST Date: Mon, 8 Feb 88 17:47 EST From: Mark A. Sheldon Subject: Scheme number notation To: SUSSMAN@G.BBN.COM, gjs@MC.LCS.MIT.EDU, JAR@AI.AI.MIT.EDU cc: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: <[G.BBN.COM] 8-Feb-88 09:35:01.SUSSMAN> Message-ID: <880208174738.0.DEATH@MICKEY-MOUSE.LCS.MIT.EDU> R3RS doesn't say what the meaning of E notation (for the exponent) is. In MIT C/Scheme, apparently e means *10^ regardless of the base. E.g. #b1e2 is 100 decimal, not 100 binary. You're right that R3RS leaves the notation for exponents underspecified. I discovered this when I used some of the MIT Scheme number-parser code to write my own reader. My reader now uses the radix specified in the prefix (if any) as the radix for reading the exponent. Thus #b1e2 is 100 binary. Worse yet, though the lexical grammar allows E with any base, it can't work with hex, since E is a hex digit. Hence, #b1E2 = #o1E2 = 1E2 = 100 but #x1E2 = 482 I also ran into the problem with E in hex: without thinking about it, I formulated the test case 1.1E-2 and got reader errors (obviously). Since E notation is really just a hold-over from FORTRAN, why not use ^ instead? It would look nicer and wouldn't conflict with any reasonable radix. Another problem in implementing a reader in Scheme is that R3RS also underspecifies the relationships among the return values of CHAR->INTEGER. There is no guarantee that the numeric characters are together in the character code. My reader (and the MIT Scheme reader) relies on this anyway. -Mark  Received: from G.BBN.COM (TCP 1000400022) by MC.LCS.MIT.EDU 8 Feb 88 09:46:56 EST Date: 8 Feb 1988 09:46-EST Sender: SUSSMAN@G.BBN.COM Subject: Wording to fix for LETREC From: SUSSMAN@G.BBN.COM To: rrrs-authors@MC.LCS.MIT.EDU Cc: sussman@G.BBN.COM, quigley@SOCRATES.BBN.COM Message-ID: <[G.BBN.COM] 8-Feb-88 09:46:03.SUSSMAN> In 4.2.2 "Binding constructs" you need to add the word ALL as follows: "...in a letrec expression, ALL the bindings are in effect while their initial values are being computed..." Otherwise it could mean that each binding is in effect while its own initial value is being computed. Julie  Received: from G.BBN.COM (TCP 1000400022) by MC.LCS.MIT.EDU 8 Feb 88 09:35:53 EST Date: 8 Feb 1988 09:35-EST Sender: SUSSMAN@G.BBN.COM Subject: Scheme number notation From: SUSSMAN@G.BBN.COM To: gjs@MC.LCS.MIT.EDU, rrrs-authors@MC.LCS.MIT.EDU Cc: allen@SOCRATES.BBN.COM, quigley@SOCRATES.BBN.COM Cc: sas@BFLY-VAX.BBN.COM, las@BFLY-VAX.BBN.COM Cc: sussman@G.BBN.COM, amellor@BFLY-VAX.BBN.COM Cc: ajc@BFLY-VAX.BBN.COM Message-ID: <[G.BBN.COM] 8-Feb-88 09:35:01.SUSSMAN> R3RS doesn't say what the meaning of E notation (for the exponent) is. In MIT C/Scheme, apparently e means *10^ regardless of the base. E.g. #b1e2 is 100 decimal, not 100 binary. Worse yet, though the lexical grammar allows E with any base, it can't work with hex, since E is a hex digit. Hence, #b1E2 = #o1E2 = 1E2 = 100 but #x1E2 = 482 Julie  Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 7 Feb 88 21:53:28 EST Received: by ZOHAR.AI.MIT.EDU; Sun, 7 Feb 88 21:56:08 est Date: Sun, 7 Feb 88 21:56:08 est From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman) Message-Id: <8802080256.AA10107@zohar> To: HAL@AI.AI.MIT.EDU Cc: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: Hal Abelson's message of Sat, 6 Feb 88 20:13:34 EST <322467.880206.HAL@AI.AI.MIT.EDU> Subject: Can we standardize Scheme without killing it? Modified rapture!  Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 7 Feb 88 21:37:47 EST Received: by ZOHAR.AI.MIT.EDU; Sun, 7 Feb 88 21:40:18 est Date: Sun, 7 Feb 88 21:40:18 est From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman) Message-Id: <8802080240.AA10087@zohar> To: gls@Think.COM Cc: rrrs-authors@mc.lcs.mit.edu In-Reply-To: gls@Think.COM's message of Fri, 5 Feb 88 19:09:01 EST <8802060009.AA01135@kali.think.com> Subject: Standardization Thank you GLS. As usual, we agree on lots of things. In particular, the most wonderful part of R^3RS is that it is less than 50 pages. Let's keep R^4RS that small! By the way, the only features I would propose to add to "official" Scheme are REDUCE and some kind of EVAL (note how it seems to be almost EVIL in these prudish times), such as our ENCLOSE (which I would now call LAMBDA->PROCEDURE) so that I can run code that I construct on the fly. Thus I think we have used up our quota.  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 7 Feb 88 12:49:48 EST Received: by iuvax.cs.indiana.edu; id AA10771; Sun, 7 Feb 88 12:48:15 EST Date: Sun, 7 Feb 88 12:48:15 EST From: Dan Friedman Message-Id: <8802071748.AA10771@iuvax.cs.indiana.edu> To: rrrs-authors@mc.lcs.mit.edu Subject: A vote for a minimal standard In conversations with Chris Haynes I have expressed my opinion that if there is to be a standardization of Scheme it ought to be under the auspices of the people who have Scheme's best interests at heart. From my current perspective it appears that IEEE is our best hope. Language design for human users is a constantly evolving process, so it should be clear that at the outset only the smallest acceptable subset of R^n should be standardized. --- Dan  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 7 Feb 88 12:39:54 EST Received: by iuvax.cs.indiana.edu; id AA10507; Sun, 7 Feb 88 12:38:22 EST Date: Sun, 7 Feb 88 12:38:22 EST From: Dan Friedman Message-Id: <8802071738.AA10507@iuvax.cs.indiana.edu> To: rrrs-authors@mc.lcs.mit.edu Subject: Minimal Standard In conversations with Chris Haynes I have expressed my opinion that if there is to be a standardization of Scheme it ought to be under the auspices of the people who have Scheme's best interests at heart. From my current perspective it appears that IEEE is our best hope. Language design for human users is a constantly evolving process. So it should be clear that at the outset only the smallest acceptable subset of R^n should be standardized. --- Dan  Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 7 Feb 88 11:47:48 EST Received: by ZOHAR.AI.MIT.EDU; Sun, 7 Feb 88 11:50:42 est Date: Sun, 7 Feb 88 11:50:42 est From: hal@ZOHAR.AI.MIT.EDU (Hal Abelson) Message-Id: <8802071650.AA09808@zohar> To: rrrs-authors@mc Subject: can we properly standardize a philosophy? Reply-To: hal@ai.ai.mit.edu Guy's comment: After distilling Hal's suggested introductory paragraphs, however, I find that perhaps what many of want is not so much a standard programming language, but a standard framework within which to investigate a family of programming languages. I know we can standardize a programming language within IEEE or X3, but can we properly standardize a philosophy? I think that latter goal has already been served by the publication of R^3S. puts the issue very well. When the question of Scheme standardization was first raised my opinion was that Scheme was already standardized in R*S and that anything more "official" would be neither necessary nor desirable. But serious concerns have been raised about (1) some other group standardizing something called "Scheme" (2) Scheme getting overshadowed by Common Lisp (3) Scheme not being viewed as a "real language". So I think it is worthwhile to see if we can go the standards route without blowing it. "Blowing it" means setting up a situation where people feel that they have to agree about large chunks of Scheme before they can work on Scheme. That turns Scheme design into a political process rather than an intellectual one. It also, unfortunately, is often the express purpose of creating a standard. I do think, however, that if we are careful, we could have our cake and it too: (1) We could satisfy the demands for standardization and the procedural requirements of a standards organization by "standardizing" a small kernel. Luckily, we have already adopted the idea of a spectrum ranging from essential features to yellow pages, which makes this possible. (2) We could satisfy ourselves that we are not overly politicizing Scheme development by including appropriate philosophical statements in the report, and by identifiying a process for evolving the standard that will guard against this. I am not at all secure that we can manage (2), which is why I think we need to meet to discuss this, and to continue discussions on this mailing list. In particular, we need to hear from Clyde Camp on behalf of IEEE and from people familiar with X3 (by the way, what is X3 ?) about whether such an approach would be compatible with the frameworks of the various standards organizations. -- Hal  Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 7 Feb 88 00:56:06 EST Return-Path: Received: from kali.think.com by Think.COM; Sun, 7 Feb 88 00:55:18 EST Received: by kali.think.com; Sun, 7 Feb 88 00:55:15 EST Date: Sun, 7 Feb 88 00:55:15 EST From: gls@Think.COM Message-Id: <8802070555.AA03061@kali.think.com> To: HAL@ai.ai.mit.edu Cc: rrrs-authors@mc.lcs.mit.edu In-Reply-To: Hal Abelson's message of Sat, 6 Feb 88 20:13:34 EST <322467.880206.HAL@AI.AI.MIT.EDU> Subject: Can we standardize Scheme without killing it? 2) However the politics goes, the technical content of the first Scheme standard should be what we have already agreed upon in R*S with the possible exception of correcting obvious blunders. I appreciate Guy Steele's sentiment that we pass a rule saying that each person can nominate at most one feature to be included. But I think that this is one feature too many. (Guy's suggested REDUCE, which I think is a wonderful thing, can be put in the Yellow Pages.) In general I would like to see a VERY conservative and VERY minimal standard. Hal's point is very well taken here, and I humbly retreat even further. After distilling Hal's suggested introductory paragraphs, however, I find that perhaps what many of want is not so much a standard programming language, but a standard framework within which to investigate a family of programming languages. I know we can standardize a programming language within IEEE or X3, but can we properly standardize a philosophy? I think that latter goal has already been served by the publication of R^3S. Had it not already appeared in SIGPLAN Notices, it might have been a candidate for the Lisp Conference. Compare this to the appearance of Milner's "A Proposal for Standard ML" in the 1984 Lisp Conference. I agree with Hal that better ideas for language design come out of the academic arena than out of standards committees--even when it is the same people involved--because the processes are very different. People continue to ask me (or tell me) whether X3J13 is really needed or whether the mere publication of CLtL was sufficient. My reaction is almost invariably "You're asking ME??" I like Scheme. Scheme is nice. Scheme makes me happy. I want everyone else to be happy too. Am I a sap? --Guy  Received: from Sushi.Stanford.EDU (TCP 4402000065) by MC.LCS.MIT.EDU 6 Feb 88 22:55:40 EST Date: Sat 6 Feb 88 19:49:54-PST From: Andy Freeman Subject: Re: Standardization To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <12372714364.17.ANDY@Sushi.Stanford.EDU> I don't understand most of the responses to RPG's proposal. This may be due to my lack of experience in standards activities or my ignorance of IEEE/ISO/ANSI/X3/X3J13 politics. (BTW - what are the latter two short for?) RPG mentioned a number of political problems in the CL standardization process. Most of the messages that mention these problems suggest that Clyde Camp's proposal avoids them but that isn't obvious to me. RPG is offering whatever structural help the CL standardizers can offer - under Camp's proposal, the Scheme community has to do everything itself. In RPG's proposal, unlike Camp's, the Scheme community doesn't have to fight the battles that the CL standardizers have already won. What specific things does IEEE offer that are less likely under RPG's proposal? Doesn't Camp's proposed Scheme standardization have to jump through hoops that RPG's puts us beyond? I believe the "Scheme is a Lisp" dogma and that Common Lisp is also a Lisp; I expect the next Lisp to appear soon (although it may not be recognized for a 10-15 years). I want to provide substantial cross-fertilization among the members of the Lisp family (although I expect CL to provide most of the negative lessons) without sacrificing the autonomy that they need. (What little I've heard from the logic programming community suggests that they are taking this approach, unlike the proponents of yet-another-algebraic-language.) Therefore, I'd like to see a standardization structure that reflects that relationship (I'll explain why I think it is now time to standardize Scheme in a couple of paragraphs). In other words, I'd like to see something along the lines of: Lisp / | \ CL Scheme Future Lisps Neither Camp's IEEE nor RPG's X3J13 sub-committee proposal match that structure but I think that RPG's is easier to "subvert". I may be naive, but if the CL people want this structure, it should be easier to promote a sub-committee than it is to bring in an outside group. Can we arrange for this to happen at the same time the initial Scheme standard is approved? If we can't, RPG's proposal is obviously inferior; if we can, that's a big point in its favor. Why I think Scheme Standardization is Good: A few weeks ago, John Ramsdell said that the current R^nRS language was not a good candidate for standardization because it was missing eval, objects, macros, support for programming in the large, and parallelism; others mentioned logic variables and type inferenceing. I agree with something implied by Chris Haynes; he said that a standard was an agreement on what was stable. I think we can push this a bit further and use standardization as a framework for managing the medium-term development of Scheme. Note that I am not saying that the standardization process should design Scheme; Kent Pitman among others is absolutely right when he says that "the organizational structure of a standards committee is not appropriate for design work." I would like to see the first round of Scheme standardization result in the red book as a trial standard and an agreement that the revision two years later would incorporate eval and objects and possibly macros. If macros are ready by then, then that standard could be a full standard to be followed in 5 years by a revision than incorporated some support for programming in the large and logic variables. If macros aren't ready in two years, then there could be another interim standard until they are. Something similar can be done for libraries. In each case, I expect to see competing proposals based on experience. In other words, I'd like to see a Scheme standard that is not only an agreement on what is and what direction we're going but one that also schedules revisions of both. I think that CL would have been better now if they'd have started 10 years earlier and gone through the loop a few more times with a similar plan. One of the beneficial side effects of a planned series of standards is that eventually Scheme development ends; it schedules the death of Scheme. Either Scheme-2010 is the one true lisp used by all (except for the fortran heretics) or, as I expect, we'll have something nice to use while epitome is developed using the scheme experience. If I'm completely confused, I'd appreciate E-mail; there's no need to post what everyone else knows. -andy -------  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 6 Feb 88 20:14:02 EST Date: Sat, 6 Feb 88 20:13:34 EST From: Hal Abelson Subject: Can we standardize Scheme without killing it? To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <322467.880206.HAL@AI.AI.MIT.EDU> Like David Bartley and Norman Adams, I've decided to unenthusiatically support standardizing Scheme through IEEE -- provided we can do it with proper precautions (see below). The reason is not so much to "get Scheme out from under the shadow of Common Lisp", as someone (I forget who) wrote to this list. Rather, I expect that as Scheme becomes more widely used, there will be increasing pressure to standardize it. And I am sure that as time goes on, it will be increasingly difficult to standardize it in "the right spirit." Already, at our preevious R*S meeting, Scheme design had become too much of a political process rather than a technical one. People had begun to see themselves not as individual language designers, but as representatives of various constituencies of Scheme users. This can only get worse as time goes on. So let's face the issue now. My fear is that it is already too late to avoid the politics. I want to make a couple of suggestions 1) We meet very soon to decide whether we want to go ahead with standardization, and if so, to figure out how to go about this. I think that this meeting should not talk about technical issues. 2) However the politics goes, the technical content of the first Scheme standard should be what we have already agreed upon in R*S with the possible exception of correcting obvious blunders. I appreciate Guy Steele's sentiment that we pass a rule saying that each person can nominate at most one feature to be included. But I think that this is one feature too many. (Guy's suggested REDUCE, which I think is a wonderful thing, can be put in the Yellow Pages.) In general I would like to see a VERY conservative and VERY minimal standard. 3) My biggest worry about standardizing Scheme is my belief that language design ought to be an evolutionary process guided by those people with the best ideas at the moment, as worked out in research papers and in implementations. It should not be a political process in which things are done by some offical set of empowered representatives (whether empowered by ANSII, ISO, IEEE, God, or whomever). That sort of approach stultifies research by making people feel as if they need to go to some "official body" to get their ideas seriously considered. I am currently refereeing papers submitted to the 1988 Lisp and Functional Programming Conference. If I simply count what Lisp dialects people are writing about, then in 150 papers I have seen so far, there are as many papers specifically about Scheme as there are about Common Lisp. If I ignore papers of the form "I have implemented a neat program in Lisp" and restrict to papers that are proposing serious language extensions or investigations of semantics, then there are about a dozen of these about Scheme and only two or three about Common Lisp. I assume that some of this is because Scheme is a cleaner language than Common Lisp. But I can't help thinking that another reason is that any serious researcher would think it a waste of time to work on an extension to Common Lisp unless he is one of the "duly constituted representiatives" of the Common Lisp Community. To put it another way, standardizing something is a good way to shut off research in it. To my mind, much of the reason that Lisp is still around after 30 years is that it never was standardized and so was able to evolve in an informal way. I think that Common Lisp is well on its way to being a dead language, and I don't want the same thing to happen to Scheme. But it's going to be hard to resist. Whatever group gets the power to make Scheme "official" is going to be tempted to "satisfy the needs of all those Scheme users out in the world" by making the standard more and more complete and by arrogating more and more of the design process to themselves. And they will do this with the best possible motives. For example, I am very impressed with the work of Bobrow, Kiczales, Gabriel, etc. in designing CLOS. But I think it is wrong for them to do this under the auspices of X3. One result is that the ONLY paper I have seen so far about objects in Common Lisp submitted to the L&FP conference this year is by members of the CLOS subcommittee. So I think we need to give some serious thought to setting up a Scheme standardization process that will be immune to this kind of temptation. For example, we might decide that extensions to the Scheme standard will be adopted only in conjuction with some academic conference (such as L&FP) and only after "the research community" is satisifed that the issues have been fully explored and that some concensus (NOT a vote) has been attained. I would like to hear suggestions from Clyde Camp on whether such a thing would be compatible with IEEE (or ANSII or ISO) standards policies. In addition, I would like us to include specific language in the Scheme standard that puts the standardization effort in this light. Here are some suggested paragraphs. I am happy to have someone else edit them and make changes, but I do want to include some such words near the beginning of the report: -------------------------------------------------- SUGGESTED PARAGRAPH FOR SCHEME STANDARD Throughout its thirty-year life, Lisp has continually adapted to encompass changing ideas about programming-language design. Specifying a standard for Scheme is intended to encourage the continued evolution of Lisp dialects by identifying a coherent set of constructs that is large enough to support the implementation of substantial Lisp programs, but also small enough to admit significant extensions and alternate approaches to language design. For example, the standard does not mandate the inclusion in Scheme of large run-time libraries, particular user interfaces, or complex interactions with external operating systems, although practical Scheme implementations ordinarily provide such features. In particular, there are important linguistic design issues that are not discussed in the Scheme standard {\em precisely because} Scheme has sparked fruitful new approaches in these areas, and the authors of this report do not wish to discourage the further development of good ideas by taking a position on issues under active investigation. Some of these issues are: Macros: The scope of identifiers in macros has traditionally been problematic for Lisp. Scheme's adoption of lexical scoping and a single namespace for identifiers has stimulated the development of macro-expansion techniquies that are more elegant and robust than those appearing in other Lisp dialects. Although this report does not specify a macro-definition facility, most popular Scheme implementations allow users to define macros. The research literature [ references ....] contains numerous discussions of macro definition in Scheme. Packaging: Scheme's uniform naming conventions permit ordinary lexical environments (in some Scheme implementations) or slight modifications of these (in other implementations) to provide poerful support for programming-in-the-large. This obviates the need for special-purpose naming mechanisms (such as multiple obarrays) as adopted by other Lisp dialects. References [.......] provide discussions of techniques for packaging and module definition in Scheme. Object-oriented programming: Scheme unadorned is nearly an object-oriented language. [JAR and Adams: I hope you don't object to my snarfing the first sentence of your paper. It's a wonderful sentence.] With simple extensions (or even simple syntactic conventions) Scheme becomes a powerful foundation for implementing a panoply of object systems, with little of the conceptual baggage adopted by other Lisp dialects. See [refs .......] for examples. [feel free to add more examples of Scheme's wonderfulness and your current research: parallelism, continuations, logic variables, type inferencing, ...] The authors of this report hope that future revisions of the Scheme standard will be sensitive to the fact that good ideas need time to mature, and that exploration can often be stifled by the premature adoption of standards. -------------------------------------------------- -- Hal  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 5 Feb 88 22:11:53 EST Received: from relay2.cs.net by RELAY.CS.NET id aa28007; 5 Feb 88 19:40 EST Received: from csc.ti.com by RELAY.CS.NET id ap05375; 5 Feb 88 19:35 EST Received: from mips by tilde id AA05055; Fri, 5 Feb 88 18:06:14 CST Received: by mips id AA14165; Fri, 5 Feb 88 18:06:09 CST Date: Fri, 5 Feb 88 18:06:09 CST From: Clyde Camp Message-Id: <8802060006.AA14165@mips> To: ramsdell%linus@MITRE-BEDFORD.ARPA, rrrs-authors@mc.lcs.mit.edu Cc: Camp%mips.csc.ti.com@RELAY.CS.NET In-Reply-To: ramsdell%linus@mitre-bedford.arpa's message of Fri, 5 Feb 88 07:53:53 EST <8802051253.AA05013@darwin.sun.uucp> Subject: Critical summary Several people have pointed out that the message numbers I referred to a while back don't mean anything. Sorry about that. I idiotically assumed the whole network used the same numbering scheme. To complicate matters, not everything of mine is getting through (probably due to pilot error). The messages I was referring to were as follows: Two initial major ones from me: "It is easier to kill a thing....." - a history "I can't help but...." - a proposal From Dick Gabriel: "Gentlemen. I have talked with Bob..." - an alternate proposal "My wording on this point.... " - an elaboration and history From me: "This is being belatedly posted ... " - a response to Dick's message If you have not received them I'll resend. Clyde  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 5 Feb 88 19:15:46 EST Received: from relay2.cs.net by RELAY.CS.NET id ab25269; 5 Feb 88 16:24 EST Received: from tektronix.tek.com by RELAY.CS.NET id dt02632; 5 Feb 88 16:11 EST Received: by tektronix.TEK.COM (5.51/6.24) id AA08543; Fri, 5 Feb 88 11:55:51 PST Received: by tekchips.CRL.TEK.COM (5.51/6.24) id AA07984; Fri, 5 Feb 88 11:55:07 PST Date: Fri, 5 Feb 88 11:55:07 PST From: Norman Adams Message-Id: <8802051955.AA07984@tekchips.CRL.TEK.COM> Subject: Standardization To: Dick Gabriel Cc: rrrs-authors@mc.lcs.mit.edu I am confused by your recent messages. 2 Feb 88: I suppose it might be natural for one who believes that association with Common Lisp is the ``worst possible thing for Scheme'' to not wish to associate with people involved with Common Lisp, but I see many of the Common Lisp folks shaking their heads and wondering how such a weird and depressing experience as Common Lisp standardization could have been foisted on them. But, alas, such a dreamer am I to wish for co-operation. Will said that having a stardards organization for Scheme be part of X3J13 would be the worst possible thing for Scheme. Others have said they would like to avoid Scheme and Common Lisp being closely associated. As I read the above, you seem to say that advocating a clearly distinguished standards effort for Scheme --as Will has advocated-- is uncooperative. Why? You yourself characterize Common Lisp standardization (as embodied by X3J13) as "a weird and depressing experience." So let the Scheme efforts walk clear of that tar pit. 4 Feb 88: 2. I am saddened by the animosity I see towards Common Lisp and by implication towards the Common Lisp community. I made the proposal because I thought the it might serve as a means of bringing two group together who would seem to be naturally linked. A preference by the Scheme community to have the Scheme language clearly distinguished from the Common Lisp language does not imply that the Scheme community sees no value in Common Lisp. You say a distaste for Common Lisp implies a distaste for the Common Lisp community. I do not understand the basis for this implication. ...In fact I have seen people who are my friends attack me because they thought I was trying to destroy their community. So, I withdraw my proposal, There must be something going on behind the scenes. I cannot understand this in the context of what I have seen on the mailing list. ...and I guess I withdraw from the arena of bringing the Lisp/Scheme communities together. Enjoy your battle. And now I am completely lost. Does the mutual influence of the Common Lisp and Scheme communities hinge on some ANSI-contained relationship? I think not. The Lisp and Scheme communities already interact on technical issues. (Will I see you at the Lisp Conference?) More interaction is possible. I would think that an X3J13 subcommittee (or whatever) on Scheme would increase political interaction, while doing little for technical interaction. And what battle? (I am still lost.) 4. We can also broaden the charter of X3J13 to specifically include Scheme. A committee or subcommittee on Scheme could be established with its own time schedule. This would accomplish several things for you: ... 6. You would have a voice and standing within any ISO process concerning Lisp in which you were interested. 7. Any renegade IEEE efforts towards standardizing Scheme would be officially disallowed through a petition from SPARC to IEEE. and in a later message Many observers (Mathis and myself included) believe that if ANSI is asked to recognize Scheme as a different language from Common Lisp, they will not do so, but ask that X3J13 broaden its charter. Certainly you did not intend make threats, but it seems to me a threat is implied: "Play the X3J13 game or you can't participate in ISO Lisp; if ISO asks X3J13 about Scheme, X3J13 will incorporate Scheme with or without the Scheme community." I find it strange that the committee that wrote "Common Lisp" into their charter so as "not to hamper the Scheme efforts" would then broaden its charter to include Scheme. From what I understand, ANSI could choose to include an IEEE effort in ISO level activities if appropriate. Clyde Camp says such cooperation is possible. Will also makes this point. Are we naive to believe that cooperation between ANSI and IEEE is possible? I have moved from being slightly against any formal standards effort to slightly in favor of an effort organized under IEEE. -Norman -------  Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 5 Feb 88 19:10:59 EST Return-Path: Received: from kali.think.com by Think.COM; Fri, 5 Feb 88 19:09:05 EST Received: by kali.think.com; Fri, 5 Feb 88 19:09:01 EST Date: Fri, 5 Feb 88 19:09:01 EST From: gls@Think.COM Message-Id: <8802060009.AA01135@kali.think.com> To: wand%corwin.ccs.northeastern.edu@relay.cs.net Cc: RPG@sail.stanford.edu, rrrs-authors@mc.lcs.mit.edu In-Reply-To: Mitchell Wand's message of Thu, 4 Feb 88 21:51:40 EST <8802050251.AA07467@corwin.ccs.northeastern.edu> Subject: Standardization Date: Thu, 4 Feb 88 21:51:40 EST From: Mitchell Wand ... [There is considerable irony in this analysis. Sussman has said on several occasions that he was never interested in Scheme as a programming language; he was just interested in writing some code. I'm not sure about Guy's feelings on this. ...] I'm interested in writing code too. To the extent that it is easy and convenient for me to use a machine to try out my code, so much the better. One of the best things about Scheme is that the important parts can be written down in one page--or carried around in my head. Not having standard Scheme implementations has not bothered me too much, because I can turn ANY Lisp into a Scheme with about half an hour of work. (Usually I am trying out a language design idea by making a toy variant of Scheme, so I am writing my own evaluator anyway.) Scheme is small and clean and has a nice semantics. The kernel of Lisp 1.5 had many of the same properties. Scheme differs primarily in having better scoping rules, and in general a more carefully thought out semantics, thanks to many people who have carefully discussed the issues over the last 1.3 decades. However, it is also useful to have standard libraries. I am happy to see lots of useful numerical utilities in a Scheme, for example. It's great to have ATANH and GCD. I wish factorial and choose (actually the generalized gamma and beta functions) and Fibonacci were built in also. I have recently had some experience in trying to write large systems in Scheme. Where it differs from Common Lisp in fundamental structures (such as control and binding), it is all to the good. What I miss from Common Lisp are the little utility routines like STRING-TRIM that I must reinvent. Nevertheless, if Scheme is to be standardized I recommend that everyone on the committee try to refrain from advocating their favorite ten extra features. Scheme cannot withstand having n people add 10n new features; the result would be a patchwork, not unlike another Lisp dialect we all know. Perhaps the committee should agree to adopt a Rule of One (cf. Lloyd Biggle's "The Still, Small Voice of Trumpets"): each person gets to choose *one* new feature to propose. That makes you sit and think carefully. I have thought about it very carefully, and I choose for my One Feature to propose that a function like Common Lisp's REDUCE be added (but with not so many of the keyword-triggered options). I use that a lot. Perhaps this is too draconian a rule for a committee, but I still suggest it as a good personal discipline. --Guy  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 5 Feb 88 18:03:02 EST Received: from relay2.cs.net by RELAY.CS.NET id aa23848; 5 Feb 88 15:02 EST Received: from northeastern.edu by RELAY.CS.NET id ak02236; 5 Feb 88 14:45 EST Received: from helios.northeastern.edu by nuhub.acs.northeastern.edu; Fri, 5 Feb 88 07:37 5 Received: from corwin by helios.northeastern.edu id aa08367; 4 Feb 88 21:55 EST Received: by corwin.ccs.northeastern.edu (5.51/SMI-3.2+CCS-main-2.3) id AA07467; Thu, 4 Feb 88 21:51:40 EST Date: Thu, 4 Feb 88 21:51:40 EST From: Mitchell Wand Subject: Standardization To: RPG@SAIL.STANFORD.EDU Cc: rrrs-authors@mc.lcs.mit.edu Message-Id: <8802050251.AA07467@corwin.ccs.northeastern.edu> In-Reply-To: Dick Gabriel's message of 04 Feb 88 1206 PST Dear Dick, I hope you will not choose to withdraw from the "arena of bringing the Lisp/Scheme communities together." I, for one, found your explanation of the (Common) Lisp standardization situation extremely enlightening and helpful, and I am sorry to hear that some people think you are trying to destroy their community. I did not observe any such sentiments in the recent net traffic. There is a legitimate concern about the future of the Scheme community, but I do not believe that this is a response to any perceived threat from the Common Lisp community or from X3J13, etc. As Scheme matures and its user community grows, it is no longer controlled by a group of 2 or 5 or 18 or 31. We (meaning the members of any of these sets) can no longer control or direct the growth of the language; such direction must be shared with other as yet unknown persons or institutions which may or may not share the intellectual goals of the original group. Consequently there is understandable uncertainty about the the best way to ensure orderly development of Scheme, that is, one which will preserve its original intents. This uncertainty was reflected in the discussions of the June 87 rrrs meeting and in the current interest in standardization. [There is considerable irony in this analysis. Sussman has said on several occasions that he was never interested in Scheme as a programming language; he was just interested in writing some code. I'm not sure about Guy's feelings on this. Thus most of the "community" in question consists of second and third generation Schemers, programming-language-people who have long since wrested control from the original 2!] I hope we can endorse Bartley's characterization of the relationship between Common Lisp and Scheme in the family of Lisp-like languages. I think it is astute both intellectually (being factually close to true) and politically (as a position to take in the standardization process). I think we have a good deal to learn from each other, and I hope that the current brouhaha will not prevent this from happening. Dick, I thank you for explaining the ISO/X3J13 situation to us and explaining how Scheme might fit into that scheme. Unfortunately, I find the argument for participation in X3J13 (or maybe it's X3?) unconvincing: your description of this looking-glass world seems more apt as an argument to run as fast as possible in the other direction. I have not yet decided whether the correct course is to participate in the IEEE standards process or to ignore the standards process altogether. I hope that we will have some good discussion on the net on this topic. --Mitch  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 5 Feb 88 15:48:41 EST Received: by iuvax.cs.indiana.edu; id AA08965; Fri, 5 Feb 88 15:22:39 EST Date: Fri, 5 Feb 88 15:22:39 EST From: Chris Haynes Message-Id: <8802052022.AA08965@iuvax.cs.indiana.edu> To: rrrs-authors@mc.lcs.mit.edu Subject: from Clyde Camp In article <41288@ti-csl.CSNET> Dick Gabriel writes: >1. Individuals belong to X3J13. Companies can belong and send some number >of representatives. All members vote as they wish, but many individuals >vote their company line for whatever reasons, possibly because they have >been told to do so. I vote as I wish, but I won't guarantee that my sense >of greed will not figure into my vote. I don't believe IEEE does things >any differently. X3's brochures state that: "Membership on X3 is by organization and is classified into three groups - Producers, Consumers and General Interest. ... All members pay a service fee to support the activity. ... Requests for waiver of the fees are addressed and granted on a case by case basis." Dick is correct in that individuals, as opposed to companies, make up X3 committees and that they are free to vote as they please. Individuals may attend one meeting free to determine whether or not they want to join. In practice, however, the membership fee often excludes small companies and individuals who cannot afford to pay it. The result is that X3 membership is primarily by organization. It is partially because of this weighting towards larger companies that the documents from X3 committees must be passed through another balloting body (representing a wider, more balanced group) before they are adopted as a standard by ANSI. With the IEEE, the working committee/group has no membership restrictions placed on it by the IEEE other than the Chair must be a member of the IEEE or one of its member societies (such as the Computer Society). All interested parties may attend and participate equally in working group meetings. When the draft standard is declared done by the working group, it is passed to the sponsor for balloting. The balloting body is made individuals who are interested and technically competant to review the document (basically, if you say you are, then you are). Like X3, it must be balanced between manufacturers, users and general interest groups. Although only IEEE or society members can actually vote, ALL negative comments, from member and non-member alike, MUST be resolved or responded to by the sponsor. This meets ANSI's balloting rules for "fairness" and is why IEEE adopted standards are generally taken as-is by ANSI. - Clyde  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 4 Feb 88 20:09:01 EST Received: from relay2.cs.net by RELAY.CS.NET id aa09980; 4 Feb 88 19:25 EST Received: from csc.ti.com by RELAY.CS.NET id ac19474; 4 Feb 88 19:11 EST Received: from mips by tilde id AA07292; Thu, 4 Feb 88 16:31:45 CST Received: by mips id AA02277; Thu, 4 Feb 88 16:31:28 CST Date: Thu, 4 Feb 88 16:31:28 CST From: David Bartley Message-Id: <8802042231.AA02277@mips> To: RPG@SAIL.STANFORD.EDU Cc: rrrs-authors@mc.lcs.mit.edu, Bartley%mips.csc.ti.com@RELAY.CS.NET, Camp%mips.csc.ti.com@RELAY.CS.NET In-Reply-To: Dick Gabriel's message of 04 Feb 88 1206 PST <8802042108.AA05337@tilde> Subject: Standardization > As I've mentioned several times, my proposal was intended as yet > another alternative for the community, with no personal motivation > to see it decided one way or the other. > [...] > 2. I am saddened by the animosity I see towards Common Lisp and by > implication towards the Common Lisp community. I made the proposal because > I thought the it might serve as a means of bringing two group together who > would seem to be naturally linked. In fact I have seen people who are my > friends attack me because they thought I was trying to destroy their > community. So, I withdraw my proposal, and I guess I withdraw from the > arena of bringing the Lisp/Scheme communities together. I have no animosity towards Common Lisp or the Common Lisp community and I did not take your proposal as a threat. Perhaps I expressed myself badly. I also had a positive message to convey---that Scheme and Common Lisp have distinct roles to play and we must take care that they not be conflated. Bringing the two groups together as you suggest is indeed a natural and healthy linking. I respectfully differ on whether it is in Scheme's best interests to be standardized by the group standardizing Common Lisp. I did not anticipate that my words could be read as an attack (and certainly not a personal attack)! Please accept my apologies. I favored your proposal when I first read it. It seemed to offer the only way for Scheme proponents to participate in the ISO Lisp standardization. Unlike some of the others on rrrs-authors, I know that we have many friends of Scheme in X3J13. And your earlier remarks about the folly (and crime) of excluding people really hit home. I ended up opposing your proposal only because I concluded that it wouldn't work out well. Earlier, you wrote: I suppose it might be natural for one who believes that association with Common Lisp is the `worst possible thing for Scheme' to not wish to associate with people involved with Common Lisp, ... I work with both Scheme and Common Lisp as do most of my coworkers here at TI. I have lead the fight among Scheme implementors to avoid "gratuitous" conflicts with established CLtL precedent (e.g., the syntax of numbers). When asked for advice, I've recommended both languages, depending on the specific needs of an application. I'm truly in both camps. I see no reason they can't coexist, and I'm helping to make it happen here. I imagine the same could be said for Will. And I value my associations with both sets of people. My experience has been that some users consider Scheme as merely an alternative Lisp but others understand and appreciate its differences. My wanting to "help bring Scheme out from under the shadow of Common Lisp (and X3J13)" is merely that---Scheme and Common Lisp are equally noteworthy and each deserves its own place in the sun. > Enjoy your battle. > > -rpg- Please don't give up on us. I appreciate the spirit in which your proposal was made and I've always considered you one of us. --db--  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 4 Feb 88 17:45:41 EST Received: by iuvax.cs.indiana.edu; id AA26053; Thu, 4 Feb 88 13:52:38 EST Date: Thu, 4 Feb 88 13:52:38 EST From: Chris Haynes Message-Id: <8802041852.AA26053@iuvax.cs.indiana.edu> To: rrrs-authors@mc.lcs.mit.edu Subject: from Clyde Camp Clyde also sent the following a while ago, but it didn't make it. - Chris -------- I can't help but make the comment that dependence on E-mail to solicit information obviously restricts inputs to those who have access AND who actually read RRRS-AUTHORS on a timely basis. That is why I have to balance RRRS-AUTHORS opinions against the opinions of x-thousand Scheme users who have purchased a product from one of the three suppliers. Unfortunately I have no way of accessing those people as a whole and my sample is relatively small. For that matter, The sample of RRRS-AUTHORS is relatively small. The Scheme standard is, at this point, a proposal. There are pros and cons, but to repeat Chris "..I feel the advantages of a standard clearly outweigh the disadvantages, at least if we act reasonably soon so that it does not get out of hand." I hope that I have also made clear my feeling that the time is right for a standardization effort and that it should begin early this year. The existing red-book is pretty much in an acceptable format for a standard already. Some wordsmithing and formatting may be necessary (for example, the inclusion of the PAR number and DRAFT at the bottom of each page) and the bug on page 30 removed but I would say that it is 90+% of the end product already (modulo whatever technical changes/additions you wish to include). One thing I would strongly suggest is that the summary be extended to justify Scheme as a completely different philosophy from Common Lisp to head off trouble in that direction to begin with - but that's up to you. In view of the discussions which have been held over RRRS-AUTHORS and by phone between various parties, let me suggest the following sequence of events: 1) To continue at least net-mail discussions for the next month or so and have this topic placed on the agenda for a meeting of the RRRS group. Preferably this meeting should occur before May and even more preferably before March. I will be glad to attend if you so wish. 2) Assuming that the general (not unanimous) concensus is to proceed, give me a recommendation for a chair and vice-chair as well as a pair of alternates. At this point Chris and Will have been the only two who meet the following requirements: a) Is an IEEE or CS member b) Believes that standardization is appropriate and who wants to chair the working group. c) Is competent technically and managerially d) His employer also supports the activity and travel necessary e) The working Group is willing to follow his leadership. The actual appointment of a chair has not been made at this point and will not formally be made until after the Project Authorization Request (PAR) has been approved. 3) Have one or both of the proposed chairs (as well as anyone else who is interested) prepare a short (<30min) presentation covering Scheme uniqueness, community, importance, and proposed milestones. Chris has some rough cuts that are not so rough and are the type of thing the MSC likes to see. 4) Given that the MSC approves (and I wouldn't be going through this if I though they would not) an interrum chair would be appointed until the PAR was approved (which might get done the next week, but probably would not get done until June due to a mismatch between the meeting frequencies of the approving committees.) Finally, let me thank Will Clinger and Chris Haynes for the work they have already done in pulling all of this together. Regards, Clyde ========================= Optional Reading: The following documentation is available to explain the details of the standardization process. The chair will get these free from me (I'll be sending a copy to Chris at least sometime this month). Phone numbers are where the material can be ordered from if others want a copy. While the chair must be aware of them, everybody else can ignore the rest of this unless you're just interested (and it IS interesting - most of the time) IEEE Standards Manual (212/705-7091 Mrs. Louise Germani) IEEE Standards Style Manual " IEEE Bylaws - January 1987 " IEEE Policy and Procedures Manual Jan, 1987 " Computer Society Constitution (includes the Bylaws and Policy and Procedures manual) (714-821-8380)  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 4 Feb 88 17:43:36 EST Received: by iuvax.cs.indiana.edu; id AA09089; Thu, 4 Feb 88 17:33:37 EST Date: Thu, 4 Feb 88 17:33:37 EST From: Chris Haynes Message-Id: <8802042233.AA09089@iuvax.cs.indiana.edu> To: rrrs-authors@mc.lcs.mit.edu Subject: more from Clyde Camp Not to say too much more, but basically I agree with Hal's suggestions. The RRRS authors have two proposals before them, one by me for IEEE sponsorship and one by Dick for X3J13 sponsorship. Either is possible and there are pros and cons for going in either direction (or no direction at all). The RRRS authors have a legitimate input to the direction a Scheme standard takes -- that's why all the netmail -- and their opinions will certainly impact what happens next. For your reference, my viewpoints are in article numbers 226, 228 and 239 while Dick's are in 234-236. Regards, Clyde  Received: from SAIL.Stanford.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 4 Feb 88 15:07:52 EST Date: 04 Feb 88 1206 PST From: Dick Gabriel Subject: Standardization To: rrrs-authors@MC.LCS.MIT.EDU As I've mentioned several times, my proposal was intended as yet another alternative for the community, with no personal motivation to see it decided one way or the other. The only two remarks I have are these: 1.I would have chosen to not standardize Scheme at all, possibly to render it different from Common Lisp in yet another way. I don't feel that there is any need to take steps to accomplish unneccessary goals. 2. I am saddened by the animosity I see towards Common Lisp and by implication towards the Common Lisp community. I made the proposal because I thought the it might serve as a means of bringing two group together who would seem to be naturally linked. In fact I have seen people who are my friends attack me because they thought I was trying to destroy their community. So, I withdraw my proposal, and I guess I withdraw from the arena of bringing the Lisp/Scheme communities together. Enjoy your battle. -rpg-  Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 4 Feb 88 10:35:38 EST Return-Path: Received: from kali.think.com by Think.COM; Thu, 4 Feb 88 10:34:16 EST Received: by kali.think.com; Thu, 4 Feb 88 10:34:13 EST Date: Thu, 4 Feb 88 10:34:13 EST From: gls@Think.COM Message-Id: <8802041534.AA29148@kali.think.com> To: bartley%mips.csc.ti.com@relay.cs.net Cc: rrrs-authors@mc.lcs.mit.edu, Camp%mips.csc.ti.com@relay.cs.net, Bartley%mips.csc.ti.com@relay.cs.net In-Reply-To: David Bartley's message of Wed, 3 Feb 88 14:09:46 CST <8802032009.AA23921@mips> Subject: Scheme Standardization Date: Wed, 3 Feb 88 14:09:46 CST From: David Bartley The fallacy is that all those languages named on the cover of "Common Lisp: The Language" (CLtL) are merely dialects of a single language, Lisp, and that Common Lisp is the modern "mainstream" incarnation of the Lisp language. The truth as I see it is that Lisp 1.5, Scheme, and Common Lisp are distinct languages in the "Lisp Family" in the same sense that Algol-60, Pascal, and Ada are distinct languages in the "Algol Family." X3J13 has as little claim to jurisdiction over Scheme as the Ada standardizers had over Pascal, Modula, or even PL/1. I have been struggling to express a thought something like this. I think Bartley has hit the nail on the head. From where I stand, Pascal and Modula are practically the same language. Proponents of those languages would deny it vociferously, and I think those who use Scheme have equal standing in refusing to be lumped with other Lisp dialects. --Guy  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 4 Feb 88 09:48:40 EST From: ramsdell%linus@mitre-bedford.ARPA Posted-From: The MITRE Corp., Bedford, MA Received: from darwin.sun.uucp by linus.research (3.2/4.7) id AA08434; Thu, 4 Feb 88 09:47:47 EST Posted-Date: Thu, 4 Feb 88 09:46:49 EST Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3) id AA03808; Thu, 4 Feb 88 09:46:49 EST Date: Thu, 4 Feb 88 09:46:49 EST Message-Id: <8802041446.AA03808@darwin.sun.uucp> To: rrrs-authors@mc.lcs.mit.edu Subject: I modify my vote on Scheme standardization I have been convinced by recent discussions to modify my vote on Scheme standardization. Much like David Bartley, and not enthusiastically, I'm now inclined to move quickly to standardize a slightly cleaned up R3RS through IEEE because I think it will help bring Scheme out from under the shadow of Common Lisp (and X3J13). John  Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 3 Feb 88 23:25:55 EST Received: by ZOHAR.AI.MIT.EDU; Wed, 3 Feb 88 23:27:53 est Date: Wed, 3 Feb 88 23:27:53 est From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman) Message-Id: <8802040427.AA07660@zohar> To: bartley%mips.csc.ti.com@RELAY.CS.NET Cc: rrrs-authors@mc.lcs.mit.edu, Camp%mips.csc.ti.com@RELAY.CS.NET In-Reply-To: David Bartley's message of Wed, 3 Feb 88 14:09:46 CST <8802032009.AA23921@mips> Subject: Scheme Standardization Thank you. I have similar sentiments.  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 3 Feb 88 18:35:37 EST Received: from relay2.cs.net by RELAY.CS.NET id aa08575; 3 Feb 88 17:11 EST Received: from csc.ti.com by RELAY.CS.NET id af11483; 3 Feb 88 16:59 EST Received: from mips by tilde id AA07796; Wed, 3 Feb 88 14:09:59 CST Received: by mips id AA23921; Wed, 3 Feb 88 14:09:46 CST Date: Wed, 3 Feb 88 14:09:46 CST From: David Bartley Message-Id: <8802032009.AA23921@mips> To: rrrs-authors@mc.lcs.mit.edu Cc: Camp%mips.csc.ti.com@RELAY.CS.NET, Bartley%mips.csc.ti.com@RELAY.CS.NET Subject: Scheme Standardization I've found the whole subject of standardization of Scheme mildy distasteful, so I've held off expressing my views until now. As some of you know, Clyde Camp occupies the office next to mine here at TI. Clyde and I have had frequent debates in which I argued against any efforts to formally standardize Scheme. Dick Gabriel's recent posting advocating X3J13 jurisdiction over Scheme and Will's rebuttal have finally brought it all into focus for me: Scheme is not Lisp, it certainly is not Common Lisp, and we must not let the X3J13 or ISO standardization of "Lisp" threaten our own efforts to make Scheme what it wants to be. The fallacy is that all those languages named on the cover of "Common Lisp: The Language" (CLtL) are merely dialects of a single language, Lisp, and that Common Lisp is the modern "mainstream" incarnation of the Lisp language. The truth as I see it is that Lisp 1.5, Scheme, and Common Lisp are distinct languages in the "Lisp Family" in the same sense that Algol-60, Pascal, and Ada are distinct languages in the "Algol Family." X3J13 has as little claim to jurisdiction over Scheme as the Ada standardizers had over Pascal, Modula, or even PL/1. Surely the genesis of Scheme and its subsequent evolution at MIT, Indiana, Yale and elsewhere is as divergent and original within its cultural context as the origins of Pascal and other "Algol-like" languages are within theirs. As a TI representative to X3J13, I'm acutely aware that my obligation to promote TI's interests may occasionally conflict with my personal opinions. I've never faced a conflict between the best interests of Common Lisp and Scheme simply because the sense of X3J13 so far has been that it is standardizing only Common Lisp, not other Lisp-like languages. I think this attitude is widely and strongly held. It would be a mistake to change it. Whether X3's standardization process is less democratic than the IEEE's is moot. X3J13 is totally inappropriate for standardizing Scheme, and, if X3 were to decide that Scheme is covered by the Common Lisp umbrella, then X3 would be inappropriate. The remaining proposals are to continue standardizing informally or to act through IEEE. My sentiments are to keep things informal. Certainly Will is correct when he says "the definition of Scheme is already cleaner than the definition of Common Lisp will be when X3J13 finishes with it." Despite sentiment, I'm now inclined to move quickly to standardize a slightly cleaned up R3RS through IEEE auspices if that will help bring Scheme out from under the shadow of Common Lisp (and X3J13). --db--  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 3 Feb 88 15:36:08 EST Received: by iuvax.cs.indiana.edu; id AA28733; Wed, 3 Feb 88 15:33:41 EST Date: Wed, 3 Feb 88 15:33:41 EST From: Chris Haynes Message-Id: <8802032033.AA28733@iuvax.cs.indiana.edu> To: rrrs-authors@mc.lcs.mit.edu Subject: [camp@mips.csc.ti.com: [RPG@SAIL.Stanford.EDU: Proposal to Handle All Possible Decisions on Scheme Standardization ]] Clyde tried to send this to our notesfile, but it didn't work, so here it is again. Date: Tue, 26 Jan 88 16:40:13 CST From: Clyde Camp To: chaynes@iuvax.cs.indiana.edu, gls@THINK.COM, jar@mc.lcs.mit.edu, "hal@mc.lcs.mit.edu.gjs"@mc.lcs.mit.edu, willc%tekchips.tek.com@RELAY.CS.NET, chaynes@iuvax.cs.indiana.edu, dfried@iuvax.cs.indiana.edu Subject: [RPG@SAIL.Stanford.EDU: Proposal to Handle All Possible Decisions on Scheme Standardization ] I have invited Bob Mathis to get in touch with me, but have not at this point heard from him. I would like to if someone would send me his phone number. The IEEE is recognized by ANSI at the same level as X3. Both are standards generating entities - in fact, the IEEE is a little more so in that it can actually adapt standards which are taken by ANSI more or less as is. X3 cannot adapt standards and the documents it puts forth to ANSI (through CBEMA) must be put through an additional consensus gathering and balloting process. I believe that this is because the IEEE is volunteer and open to anyone while X3 membership requires that all members pay a service fee and as such it tends to represent companies/organizations rather than individuals. If you want Scheme to be associated with Common Lisp and held under the same umbrella, then X3 makes sense. Otherwise, I believe the IEEE is a better choice. All of the IEEE/CS's standards activities were presented to X3's SPARC committee on January 12. I was there, not Dick nor Bob. There was interest by several people as to how Scheme and Common Lisp were related, but absolutely no indication that there was a problem. Since then there has been no official or unofficial problem. This presentation to X3 is purely voluntary on the part of the IEEE in order to identify potential standardization conflicts before things get as far along as FORTH and PASCAL did. There is, I might add, no reciprocal presentation by X3 to any IEEE entity. So far, I'm the highest ranking officer in any of the organizations to discuss this with you and I've tried to be open about it once I recognized that everyone wanted to be informed. I would appreciate it if people sending out non-RRRS-AUTHORS mail on this matter would copy me so that I can address incorrect information if necessary before it becomes gospel. It is unclear to me whether Dick and Bob are speaking for X3J13 or representing their own opinions. (Not to imply that either is bad, I just don't know one way or the other.) To address Dick's itemized list: 1) This is a suprise to me. Yes, they are both lisp and have lots of closing parentheses but I don't consider them to be indistingishable at all. Whether or not they belong in two separate organizations is a separate issue. As I said in my previous message, there is something to be said for a hierarchical tree of lisp dialects under some organization. If this is indeed the desire of the RRRS-AUTHORS then so be it. But I was under the distinct impression that smushing Scheme in under common-lisp was a highly undesirable thing. 2) ANSI does recognize X3J13 as the technical working group for (a) Lisp. There is no reason, rule, law, precedent which prohibits the IEEE from starting up this effort if everyone agrees that it is the right thing to do. There is also nothing which prohibits ANSI from recognizing such an activity. X3J13 represents the status quo today, not for all future time. It certainly does not "..include dialects such as Scheme" as an absolute de facto state although without contention that is where things would probably fall. 3) If you want. I would point out that the members & organizations must pay a fee. X3 members can freely participate in IEEE workshops, but not vice versa. With respect to speed and "whether anything comes out" issues, the same applies to the IEEE. The document is ready when the working group says it is. If the working group thinks that it should be abandoned, it can be. 4) According to item #2, it's already included?!? In any case, if Scheme==Common-lisp then I'm wasting my time. 5) The only pressure the RRRS-AUTHORS have seen is pressure to START the process. This is the very thing I was trying to avoid in the first place by giving the RRRS-AUTHORS first whack at being the core of working group, thereby giving them significant control over what was going on. X3J13 has had no interest in this until now. 6) The same is true with the IEEE as with X3. The ANSI US National Committee appoints delagates to ISO and IEC. X3 and IEEE are both represented. 7) Come on now!! I do, obviously, think it would be a mistake, but as I've said before, if the RRRS-AUTHORS community wants to use X3J13 then that's the way it'll be - neither I nor the IEEE are going to engage in a "renegade .. effort for standardizing Scheme." My original goal was to get some standardization effort started and I felt (and feel) that the IEEE was better suited. But you guys are the ones doing the work and if you're not happy with that, then by all means go with X3. In all honesty, I think that the row will be much tougher to hoe. But just to clear up things, such a petition to SPARC would NOT "officially disallow" anything. Given the scenario that X3 and IEEE both feel that they have legitimate activities in the same area (meaning that there are blocks of people in both organizations who adamently feel there is reason to continue), then both organizations would carry the arguments to the ANSI Information Systems Standards Board (ISSB) to arbitrate the case if it could be settled in no other manner. (X3J13 might have to do it through SC22, but I'm not sure.) This is analogous to two kids arguing over ownership of a toy and going to daddy to settle it. Depending on the arguments, the convictions of the organizations, precedent, sizes of working groups and lots of other factors it could go either way. IEEE's "won" some, X3's "won" some. In either case, it is often common to have (as in the case of FORTH and PASCAL) some sort of joint ownership/control. 8) True. But this is happening anyway and any standardization effort will tend to promote it. 9) Not necessarily true although there is some merit to this. Again, the question is how closely do you guys want Scheme to be tied to Common Lisp.  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 3 Feb 88 09:25:33 EST From: ramsdell%linus@mitre-bedford.ARPA Posted-From: The MITRE Corp., Bedford, MA Received: from darwin.sun.uucp by linus.research (3.2/4.7) id AA28796; Wed, 3 Feb 88 09:24:36 EST Posted-Date: Wed, 3 Feb 88 09:23:40 EST Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3) id AA02828; Wed, 3 Feb 88 09:23:40 EST Date: Wed, 3 Feb 88 09:23:40 EST Message-Id: <8802031423.AA02828@darwin.sun.uucp> To: RPG@SAIL.Stanford.EDU Cc: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: Dick Gabriel's message of 30 Jan 88 1738 PST <8801311332.AA04320@mitre-bedford.ARPA> Subject: Bizarre Story Dick writes: >... The Common Lisp group tried to think of ways of trademarking ``Lisp'' >or ``Common Lisp'' but we are way, way too late. Can we trademark the name ``Scheme''? I do not think it is too late for that. -------------------------- On the subject of confusing Scheme with Common Lisp, I follow the practice of never mentioning Lisp while talking about Scheme unless the person I am talking to asks about Scheme's relation to Lisp. This practice avoids the AI baggage, as well as any negative impressions the person has of Lisp. Of course, disowning our connection to Lisp would be like disowning one's parents, but I see no need to tie our fortunes to Lisp's. Thus I strongly oppose the idea of expanding X3J13 to cover both Lisp and Scheme. If we choose to standardize Scheme, let's do it independently of efforts to standardize other dialects of Lisp. John  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 3 Feb 88 08:56:07 EST From: ramsdell%linus@mitre-bedford.ARPA Posted-From: The MITRE Corp., Bedford, MA Received: from darwin.sun.uucp by linus.research (3.2/4.7) id AA27955; Wed, 3 Feb 88 08:55:30 EST Posted-Date: Wed, 3 Feb 88 08:54:33 EST Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3) id AA02798; Wed, 3 Feb 88 08:54:33 EST Date: Wed, 3 Feb 88 08:54:33 EST Message-Id: <8802031354.AA02798@darwin.sun.uucp> To: rrrs-authors@mc.lcs.mit.edu In-Reply-To: Hal Abelson's message of Sat, 30 Jan 88 09:45:47 est <8801301445.AA04589@zohar> Subject: "Well, Stanley,here's another nice mess you've gotten us into." In Hal's message, he suggested a meeting be devoted to the issue of Scheme standardization. I volunteer to host such a meeting at The MITRE Corporation. MITRE is located about twenty miles northwest of Boston and has the facilities to host such a meeting. John  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 3 Feb 88 07:44:45 EST From: ramsdell%linus@mitre-bedford.ARPA Posted-From: The MITRE Corp., Bedford, MA Received: from darwin.sun.uucp by linus.research (3.2/4.7) id AA12353; Tue, 2 Feb 88 09:13:42 EST Posted-Date: Tue, 2 Feb 88 09:13:00 EST Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3) id AA01745; Tue, 2 Feb 88 09:13:00 EST Date: Tue, 2 Feb 88 09:13:00 EST Message-Id: <8802021413.AA01745@darwin.sun.uucp> To: rrrs-authors@mc.lcs.mit.edu Subject: [jap%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK: Scheme standardization] I ask Julian Padget what he thought about Scheme standardization. I thought his views would be interesting because of his work with EuLisp. Here is his response. John Posted-Date: Mon, 1 Feb 88 22:23:13 GMT To: ramsdell <@mbunix.arpa:ramsdell@linus> Cc: jap%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK In-Reply-To: ramsdell's message of Mon, 1 Feb 88 15:14:15 EST Subject: Scheme standardization Date: Mon, 1 Feb 88 22:23:13 GMT From: jap%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK Sender: jap%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK I only heard today some rumour about Scheme standardisation (although it does ring faint bells from something I heard a little while ago). Who proposed it and what was their motive? I am not enthusiastic about Scheme being standardised - you might think that reaction is because it conflicts with the work I get associated with (i.e. EuLisp). That is not so, although whether there is room for an ANSI Lisp standard, an ISO Lisp standard and another ANSI Lisp standard (given that Scheme is a dialect of Lisp), all conflicting, is highly questionable. It also reflects badly on ANSI's judgement if it is prepared to condsider this since it would then be promoting the standardisation of dialects which is contrary to the notional remit of a standards organisation. My main reason for not being in favour of standardising Scheme is that I have learnt a lot about the standards circus in the last few years, the kind of people that get involved in standardisation and what (standards) committees do to programming languages. I realise I am pointing recriminating finger at myself too - in my defence I say that I did not know what I was getting into...such is the naivete of youth! Anyway, that would be a sad fate for a language that has been so carefully thought out and refined (a few minor warts remain). I presume you mean tail not tale regarding ISO Lisp vs. ANSI Common Lisp, but I am not sure about the versus part. What has Dick been saying? Off to another EuLisp meeting tomorrow, back next Monday (short holiday too). --Julian.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 3 Feb 88 00:00:23 EST Date: 02 Feb 88 2059 PST From: Dick Gabriel Subject: Scheme Standardization To: rrrs-authors@MC.LCS.MIT.EDU Because I made my suggestion with the intent of providing another alternative for the Scheme community, I want to argue neither for nor against it. I wish to clarify 2 factual errors Will made in his message: 1. Individuals belong to X3J13. Companies can belong and send some number of representatives. All members vote as they wish, but many individuals vote their company line for whatever reasons, possibly because they have been told to do so. I vote as I wish, but I won't guarantee that my sense of greed will not figure into my vote. I don't believe IEEE does things any differently. 2. I never mentioned any such activity as ``Common Lisp 2000'' or the ``next Common Lisp'' to Will (we talked on the phone for an hour or so). I mentioned that my own goal was to see the Common Lisp community and the Scheme community working on the next rendition of Lisp. I explicitly mentioned that there were few positive lessons from Common Lisp for such a new language - the key contributions were negative (don't do this, don't do that). I mentioned as the primary set of positive lessons the experience that Common Lisp implementors had with programming environments. I suppose it might be natural for one who believes that association with Common Lisp is the ``worst possible thing for Scheme'' to not wish to associate with people involved with Common Lisp, but I see many of the Common Lisp folks shaking their heads and wondering how such a weird and depressing experience as Common Lisp standardization could have been foisted on them. But, alas, such a dreamer am I to wish for co-operation. -rpg-  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 2 Feb 88 21:08:43 EST Received: from relay2.cs.net by RELAY.CS.NET id ai04566; 2 Feb 88 19:06 EST Received: from tektronix.tek.com by RELAY.CS.NET id cl05041; 2 Feb 88 18:53 EST Received: by tektronix.TEK.COM (5.51/6.24) id AA08886; Tue, 2 Feb 88 15:10:23 PST Received: by tekchips.CRL.TEK.COM (5.51/6.24) id AA28377; Tue, 2 Feb 88 15:10:05 PST Message-Id: <8802022310.AA28377@tekchips.CRL.TEK.COM> To: rrrs-authors@mc.lcs.mit.edu Cc: RPG@SAIL.STANFORD.EDU, willc%tekchips.crl.tek.com@RELAY.CS.NET, adams%tekchips.crl.tek.com@RELAY.CS.NET Subject: Re: ISO vs ANSI vs IEEE vs X3 vs The Sons of Hercules Date: 02 Feb 88 15:10:03 PST (Tue) From: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET I believe that the formation of a Scheme standardization project within X3J13 is the worst thing that could possibly happen to Scheme. Gabriel observes, correctly, that most people confuse Scheme with Common Lisp and vice versa. Placing the responsibility for Scheme with the committee whose charter is to standardize Common Lisp could only increase this particular confusion, while an entirely separate standardization activity for Scheme would help to relieve the confusion. Gabriel has suggested, correctly, that having Scheme standardization under X3J13 would make it more convenient for technical experts from the Common Lisp community to take part in the standardization of Scheme. But it would also force technical experts from the Scheme community to suffer the tedium of X3J13 meetings concerning a language that many of them care nothing about, if they want any say in the future of Scheme. Furthermore they would have to pay $200 annually in dues and $1000-$2000 in travel expenses for the privilege. X3J13 is a committee formed for the purpose of standardizing Common Lisp, not Scheme or any other dialect of Lisp. It is a committee of institutions, not individuals. Though I have attended every X3J13 meeting, I will not be eligible to vote at the next meeting in Palo Alto; Tektronix's representative will vote, though he will be attending for the first time. Representatives have made no bones about voting the financial interests of their companies. Gabriel himself has on several occasions noted that although he personally favors certain technical positions, he would have to vote the contrary position in order to protect his company. (While only a few of the companies that make up X3J13 have financial reasons for hostility to Scheme, as few or fewer have reasons to be friendly.) It is not surprising that X3J13 has found it difficult to make technical progress in such a climate, so the leading technical experts have essentially given up on all substantive changes (except possibly for CLOS) and are concentrating their efforts on the cleanup and clarification committee, ably led by Larry Masinter. The definition of Scheme is already cleaner than the definition of Common Lisp will be when X3J13 finishes with it. What Scheme needs is some serious language design work, which is precisely the sort of thing that X3J13 has been unable to do for Common Lisp. I believe the root of my disagreement with Gabriel is this: It sounds to me like Gabriel thinks the Scheme community should get together with the Common Lisp community and design the next iteration of Common Lisp (which Fahlman calls Common Lisp 2000) *rather than* going off and designing the next iteration of Scheme. There's nothing wrong with working on Common Lisp 2000, but I think Scheme is more important because Scheme still has a shot at becoming a good language and I don't think Common Lisp does. Why doesn't it? Because most of the serious flaws in Common Lisp are attempts to maintain compatibility with old-fashioned dialects of Lisp. If the designers of Common Lisp were unable to resist the demands of compatibility when in truth very little Lisp code of lasting importance had been written in all of human history, then how do they expect to resist demands that Common Lisp 2000 be compatible with Common Lisp? Better to start over. Scheme is one of the best places to start. That's why I want to preserve it as a distinct entity, not submit it to the whims of X3J13. Concerning ISO, it is certainly true that the charter for ISO Lisp would lead it to supersede all dialects of Lisp. Scheme will be able to escape this only because of the fortunate historical accident that its name does not include the word "Lisp", and because a significant number of people (particularly Europeans) already claim that Scheme is not Lisp. It also is true that the Scheme community will probably have no say in the deliberations that lead to the ISO Lisp standard, since there is no formal standardization effort for Scheme. Gabriel's story of how all this came to be is accurate. He loses me, though, when he says that Many observers (Mathis and myself included) believe that if ANSI is asked to recognize Scheme as a different language from Common Lisp, they will not do so, but ask that X3J13 broaden its charter. If X3J13 really wanted to be helpful, it could easily pass a resolution requesting that ANSI recognize a separate standardization activity for Scheme, and allow the Scheme community to be represented at the ISO level as well. (In my opinion, such a resolution would not be useful unless the Scheme community had already initiated standardization through IEEE or X3 (but not X3J13).) In my opinion, ANSI would probably listen to such a resolution coming from X3J13. Even if ANSI did not, X3J13 could refuse to act on its broadened charter, leaving the Scheme community free to continue its informal efforts. In fact, however, it is possible that ANSI (if we initiate standardization through IEEE) or X3 (if through X3) would *insist* upon a separate standardization activity for Scheme, even if X3J13 were to recommend *against* such recognition. It is not unusual for one language standardization group to claim that another is redundant. I have been told that in the process of adjudicating such claims the standards organizations usually get around to asking the users and implementors of the allegedly redundant language what they think, and they occasionally listen to the answer. I'm not saying this is likely, but I believe there is good reason to be optimistic so long as X3J13 is supportive or remains neutral. Even if all goes against us, we can continue our work by simply ignoring the whole matter of standards (which is what we have done so far) and we probably would not get into a situation much worse than the one the Lisp world is already in, through no fault of ours. Peace, William Clinger Semantic Microsystems, Inc.  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 1 Feb 88 20:52:45 EST Received: from relay2.cs.net by RELAY.CS.NET id ab00539; 1 Feb 88 19:16 EST Received: from csc.ti.com by RELAY.CS.NET id an27391; 1 Feb 88 19:00 EST Received: from mips by tilde id AA14226; Mon, 1 Feb 88 17:24:59 CST Received: by mips id AA00414; Mon, 1 Feb 88 17:20:19 CST Date: Mon, 1 Feb 88 17:20:19 CST From: David Bartley Message-Id: <8802012320.AA00414@mips> To: rrrs-authors@mc.lcs.mit.edu Subject: re: Next R*RS metting... I expect to attend the Lisp conference this summer, so I would favor the option of meeting there for R*RS discussions. If we do, let's arrange to tack a day onto the front or back of the conference schedule so we can allow ourselves enough time to do something worthwhile. Hal has suggested that we meet concerning the standardization issue much sooner than that. Where should that meeting be? X3J13 will be meeting in Palo Alto March 14-18, so I would expect that I, Will, rpg, and perhaps Kent Pitman and others could talk things over then.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 30 Jan 88 20:39:22 EST Date: 30 Jan 88 1738 PST From: Dick Gabriel Subject: Bizarre Story To: rrrs-authors@MC.LCS.MIT.EDU Yes, it is quite bizarre, but you get to read about it while I get to live it. The Common Lisp group tried to think of ways of trademarking ``Lisp'' or ``Common Lisp'' but we are way, way too late. The only point to my story is that X3J13 can provide a safe haven from Scheme getting involved in its own mess with standardization, strange as that suggestion might sound. Essentially we can expand X3J13 to cover Lisp/Scheme, form a subcommittee, and forget that subcommittee ever existed (unless you want to standardize, in which case you can make your own schedule). This would protect you from IEEE, and you can forget about the politics. If you don't do this, someone can start an IEEE group without your consent and press ahead in a haphazard way. Maybe you'll be able to stall or whatever with IEEE, but I can guarantee you can stall forever with X3J13. Hey, I want to save Scheme from all of this mess, and this looks like the best way to me. -rpg-  Received: from murren (TCP 2206400263) by MC.LCS.MIT.EDU 30 Jan 88 18:16:02 EST Received: by MURREN.AI.MIT.EDU; Sat, 30 Jan 88 18:21:16 est Date: Sat, 30 Jan 88 18:21:16 est From: hal@MURREN.AI.MIT.EDU (Hal Abelson) Message-Id: <8801302321.AA05218@murren> To: RPG@SAIL.Stanford.EDU Cc: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: Dick Gabriel's message of 30 Jan 88 1445 PST <8801302300.AA05207@murren> Subject: ISO vs. ANSII vs. IEEE vs. X3 vs. The Sons of Hercules Reply-To: hal@ai.ai.mit.edu Your story about Lisp standardization is truly bizarre. It does not make me very receptive the idea of embroiling Scheme in such a mess. Do you think it is too late for MIT to trademark the name "LISP" and thus put an end to all of this nonsense?  Received: from SAIL.Stanford.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 30 Jan 88 17:46:59 EST Date: 30 Jan 88 1445 PST From: Dick Gabriel Subject: Clarifications To: rrrs-authors@MC.LCS.MIT.EDU My wording on this point is not good: 2. ANSI recognizes X3J13 as the technical working group for Lisp in the US. Therefore, an IEEE effort would have no standing or voice in any ISO work relating to Lisp, which is regarded as including dialects such as Scheme. Let me try again. The charter for X3J13 specifically talks about Common Lisp. I will explain below why that phrasing is used and how well the strategy behind that phrasing is working. ISO has established a Working Group for ISO Lisp. I will explain below why that phrasing is used and how well the strategy behind that phrasing is working. ISO has asked the US to participate in the ISO Lisp work, which means ANSI was asked. ANSI in turn asked X3J13 whether it would participate - because such participation was mentioned in the X3J13 charter - and X3J13 said it would. Therefore all representatives to the ISO Lisp Working Group must be X3J13 members. The reason X3J13 talks about Common Lisp is because the members of X3J13 do not want to see a Lisp standard - they want to see Lisp be able to continue to grow without the fetters of standardization. In particular, they do not want to hamper the Scheme efforts. The pressure in the US that drives X3J13 is to standardize Common Lisp, and the strategy is to work on a specific dialect of Lisp to avoid the issue of standardizing Lisp as a whole. In particular, X3J13 wanted to block an ISO standard Lisp. Hence one could conclude that Scheme is free to do what it wants. The reason ISO talks about Lisp is because the European community does not like Common Lisp and wants to see the right thing become a standard. Unfortunately from how things have turned out, they want to see a Scheme-like dialect standardized. Therefore they have slanted things to include Scheme as far as ISO is concerned, and thus ANSI will probably view X3J13 as necessarily encompassing the Scheme community. The history is that the ISO effort started in response to activities towards starting X3J13. X3J13 was not actually formed when the ISO efforts started, so X3J13 tried to calm down the ISO effort by writing ``Common Lisp'' into its charter. The funny (or sad) situation is that each of the groups behind the ISO effort and the X3J13 effort will point to the other group as the reason they started their own standardization efforts! However, the ISO effort went ahead, and the linkage at ANSI between ISO Lisp and ANSI Common Lisp was made. Many observers (Mathis and myself included) believe that if ANSI is asked to recognize Scheme as a different language from Common Lisp, they will not do so, but ask that X3J13 broaden its charter. ISO will talk only to ANSI about Lisp, so an IEEE Scheme effort will not have an official influence on the ISO work, and therefore X3J13 is probably the only vehicle for ISO-level Scheme work. Now, the situation has gotten a lot more complicated than what I just painted. The situation I painted is that the US through X3J13 wants to limit standardization to Common Lisp and specifically under that name. The delegation to ISO from the US has as the first item on its agenda a request to limit the scope of the ISO effort and to try to change the name of the ISO effort from ISO Lisp to something else, possibly ISO Common Lisp. However, I fear that the seeds have been planted at ISO - as they were accidentally at ANSI - in such a way that Common Lisp is not distinguishable from Lisp, and that the attempted change will not work (due to ISO reluctance). Meanwhile, a group of Europeans who had previously argued against Common Lisp have now concluded that the pressing issue is time-to-draft, and that therefore a cleaned-up Common Lisp is the only possibility, due to manufacturer pressure. So we might face the situation of the European delegation asking that ISO Lisp be Common Lisp while ISO refuses to change the charter for the working group. If this situation were to prevail, we would have ISO Lisp be Common Lisp. To prevent that, my response (as head of the US delegation) would be to state the US position as being against Common Lisp as ISO Lisp, and to propose a family of Lisp dialects, starting with an ISO Common Lisp dialect and followed by a better standard for ISO Lisp later. In this case, the Scheme community would have to be brought in - in my opinion - and that can only happen through X3J13. The best situation would be for ANSI to have ANSI Common Lisp and for there not to be an ISO standard, but because the wheels are turning at ISO, this cannot happen. The next best thing is there to be an ISO Common Lisp, leaving open indefinitely the possibility of an ISO Lisp. If there must be an ISO Lisp on the horizon, I believe there ought to be an ANSI Common Lisp right away and a re-designed ISO Lisp in some years. There is a fair amount of sympathy for an immediate ANSI Common Lisp followed by a re-designed Lisp in some years among the X3J13 group. If this were to come to pass, interaction with the Scheme community is imperative. Therefore there is ample opportunity for there to be an ISO Lisp that is not Common Lisp, and I believe the community of people who truly wish ISO Lisp to be Common Lisp is small. I hope this clarifies as best as can be done the rather bizarre Lisp standardization situation. The first ISO Lisp meeting is February 24 or so in Paris, and we ought to know more about things when we return. As you may know, I asked Will Clinger to join me in hopes of making something good of the situation, so you will get his report. -rpg-  Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 30 Jan 88 14:39:40 EST Received: by ZOHAR.AI.MIT.EDU; Sat, 30 Jan 88 14:41:46 est Date: Sat, 30 Jan 88 14:41:46 est From: hal@ZOHAR.AI.MIT.EDU (Hal Abelson) Message-Id: <8801301941.AA04743@zohar> To: rpg@sail.stanford.edu Cc: rrrs-authors@mc.lcs.mit.edu Subject: questions about X3 and Scheme Reply-To: hal@ai.ai.mit.edu In your message about Scheme standardization, you wrote 2. ANSI recognizes X3J13 as the technical working group for Lisp in the US. Therefore, an IEEE effort would have no standing or voice in any ISO work relating to Lisp, which is regarded as including dialects such as Scheme. Could you elaborate on what this means? In particular, (a) Who regards the X3 effort as including dialects such as Scheme? (b) Does your comment imply that there could not be an ISO standard for any Lisp dialect other than for Common Lisp?  Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 30 Jan 88 14:32:00 EST Received: by ZOHAR.AI.MIT.EDU; Sat, 30 Jan 88 14:34:37 est Date: Sat, 30 Jan 88 14:34:37 est From: hal@ZOHAR.AI.MIT.EDU (Hal Abelson) Message-Id: <8801301934.AA04740@zohar> To: rrrs-authors@mc.lcs.mit.edu Subject: forwarded message from Dick Gabriel Reply-To: hal@ai.ai.mit.edu This is a message about Scheme standardization that was mailed to a new people a few days ago. I think it needs to be mroe widely seen. Please send comments to all RRRS-AUTHORS -- Hal From RPG@SAIL.Stanford.EDU Sat Jan 30 14:32:10 1988 Date: 30 Jan 88 1034 PST From: Dick Gabriel Subject: Proposal to Handle All Possible Decisions on Scheme Standardization To: hal@AI.AI.MIT.EDU Gentlemen. I have talked with Bob Mathis regarding the standardization of Scheme, and he and I agreed on the following remarks and suggestions. 1. To the outside world, Lisp and Scheme are not distinguishable. To have separate technical working groups for them is not a sensible situation, especially within 2 separate organizations. 2. ANSI recognizes X3J13 as the technical working group for Lisp in the US. Therefore, an IEEE effort would have no standing or voice in any ISO work relating to Lisp, which is regarded as including dialects such as Scheme. We understand that there is some anxiety about whether to standardize Scheme, and if so on what schedule. We are in a position to suggest several alternatives to you: 3. We can establish a subcommittee within X3J13 for Scheme under the current X3J13 charter. That subcommittee can work at its own speed on activities relating to Scheme. Whether that subcommittee ever reported anything out would be up to it. 4. We can also broaden the charter of X3J13 to specifically include Scheme. A committee or subcommittee on Scheme could be established with its own time schedule. This would accomplish several things for you: 5. You would have a vehicle for standardizing Scheme if and when you choose. There would be no pressure regarding your decision on this matter. That is, this can be a vehicle to prevent standardization without your consent, and it can also be a vehicle for standardization when you feel like it is appropriate. 6. You would have a voice and standing within any ISO process concerning Lisp in which you were interested. 7. Any renegade IEEE efforts towards standardizing Scheme would be officially disallowed through a petition from SPARC to IEEE. 8. The Common Lisp community could be exposed to the Scheme community and vice versa, bringing benefits to both communities. 9. A rational approach within ISO towards Lisp could be more easily achieved if the Scheme community was officially represented. We would not be in a position of the US appearing to be completely Common-Lisp-oriented. I sent this note to a smaller group than RRRS Authors in order to keep the discussion among the leaders. Please feel free to distribute this to people whom I have overlooked. In order for Bob Mathis and me to file the petition from SPARC to IEEE, a positive response from the Scheme community is needed. If you decide for or against this proposal, please let us know. -rpg-  Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 30 Jan 88 09:43:09 EST Received: by ZOHAR.AI.MIT.EDU; Sat, 30 Jan 88 09:45:47 est Date: Sat, 30 Jan 88 09:45:47 est From: hal@ZOHAR.AI.MIT.EDU (Hal Abelson) Message-Id: <8801301445.AA04589@zohar> To: rrrs-authors@mc.lcs.mit.edu Subject: "Well, Stanley,here's another nice mess you've gotten us into." Reply-To: hal@ai.ai.mit.edu Over the past two months there have been a number of discussions, on and off of this mailing list, concerning a proposed Scheme standardization effort. Clyde Camp has proposed standardizing Scheme through IEEE, but there is apparently some sentiment for a closer connection with Common Lisp and X3, and there is also sentiment for not standardizing Scheme at all. Many RRRS-AUTHORS (including me) have not contributed to this discussion, presumably because we were confused/bored/indifferent. I think that it's time for a real discussion to start. 1. People who have something to say about this issue should mail their comments to all of RRRS-AUTHORS. Outrageous flammage is welcome, as always. My main concern is that if (and I do mean IF) a standardization process is to begin, then it should begin with a proposal that is made on behalf of the RRRS-AUTHORS as a group. 2. I think we should have a meeting sometime during the next two months, whose agenda is to discuss the standardization issue and to produce a plan for standardization, if that is the decision of the group. Given the political nature of this discussion, it is unlikely that any technical work is going to get done, so this meeting should be in addition to a technical meeting that would take place later, presumably in conjunction with the Lisp conference in July. Some issues to be discussed: Do we want to endorse a Scheme standardization process? What is the appropriate standards organization? Who is going to do the work? Would anyone like to volunteer to host the meeting?  Received: from murren (TCP 2206400263) by MC.LCS.MIT.EDU 30 Jan 88 08:53:33 EST Received: by MURREN.AI.MIT.EDU; Sat, 30 Jan 88 08:59:15 est Date: Sat, 30 Jan 88 08:59:15 est From: hal@MURREN.AI.MIT.EDU (Hal Abelson) Message-Id: <8801301359.AA04713@murren> To: rrrs-authors@mc.lcs.mit.edu Subject: testing, please ignore Reply-To: hal@ai.ai.mit.edu  Received: from G.BBN.COM (TCP 1000400022) by MC.LCS.MIT.EDU 28 Jan 88 19:32:40 EST Date: 28 Jan 1988 19:31-EST Sender: SUSSMAN@G.BBN.COM Subject: Some RRRS comments/corrections From: SUSSMAN@G.BBN.COM To: rrrs-authors@MC.LCS.MIT.EDU Cc: allen@SOCRATES.BBN.COM, quigley@SOCRATES.BBN.COM Cc: sas@BFLY-VAX.BBN.COM, amellor@BFLY-VAX.BBN.COM Cc: sussman@G.BBN.COM Message-ID: <[G.BBN.COM]28-Jan-88 19:31:32.SUSSMAN> Here are a few things we noticed while documenting Butterfly Scheme: CI in string and character procedure names: You describe it as a suffix, and give its relationship to the ? suffix. But it is generally embedded earlier in the name (not ...ci?). You probably want to just say they have CI in their names. DO: The expressions after the are optional according to the text, but the template shows one or more expressions. Apparently it is the template that is wrong. TRUNCATE: The description is incomplete -- note that it fails to specify the sign of the answer. Julie  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 25 Jan 88 03:39:48 EST Received: from relay2.cs.net by RELAY.CS.NET id aa07222; 25 Jan 88 3:39 EST Received: from brandeis by csnet-relay.csnet id ab03817; 25 Jan 88 3:27 EST Received: by brandeis.ARPA (5.51/4.7) id AA00620; Sun, 24 Jan 88 16:52:15 EST Date: Sun, 24 Jan 88 16:52:15 EST From: James Miller To: dyb%iuvax.cs.indiana.edu@RELAY.CS.NET Cc: rrrs-authors%mc.lcs.mit.edu@RELAY.CS.NET In-Reply-To: "R. Kent Dybvig"'s message of Sat, 23 Jan 88 15:07:16 EST <8801232007.AA11432@iuvax.cs.indiana.edu> Subject: Next R*RS meeting... I'd prefer that the meeting coincide with the Lisp conference if possible. --Jim  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 23 Jan 88 15:09:19 EST Received: by iuvax.cs.indiana.edu; id AA11432; Sat, 23 Jan 88 15:07:16 EST Date: Sat, 23 Jan 88 15:07:16 EST From: R. Kent Dybvig Message-Id: <8801232007.AA11432@iuvax.cs.indiana.edu> To: rrrs-authors@mc.lcs.mit.edu Subject: Next R*RS meeting... At the last Scheme meeting (Boston, Summer 87) I volunteered to organize the next Scheme meeting, to be held at Indiana sometime this spring. I would still be pleased to do so, if people think it would be a good idea, but we might want to consider getting together at the Lisp conference this summer instead and perhaps holding the Indiana meeting next spring. I think this was suggested last summer, but I remember someone expressing concern that people may not be able to make the Lisp conference, since at that time it was expected to be overseas. Comments? Kent PS. I'm hoping this is an issue we can reach a decision on!