Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 6 Jan 88 22:12:48 EST Date: Wed, 6 Jan 88 22:08:39 EST From: Jonathan A Rees Subject: who contributes? To: camp%mips.csc.ti.com@RELAY.CS.NET cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Wed 6 Jan 88 12:36:22 CST from Clyde Camp Message-ID: <307797.880106.JAR@AI.AI.MIT.EDU> Date: Wed, 6 Jan 88 12:36:22 CST From: Clyde Camp How many read or have access to RRRS-AUTHORS vs how many actually contribute? I was sort of curious about this. I count 22 individuals directly on the mailing list, plus four redistributions: OZ - 14 people HP-SCHEME - I have no idea; I'll guess 4 Indiana - ditto; guess 7 TI - ditto; guess 7 That makes about 54 people, if I add correctly. Probably a conservative estimate. 43 people (plus one program and one stuffed animal) have contributed to the 825 messages. 20 people have contributed 7 or more messages each. These 20 people account for 95% of the messages. (Counting messages is a crude measure, but it's all I have the energy to do.) As I expected, I am the most embarrassed, with Bill Rozas and Will Clinger 2nd and 3rd. Jonathan Rees 191 (192 with this message) Bill Rozas 84 Will Clinger 70 David Bartley 64 John Ramsdell 60 Kent Dybvig 55 Chris Hanson 55 Guy Steele 30 Kent Pitman 24 Gerald Jay Sussman 21 Mitchell Wand 20 Chris Haynes 17 Andy Cromarty 15 Dan Friedman 13 Andy Freeman 12 Bert Halstead 11 Norman Adams 10 George Carrette 8 Paul Hudak 7 Alan Bawden 7 Perry Wagle 6 Gary Brooks 5 Don Oxley 4 Charlotte Mooers 4 Matthias Felleisen 3 Ken Haase 3 Hal Abelson 3 Warren Harris 2 Myrna Fox 2 Henry Wu 2 Eugene Kohlbecker 2 David Brown 2 Steve Vegdahl 1 Robert Hieb 1 Richard Kelsey 1 Richard Fateman 1 Oliver Laumann 1 Morris Katz 1 Mark Meyer 1 Larry Masinter 1 Jay Leech 1 Clyde Camp 1 Arthur Altman 1 COMSAT 1 Tigger 1  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 6 Jan 88 14:12:56 EST Received: from relay2.cs.net by RELAY.CS.NET id aa28365; 6 Jan 88 14:11 EST Received: from csc.ti.com by RELAY.CS.NET id ai21643; 6 Jan 88 13:58 EST Received: from mips by tilde id AA15625; Wed, 6 Jan 88 12:36:27 CST Received: by mips id AA17672; Wed, 6 Jan 88 12:36:22 CST Date: Wed, 6 Jan 88 12:36:22 CST From: Clyde Camp Message-Id: <8801061836.AA17672@mips> To: rrrs-authors@mc.lcs.mit.edu Subject: Scheme Standardization ======================================================================== = IT IS MUCH MORE DIFFICULT TO GIVE BIRTH TO SOMETHING THAN TO KILL IT = ======================================================================== I've watched the RRRS-AUTHORS mail for the last couple of weeks with interest and feel it is time to respond to the issues raised on standardization and clear up a few apparent misconceptions. For those of you who do not know me, my name is Clyde Camp and I work for the Computer Science Center of Texas Instruments. I've been involved in standards work both inside TI and outside for about 15 years. I'm also the chair of the Microprocessor Standards Committee (MSC), having been vice-chair for a year and secretary for three years preceding that. Before I go any further, let me point out that in any discipline there are always horror stories of things gone wrong or difficulties encountered. The standards world is no different and the few horror stories are widely circulated while the many successes go largely un-noticed by all except those directly involved. It is also interesting to note that, historically, the more severe problems have been due to hesitation or waiting too long to do something rather than starting things too quickly. One of the major reasons for the various committees is to isolate the technical work of the working group members from most of the "hassle" of the standardization process itself. Only the chair NEED worry about that (although anyone else who is really interested is welcome to attend anything.) The rest of this is broken into three parts: 1) A history of the Scheme standard proposal mentioned by Chris Haynes. 2) A response to the replies he had received as of January 4th. 3) A set of recommendations which the readers should consider. (transmitted separately) In the interests of time I have not attempted to explain the sequential steps involved in standardization, except as they directly apply. The process is rather well outlined in a pair of articles by Dr. Michael Smolin in the August-87 issue of IEEE MICRO (pages 82-83) and in the October-87 issue (pp 92-94). If any of you wish to contact me directly, I can be reached at (214) 995-0407 (beware the answering machine) or at camp%TI-CSL@CSNET-RELAY. ***HISTORY*** The current attempt to bring about a Scheme standard was originally initiated by me about the middle of last year and was based on the following: 1) Scheme is an ideal language for general symbolic processing 2) It is significantly better suited for embedded applications and small systems than Common Lisp 3) It is an ideal educational/instructional language 4) There were at least three commercial implementations (all mostly alike, but with significant differences) 5) There seemed to be a growing ground swell of users who liked the language (brought about in no small part by the Abelson/Sussman 'Bible') 6) There was already a group in existence who had generated a working 'specification' for the language, who represented a reasonable mix of theorists, users and implementors and who were eminently qualified. This existing 'specification' is already better than some existing standards. 7) I didn't want to see the Common Lisp standardization mess (due in a large part to waiting too long before starting) repeated with Scheme. I wanted it to be a pro-active standard rather than a retro-active one. 8) I felt that the IEEE/CS was the best way to get such a standard developed. My personal belief is that Scheme stands a very good chance of being the symbolic and arithmetic language-of-choice in the long-term (5-10 years). But I don't believe that it can be so without at least partially leaving its current academic environment and finding a sponsoring organization such as the IEEE or ACM - there will be too many external pressures (user, industry, government). At that time I sent Jonathan Rees, David Bartley and a few others a short message on the pros/cons of standardization and suggested that the topic be brought up at the June-1987 RRRS meeting. Based on David's report back to me that it had been raised and quickly dismissed, I took the easy path of not pursuing the issue any further (and have even lost the text of the message I sent.) In early December, 1987, Jim Flournoy (with the Computer Society Standards Activity Board) independently recognized that it might be an appropriate time to begin a Scheme standardization effort. He called me and asked for names of people who I thought might be willing to chair such an activity. I opened up the RRRS red-book and gave him the names of the people who were foolish enough to have their names printed on the first page. When he reported back that Chris Haynes and Will Clinger had agreed to consider being chair and secretary respectively, I called both back in mid-December and, after several long discussions, conned them into considering positions of chair and vice-chair instead. Will and Chris then began polling the Scheme community for Interest, Disinterest, Non interest. The jury is still out. Without going into all the gory details, we tried to get things lined up to have Chris or Will present at the January MSC meeting (or me pitch their presentation). The January meeting was important because it was the day before the annual ANSI Standards Project Authorization Review Committee (SPARC) meeting. It would have been ideal if this could have been worked out since SPARC is the committee which reviews submissions to ANSI by X3 and IEEE. For various reasons, this time frame turned out to be too short for everybody to get their act together, so I would like to try for the the next MSC meeting in March or the one in May. One of the primary reasons for pushing on this is to get a head start on all the administrative time lags built into the process. For those of you who are by this time thinking "All that crap is the reason I didn't want to get involved with the damn standards activity to begin with" the good news is that none of the above should affect what the working group is doing or when it meets. One of the major reasons for the various committees is to isolate the technical work of the working group (WG) members from most of the administrative process of the standardization business itself. Only the chair NEED worry about that although anyone else who is really interested is welcome to attend anything. ***** RESPONSE **** CHRIS HAYNES: A excellent (balanced) summary. There is little I can add other than to correct a few minor points (which may have been due to a mis-communication on my part to begin with). With respect to working group attendance and 'voting' rights, there are NO formal procedural requirements at the working group level. The WG Chair is pretty much free to run things the way he wants. Although there are some informal guidelines that will be recommended, the CS Policies and Procedures manual states merely that the chair of the working group is responsible for developing the document. Again, the reason for this is to keep the working group as free from the administrative details as it wishes to be. There are no requirements for meeting frequency or place or attendance for example. While the Chair is required to be a CS or IEEE member, there is no such requirement on any of the other WG members. As Chris pointed out, trial-use standards are reviewed every two years and recommended for full use, withdrawal or revision. Full-use standards come up for review every five years for reconfirmation, withdrawal or revision. So a 'STANDARD' is not cast in concrete for all time. The extensive use of E-mail net to development a standard is a new (to the MSC) methodology, but one which I encourage. Although non-net interested parties must also be accommodated, the Chair can probably handle this is by keeping a mailing list of those entities and sending them hard copies of the net traffic at periodic intervals or as necessary. The IEEE secretariat can be used to take care of reproduction and mailing if necessary (all she needs is one copy and a mailing list) but we have a limited budget and prefer that the WG work this out if possible. DICK GABRIEL: (1-3) There are some tough arguments and questions here but many of them are between basic philosophical issues which are akin to arguing the advantages/disadvantages of big-endian vs. little-endian. Dick's comments about splitting up (or not) Scheme and Common Lisp were interesting because I've wondered as well about the possibility of a family of symbolic processing languages. The scope of something like this is scary and the initial reaction is probably "No way, Jose - Impossible". But those of you who think pulling together (apparently) radically different things under one umbrella is an impossible task should talk to Maurice Graube who chairs the 802 networking standard (a success story if ever there was one.) I fully agree with Dick's statement that the work gets done by small groups which are self motivated but disagree with his conclusion that nothing will change other than for the worse. A properly run standards working group does help motivation, discipline and visibility - it happens more often than not. Common Lisp is, unfortunately, an example of 'not'. (4-6) The answer to all three of these is basically "It's possible, but only if you let it." I think it's far less likely that any of these fears will be realized if the RRRS cadre is in the driver's seat. A scenario that bothers me more is "company X" pushing its implementation of Scheme as THE correct and only implementation. (7 - the first one) RPG is right except for the last paragraph, which again is my fault. With exception of the actual working groups, voting rights at each committee level are xxxx + "appointment by the chair with concurrance of the next higher chair" where xxxx is formally specified in the CS Policies and Procedures manual. The working groups have no such restrictions and although the recommendation is that some generally uniform policy be maintained, it is always the Chair's perogative to issue voting rights (for example to individuals who can't personally attend for some reason but who are obviously valuable contributors) or to remove them (for example to allow company-X only one vote to prevent it from sending 300 people to swing the standard to meet its product) or to not vote at all and develop the specification by some other means of consensus. With respect to lawsuits, the IEEE provides protection to the WG from such things to some extent. While such an issue has never come up and the degree or capability to which the IEEE would defend such a suit is unknown, members are certainly better protected than a non-sponsored group. (7 - the right thing?) Perhaps this effort? RAMSDELL: ========= These are largely tactical decisions which can be made if and when a WG is formed. Again, standards can be added to. The current RRRS approach of essential vs non-essential may be entirely appropriate. Similar things have been done on hardware standards. I think I would advise against trying to include parallelism at this stage. ALAN BAWDEN: ============ I don't believe in the "First Strike" theory either, although I do wonder why it keeps happening. Seriously, it has happened but while the possibility exists, I suspect that in this particular case the scheme community is sufficiently close-knit that it would be aware of such an effort and might be able to insert the red-book as a proposed draft even if it should occur. It is always easier and more efficient to start with something which is at least partially acceptable than to start all over from scratch - if for no other reason than the job of physically entering the text. CHRIS HANSON: =============== What?!?!?!? I'm one of those "IEEE people" you refer to (as are four of the 17 RRRS authors) and I will certainly take issue with anyone who tells me I have no committment to the language. It's BECAUSE I have a committment to the language that I'm taking the effort to try and get this effort going. If you have legitimate arguments on either side then voice them by all means, but please do so without rancor. KENT PITMAN: ============ I hope the previous megawords clear up some of your confusion with regard to who is doing what and why. You are somewhat right in your belief that the larger a group becomes, the less useful work it can do. I say somewhat because it depends on the absolute size - I'll contend that three can do more than one but certainly 20 can do more than 200. However, as I've said before, the entire standards organization is not involved here - only those that are in your working group. Even this could become large although only a few do "useful work". Using the MSC itself as an example, the mailing list is about 200, however only 30 or so are what I would call participating. The rest are there primarily for info although they may inject comments (sometimes even useful ones!) now and then. It may help to think about it like CS-NET. How many read or have access to RRRS-AUTHORS vs how many actually contribute? Ceasing design work to initiate a standard is not a requirement. If it were, there would be far fewer standards around. It is entirely possible to be in 100% compliance with a standard and yet extend it provided the extensions don't alter things you've done before. The goal of a standard is most definitely NOT to "maximize the number of people to whom it appeals at the cost of its values" although where to draaw the line is often difficult to decide. =================== My recommendations on where to proceed from here are being transmitted in a separate message. REgards, Clyde  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 5 Jan 88 18:30:50 EST Received: by iuvax.cs.indiana.edu; id AA26238; Tue, 5 Jan 88 16:35:05 EST Date: Tue, 5 Jan 88 16:35:05 EST From: Chris Haynes Message-Id: <8801052135.AA26238@iuvax.cs.indiana.edu> To: rrrs-authors@mc.lcs.mit.edu Subject: standardization More time is needed for discussion, so the formation of a Scheme standardization working group will NOT be proposed at the MSC meeting this month. We should continue the debate what would be a good time to start a standardization effort and how it would be best to proceed. Historically, it seems that every language that obtains a reasonably large user community is eventually standardized (usually over the objections of its designers and implementers). Since the Scheme community is growing rather rapidly, it is just a matter of time before some part of the user community initiates standardization. So the question is WHEN, not WHETHER, it would be best to untertake standardization. Perhaps there are sound technical reasons for a substantial delay (say a year or more). If so, I would like to hear them. However, my impression from last summer's meeting is that almost all of what we have now is relatively stable, and the new features we would like to consider adding (macros, modules, etc.) are all very much in the design stage. It will likely take at least a year (probably two or more) to refine these proposals and get them widely implemented, and another year of experience with them before we can be sure we like them. Only then (2 or 3 years hence) would it seem likely that major new features should be candidates for standardization. I believe the advantages of moving relatively soon to standardize approximately what we have now outweigh the disadvantages of waiting that long. Admittedly this judgment is based on weighing the importance of a number of nontechnical considerations. Thus it is impossible for me to be sure this is right, much less make a definitive argument in its favor. In this respect especially, we need feedback from all segments of the Scheme community (not just its designers and implementers). It is vital that standardization not impede the development of new features and improved implementations, but I do not see why it should (other than taking the time of some individuals who would be involved in both). Again, if anyone has technical grounds for casting reasonable doubt on this judgment, please speak up. I'm leaving town again for a couple of weeks. I'll respond to many of the comments received thus far when I return. Regards, Chris Haynes  Received: from Riverside.SCRC.Symbolics.COM (TCP 20024224425) by MC.LCS.MIT.EDU 28 Dec 87 14:09:25 EST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 213984; Mon 28-Dec-87 14:07:47 EST Date: Mon, 28 Dec 87 14:07 EST From: Kent M Pitman Subject: My vote against standardization To: RRRS-Authors@MC.LCS.MIT.EDU cc: KMP@STONY-BROOK.SCRC.Symbolics.COM References: <8712280614.AA27983@kleph>, <871227170521.7.ALAN@PIGPEN.AI.MIT.EDU>, The message of 22 Dec 87 12:56 EST from Dick Gabriel Message-ID: <871228140737.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I think a Scheme standardization process at this time would be an extraordinarily bad idea. I think that a time will come when, as RPG suggests, it will be appropriate to offer the ideas of Scheme as a gift to the community to stand on their own, but I do not think this is the time. I was not clear on whether this standardization process was generated by one of our members. If this move toward standardization is externally generated, I suggest that the RRRS-Authors should make a formal statement to IEEE asking them not to make the standard. If the move was internally generated or if there was any prior groundwork done by any of our members without involving the others, then I take great personal offense at our not having been informed. It is my strong belief that the larger the group becomes, the less useful work it can do. We have useful work yet to do with Scheme. It is questionable whether we can do it with a group the size that we have now. It is nearly certain that we cannot do it with a group the size of a standards organization. It is also nearly certain that the organizational structure of a standards committee is not appropriate for design work. Design is a creative process and it cannot generally be achieved by an enforced democratic process. For a time it is still appropriate to be exclusive, anti-social, etc. (one of the options RPG suggested we might take). I believe that for a time it is still appropriate to weigh certain people's opinions more than others (even if for friendship's sake we don't always come out and say whose or why). Entrance into standardization should be clearly accompanied by an agreement to cease all design work. If we think that any further substantive change to the language is in order (macros, eval, optional arguments, ...), we're inviting disaster. CL has shown that one compromise leads to another, and that in the end we may have something that locally appeases many stated gripes, but that globally is a hodgepodge. There is no reason that we can't make Scheme into a language which has greater appeal. But achieving that requires some interesting design work to be done, not the bureaucracy of a standards committee. And anyway, I'm content to have Scheme be a language which does not appeal to everyone -- as long as there is a community which recognizes its value. I'm not content to have Scheme be a language whose goal in life is to maximize the number of people to whom it appeals at the cost of its values. I am willing to risk that IEEE (or anyone else) might still try to make a Scheme standard without our consent. I assume they have the legal right to make such a standard with or without our cooperation, but I think we should give them the benefit of the doubt and assume they are honorable folks who would respect our wishes. There is no shame in being proven wrong on this point.  Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 28 Dec 87 01:13:54 EST Received: by KLEPH.AI.MIT.EDU; Mon, 28 Dec 87 01:14:15 est Date: Mon, 28 Dec 87 01:14:15 est From: cph@KLEPH.AI.MIT.EDU (Chris Hanson) Message-Id: <8712280614.AA27983@kleph> To: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: Alan Bawden's message of Sun, 27 Dec 87 17:05 EST <871227170521.7.ALAN@PIGPEN.AI.MIT.EDU> Subject: A vote against standardization Reply-To: cph@mc.lcs.mit.edu Date: Sun, 27 Dec 87 17:05 EST From: Alan Bawden Here is my vote against official standardization. Let me add my voice to those of Alan and John. I think it is premature to form an explicit standard. I also feel that the drive for standardization should be undertaken by us when we have some kind of concensus that it is a desirable thing, not because of pressure from external parties who have little or no commitment to the language (I would place the IEEE people in this category).  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 DEC 87 17:04:56 EST Received: from PIGPEN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 27 Dec 87 17:04-EST Date: Sun, 27 Dec 87 17:05 EST From: Alan Bawden Subject: A vote against standardization To: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: <8712241446.AA01711@darwin.sun.uucp>, The message of 22 Dec 87 12:56 EST from Dick Gabriel , The message of 19 Dec 87 15:54 EST from Chris Haynes Message-ID: <871227170521.7.ALAN@PIGPEN.AI.MIT.EDU> Here is my vote against official standardization. I will limit myself to briefly remarking on the dangers of the "First Strike" theory of programming language standardization: If the good guys (us) don't get together and make a standard, then the bad guys (them) will do it and screw up. Therefore (even though we don't really want the hassle of standards bureaucracy) we had better do it first. This argument attempts to encourage a stampede by playing to everybody's insecurities about losing control of the language. It is dangerous to place too much weight on this argument, because you can find yourself saddled with a standards process that in fact -nobody- really wanted (not even the people you perceive of as the "bad guys"). If a critical mass of the Scheme community decides that it will participate in an official standards committee, then there will be a standard, no matter what the rest of us might think. But I hope that if that happens, the members of that critical mass will have decided to participate on the basis of arguments -other- than the First Strike theory.  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 24 Dec 87 09:51:47 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 AA02009; Thu, 24 Dec 87 09:50:13 EST Posted-Date: Thu, 24 Dec 87 09:46:55 EST Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3) id AA01711; Thu, 24 Dec 87 09:46:55 EST Date: Thu, 24 Dec 87 09:46:55 EST Message-Id: <8712241446.AA01711@darwin.sun.uucp> To: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: Dick Gabriel's message of 22 Dec 87 0956 PST <8712222018.AA08060@mitre-bedford.ARPA> Subject: A vote against standardization I must agree with a few of Dick's comments, especially those pertaining to the question of timing. It seems to me too early to standardize Scheme, a language destined to go through big changes. 1) Currently, there is no conforming macro facility, nor an official description of the correct one. 2) The situation with EVAL is not settled (I favor Rees's EVAL-IN-R3RS). 3) I would not like to see us get into the same mess Common Lisp got into over object-oriented programming. We should standardize after there is some consensus on what to do on that subject. I am eagarly awaiting Adam's and Clinger's suggestion. 4) We have no support for the development of large systems. I think this is an area that the Scheme community could greatly advance. Dick's interview in UNIX Review points out the limitation of Common Lisp. Let's standardize after we have something to say about large systems. 5) Parallelism? Maybe we should break ground? John  Received: from SAIL.Stanford.EDU (TCP 4425400302) by MC.LCS.MIT.EDU 22 Dec 87 15:13:41 EST Date: 22 Dec 87 0956 PST From: Dick Gabriel Subject: Some Remarks on Standardization (by someone who has been there) To: rrrs-authors@MC.LCS.MIT.EDU Ladies and Gentlemen: I have heard from my friend Will Clinger and read in a message from Chris Haynes that the Scheme group is considering pursuing an IEEE standard for Scheme. I made some remarks to Will about this by phone, but I would like to address them to the group as a whole. Let me say at the outset that I do not have any deep feelings about the matter, though I cannot guarantee that I won't present strong arguments on one side or the other in this message. The rest of this message largely follows the outline of Chris Haynes's (Strunk and White) message: 1) Is a Standard Necessary? Chris Haynes points out that some businesses and educators would adopt Scheme if it were a standard language. The Europeans believe this is true for Lisp in Europe. I do not believe it is true in the US. The problem with adoption of Scheme and Lisp in the US by industry is that they are too closely associated with AI, that it is difficult or impossible to have Scheme/Lisp-written code be linkable into an executable image along with other code, and that the speed of code is unacceptable. I think each of these can be attacked, I think that solving the second reduces the importance of the third, and that none of this has to do with standarization. Like it or not, Scheme is a dialect of Lisp. And right now Common Lisp is regarded as the only Lisp worth considering. Now as you may know, I am not a huge supporter of Common Lisp as a language - note my Critique paper with Rod Brooks and my attempt with Will Clinger to push for a cleaner language (in fact Scheme) at the ISO level (which attempt has not yet failed); note also my recent interview with Unix Review. On the other hand, I am a supporter of Common Lisp as a tool for legitimizing Lisp and for getting a decent standard for Lisp. The strategy I use is that standarization is a two step process: first you convince people there ought to be a standard; second, you convince them that if there is to be a standard, it ought to be a good one. Common Lisp as a defacto standard achieves the first of these. I was trying, with Will's help, to achieve the second. Splitting up Common Lisp from Scheme has some desirable and some undesirable effects. A desirable effect is that this sends the message that Scheme is so unlike Common Lisp that if you had doubts about Common Lisp because of weird features, Scheme don't have 'em. An undesirable effect is that the people you hope to convince of Scheme - industry - don't see Common Lisp and Scheme as very different at all: maybe one is smaller than the other. In the old days, one excuse I heard about why people didn't use Lisp was that the ``Lisp community cannot get it together,'' by which was meant that the various quarters could not agree on a single Lisp. An ANSI Common Lisp and an IEEE Scheme reinforces that. I would not want to rule out the possibility of an ANSI Scheme as a standard within the Lisp family, including Common Lisp. I don't believe that an IEEE standard will increase the visibility of Scheme significantly. Remember, there are ANSI and IEEE standards for all sorts of bizarre languages (and I don't mean ADA). These remain as anonymous to everyone I know as they were before they were standardized. Finally, standarization is the reward for a successful language, not a tool for making it so. Some argue that standardizing Lisp will save the language from sinking back into academia, but I doubt this. I believe Lisp has to fit into the rest of the world better. C is being standardized because everyone uses it, and so with Common Lisp. 2) Will Standardization Help Motivation and Discipline? This is somewhat of a fairy tale. What has happened with Common Lisp is that many people who used to do the work have ducked new work because they believe that the next guy should feel motivated to do the work. When push comes to shove, the work gets done in informal groups who are self-motivated, which is the current situation with Scheme - nothing will change other than for the worse. 3) Will a Standard Improve Portability? You can choose to have a non-validatable language (ISO prohibits this, I think). You can also choose to leave some things up to implementations. The standard doesn't necessarily improve things. *********************************************************************** The arguments against standardization and the remarks Chris makes about them are more interesting than the arguments for standardization. 4) Will a Standard Increase the Likelihood of Difficult Implementation? Do you expect difficult-to-implement features will be added? What are some possibilities? Or do you expect that increased pressure to conform will require implementors to implement already-standard but difficult-to-implement features? If these features are elegant and the right thing, why give implementability and efficiency the upper hand (or any hand)? And if implementability and efficiency begin to reign, what else will they bring into the language? 5) Will Unnecessary and Flawed Features Creep In? If Scheme currently includes only necessary features, then necessity is based on judgement. If unnecessary but convenient features will be left out, then there is some reason to desire an official library. Such a library requires funding to achieve and maintain - Common Lisp failed completely to do this although it was an explicit goal. The issue of technically flawed features raises the largest issue in my mind. Throughout the Common Lisp and CLOS efforts we employed Moon's Maxim: Do Not Standardize on Research. Standardization is codifying and specifying existing, proven practice with minor cleanup. If you follow this, you will not include any technically flawed features, only technically retarded ones. Here is a case in point: If you standardize Scheme in the next year or two, that standard cannot include any macro facility. This is because a PhD thesis on the topic has just been published, and no implementation of the latest, most final ideas has been in use for long enough. The Common Lisp macro facility is mightily flawed, but it codifies 20 years of practice, and its flaws are well-known. This situation is very much more desirable than casting as a standard something you just thought of. 6) Will Research Stop? Well, I don't know. The personal motivation for research does not stop, but the funding for that research might stop. This has happened to the Common Lisp community. Until this year, there was funding aplenty for Lisp research from DARPA; now it's all gone. We standardized ourselves out of our jobs. Note that successful standards are revised every 5 - 10 years. 7) Will the Wrong Folks Move In? I have to admit that the commentary on this topic reminded me of the most despicable days of the Common Lisp effort, and it actually makes me a bit sad. The desire to define a standard and the need to be a small group in control are inconsistent. If you feel strongly about achieving both, you will accomplish a situation you will regret for a long time. When you choose to make a standard for a language, you are saying that you have something that the community at large uses and wants to continue to use; this is an act of generosity and public spirit. When you turn around and state that these very people towards whom you have shown this concern should be excluded, you are saying that these people are incapable or evil; this is an act of arrogance and insensitivity. Silly as it might sound, this will come back to haunt you just as it came back to haunt the Common Lisp folks. There really was a Quinquevirate, a gang of five, who controlled Common Lisp for the last year of its definition and who tried to control the first year of standards discussion just prior to X3J13 forming. We actively tried to exclude people from our inner circle. The rational basis was that we were the founding fathers and knew the motivations for the decisions. But like the Constitution, the interpretation of what we did fell from our hands and should have fallen from our hands. The only fact that eases my own conscience is that some people of impeccable character participated along with me. Nevertheless, I'm ashamed of that period. If you want to exclude the wrong people, remain informal and self-selected. If you want to standardize, welcome outsiders - this is what you want, right? You want converts, so don't insult them. If you want your ideas to prevail, then they must prevail because they are good ideas and because you have exerted technical leadership. All standards organizations impose a form of democracy on the process. Imagine that your worst enemies are Chairman and Vice Chairman. Do you fear that your ideas and your ability to lead the community at large (who will vote) are not strong enough to prevail? If you do, then do not start the process. Also note, your rules for voting rights exclude Steele and me. I doubt IEEE would allow it. Some of the Quinquevirate were threatened with lawsuits. Don't do it. 7) What's the Right Thing? Here's a sad story. It's the story that is forcing Will Clinger out of the ISO process. You all know that the EuLisp community was pushing for a more Scheme-like language as an ISO standard. One reason they felt this was is that the Common Lisp community excluded them early on. However, the forces at large have caused Common Lisp to prevail to such an extent that the EuLisp community seems to be backing down and is ready to work with Common Lisp. I had hoped, along with Will, that we could have worked with them to bring a better standard to the international community. I think that the only way to do this, now, is for the Scheme and Common Lisp communities to work together more closely somehow. As you think about this statement, keep in mind that many members of the Common Lisp world wished something more like Scheme had been adopted. Well, enough of this. The war for Lisp is not on the standards battelfield anymore, anyway. -rpg-  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 19 Dec 87 15:55:20 EST Date: Sat, 19 Dec 87 15:54:15 est From: Chris Haynes To: rrrs-authors@mc.lcs.mit.edu Subject: Scheme Standard The Microprocessor Standards Committee (MSC) of the IEEE Computer Society is proposing formation of a working group for the purpose of developing an IEEE Scheme standard. Some of the merits of such a move follow: PRO: (1) An official standard will demonstrate the LEGITIMACY of Scheme in the eyes of many. I expect this will frequently make the difference in decisions by businesses and educators to adopt Scheme. (2) It will increase Scheme's VISIBILITY. Word of standards travels in many quarters where Scheme is hardly known. (3) It will add MOTIVATION and DISCIPLINE to efforts at refining Scheme. The last Scheme meeting we had indicated some need for more discipline, and perhaps the lack of activity in this newsgroup of late indicates need for more motivation. (4) It will improve code portability (and publication uniformity). The force of this point is reduced greatly by the existing Report, which satisfies much of this need. CON: (5) Changes could be made that would be unreasonably expensive for existing Scheme implementations to incorporate. (6) Unnecessary and technically flawed features could be added. (7) The specification could make Scheme rigid, cutting off experimentation and research. (8) Participants would be forced to cope with administrative hassles and the time and monetary costs of travel to meetings. The PROs speak for themselves, though comments that expand or reinforce them are welcome. Let me address the CONs. I believe (5) and (6) are the most serious concerns. They express fear that the authors of the existing Report, who have been very conservative in these respects, will "lose control" of the standardization process. The best strategy for avoiding this is to act promptly. By acting now, I believe the Report authors and others of like mind will prevail both in voting numbers and administrative matters. If we delay, others will almost certainly initiate the standardization process (and thereby assume administrative control). Also, the longer we wait the larger the Scheme community becomes. An increasing number of converts to Scheme are apt to be defectors from Common Lisp who want something simpler, but are also attached to all sorts of things that we'd rather not see in Scheme. Many of these folks will be from industry, with travel money and agendas that will bring them to standards meetings. Working group attendance is open to the public. Voting rights are based on attendance at recent meetings, using a formula determined by the Chair and acceptable to the MSC. A reasonable formula would give voting rights initially to attendees of the previous Scheme Report meetings and exclude others at their first meeting, and perhaps also their second. Official standardization may contribute a bit to the rigidity of a language, but I believe this contribution will be much less than is feared by some. Standards are typically revised every two years or so, at least for the first few revisions, and it is certainly possible to reverse earlier decisions. The best known standards are for the best known languages, and the standards process for these languages reflects the inertia already present as a result of long tradition. A standard inevitably costs time and money, but I believe this can be kept to tolerable levels. Though active working groups typically meet about four times a year, by continuing our tradition of extensive discussions on the net it should be possible to reduce this number to two per year. In balance, I feel the advantages of a standard clearly outweigh the disadvantages, at least if we act reasonably soon so it does not get out of control. The MSC will consider the formation of a Scheme standardization working group at its meeting on January 7th. I am being considered for Chair, with Will Clinger for Vice-Chair. I have no "hidden agenda". In the first year or so I would like to see the working group endeavor to ratify approximately what we already have in the R3RALS, with some clarifications and improvements that were intended for a R4RALS in the same time frame. Standardization is a means to consolidate and gain recognition for progress that has been made. It draws upon and facilitates (rather than precludes) progress by less institutionalized groups. Comments are welcome. -- Chris Haynes  Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 9 Dec 87 12:08:19 EST Received: by KLEPH.AI.MIT.EDU; Wed, 9 Dec 87 12:08:55 est Date: Wed, 9 Dec 87 12:08:55 est From: cph@KLEPH.AI.MIT.EDU (Chris Hanson) Message-Id: <8712091708.AA13269@kleph> To: JAR@AI.AI.MIT.EDU Cc: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: Jonathan A Rees's message of Tue, 8 Dec 87 19:23:30 EST <296594.871208.JAR@AI.AI.MIT.EDU> Subject: data structures <--> functions Reply-To: cph@mc.lcs.mit.edu Date: Tue, 8 Dec 87 19:23:30 EST From: Jonathan A Rees Date: Sun, 6 Dec 87 01:51:10 est From: gjs at ZOHAR.AI.MIT.EDU (Gerald Jay Sussman) To: JAR at AI.AI.MIT.EDU Re: data structures <--> functions I really feel the need for EVAL (or ENCLOSE) quite seriously. As I recall, the original problem with EVAL was just the decision about whether or not there would be a second argument. We were unable to come to concensus because there was no compatible way to solve the problem without using optional arguments, which no one wanted to do. Since everyone has EVAL, it seems silly to be tied up on this one point. Maybe we should adopt a different procedure, perhaps called STANDARD-EVAL or GLOBAL-EVAL, which took just one argument. This would be identical to EVAL on systems without first-class environments, and would supply a default environment on the others.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 8 Dec 87 19:19:14 EST Date: Tue, 8 Dec 87 19:23:30 EST From: Jonathan A Rees Subject: data structures <--> functions To: gjs@ZOHAR.AI.MIT.EDU cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Sun 6 Dec 87 01:51:10 est from gjs at ZOHAR.AI.MIT.EDU (Gerald Jay Sussman) Message-ID: <296594.871208.JAR@AI.AI.MIT.EDU> Date: Sun, 6 Dec 87 01:51:10 est From: gjs at ZOHAR.AI.MIT.EDU (Gerald Jay Sussman) To: JAR at AI.AI.MIT.EDU Re: data structures <--> functions I really feel the need for EVAL (or ENCLOSE) quite seriously. In particular I find the need to execute code that my programs write. I wish this would be somehow solved. How about if we put a meta-circular evaluator into the scheme library that only knows about the standard R^3RS global variables? Then if you wanted to evaluate (+ (EXPT 2 23) 7), you could do (LOAD "scheme-library/eval") ;or whatever (EVAL-IN-R^3RS-ENV '(+ (EXPT 2 23) 7)) Then, although particular implementations could choose to do "efficient" implementations of this library routine, the beast is implementable in R^3 Scheme, so no one could complain about its semantics or any threat to change the language definition itself. The only problem is, what if the expression E has free variables (e.g. FOO) that are defined in the current environment, but not in the R^3RS global environment? Well, if FOO isn't going to be assigned, how about ((EVAL-IN-R^3RS-ENV '(LAMBDA (FOO ...) E)) FOO ...) or, if it is going to be assigned, something more complicated, like ((EVAL-IN-R^3RS-ENV '(LAMBDA (GET-FOO SET-FOO! ...) E')) (LAMBDA () FOO) (LAMBDA (VAL) (SET! FOO VAL)) ...) where E' = E with (GET-FOO) substituted for FOO and SET-FOO! substituted for SET! FOO. Or, another entry point to the interpreter could be created that would do substitutions of this kind automagically. I think this would serve moderately well. I'd be happy to submit such a package to the library (name and arguments negotiable) if there's interest. This could at least hold us until we can come to agreement over something that would give real level-crossing access to environments.  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 24 Nov 87 13:19:44 EST Date: Tue, 24 Nov 87 13:14:07 est From: R. Kent Dybvig To: cph%kleph.ai.mit.edu@RELAY.CS.NET Subject: Re: [net%TUB.BITNET: Questions] Cc: rrrs-authors@mc.lcs.mit.edu From: Chris Hanson To: net%TUB.BITNET@MITVMA.MIT.EDU Cc: rrrs-authors@mc.lcs.mit.edu Subject: [net%TUB.BITNET: Questions] Date: Mon, 23 Nov 87 19:28:38 +0100 From: Oliver Laumann I'll answer your second question and leave the first for someone else. 2) What is the exact difference between (write-char ) and (display )? "write-char" seems to be redundant. Is "display" supposed to terminate its output by a space or newline or something like this? Second, `display' is a generic operation, in the sense that it will print any object. It recursively prints compound structures, treating any imbedded strings and characters specially. Because of this, it is a moderately expensive operation to perform, since it potentially will have to do quite a bit of work. On the other hand, `write-char' is a very simple operation, in fact the simplest output operation (all of the other output procedures could be defined in terms of it). Because of this it can be very efficiently implemented. There is a more important reason related to the fact that "display" is a generic operation. Character objects are not guaranteed to be distinct from other objects, although they are in some implementations. So, for example, it is possible to represent them as a range of integers or as unit-length strings. Since display will always choose to print integers as integers and strings as strings, the procedure "write-char" is needed to force a character so represented to be treated as a character.  Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 24 Nov 87 07:18:00 EST Received: by KLEPH.AI.MIT.EDU; Mon, 23 Nov 87 21:53:31 est Date: Mon, 23 Nov 87 21:53:31 est From: cph@KLEPH.AI.MIT.EDU (Chris Hanson) Message-Id: <8711240253.AA21474@kleph> To: net%TUB.BITNET@MITVMA.MIT.EDU Cc: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: Jonathan A Rees's message of Mon, 23 Nov 87 20:40:07 EST <290382.871123.JAR@AI.AI.MIT.EDU> Subject: [net%TUB.BITNET: Questions] Reply-To: cph@mc.lcs.mit.edu Date: Mon, 23 Nov 87 19:28:38 +0100 From: Oliver Laumann I'll answer your second question and leave the first for someone else. 2) What is the exact difference between (write-char ) and (display )? "write-char" seems to be redundant. Is "display" supposed to terminate its output by a space or newline or something like this? There are two reasons for this. First is the historical development of the standard. Originally, when `display' was defined, its action on characters was defined to be the same as `write'. So at that time `write-char' was not redundant. Later `display' was changed to treat characters specially, creating the redundancy. Second, `display' is a generic operation, in the sense that it will print any object. It recursively prints compound structures, treating any imbedded strings and characters specially. Because of this, it is a moderately expensive operation to perform, since it potentially will have to do quite a bit of work. On the other hand, `write-char' is a very simple operation, in fact the simplest output operation (all of the other output procedures could be defined in terms of it). Because of this it can be very efficiently implemented. Finally, there is my own personal bias -- MIT Scheme has a non-standard output procedure called `write-string', which accepts a single string argument and prints it exactly as `display' would. Using `write-char', `write-string', and `write', I've found that I never need to use `display'. This is because all of the instances where I would have used `display', I actually mean `write-string', so I use the latter instead.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 Nov 87 20:41:48 EST Date: Mon, 23 Nov 87 20:40:07 EST From: Jonathan A Rees Subject: [net%TUB.BITNET: Questions] To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <290382.871123.JAR@AI.AI.MIT.EDU> Could the responsible parties please answer these questions, and post the questions and answers to the scheme mailing list? Thanks. -Jonathan Date: Mon, 23 Nov 87 19:28:38 +0100 From: Oliver Laumann To: scheme-request at mc.lcs.mit.edu Re: Questions I have two minor questions about the Revised^3 Report of Scheme. 1) The report mentions two procedures (close-input-port ) and (close-output-port ). I don't see why it is necessary to have two procedures to close ports. Wouldn't it be sufficient to have something like "close-port" that can be applied to both types of ports? 2) What is the exact difference between (write-char ) and (display )? "write-char" seems to be redundant. Is "display" supposed to terminate its output by a space or newline or something like this? I'm sorry if the answers are obvious; I'm relatively new to Scheme. -- Regards, Oliver Laumann, Technical University of Berlin, Germany. ...!pyramid!tub!net or net@TUB.BITNET  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 28 Oct 87 21:42:39 EST Date: Wed, 28 Oct 87 21:43:19 EST From: Alan Bawden Subject: CALL To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <276693.871028.ALAN@AI.AI.MIT.EDU> We could also eliminate the confusion between keywords and procedure calls by introducing a new keyword CALL, that would be used to indicate a combination: (DEFINE (FACT N) (IF (CALL < N 2) 1 (CALL * N (CALL FACT (CALL - N 1))))) To further strain your brains I recall an idea that Bill Rozas (I think) once had. He suggested that instead of putting the keyword or procedure in the CAR of an expression, we could use the CADR. Then we might have (with renamings appropriate for infix keywords): ((N FACT) IS ((N < 2) THEN 1 (N * ((N - 1) FACT)))) Seriously, as long as you can -statically- determine what identifiers are keywords, I don't see any reason to change the language.  Received: from VX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 OCT 87 21:23:40 EST Received: by VX.LCS.MIT.EDU with sendmail-4.12/4.8 id ; Wed, 28 Oct 87 20:42:45 est Date: Wed, 28 Oct 87 20:42:45 est From: Michael R. Blair To: rrrs-authors@mc Subject: RE: applicability of "syntax" mumble Why use annoying special charcters like $ or case? Why not have the special form AND and the procedure CONJUNCTION... OR DISJUNCTION... IF PREDICATION... ...and the like. Better yet, since fonts are the wave of the future, lets make italics old-english indicate ... mumble mumble Hey! Let's make syntax FIRST CLASS!! ~Ziggy  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 28 Oct 87 19:41:04 EST Received: from relay2.cs.net by RELAY.CS.NET id aa10202; 28 Oct 87 12:56 EST Received: from northeastern.edu by RELAY.CS.NET id af21255; 28 Oct 87 12:50 EST Received: from corwin.ccs.northeastern.edu by nuhub.acs.northeastern.edu; Wed, 28 Oct 87 09:37 EDT Received: by corwin.CCS.Northeastern.EDU (5.51/5.17) id AA11202; Wed, 28 Oct 87 09:25:57 EST Date: Wed, 28 Oct 87 09:25:57 EST From: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET To: dyb@iuvax.cs.indiana.edu Cc: gls@THINK.COM, rrrs-authors@mc.lcs.mit.edu In-Reply-To: "R. Kent Dybvig"'s message of Tue, 27 Oct 87 16:19:04 est Subject: applicability of "syntax" constructs How about making syntactic keywords start with the letters I through N, and identifiers start with A-H and O-Z?  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 27 Oct 87 16:21:41 EST Date: Tue, 27 Oct 87 16:19:04 est From: R. Kent Dybvig To: gls@Think.COM Subject: Re: applicability of "syntax" constructs Cc: rrrs-authors@mc.lcs.mit.edu From: gls@Think.COM Subject: applicability of "syntax" constructs Date: Tue, 27 Oct 87 11:13:10 est From: R. Kent Dybvig Instead of using $ to mark syntactic keywords, why not use the convention that keywords are capitalized (or in all-caps) and that identifiers are in lower case? BECAUSE people hate mixed case AND think it is ugly. WOULD you want TO use mixed case IN your code? --Quux :-) $really! $it is obviously better to use dollar signs. $at least $i think so. $don't you? Seriously, I do not find the following terribly ugly: (Define fumble (Lambda (x) (If (< x 0) (fumble (- x)) x))) or (DEFINE fumble (LAMBDA (x) (IF (< x 0) (- (fumble (- x))) x))) I would prefer to put keywords in bold face, but those with upper-case only terminals wouldn't be the only ones left out in the cold!  Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 27 Oct 87 15:55:44 EST Received: by GENEVA.AI.MIT.EDU; Tue, 27 Oct 87 15:57:52 est Date: Tue, 27 Oct 87 15:57:52 est From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas) Message-Id: <8710272057.AA17882@geneva> To: dyb@iuvax.cs.indiana.edu Cc: rrrs-authors@mc.lcs.mit.edu In-Reply-To: "R. Kent Dybvig"'s message of Tue, 27 Oct 87 11:13:10 est <8710272047.AA17836@geneva> Subject: applicability of "syntax" constructs Reply-To: jinx@zurich.ai.mit.edu Some implementations are case insensitive, and although the issue is mostly one of readability and convention, and should not be depended on by code, I'd hate to see some information that a program could not use (heuristically, of course) to advantage. Otherwise that would be fine.  Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 27 Oct 87 12:48:20 EST Return-Path: Received: from kali.think.com by Think.COM; Tue, 27 Oct 87 12:44:44 EST Received: by kali.think.com; Tue, 27 Oct 87 12:45:08 EST Date: Tue, 27 Oct 87 12:45:08 EST From: gls@Think.COM Message-Id: <8710271745.AA09092@kali.think.com> To: dyb@iuvax.cs.indiana.edu Cc: jinx%geneva.ai.mit.edu@relay.cs.net, rrrs-authors@mc.lcs.mit.edu In-Reply-To: R. Kent Dybvig's message of Tue, 27 Oct 87 11:13:10 est <8710271615.AA28649@Think.COM> Subject: applicability of "syntax" constructs Date: Tue, 27 Oct 87 11:13:10 est From: R. Kent Dybvig Instead of using $ to mark syntactic keywords, why not use the convention that keywords are capitalized (or in all-caps) and that identifiers are in lower case? BECAUSE people hate mixed case AND think it is ugly. WOULD you want TO use mixed case IN your code? --Quux :-)  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 27 Oct 87 11:15:34 EST Date: Tue, 27 Oct 87 11:13:10 est From: R. Kent Dybvig To: jinx%geneva.ai.mit.edu@RELAY.CS.NET Subject: Re: applicability of "syntax" constructs Cc: rrrs-authors@mc.lcs.mit.edu Instead of using $ to mark syntactic keywords, why not use the convention that keywords are capitalized (or in all-caps) and that identifiers are in lower case?  Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 26 Oct 87 17:37:57 EST Received: by GENEVA.AI.MIT.EDU; Mon, 26 Oct 87 17:26:54 est Date: Mon, 26 Oct 87 17:26:54 est From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas) Message-Id: <8710262226.AA17162@geneva> To: andy%hobbes@ads.arpa Cc: rrrs-authors@mc.lcs.mit.edu In-Reply-To: Andy Cromarty's message of Mon, 26 Oct 87 08:49:51 PST <8710261649.AA03168@hobbes.ads.arpa> Subject: applicability of "syntax" constructs Reply-To: jinx@zurich.ai.mit.edu I'd like to solicit views on the question of application of macros and their first- vs. second-class status in Scheme. ... I suspect that the subject is highly controversial, but these are my views on the matter: 1) There is a traditional pun used in Lisp. The syntax for special forms and combinations (procedure calls) is the same. This results in a a fair amount of convenience, some power, and a great deal of confusion. A perhaps wiser decision would have been to mark special forms with square brackets (or squiggly braces, or something like that), rather than the parentheses used for combinations, but the resulting language would not be a Lisp. Your problem arises from trying to view special forms as combinations (due most likely to this pun), and therefore inquiring about the status of their (nonexistent) operator. (if ) is part of the syntax of the language. IF is not a "special" operator which does something "strange". The whole expression (form) is special, and the only thing in common between it and a combination is the similarity in surface syntax. In the same way that no C programmer would think of applying "while" or "if" to arguments (let alone pass them around), no Scheme programmer should think of invoking "if", "cond", "lambda", "or", or user defined special form keywords. The keywords mean nothing by themselves, they are as good as the parentheses that surround the form, and it makes as much sense to talk about applying them as about applying parentheses, semicolons, or spaces. As far as I know, none of the major implementations of Scheme match the popular evaluation model you suggest. IF, COND, OR, etc can be viewed as part of the compiler or preprocessor, and are long gone by the time the issue of where to find X arises. In MIT Scheme, which is consistent with this philosophy, the question of whether IF is APPLICABLE?/PROCEDURE? cannot arise. IF is "nothing", and the expression (procedure? if) is in error, and in fact would cause something like Error: Unbound variable IF to be printed. A different question altogether is whether special form keywords can be valid variable identifiers, and if so, what happens in case of conflict. 2) The "unfortunate" fact of life is that Scheme is an applicative order language, and some things which could be accomplished conveniently in a normal order dialect cannot. For example, in the presence of (define (if pred conseq alt) (cond (pred conseq) (else alt))) the following expression is in error, although the intent was quite different. (let ((x 0)) (if (= x 0) 'INFINITY (/ 1 x))) To make up for this "deficiency" of the language, we "abuse" special forms, and define a special form whose KEYWORD is "if" and accomplishes the desired behavior, but is no substitute for a normal order IF procedure. Note that in your example (apply or '(#f #f #t)) the answer is clear, but what should the answer be in (let ((x 2)) (apply or (list (= x 2) (begin (write 4) (= x 3))))) There are many possibilities. The main ones are: a) 4 is never printed. This would be the case in a "normal order Scheme". If you choose this one, you've just required APPLY to be a normal order procedure, and similarly for most other high order procedures. That is a valid language decision, different from that made by Scheme's designers. While it has nicer properties than applicative order, normal order also has some problems, not the least of which is that no one (as far as I know) knows how to compile normal order languages efficiently. b) 4 is printed, and the correct "boolean" value is returned. This leads to a very ugly semantics: For consistency, you would have the following two expressions behave differently, (or (= x 2) (begin (write 4) (= x 3))) ((begin or) (= x 2) (begin (write 4) (= x 3))) which I think is worse than the original "problem". 3) Assuming that we are happy with the fact that special forms have no operators, (and therefore the notion of applying OR is confused), the problem of distinguishing special form keywords from identifiers whose values are procedures still remains. This is a matter of readability/documentation, and a simple solution is the adoption of conventions. A suggestion along these lines is to use the same sort of convention that is already informally followed for predicates (the last character of their name is ?). For example, user defined special form keywords could have $ as their first character. The built-in special forms follow no such conventions, but there are few of them, and most programmers probably remember them, so we can live with them the way they are.  Received: from ADS.ARPA (TCP 20071200430) by MC.LCS.MIT.EDU 26 Oct 87 11:53:04 EST Received: by ADS.ARPA (5.57/1.2) id AA07538; Mon, 26 Oct 87 08:52:22 PST Received: by hobbes.ads.arpa (3.2/SMI-3.2) id AA03168; Mon, 26 Oct 87 08:49:51 PST Date: Mon, 26 Oct 87 08:49:51 PST From: andy%hobbes@ADS.ARPA (Andy Cromarty) Message-Id: <8710261649.AA03168@hobbes.ads.arpa> To: rrrs-authors@mc.lcs.mit.edu Subject: applicability of "syntax" constructs Reply-To: andy%hobbes@ads.arpa [I haven't seen mail from RRRS-AUTHORS for a while; I assume this is because the list has been dormant, rather than because of a mailer problem.] I'd like to solicit views on the question of application of macros and their first- vs. second-class status in Scheme. The popular evaluation model for "syntax," as I understand it, implies that evaluation of (X a b c) will induce Scheme to look for a "syntax" definition of X before looking for a normal binding, whereas in (a X b c) the "syntax" definition of X is not sought by the evaluator and the normal binding, if any, is used. Now consider the case where, for example, "a" above is "apply". I find this troubling. (apply or '(#f #f #t)) "should work," from the perspective of the programmer. This is true for two reasons: 1. Consistent treatment of operators as viewed from the perspective of the programmer (vs. the implementor or language designer). 2. Inability to determine when objects may or may not be applied on a practical basis. Some time ago we discussed introducing APPLICABLE?; I believe this was shelved in favor of PROCEDURE?, which of course is not quite the same thing. I'm especially concerned about what happens once we define a user-accessible macro capability and let the users loose with it: in a large system, a given programmer only writes a small part of the software, but for Scheme the standard interface specification of a procedure someone else wrote no longer is adequate to tell you how to use it---you also need to know whether or not it is APPLICABLE?. Worse, in practice we learn how to use operators by looking at other people's code rather than from an interface spec (if one even exists), and even a programmer who is familiar with the principles of Dijkstra short-circuit AND/OR constructs and so forth would find nothing in looking at (or #t #f) to would indicate that (apply or '(#t #f)) would be improper. Even given the availability of some predicate that distinguishes between syntax and procedures, our code would become tortuously cluttered if we have to insert checks for APPLICABLE? throughout our programs whenever we wish to apply (what we hope is) the procedure bound to a token someone else defined. This line of reasoning seems to me to lead to a requirement for either a "smart compiler" or the implementation of macros as first-class objects, at which point we seem in essence to be talking about FEXPRS/NLAMBDAS. I've only gotten into this issue far enough for it to bother me, not far enough to see a clear design solution; perhaps others have more insight to offer. asc  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 8 Sep 87 11:31:42 EDT Posted-From: The MITRE Corp., Bedford, MA Received: from darwin.sun.uucp by linus.research (3.2/4.7) id AA24995; Tue, 8 Sep 87 09:36:14 EDT Posted-Date: Tue, 8 Sep 87 07:54:10 EDT Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3) id AA13386; Tue, 8 Sep 87 07:54:10 EDT Date: Tue, 8 Sep 87 07:54:10 EDT From: ramsdell%linus@mitre-bedford.ARPA Message-Id: <8709081154.AA13386@darwin.sun.uucp> To: rrrs-authors@mc.lcs.mit.edu Cc: ramsdell%linus@mitre-bedford.ARPA In-Reply-To: ramsdell@linus's message of Sat, 15 Aug 87 20:37:59 EDT <8708160037.AA07174@darwin.sun.uucp> Subject: Preemptive garbage collection To answer my own question, the state of the art in preemptive garbage collection algorithms seems to be the one by David Ungar, "Generation Scavenging: A Non-disruptive High Performance Storage Reclamation Algorithm" in Proc. ACM SIGSOFT/SIGPLAN SE Symp. Practical Software Development Environments, Pittsburg, PA, April 1984, pp. 157-167. I say this because at least Franz Inc is going with this garbage collector for its Sun implementation of Common Lisp and so are the SmallTalk people. Are there any Scheme implementations going with this garbage collector? John PS The last note used the confusing term "pausing GC" instead of preemptive GC.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 18 Aug 87 10:50:36 EDT Date: Tue, 18 Aug 87 10:50:12 EDT From: Jonathan A Rees Subject: Pausing garbage collection To: ramsdell%linus@MITRE-BEDFORD.ARPA cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Sat 15 Aug 87 20:37:59 EDT from ramsdell%linus at mitre-bedford.ARPA Message-ID: <243369.870818.JAR@AI.AI.MIT.EDU> The main reason T uses Clark's GC is to linearize lists and thereby reduce paging, presumably. (Also because we had just spoken to Clark before we wrote it.) I'm not sure it's otherwise a win; I think it may inspect objects objects fewer times, but the constant factor might be bad because of the way it represents its stack -- several memory references are required to chase forwarding pointers and get the next object to inspect. The usual scan/free pointer copying GC (I forget what it's called) is certainly simpler and probably just as good, especially if you have lots of physical memory. It would be nice to see some experiments comparing the two, however.  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 17 Aug 87 04:36:06 EDT Posted-From: The MITRE Corp., Bedford, MA Received: from darwin.sun.uucp by linus.research (3.2/4.7) id AA02931; Sat, 15 Aug 87 20:38:07 EDT Posted-Date: Sat, 15 Aug 87 20:37:59 EDT Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3) id AA07174; Sat, 15 Aug 87 20:37:59 EDT Date: Sat, 15 Aug 87 20:37:59 EDT From: ramsdell%linus@mitre-bedford.ARPA Message-Id: <8708160037.AA07174@darwin.sun.uucp> To: rrrs-authors@mc.lcs.mit.edu Subject: Pausing garbage collection Sorry about using this mailing list for other than what it was intended, but I think you are best qualified to answer my question. Is it true that the state of the art in pausing garbage collection algorithms is the one by Douglas Clark, "An Efficient List-Moving Algorithm Using Constant Workspace", in CACM, June 1976, Vol. 19, No. 6, pp. 352-5? I know that T uses this algorithm. John  Received: from bu-cs.BU.EDU (TCP 30003134401) by MC.LCS.MIT.EDU 16 Aug 87 20:29:21 EDT Received: from bucsf (BUCSF.BU.EDU) by bu-cs.BU.EDU (3.2/4.7) id AA01328; Fri, 14 Aug 87 16:45:50 EDT Return-Path: Received: by bucsf (4.12/4.7) id AA15933; Fri, 14 Aug 87 07:25:16 edt Date: Fri, 14 Aug 87 07:25:16 edt From: gjc@bucsf.bu.edu (George J. Carrette) Message-Id: <8708141125.AA15933@bucsf> To: scheme@mc.lcs.mit.edu, willc%tekchips.tek.com@RELAY.CS.NET Subject: Re: Gabriel benchmarks in Scheme Cc: rrrs-authors@mc.lcs.mit.edu There was a continuation passing version of tak I ran in VAX-NIL and submitted a couple years ago, called TAKF. It made it into "the book" but unfortunately was not run by many (if any) other lisp implementors. Perhaps an interesting note, on the MIT Lispmachine instruction set (CADR, LM-2, LMI-LAMBDA, TI-EXPLORER) the procedures for TAK and TAKF compile into exactly the same sequence of instructions, and TAKF is slightly faster, with one memory reference less per procedure call (no, make that two memory reference, one for the exit-vector and one for the function-cell). Needless to say, in most lisps TAKF is considerably slower than TAK. In Maclisp or Franz, with FUNCALL, quite considerably slower, although with SUBRCALL in Maclisp there is no problem.  Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 13 Aug 87 00:44:07 EDT Received: by ZOHAR.AI.MIT.EDU; Wed, 12 Aug 87 23:36:17 edt Date: Wed, 12 Aug 87 23:36:17 edt From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman) Message-Id: <8708130336.AA08981@zohar> To: willc%tekchips.tek.com@RELAY.CS.NET Cc: scheme@mc.lcs.mit.edu, rrrs-authors@mc.lcs.mit.edu In-Reply-To: willc%tekchips.tek.com@RELAY.CS.NET's message of 12 Aug 87 14:11:55 PDT (Wed) <8708122111.AA15730@tekchips.TEK.COM> Subject: Gabriel benchmarks in Scheme great.. please bring them when you come. regards to anne  Received: from renoir.Berkeley.EDU (TCP 20010101004) by MC.LCS.MIT.EDU 12 Aug 87 19:38:15 EDT Received: by renoir.Berkeley.EDU (5.58/1.25) id AA03890; Wed, 12 Aug 87 16:36:13 PDT Date: Wed, 12 Aug 87 16:36:13 PDT From: fateman@renoir.Berkeley.EDU (Richard Fateman) Message-Id: <8708122336.AA03890@renoir.Berkeley.EDU> To: scheme@mc.lcs.mit.edu, willc%tekchips.tek.com@relay.cs.net Subject: Re: Gabriel benchmarks in Scheme Cc: rrrs-authors@mc.lcs.mit.edu The guts of the FRPOLY benchmark was written by the late Prof. William A. Martin, of MIT, c. 1968. That is, before many people reading this were born, and when the Mathlab group was concerned with other issues than those we face today in programming and teaching programming. I think that the part that causes the most difficulty in understanding is in the middle of the polynomial multiplication routine. A more straightforward program, such as the one in Scheme given in Abelson/Sussman^2, can use O(n^2) rather than O(n) conses in multiplying two degree-n polynomials compared to Martin's program. I find it unfortunate that people feel they have to understand code in MacLisp in order to translate it into Scheme. Can't this be done automatically?  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 12 Aug 87 18:54:35 EDT Received: from relay2.cs.net by RELAY.CS.NET id ac01166; 12 Aug 87 18:39 EDT Received: from tektronix.tek.com by RELAY.CS.NET id aw06697; 12 Aug 87 18:28 EDT Received: by tektronix.TEK.COM (5.51/6.24) id AA19826; Wed, 12 Aug 87 14:13:49 PDT Received: by tekchips.TEK.COM (5.51/6.24) id AA15730; Wed, 12 Aug 87 14:11:57 PDT Message-Id: <8708122111.AA15730@tekchips.TEK.COM> To: scheme@mc.lcs.mit.edu Cc: rrrs-authors@mc.lcs.mit.edu Subject: Gabriel benchmarks in Scheme Date: 12 Aug 87 14:11:55 PDT (Wed) From: willc%tekchips.tek.com@RELAY.CS.NET In the most recent issue of Lisp Pointers, Walter van Roggen asked implementors to send in their most recent timings for the Gabriel benchmarks. I would like to encourage implementors of Scheme to respond to this request. I have recently finished translating the Gabriel benchmarks (except for STAK, which is a test of fluid variables, and FRPOLY, which is written "in a somewhat unpleasant programming style" that is hard to understand or translate) into Scheme. Please let me know if you would like the source code. Some of the benchmarks use property lists; I didn't try to change that, because most implementations can mimic property lists. At least one of them (BROWSE) also assumes that CAR and CDR of the empty list is the empty list; I didn't try to change that either. Otherwise the benchmarks should be reasonably portable. They have been run in MacScheme. I changed the CTAK benchmark, which tested both fluid binding and escapes, into a straight test of CALL-WITH-CURRENT-CONTINUATION. Otherwise the tests measure pretty much the same things in Scheme as they do in Common Lisp. (That's not to say I always understand what they are supposed to measure in Common Lisp.) Because the Gabriel benchmarks do not test first class procedures and do use much tail-recursion, I have added a continuation-passing version of TAK to the Scheme benchmarks. peace, William Clinger Tektronix Computer Research Lab willc%tekchips.tek.com@relay.cs.net  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 29 Jul 87 09:39:08 EDT Date: Wed, 29 Jul 87 09:41:25 EDT From: Jonathan A Rees Subject: backquote semantics To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <234576.870729.JAR@AI.AI.MIT.EDU> re-sending... Date: Mon, 27 Jul 87 15:55:40 EDT From: Jonathan A Rees Subject: backquote semantics To: stevev%tekchips.tek.com@RELAY.CS.NET cc: rrrs-authors%tekchips.tek.com@RELAY.CS.NET In-reply-to: Msg of 22 Jul 87 14:16:12 PDT (Wed) from Steve Vegdahl Message-ID: <233499.870727.JAR@AI.AI.MIT.EDU> Date: 22 Jul 87 14:16:12 PDT (Wed) From: Steve Vegdahl (define foo (lambda () '(x y z))) (define baz (lambda () `(x y z))) (define grump (lambda (k) `(x y z ,k))) Are the following expressions true, false, or implementation-dependent? 1: (eq? (foo) (foo)) 2: (eq? (baz) (baz)) 3: (eq? (grump 'w) (grump 'w)) This is definitely an ommission from the report; I don't think the issue ever got much discussion. Personally I don't much care how backquote works, although I think it would be nice if it did a minimum of consing. Other people think differently. My advice would be to assume it's implementation-dependent until the question gets discussed on this mailing list, and to see Steele's book Common Lisp: The Language for a discussion of the range of possible implementations until something better comes along.  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 23 Jul 87 03:01:09 EDT Received: from relay2.cs.net by RELAY.CS.NET id af05018; 23 Jul 87 2:51 EDT Received: from tektronix.tek.com by RELAY.CS.NET id ao19444; 23 Jul 87 2:44 EDT Received: by tektronix.TEK.COM (5.51/6.23) id AA07882; Wed, 22 Jul 87 14:17:32 PDT Received: by tekchips.TEK.COM (5.51/6.23) id AA12230; Wed, 22 Jul 87 14:16:14 PDT Message-Id: <8707222116.AA12230@tekchips.TEK.COM> To: rrrs-authors%tekchips.tek.com@RELAY.CS.NET Subject: Date: 22 Jul 87 14:16:12 PDT (Wed) From: Steve Vegdahl I have a question about Scheme about which I am unclear after reading R3RS. Consider the following procedure definitions (define foo (lambda () '(x y z))) (define baz (lambda () `(x y z))) (define grump (lambda (k) `(x y z ,k))) Are the following expressions true, false, or implementation-dependent? 1: (eq? (foo) (foo)) 2: (eq? (baz) (baz)) 3: (eq? (grump 'w) (grump 'w)) It is hard to imagine that implementation would require 1 to be false or 3 to be true. But I could imagine, for example implementations being allowed to transform: '(x y z) into (list 'x 'y 'z) thereby creating a distinct list each time the expression is evaluated. Steve Vegdahl Computer Research Lab Tektronix Labs Beaverton, Oregon  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 22 Jul 87 12:12:20 EDT Posted-From: The MITRE Corp., Bedford, MA Received: from darwin.sun.uucp by linus.research (3.2/4.7) id AA05335; Wed, 22 Jul 87 12:11:20 EDT Posted-Date: Wed, 22 Jul 87 12:10:25 EDT Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3) id AA06942; Wed, 22 Jul 87 12:10:25 EDT Date: Wed, 22 Jul 87 12:10:25 EDT From: ramsdell%linus@mitre-bedford.ARPA Message-Id: <8707221610.AA06942@darwin.sun.uucp> To: rrrs-authors@mc.lcs.mit.edu Subject: modules Thanks to Will for his fine summary of the Scheme meeting. My highest priority item for changes to Scheme is the inclusion of macros. I was quite happy when Will reported: ------------ MACROS The situation is pretty much ok. It looks like most of the work is going to have to be done by people at MIT, because that's where the largest concentration of macrologists seems to lie. ------------------- I have directed my attention to my second highest priority: modules. I decided to start by surveying modules in existing languages. I ignored COBOL, FORTRAN, Pascal, C, PL/1 (Hmm... aren't they the most used languages?), and Prolog, as those languages have little to say on the subject of modules. I looked closely at ML, Modula-2, Ada, CLU and Common Lisp. While the solutions these languages and their environments present to the problem of organizing and structuring large programs suggest many possibilities for Scheme, I in no way would like to preclude a novel approach. I've noticed three broad goals of module systems: 1. Logical separation of information -- in which information describing an interface is shared, but information describing an implementation is hidden (All). Multiple implementations of the same interface is often also sometimes goal. 2. Physical separation of information -- in which compilation of modules can proceed the compilation of the entire program with out greatly affecting the quality of code produced (ML, Modula-2, Ada). Compilations are performed with knowledge of all relevant interfaces, so that inter-module type checking can be performed, and the compiler can use the type information. Usually, the subject of precompiled libraries and recompilation control, like Unix make, are also addressed. 3. Object-oriented programming support -- in which instances of modules are *interpreted types*, wherein the data object and its operations are considered as a generalized form of type (ML, CLU). I know that some Scheme people are interested in supporting block compilation, so physical separation of information should be a goal. I'm sure all would like a module system to support logical separation of information, but I think using modules to support object-oriented programming is debatable. Of course, my characterization of the goals of modules in other systems is debatable, a debate I welcome. Common Lisp's view of logical separation consists of limiting the access of some symbols, and I suspect it can quickly be dismissed. One difference between modules in CLU and in Modula-2, ML, and Ada, is the latter languages have separate constructs that declare an interface and an implementation. This separation is strongly supported by users, and I hope a Scheme module system allow the same separation. Furthermore, ML and Ada allow parameterized implementations which are instantiated. This also seems to be a win. It seems that ML's module system is a better than Ada's as a base from which a Scheme module system may evolve. For one reason, ML shares the goal of supporting interactive program development unlike Ada. However, the following changes to Ada suggested by some Ada people here at MITRE may be useful. 1. Implementations (package bodies in Ada) should be first-class so that object-oriented programming is better supported. 2. Explicit control of what is imported should be added. This can be used to insure code remains valid even when interfaces change. 3. Multiple levels of hiding should be added. In Ada (and the other languages as well), you either have access to all an interface exports, or you have access to nothing. They want the use of an interface to determine what is exported. Then again, maybe these suggestions won't be useful. I encourage all to look at David MacQueen's article in the 1984 LISP and Functional Programming Conference called "Modules for Standard ML". John  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 15 Jul 87 15:38:14 EDT Date: Wed, 15 Jul 87 14:36:15 est From: Robert Hieb To: rrrs-authors@mc.lcs.mit.edu Subject: optional arguments From the minutes of the Scheme implementors meeting: ------------------------------------------------------------------------------- OPTIONAL ARGUMENTS We agreed to use the #!OPTIONAL syntax as in MIT Scheme. For example, (lambda (x #!optional y z . w) ...) evaluates to a procedure with one required argument, two optional arguments, and a rest argument. How do you tell if an optional argument is supplied? It is not supplied if its value satisfies the DEFAULT-OBJECT? predicate. For example, the WRITE procedure might be written (define (write x #!optional p) (let ((p (if (default-object? p) (current-output-port) p))) ...)) A feature of this approach is that the caller can pass a default object as an argument, thereby faking an unsupplied argument. This is nice when you want to supply a value for one optional argument without supplying for any other optional arguments that precede it in the argument list. We did not decide on a syntax for default objects. This may have been an oversight. You can get a default object by writing ((lambda (#!optional x) x)). ------------------------------------------------------------------------------- This optional feature seems to be useful mainly for efficiency, in that it makes it possible to avoid the allocation involved in the following: (define (write x . l) (let ([p (if (null? l) (current-output-port) (car l))]) ...)) where a list would have to be allocated for the optional port. However not much functionality is gained here, except for the error checking on the supplied argument count (the second version would swallow |(write x y z)|, while hopefully the #!opt interface would choke on it), and a somewhat more convenient access to supplied optional arguments. The price paid is a more complicated lambda-list interface, and a rather homely one at that. It is also questionable whether we want to introduce another special object, the default object. Apparently it is to be a first class object, which can be referenced and passed around. I agree that some sort of improved optional argument interface is needed if Scheme is to continue to support optional arguments to rrrs-specified procedures. A valid criticism of the present Scheme specification is that it allows optional arguments without providing a reasonable user interface. Efficiency is certainly a consideration--many users would like to be able to write procedures with optional arguments without taking a big efficiency hit (even worse is the necessity of educating users who need to be concerned about efficiency of such tradeoffs between functionality and efficiency). However the issue of usability should also be addressed. The rest-interface is most useful for procedures that take an indefinite number of arguments, and its use is strained at best when used to implement restricted optional arguments. Error checking for excess arguments is messy, and usually ignored (as in my above example). The process of determining whether an argument has been supplied, and setting up the correct binding is also tedious and not very transparent. What is needed is an interface that makes the whole process safe and transparent, and at the same time allows efficient implementation. The interface should be attractive enough that users aren't tempted to use the rest-interface unnecessarily. Of course the usability problem can be solved by macros, but as long as we are considering moving something new into the language, it makes sense to provide it at as close to desired final form as possible, so as to prevent the explosion of incompatible macro interfaces that try to provide convenient access to an excessively primitive feature. Looking at the |#!optional| proposal, it is clear that it solves the problem of error checking for excessive arguments. It also simplifies checking for the presence of supplied values and accessing those values for rebinding, since they may be accessed by name rather than by position in a list. However the actual checking and rebinding must still be explicitly carried out, and the process of rebinding is not very transparent, since it is buried inside of |let|s and |if|s. The introduction of a default value is also questionable, since its main use is to be looked at and thrown away. The burden of making sure that it does get checked and replaced is left to the user, and if he fails to handle it correctly the default value remains to slosh around and cause mysterious errors. (It could get passed along to another procedure with default arguments!) The cases where the default value is used other than by |default-object?| are probably (hopefully?) few and arcane, and thus of questionable significance. I suspect most users, and systems, would want to build some cleaner interface on top of the primitive |#!optional| one, so we should investigate such interfaces with the goal of finding one that can be supported directly by the Scheme community, keeping optional arguments simple and contained. One such optional argument interface which has useful features both in terms of efficient implementation and in terms of a useful user interface is |case-lambda|, which dispatches on the number of arguments received. For instance: (define write (rec write (case-lambda [(x p) ...] [(x) (write x (current-output-port))]))) Each branch of a |case-lambda| statement is equivalent to a similarly structured |lambda| statement, except which branch is applied depends upon how many arguments are supplied. Thus the above is semantically equivalent to: (define write (rec write (lambda l (apply (case (length l) [2 (lambda (x p) ...)] [1 (lambda (x) (write x (current-output-port)))] [else (error 'write "wrong number of arguments")]) l)))) However in practice the code can be highly optimized, and the list |l| need never be created. Since the internal |write| has lexical scoping, the call to it in the second case should be just a jump. The actual dispatching on the argument count can also optimized by the compiler, probably resulting in better performance than that provided by checks against a default value, even if the |default-object?| predicate is recognized by the compiler. So, provided that one is willing to let the compiler recognize one more special form, the performance for |case-lambda| should be excellent. |case-lambda| also provides a simple user interface. The default value problem goes away. The status and intent of procedure parameters is signaled immediately--one needn't look at the code body to determine where the real value is available and where it isn't. If an argument is visible in a piece of code, it has a 'real' value. The number of new identifiers and forms is also minimized. While the #!proposal introduces |#!optional| and |default-object?|, and probably something like |#!optional-default-object|, |case-lambda| needs only its own name, and for those who like to keep core special forms to an absolute minimum, |lambda| can clearly be defined as a special case of |case-lambda|. One argument for the naturalness of the |case-lambda| specification of procedures that take optional arguments is that it is very similar to the specification patterns used in the rrrs for procedures that accept optional arguments. It seems to be a natural way to think and write about them. Another useful feature of |case-lambda| is that it makes it simple to treat any of the arguments to a procedure as optional, not just those on the tail of the argument list. For instance if one thought the port should come first (but still be defaulted) in |write|: (define backwards-write (case-lambda [(p x) (write x p)] [(x) (write x (current-output-port))])) A more realistic example is |-|, in which it IS the first argument that is missing when only one is provided: (define - (case-lambda [(x y) (minus x y)] [(x) (minus 0 y)] [(x . l) (let loop ([total x] [rest l]) (if (null? l) total (loop (minus total (car l)) (cdr l))))])) This points out a drawback to all the optional argument interfaces presented so far--none supply a simple way to avoid the allocation involved when indefinitely many arguments are allowed. Often one ends up with the above situation, in which the list is used as a stack and never escapes, but still must be allocated. Note that the following simpler definition would be incorrect since the list is reallocated on the recursive calls to |-| in the third case: (define - (rec - (case-lambda [(x y) (minus x y)] [(x) (minus 0 y)] [(x y . l) (apply - (minus x y) l)]))) The problem is that the allocation involved in creating the lists will be quadratic in relation to the number of arguments, when the algorithm should of course be linear. (Perhaps this really points out a problem in the interaction between |apply| and the rest-interface.) Either the |#!optional| and |case-lambda| technique can be implemented with macros in systems that don't wish to provide the interface as a primitive. There is a problem in implementing the |#!optional| interace as a macro though--what is to be the special optional-default-value? Clearly it should be unique--not |eq?| to anything else in the system. However it is also desirable that no primitive type predicates other than |default-value?| answer yes to it, and it should be atomic--consequently it should not be just a unique structured object obtained by something like: (define *optional-default-value* '(*optional-default-value*)) The one feature that |#!optional| provides that |case-lambda| doesn't is the ability to sneak around the normal interface by providing the optional- default-value in the middle of an argument list--perhaps as an argument to something like (define (substring s #!optional start end) (let ([start (if (default-object? start) 0 start)] [end (if (default-object? end) (string-length s) end)]) ...) which could then be called with something like (substring some-string (default-optional-object) some-end) instead of (substring some-string 0 some-end) which of course is a straw-man argument, but I suspect it might be hard to come up with many good examples where that feature would be useful. It would almost have to be a case where one couldn't know or access the default. And of course once such an object "gets loose" it becomes tempting to use it in other similar contexts. For instance |(assq x al)| might return it if |x| isn't found, otherwise it could return the value associated with |x|-- arguably a more useful and natural interface, but as the special optional- default-value floats around it will become as useful as |#f|, and eventually as useless. Perhaps |(values)| should return it to a continuation expecting one value? It is worth considering just why |#f| isn't usable as the special optional-default-value, and wondering whether a new optional-default-value would eventually suffer a similar fate. One way to preserve the "odv" for its original intended use is to forbid its use as a value. Referencing a defaulted identifier then forces an error similar to referencing an unbound symbol. But then |default-object?| (which should then be renamed something like |supplied?|) becomes yet another special form, and the above trick goes away (as perhaps it should), and of course implementors have yet another error to trap, users have yet another error to stumble over, and the optional-interface becomes even more difficult (if not impossible) to implement correctly as a macro. Revising the |#!optional| syntax so that default values are specified overcomes most of its problems, but is still not useful as |case-lambda| in many common situations. One might have (lambda (x ... #!optional [y v] ... . z) e ...) or something similar, in which the |v|s are the default values for the optional |y|s. For instance: (define (write x #!optional [p (current-output-port)])) ...)) One new question this raises is the scoping of the |v|s--which of the identifiers in the parameter list should they be allowed to see? The simplest answer is none, but that makes it difficult to write procedures like |substring| from above, where the defaults depend on the supplied values. So perhaps they should be able to see the required arguments--or even the supplied optionals--or perhaps all the identifiers to each value's left, with a |let*| semantics... Unlike |case-lambda|, the scoping is not obvious. It is also hard to use it to define certain classes of procedures with optional arguments. For instance try using this syntax on |-|. (define - (let ([flag '(flag)]) (lambda (x #!optional [y flag] . l) (if (eq? y flag) (minus 0 x) (let loop ([total (minus x y)] [rest l]) (if (null? l) total (loop (minus total (car l)) (cdr l)))))))) is the best I can do, and I don't much care for the way it looks, nor does it look like it is going to be easy to optimize. The comparison procedures like |<| lead to equally murky results using this version of |#!optional|, but are relatively clean using |case-lambda.| In conclusion, |case-lambda| provides a pretty and simple high-level optional interface that can be efficiently implemented without further overloading of the identifier-list and without requiring the introduction of new special objects.  Received: from VX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 JUL 87 20:02:23 EDT Received: by VX.LCS.MIT.EDU (4.12/4.8) id AA22882; Sun, 12 Jul 87 20:01:55 edt Date: Sun, 12 Jul 87 20:01:55 edt From: Michael R. Blair To: rrrs-authors@mc Subject: DELAYED? predicate ...sorry, the body of my previous message was delayed. It follows: PROPOSAL FOR A NEW PREDICATE: ---------------------------- (DELAYED? ) ==> #T iff is an unforced PROMISE created via the DELAY procedure. #F otherwise RATIONALE: --------- Insofar as it is possible to create a PROMISE (using DELAY), it is desireable to detect if an object is in fact an unforced PROMISE. To point, I find it occasionally desirable to check if a particular PROMISE has ever been FORCEd soas to glean some information about the dynamic behavior of a piece of code (such as, ``has this node in a tree ever been visited (FORCEd)?''). To my knowledge, PROMISEs are the only instance of a data-type in Scheme that may be created but not detected. This makes them somewhat less than first-class in my mind. SAMPLE IMPLEMENTATION: -- based on RRRS p.27 --------------------- (delay ) --> (make-promise (lambda () )) (define (make-promise (lambda (proc) (let ((already-run? #F) (result #F)) (lambda (message) ; Add a message parameter (case message ; Dispatch on message ((:FORCE) (cond ((not already-run?) ; Old code for FORCE (set! result (proc)) (set! already-run? #T) )) result) ((:DELAYED?) (not already-run?)) )))))) ; Expose the toggle (define (force (lambda (object) (object ':FORCE)) )) (define (delayed? (lambda (object) (object ':DELAYED?)) )) CONSIDERATIONS: -------------- Noting that some implementations may chose to make PROMISEs operationally indistinguishable from their FORCEd value (e.g. implicit forcing), DELAYED? may have to be a special form soas NOT to implicitly FORCE its argument. Finally, I was very careful NOT to propose a predicate PROMISE?, noting that some implementations may opt to make FORCE actually alter its argument soas to henceforth be replaced (in the store) by the computed value. I was likewise careful not to request (FORCED? ) which in some implementations would NOT neccessarily be the logical inverse of DELAYED? (e.g. may always return #F in implementations that modify the store as noted above). ~Ziggy  Received: from VX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 JUL 87 20:00:46 EDT Received: by VX.LCS.MIT.EDU (4.12/4.8) id AA22868; Sun, 12 Jul 87 20:00:20 edt Date: Sun, 12 Jul 87 20:00:20 edt From: Michael R. Blair To: rrrs-authors@mc Subject: (DELAYED? ) predicate  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 11 Jul 87 02:08:00 EDT Received: from relay2.cs.net by RELAY.CS.NET id ae28446; 11 Jul 87 1:54 EDT Received: from tektronix.tek.com by RELAY.CS.NET id be00569; 11 Jul 87 1:48 EDT Received: by tektronix.TEK.COM (5.51/6.23) id AA22718; Fri, 10 Jul 87 17:58:59 PDT Received: by tekchips.TEK.COM (5.51/6.23) id AA15349; Fri, 10 Jul 87 17:57:31 PDT Message-Id: <8707110057.AA15349@tekchips.TEK.COM> To: rrrs-authors@mc.lcs.mit.edu Subject: Minutes of the Scheme meeting etc. Date: 10 Jul 87 17:57:29 PDT (Fri) From: willc%tekchips.tek.com@RELAY.CS.NET Minutes of the Scheme meeting at MIT on Saturday, 27 June 1987 Attendees included: Hal Abelson (MIT) Norman Adams (Tektronix) David Bartley (Texas Instruments) Alan Bawden (MIT) Gary Brooks (Indiana U) Terry Caudill (Texas Instruments) Stewart Clamen (BBN/CMU) Will Clinger (Tektronix) Olivier Danvy (Copenhagen U) Bruce Duba (Indiana U) Kent Dybvig (Indiana U) Matthias Felleisen (Indiana U) Anne Hartheimer (Semantic Microsystems) Chris Haynes (Indiana U) Bob Hieb (Indiana U) Morry Katz (Rockwell/MITRE) Richard Kelsey (Yale) David Kranz (Yale) Eugene Kohlbecker (U Rhode Island) Jim Miller (MIT/Brandeis) Jim Philbin (Yale) Kent Pitman (Symbolics) Eric Ost (Indiana U) John Ramsdell (MITRE) Jonathan Rees (MIT/DEC) Bill Rozas (MIT) Gerry Sussman (MIT) Mitch Wand (Northeastern U) Peter Williams (U Illinois) After much rearrangement of chairs and table, Mitch Wand opened the meeting around nine-thirty. The participants introduced themselves and, if they wished, explained what they use Scheme for and what they want for and from Scheme. ENVIRONMENTS Then Hal Abelson instigated "a sample foray into content" by asking whether anyone was so absurd as to think that pattern matching is good or first class environments are bad. Gerry Sussman said that first class environments as in MIT Scheme are a disaster but that another kind was useful. Bill Rozas elaborated by saying that (THE-ENVIRONMENT) is too powerful; experience at MIT showed that it was primarily used in situations where (build-environment (define ...) (define ...) ...) would suffice. The environment resulting from BUILD-ENVIRONMENT could then be used as an argument to EVAL. The effect of top-level definitions, as in (EVAL '(DEFINE ...) ENV), is still a thorny question. MIT's view is that its incremental definition semantics is just a debugging tool. Gerry suggested that if you don't specify a base environment to BUILD-ENVIRONMENT then you should get an empty one. Jonathan Rees pointed out that ML-style modules need to be studied as an alternative. Norman Adams observed that he saw environments being used in two different ways: (1) programming in the large (modules); (2) tables indexed by symbols; he stated that the first was a good use but the second was bad. Jonathan contrasted environments with modules, saying that the module problem was to hook files together without having to use a gigantic LETREC, while environments and EVAL were useful mainly for performing a kind of reflection in the sense of Brian Smith's thesis. Gerry explained his derivation of a sine routine without using magic constants as an example of a legitimate use of EVAL. Against complaints from Will Clinger that people needed to be discouraged from using EVAL, he said "Our job is not to protect losers from themselves, but to provide winners with what they need to win." Kent Pitman then presented T's original approach of breaking EVAL into smaller pieces that might reflect the stages of compilation and linking that are involved in separate compilation. A committee was formed to think about EVAL and environments and to report back. It was suggested that the members should be Kent Pitman, Kent Dybvig, Alan Bawden, Jonathan Rees, and one of Bill Rozas and Chris Hanson. YELLOW PAGES (LIBRARY) Bill Rozas was appointed as the first librarian, or keeper of unsupported, user-contributed software. Anne Hartheimer will provide some assistance at first. Contributions to the library should be sent to scheme-librarian@mc.lcs.mit.edu. MULTIPLE RETURN VALUES Multiple return values were tabled after much discussion, little agreement. SHOULD COLON REALLY BE AN EXTENDED ALPHABETIC CHARACTER Yes. PATTERN MATCHING No change, to be left to the library. NUMBER SYNTAX Students find it confusing that 0+3i works but 3i doesn't. Alternative syntaxes were discussed briefly. Questions were raised about the semantics of exactness and inexactness. Concerning input syntax: Is 12.5 exact? What to make of #e#s12345? It was suggested that (> #i5 #i4) should cause smoke to come out of the machine. This discussion was continued on the afternoon of the second day. The meeting adjourned about five o'clock. ================================================================ Minutes of the Scheme meeting at MIT on Sunday, 28 June 1987 [Attendance was not noted the second day, but Julian Padget (U Bath) was one addition to the first day's roster.] Mitch Wand called the meeting to order around nine o'clock. Alan Bawden explained the macro proposal that he had posted to RRRS-AUTHORS. It seemed to be pretty much the right thing, but a number of questions remain: What is its relationship to expansion-passing style? Where do you get the expand-time environment? Can you change it? Can macros return DEFINE forms? How do "top level" macro definitions work? Should free variables in a file be resolved as absolute or as relative to a LOAD-environment? Should atomic, e.g. PI, macro forms be supported? Does anyone have a nice user interface for the macro machinery? Can a symbol be an identifier (variable) and a macro keyword at the same time? Which of EVAL, COMPILE, EXPRESSION->VALUE, etc, takes a syntax table argument? Matthias Felleison complained that the proposal was too powerful and/or concrete. Mitch Wand characterized Matthias's concerns as: What is the nature of the input language? It was agreed that it consist of lists and preprocessed expressions. What is the nature of the output language? It was agreed that it would be abstract, and didn't matter. Should there be restrictions on the possible transformations? This seemed to be the essence of Matthias's objections. Matthias agreed to post a more formal statement of his concerns to RRRS-AUTHORS. A straw poll indicated that nearly all were in favor of moving forward from Alan's report. CUSTOMIZABLE READER Will Clinger solicited comments about a customizable reader he was proposing for the yellow pages. The proposed reader did not solve the main problem that people seemed to want customizable readers for, namely the need to load code that was written with different lexical conventions. NUMBER PROPOSAL Gerry Sussman and Will Clinger then presented a revised number syntax and semantics they and David Bartley had worked on the previous evening. Probing questions revealed that the semantics of inexact numbers were still unclear, and the matter was tabled after much argument. EuLISP Julian Padget presented a summary of generic procedures in EuLisp. EQV? Bill Rozas requested that the R3RS be changed to permit (EQV? "" "") to be false, because empty strings are extensible in MIT Scheme. This was opposed by Will Clinger, on the grounds that extensions were permissible only insofar as they were not in conflict with the language specification. Much irrelevant discussion ensued concerning English descriptions versus formal semantics, the social value of lawyers, and the lessons of history concerning the decline and fall of programming languages. When discussion returned to the technical issue, the participants were in no mood to agree. OPTIONAL PROCEDURES It was suggested that optional procedures should either be made essential or moved to the yellow pages. The general feeling, however, was that the non-essential procedures helped to define a layered language, which was good. Bill Rozas suggested that the "yellow pages" library could contain a supported section containing implementations of the standard but non-essential procedures. A committee was appointed to think about language stratification: David Bartley, Bruce Duba, Jim Miller, Bill Rozas, and Gerry Sussman. NEXT MEETING People from Indiana University offered to host the next meeting, in the fall. [My notes do not show the year; I assume the next meeting would be in the fall of 1988. Question: Why not have it at the ACM Conference on Lisp and Functional Programming?] The meeting adjourned about five o'clock. ================================================================ Feeling that the weekend meeting had not accomplished all that needed to be accomplished, a small group of implementors met on Tuesday evening around six o'clock. Present were David Bartley (TI), Will Clinger (Tektronix), Chris Hanson (MIT), Jonathan Rees (MIT), and Bill Rozas (MIT). It was noted that Chez Scheme was not represented at all, and that T was represented only by Jonathan. Agreements made by this small group are certainly not official or binding on anyone (as indeed is true of decisions made by the larger group), but they may be of interest as an indication of the direction certain implementations are going. [My notes record the topics in the order in which they were proposed for the agenda, not the order in which they were discussed.] MACROS The situation is pretty much ok. It looks like most of the work is going to have to be done by people at MIT, because that's where the largest concentration of macrologists seems to lie. ENVIRONMENTS & MODULES Let's get some serious discussion going on RRRS-AUTHORS. This is important. STRUCTURES & OPAQUE OPBJECTS We didn't even touch on this over the weekend, though Norman Adams had prepared a list of issues. Norman should post to RRRS-AUTHORS in order to get something going. This is also important. OPTIONAL ARGUMENTS We agreed to use the #!OPTIONAL syntax as in MIT Scheme. For example, (lambda (x #!optional y z . w) ...) evaluates to a procedure with one required argument, two optional arguments, and a rest argument. How do you tell if an optional argument is supplied? It is not supplied if its value satisfies the DEFAULT-OBJECT? predicate. For example, the WRITE procedure might be written (define (write x #!optional p) (let ((p (if (default-object? p) (current-output-port) p))) ...)) A feature of this approach is that the caller can pass a default object as an argument, thereby faking an unsupplied argument. This is nice when you want to supply a value for one optional argument without supplying for any other optional arguments that precede it in the argument list. We did not decide on a syntax for default objects. This may have been an oversight. You can get a default object by writing ((lambda (#!optional x) x)). MULTIPLE RETURN VALUES We agreed on the names VALUES and WITH-VALUES for the procedures that return and accept multiple values, respectively. VALUES takes any number of arguments and returns them as multiple values. WITH-VALUES takes two arguments, of which the first is a thunk that may return multiple values and the second is a procedure to be called on the values returned by the thunk. Since the five or six alternative semantics that people are considering are linearly ordered by upward compatibility, it doesn't matter too much what particular implementations do in the short term. Texas Instruments will probably implement a semantics in which a continuation that expects a single return value will accept any number of return values, ignoring extra return values and seeing #F as the return value if there are actually no return values. EQUIVALENCE PREDICATES The section on equivalence predicates in R3RS was a noble try, but it satisfied neither those who wanted an abstract, portable definition of EQV? nor those who wanted EQ? to be an thoroughly implementation-dependent notion of object identity. Will Clinger volunteered to rewrite the section, basing it on a notion of object identity implemented by EQ? that is specified partially in an implementation-independent way, allowing unspecified behavior to vary at the whim of implementations. EQV? would then be a less implementation-dependent abstraction of EQ?. The description of EQUAL? also needs to be tightened up. The behavior of EQV? on empty strings and empty vectors would be left implementation-dependent. The behavior of EQ? and EQV? on procedures would be left as in R3RS; that is, EQ? and EQV? would have to return true of procedures created by the same evaluation of a lambda expression, would have to return false of procedures that behave differently (for example because their local state is different), and would be implementation-dependent on procedures that behave identically even though they might have been created by different evaluations of a lambda expression or lambda expressions. One effect of these changes will be to make EQV? more like Common Lisp's EQL procedure. TOP LEVEL DEFINE SYNTAX We considered whether the change in the 1986 Scheme standard that made (define (foo ...) ...) equivalent to (define foo (lambda (...) ...)) instead of (define foo (rec foo (lambda (...) ...))) might have been a mistake because of the efficiency issue. We decided that we liked the way it was done in the 1986 standard, but that it was ok for implementations to default to a "benchmark mode" that treats such definitions as in the 1985 standard, provided there is a way to disable benchmark mode. CONDITION HANDLING We cannot consider a standard condition (exception) handler until we have a standard list of exceptions, interrupts, i/o errors, and syntax errors. We also need some way to associate handlers with conditions dynamically; fluid variables would be one possibility but are more general than necessary for this use. INTEGRABLE DECLARATIONS, CONSTANT DECLARATIONS, AND BLOCK COMPILATION Most of the perceived need for these would go away if we had a good enough module facility. Implementations can in the meantime experiment with block compilation, knowing that most of the work should be salvageable when modules arrive. Insight: To declare that something is integrable not only declares it a constant, but also advises the compiler that constant folding is worth attempting. INPUT EDITOR Jonathan Rees proposed a procedure to make it possible to write a portable reader that supports editing of input in the native style on machines whose native style is to evaluate expressions immediately when the closing parenthesis is typed. He was encouraged to submit implementations to the yellow pages library. This seems to be a case where non-portable implementations of a portable concept is appropriate for the library. PEEK-CHAR Jonathan pointed out that the standard input procedures documented in R3RS are not powerful enough to write a portable reader, because Scheme lacks PEEK-CHAR and equivalents. We know that all major implementations except possibly Chez Scheme have a PEEK-CHAR procedure. We'd like to add PEEK-CHAR to the R3RS if there are no major objections. FLUID VARIABLES We felt that MIT has the best semantics for fluid variables. Its greatest weakness is its possible inefficiency on multi-tasking and multiprocessor implementations, but the implementors of MIT Scheme have some ideas that may solve that problem. The meeting adjourned around midnight. ================================================================ End of minutes.  Received: from Sushi.Stanford.EDU (TCP 4402000065) by MC.LCS.MIT.EDU 10 Jul 87 02:19:53 EDT Date: Thu 9 Jul 87 23:13:27-PDT From: Andy Freeman Subject: re: structures To: MKATZ@A.ISI.EDU cc: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: Message from "Morris Katz " of Thu 9 Jul 87 11:45:15-PDT Message-ID: <12317165967.21.ANDY@Sushi.Stanford.EDU> Morris Katz wrote: [He discussed a structures package written by Steware Clamen that is similar to Norman Adams' proposal. He mentioned some of its additional properties.] The first is an option as to whether a structure should carry along its type and be runtime type checked each time an accessor or mutator utilizes it. This allows the user a trade-off between type security and execution efficiency. If this trade-off is controlled by options in the structure definition, I sure hope the sense of the option is "right". The default should be as type secure as possible. The context where accessors and mutators are used should determine whether or not run-time type-checking is performed. If implicit and explicit type-checking is never used at run-time, the type information may be optimized away. (That may not be possible for top-level definitions in an interactive system, but ....) T (and MacLisp) had a primitive version of this for predefined structures (cons' and vectors are the ones I remember); if a procedure is compiled with the appropriate options, the compiled code does not include type-checks. #include {standard args for incomplete type-inference systems} I realize that Adams' proposal does not have the hooks for a useful type-inference system, but that is a good direction to leave open. -andy -------  Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 9 Jul 87 22:32:53 EDT Received: by ZOHAR.AI.MIT.EDU; Thu, 9 Jul 87 22:33:22 edt Date: Thu, 9 Jul 87 22:33:22 edt From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman) Message-Id: <8707100233.AA08839@zohar> To: MKATZ@A.ISI.EDU Cc: rrrs-authors@MC.LCS.MIT.EDU In-Reply-To: Morris Katz's message of 9 Jul 1987 11:45:15 EDT <8707091602.AA08685@zohar> Subject: structures Actually, I think that such worrying about function-call overhead is the problem of a compiler, not of a user. The compiler should be willing to integrate procedures, when it is advantageous. Such optimizations may require compiler declarations, but I don't think that they belong in the language at this point.  Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 9 Jul 87 11:52:03 EDT Date: 9 Jul 1987 11:45:15 EDT Subject: re: structures From: Morris Katz To: rrrs-authors@MC.LCS.MIT.EDU Stewart Clamen built a structures packages for MIT CScheme which is almost identical to the one proposed by Norman Adams. It however contained a few additional ideas which I believe are worth considering. These all take the form of options at strucutre declaration time. The first is an option as to whether a structure should carry along its type and be runtime type checked each time an accessor or mutator utilizes it. This allows the user a trade-off between type security and execution efficiency. The second option is the ability to specify whether accessors, mutators, etc should be built as procedures, macros, or both. In order to efficiently manipulate structures it may be desirable to have accessors and mutators be macros to avaoid the extra function call overhead. Morry Katz -------  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 8 Jul 87 19:08:20 EDT Received: from relay2.cs.net by RELAY.CS.NET id aa01544; 8 Jul 87 18:53 EDT Received: from tektronix.tek.com by RELAY.CS.NET id ak05511; 8 Jul 87 18:43 EDT Received: by tektronix.TEK.COM (5.51/6.23) id AA26009; Wed, 8 Jul 87 14:19:52 PDT Received: by tekchips.TEK.COM (5.51/6.23) id AA01100; Wed, 8 Jul 87 14:22:40 PDT Date: Wed, 8 Jul 87 14:22:40 PDT From: Norman Adams Message-Id: <8707082122.AA01100@tekchips.TEK.COM> Subject: structures To: rrrs-authors@mc.lcs.mit.edu The following outlines a facility for defining new record types. Such a facility could be implemented using whatever we come up with for macros, and PROJECT/INJECT/IN? as described in Will's minutes from the lunch meeting at the '86 Lisp conference. I am proposing the functionality described (and implied), not the particular names. Related issues are modules, types, and object-oriented programming. This proposal may be premature if we haven't addressed these, or it may be a stop-gap until we do. DEFINE-RECORD-TYPE defines a new disjoint record type which has a fixed set of named fields. DEFINE-RECORD-TYPE defines procedures for making instances of the type, and accesssing and assigning the fields of the instances. DEFINE-RECORD-TYPE also defines a predicate which returns true only for instances of the type defined. The simplest syntax for DEFINE-RECORD-TYPE is (DEFINE-RECORD-TYPE typeName fieldName ...) This would define the procedures MAKE- ? - (for each field) SET--! (for each field) ---------------- Locality of names Given that DEFINE-RECORD-TYPE is making definitions, where are these definitions allowed, and what is the scope of these names? Here are two possibilities. Sketchy implementations illustrate. 1) Use syntactic extension and internal defines to provide local names. (define-record-type emp name age) == (begin (define make-emp (lambda () ...)) (define emp? (lambda (x) ...)) (define emp-name (lambda (emp) ...)) (define emp-age (lambda (emp) ...)) (define set-emp-name! (lambda (emp name) ...)) (define set-emp-age! (lambda (emp age) ...)) ) DEFINE-RECORD-TYPE form at top level would define the procedures globally; but at the beginning of a would define the procedures locally. This assumes that code generated by macros works the same way as "source" code. 2) Provide a procedural interface to make new record types, don't depend on internal define. DEFINE-RECORD-TYPE is one possible syntactic extension which uses MAKE-RECORD-TYPE, a procedure. This approach could be combined with the first. (define-record-type emp name age) == (begin (define make-emp '#!unspecified) (define emp? '#!unspecified) (define emp-name '#!unspecified) ... (let ((new-record-type-frob (make-record-type 'emp '(name age)))) (set! make-emp (record-type-constructor new-record-type-frob)) (set! emp? (record-type-predicator new-record-type-frob)) (let ((selectors (record-type-selectors new-record-type-frob)) (assigners (record-type-assigners new-record-type-frob))) (set! emp-name (record-type-selector selectors 0)) (set! emp-age (record-type-selector selectors 1)) (set! set-emp-name! (record-type-assigner assigners 0)) (set! set-emp-age! (record-type-assigner assigners 1)) )))) This approach provides an interface which does not force particular names on the client. ---------------- Initializers There are many possible enhancements that can be made to this simple form of DEFINE-RECORD-TYPE. Record facilities often provide some way to do some form of initialization. Some possibilities: - Fields are initialized to values passed to the constructor. Either require that a value be passed for each field, or have some indication for each field in the DEFINE-RECORD-TYPE form that the constructor will or will not be passed a value with which to initialize the field. - An initial value for each or any field may given in the DEFINE-RECORD-TYPE form. The expression for an initial value might be evaluated one time, or once per call to the constructor. If not the latter, when is the expression evaluated? What is the syntax for any of this? ---------------- Other issues What is the name? DEFINE-STRUCTURE, DEFINE-STRUCTURE-TYPE, DEFSTRUCT READ and WRITE syntax. Unitialized fields - it "is an error" to access an uninitialized field? Do we want to say anything about redefinition? If you load a file containing a DEFINE-RECORD-TYPE, say for EMPLOYEE, are existing instances of EMPLOYEE still going to answer true to EMPLOYEE? after you reload the file? Do we want to support variant records in any way? I think there is a temptation to featurize a record package to compensate for the lack of strong types. -- Norman -------  Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 6 Jul 87 14:34:28 EDT Received: by ZOHAR.AI.MIT.EDU; Mon, 6 Jul 87 14:28:44 edt Date: Mon, 6 Jul 87 14:28:44 edt From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman) Message-Id: <8707061828.AA07651@zohar> To: ramsdell%linus@mitre-bedford.ARPA Cc: rrrs-authors@mc.lcs.mit.edu In-Reply-To: ramsdell%linus@mitre-bedford.ARPA's message of Mon, 6 Jul 87 08:15:09 EDT <8707061215.AA06553@darwin.sun.uucp> Subject: Tigger on Scheme thank you for the neat poem.  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 6 Jul 87 11:01:24 EDT Posted-From: The MITRE Corp., Bedford, MA Received: from darwin.sun.uucp by linus.research (3.2/4.7) id AA20362; Mon, 6 Jul 87 10:55:59 EDT Posted-Date: Mon, 6 Jul 87 09:36:27 EDT Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3) id AA06667; Mon, 6 Jul 87 09:36:27 EDT Date: Mon, 6 Jul 87 09:36:27 EDT From: ramsdell%linus@mitre-bedford.ARPA Message-Id: <8707061336.AA06667@darwin.sun.uucp> To: matthias@iucs.cs.indiana.edu Cc: rrrs-authors@mc.lcs.mit.edu In-Reply-To: Matthias Felleisen's message of Fri, 3 Jul 87 09:35:49 est <8707031439.AA00576@mitre-bedford.ARPA> Subject: Macros again: read first Please clarify one issue: Is your "counterproposal" at odds with the PREPROCESS three-quarter macro proposal? That is, are you arguing for restricting the proceedures given to ADD-KEYWORD, the restriction being that the procedures are functional? Or are you arguing against what was decided last weeks Scheme meeting? Please don't make me take back my words: ..... I enjoyed most of the meeting, and I am enthusiastic about the prospect of agreement on the most important issue in my opinion: the issue of macros. John  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 6 Jul 87 08:17:50 EDT Posted-From: The MITRE Corp., Bedford, MA Received: from darwin.sun.uucp by linus.research (3.2/4.7) id AA14560; Mon, 6 Jul 87 08:15:26 EDT Posted-Date: Mon, 6 Jul 87 08:15:09 EDT Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3) id AA06553; Mon, 6 Jul 87 08:15:09 EDT Date: Mon, 6 Jul 87 08:15:09 EDT From: ramsdell%linus@mitre-bedford.ARPA Message-Id: <8707061215.AA06553@darwin.sun.uucp> To: rrrs-authors@mc.lcs.mit.edu Subject: Tigger on Scheme ------------ Forwarded from the MilneNet ------------- Posted-Date: Mon, 6 Jul 87 07:46:39 EDT Date: Mon, 6 Jul 87 07:46:39 EDT From: Tigger@Hundred-Acre-Woods.Milne To: ramsdell@linus.uucp Subject: Scheme The wonderful thing about Scheme is: Scheme is a wonderful thing. Complex procedural ideas Are expressed via simple strings. It's clear semantics, and lack of pedantics, Help make programs run, run, RUN! But the most wonderful thing about Scheme is: Programming in it is fun, Programming in it is FUN! ------------------------------------------------------ Gerry started the last Scheme meeting with a stated desire that it be fun. I have to observe that laudable goal was lost by the end of the meeting. I enjoyed most of the meeting, and I am enthusiastic about the prospect of agreement on the most important issue in my opinion: the issue of macros. I enjoyed talking with you all. Let's not get too serious about Scheme. John  Received: from iucs.cs.indiana.edu (TCP 30003147315) by MC.LCS.MIT.EDU 3 Jul 87 10:37:58 EDT Date: Fri, 3 Jul 87 09:35:49 est From: Matthias Felleisen To: rrrs-authors@mc.lcs.mit.edu Subject: Macros again: read first I have tried to reformulate my original message to answer some of JAR's questions (there have been several exchanges between the two of us). This is not a complete counterproposal and I don't have the time to come up with a complete counterproposal. The purpose of this note (and its predecessor) is to stimulate the committee to think in different ways about the issue of macros and related matters. 1. Old-style macros have two purposes. First, they are used to extend the set of available syntactic facilities. Second, they also have the power of performing arbitrary computations on their input expressions and the existing environment at compile time. 2. From my point of view, the extension of syntax is the addition of syntactic forms to (a possibly extended) RRRS and the definition of their semantics via an equivalence with already available facilities. It follows that an extension of syntax is a map from (abstract syntax) trees to (abstract syntax) trees. These tree domains are only a subset of the domain of S-expressions and that is the important point. Because the input/output domains are tree domains, i.e., they neither posses state nor are they circular (this does not mean that they cannot contain closures that are circular or have state), there is no need to use side-effects for the manipulation of the input/output structures. Assignments exist for the sole purpose of creating circularities and of modeling state [NOTE: People use assignments for other purposes as well, but these (first-order) uses can be eliminated without restructuring the entire program (as in store-passing and continuation-passing style programming for the general solution]. In the same vein I can argue against call/cc the second, non-functional computational primitive (the uses for expansion time can be anticipated by the expander as opposed to the transform function). In short, the manipulation of abstract syntax trees requires nothing but the purely functional subset of Scheme and this should be accounted for. 3. According to the preceding explanation, I call "macros" the set of unrestricted transformation functions, which possibly use side-effects, jumps (i.e. call/cc) etc.; "extend-syntax" is the facility which implements functional transform functions. 4. Would Eugene's extend-syntax do it? No, it is too powerful. It provides a WITH-construct for arbitrary manipulations. [I believe the facility was added for macro-lovers but Eugene can answer this better.] The WITH must be restricted so that it conforms with the functional spirit. For inserting circular closures or closures with state in the output tree I perceive the need for a more expressive target language for the expander, i.e. a language where such things can be written down. [I personally see a need for this and have used this quite often, but as I said it suffices to extend the target language or to accept a restricted with.] The pattern language of Eugene's extend-syntax is not essential. A restriction of MacroScheme to cons, car, cdr, map etc and and exclusion of set!, set-car!, set-cdr!, eq?, etc. should do it although I believe that the pattern language is in most instances more convenient. [Hundreds of students at Indiana get along with it and encounter very few problems so I also think that it is not difficult to learn.] Side-effects for debugging. I have had to debug hundreds of extend-syntax macros in the past 2 or 3 years (and several of the transformers). I have practically never used side-effects in the WITH-clauses but always in the expansion part of the macros. Perhaps the pattern languages has helped, perhaps I am too optimistic. On the other hand, I could also imagine that we add debugging aids to the functional MacroScheme language. I can see that this point deserves discussion. -- Matthias [JAR was disturbed by the rhetoric of this note. If there is any, I ask you to overlook it.]  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 1 Jul 87 11:36:19 EDT Date: Wed, 1 Jul 87 11:38:11 EDT From: Jonathan A Rees Subject: Macros To: matthias@IUCS.CS.INDIANA.EDU cc: rrrs-authors@MC.LCS.MIT.EDU In-reply-to: Msg of Wed 1 Jul 87 08:54:27 est from Matthias Felleisen Message-ID: <222081.870701.JAR@AI.AI.MIT.EDU> Date: Wed, 1 Jul 87 08:54:27 est From: Matthias Felleisen b: performing arbitrary and possibly infinite computations. This is the point of contention and the Indiana school of thought rejects this possibility. Old-style macros with no global side-effects can still be implemented with extend-syntax: ... ... I opt for an extend-syntax-like mechanism as a primitive tool. I must be missing something. This sounds like a gross contradiction to me. Could you be clearer, perhaps even concrete, about what you mean by "extend-syntax-like"?  Received: from iucs.cs.indiana.edu (TCP 30003147315) by MC.LCS.MIT.EDU 1 Jul 87 09:56:18 EDT Date: Wed, 1 Jul 87 08:54:27 est From: Matthias Felleisen To: rrrs-authors@mc.lcs.mit.edu Subject: Macros Here is a final attempt to explain my position on macros and related matters. I perceive two major purposes for macros: 1. extending the set of available syntactic facilities 2. manipulating an s-expression in an arbitrary way and interpreting the result as program text at compile time. I shall call the first kind of facility "extend-syntax", the second kind "sep" (for s-expression processing). 1. When we extend syntax, we manipulate s-expressions that coincide with abstract syntax trees. Since these are trees, not graphs, there is NO NEED WHATSOEVER to use any kind of assignment: assignments exist for creating circularities and for modeling state (in the sense of objects and state variables). Therefore, a functional specification of these extensions is sufficient. Furthermore, the extension of language syntax should be as far as possible separated from ordinary evaluations although this is subject to research and compromise. This is---in my eyes, perhaps not Eugene's---the essence of Eugene's dissertation on extend-syntax. His choice of using pattern-matching for the specification of extensions is---for many people--- convenient, but not inherent. 2. The arbitrary manipulation of s-expressions at compile time can mean two things: a: obtaining a value that we cannot write down in Scheme and including it in expansions, e.g. closures. This is actually a problem of Scheme and can be fixed in various ways. A weak solution is Eugene's with-construct in extend-syntax which accomplishes this, but unfortunately also does other things. (Another solution is to work with a stronger language.) b: performing arbitrary and possibly infinite computations. This is the point of contention and the Indiana school of thought rejects this possibility. We feel the interaction between compile time and run time (or anytime computations) is not understood well enough to justify an inclusion in RRRS. Just as there is a better way for expressing extend-syntax the community should look for better ways for dealing with these problems. Old-style macros with no global side-effects can stillbe implemented with extend-syntax: (extend-syntax (define-macro Macro TransForm) (extend-syntax (Macro exp ...) (eval (Transform '(exp ...)))) [This requires eval and possibly a split of eval into several pahses together with Dan's favorite (and (in)famous) extend-syntax macro eval-once.] Because extend-syntax (in whatever form) is simpler and demonstrates to the world that the Scheme-designers understand the problem and because it can implement conservative sep-macros, I opt for an extend-syntax-like mechanism as a primitive tool. -- Matthias & Bruce.  Received: from iucs.cs.indiana.edu (TCP 30003147315) by MC.LCS.MIT.EDU 30 Jun 87 20:59:30 EDT Date: Tue, 30 Jun 87 18:37:18 est From: Matthias Felleisen To: rrrs-authors@mc.lcs.mit.edu Subject: Macros Here is a final attempt to explain my position on macros and related matters. I perceive two major purposes for macros: 1. extending the set of available syntactic facilities 2. manipulating an s-expression in an arbitrary way and interpreting the result as program text at compile time. I shall call the first kind of facility "extend-syntax", the second kind "sep" (for s-expression processing). 1. When we extend syntax, we manipulate s-expressions that coincide with abstract syntax trees. Since these are trees, not graphs, there is NO NEED WHATSOEVER to use any kind of assignment: assignments exist for creating circularities and for modeling state (in the sense of objects and state variables). Therefore, a functional specification of these extensions is sufficient. Furthermore, the extension of language syntax should be as far as possible separated from ordinary evaluations although this is subject to research and compromise. This is---in my eyes, perhaps not Eugene's---the essence of Eugene's dissertation on extend-syntax. His choice of using pattern-matching for the specification of extensions is---for many people--- convenient, but not inherent. 2. The arbitrary manipulation of s-expressions at compile time can mean two things: a: obtaining a value that we cannot write down in Scheme and including it in expansions, e.g. closures. This is actually a problem of Scheme and can be fixed in various ways. A weak solution is Eugene's with-construct in extend-syntax which accomplishes this, but unfortunately also does other things. (Another solution is to work with a stronger language.) b: performing arbitrary and possibly infinite computations. This is the point of contention and the Indiana school of thought rejects this possibility. We feel the interaction between compile time and run time (or anytime computations) is not understood well enough to justify an inclusion in RRRS. Just as there is a better way for expressing extend-syntax the community should look for better ways for dealing with these problems. Old-style macros with no global side-effects can stillbe implemented with extend-syntax: (extend-syntax (define-macro Macro TransForm) (extend-syntax (Macro exp ...) (eval (Transform '(exp ...)))) [This requires eval and possibly a split of eval into several pahses together with Dan's favorite (and (in)famous) extend-syntax macro eval-once.] Because extend-syntax (in whatever form) is simpler and demonstrates to the world that the Scheme-designers understand the problem and because it can implement conservative sep-macros, I opt for an extend-syntax-like mechanism as a primitive tool. -- Matthias & Bruce.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 Jun 87 22:22:37 EDT Date: Tue, 23 Jun 87 22:24:48 EDT From: Jonathan A Rees Subject: sundry To: rrrs-authors@MC.LCS.MIT.EDU cc: spols%oz@MC.LCS.MIT.EDU Message-ID: <218731.870623.JAR@AI.AI.MIT.EDU> A recapitulation of the details of the workshop, with some directions for the minority (!) of you not familiar with the area: We meet Saturday and Sunday starting at 9:30 a.m. Tentative finishing time is 5 p.m. but we can stay longer or shorter if we like. The current head count is 33. The Grier Room is also known as room 34-401. The entrance to buildings 34, 36, and 38 is on Vassar Street about halfway between Main Street and Massachusetts Avenue. At the entrance there is a big new glass atrium, several stories high, that's hard to miss, and a revolving door. Building 34 nestles in between buildings 36 and 38 and away from the street, opposite the main entrance. Go to the left (building 36) and take the stairs or elevator up to the fourth floor. 401 is the only room on the fourth floor of building 34; it has two halves (A and B) with separate doors, and we'll be meeting in one half and lunching in the other. There is a parking lot across the street; if I'm not mistaken, weekend parking there is unrestricted. Street parking may also be available. Building 34 is only about 2.5 blocks from the Marriott. Take Main St away from the river and hang an obtuse left onto Vassar just before the railroad tracks. I started writing out directions for how to drive to the Marriott from the airport; it's easy if you know what you're doing, but a missed exit can, for example, put you on a toll bridge headed to distant Charlestown. So I'll take the coward's way out and suggest that it's probably best to get directions and a map from your car rental agency; they're probably better at giving directions than I am (I have no car). Better yet, take the subway (shuttle bus to blue line to green line (or orange line) to red line to Kendall) -- very easy, you ascend from the subway directly into the hotel complex. If anyone so requests, however, I'd be happy to try to write up directions. If you have questions or get into trouble, my phone number at MIT is (617) 253-8581, home 423-3953. Mary Spollen's phone number is 253-5855. If you haven't sent your payment yet then please bring a check ($14, payable to MIT) on Saturday. - Jonathan  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 18 Jun 87 21:58:48 EDT Received: from relay2.cs.net by RELAY.CS.NET id aa13647; 18 Jun 87 21:20 EDT Received: from ti-csl by RELAY.CS.NET id aa04204; 18 Jun 87 21:15 EDT Received: by tilde id AA24906; Thu, 18 Jun 87 19:00:48 CDT Received: by home id AA09063; Thu, 18 Jun 87 18:59:25 cdt Date: Thu, 18 Jun 87 18:59:25 cdt From: David Bartley Message-Id: <8706182359.AA09063@home> To: GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Cc: bartley%home%ti-csl.csnet@RELAY.CS.NET, RRRS-Authors@mc.lcs.mit.edu In-Reply-To: Gerald Jay Sussman's message of Fri 12 Jun 87 02:45:08-EDT <12309831704.6.GJS@OZ.AI.MIT.EDU> Subject: number syntax and exactness > Let's look through your points one-by-one. [...] > > B: (3) Scheme separates the concept of exactness from type; Common > Lisp does not. > > No... Exactness is intended to be a statement about the mathematical > type of a quantity. Scheme tries to separate the mathematical type from > the implementation representation. This is not a complete separation, but > it is important to make it as separate as possible. I meant that Scheme separated exactness from type in the sense that "exactness is independent of the position of the number on the tower [of numeric types]" (6.5.2). Isn't this also what you are saying? I agree that it certainly is easy to get confused about whether we're talking about mathematic types, "types" in the language, or representational "types." > B: I don't understand how to make exactness > orthogonal to precision, however (see point 4). What does > #e#s123456789 mean if an implementation can't represent the value > 123456789 exactly in a short FLONUM? > > Your problem here is that you have conflated the size of the flonum, > a property of the representation, not the mathematical type, with a > mathematical exactness property. It seems to me that the example you > show is just an error -- to be caught by the reader -- as it would > complain about #d() or 3.4e5.6. Although the notation #e3 means that we are talking about exactly the abstract number 3, our purpose in using the notation is to communicate that to a program. Thus, we must consider whether our representation "types" suffice to do so. Of course this is conflating a property of the representation with a mathematical property---that's what I/O of numbers has to deal with. From 6.5.2: "Some operations, such as the square root (of non-square numbers), must be inexact because of the finite precision of our representations." I'm saying that another such operation is input, when obeying a precision specification prevents the reader from correctly representing an exact number. Is this an error, as you suggest, or no worse than having (SQRT #e3) return an inexact result? > B: In Common Lisp, precision is an attribute of (inexact) FLONUMs only. > The last paragraph of 6.5.3 of R3RS says essentially the same thing, > clarifying the syntax in 7.1.1. This seems inconsistent to me, > though, since it relates "precision" to the FLONUM representation type > whereas I see "precision" as an attribute of "inexactness." If we can > speak of inexact integers, then we should perhaps be able to speak of > short or long ones without requiring that they be implemented as > FLONUMs. > > Again, David, I think that you are confusing representation type with > the mathematical status of a quantity. In fact, the shortness or longness > of a flonum says nothing about the precision of a numeric quantity so > represented. For example, 3.14159232145678 is a rather imprecise value > for pi, but it is represented in a medium of potentially large precision. > Exactness is intended to be a property of the precision of a quantity, not a > property of the potential precision of a representation. I shouldn't have said that I see "precision" as an ++attribute++ of "inexactness," as that is an overstatement. I'm trying to say that fixed precision can impair our ability to represent some exact numbers correctly. The shortness or longness of a flonum DOES say something about the likelihood of being able to represent an exact value (consisting of many digits) correctly, because #e1.5 can probably be represented exactly as either a short or long flonum, but #e1.000000000000000000000005 may fit correctly only in a long [I'm assuming a decimal flonum here]. Thus, #e#s1.000000000000000000000005 involves a contradiction. Part of my discussion following my point (4) was in error because I didn't notice this sentence in the last paragraph of 6.5.3: "In either case, we are specifying an explicit way to represent an inexact number." This tells me that #e#s123456789 is incorrect because the #S directly contradicts the #E. However, I still would like some clarification on whether a number like #e1.000000000000000000000005 (no #S) is an error or is quietly represented as an inexact number because READ is sometimes an inexact operation. ---------- I can see that there are enough flaws in my presentation that I need to start over on it. However, I will be on vacation from this Saturday until I show up at the Scheme meeting next Saturday, so I'll just wait and see if there is any interest when I get there. --db--  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 15 Jun 87 17:29:31 EDT Received: from relay2.cs.net by RELAY.CS.NET id ag01996; 15 Jun 87 15:53 EDT Received: from tektronix.tek.com by RELAY.CS.NET id ar11342; 15 Jun 87 15:47 EDT Received: by tektronix.TEK.COM (5.51/6.23) id AA08034; Mon, 15 Jun 87 11:47:20 PDT Received: by tekchips.TEK.COM (5.51/6.22) id AA05321; Mon, 15 Jun 87 11:49:50 PDT Message-Id: <8706151849.AA05321@tekchips.TEK.COM> To: rrrs-authors@mc.lcs.mit.edu Subject: Session chair In-Reply-To: Your message of Fri, 12 Jun 87 17:54:55 EDT. <213724.870612.JAR@AI.AI.MIT.EDU> Date: 15 Jun 87 11:49:49 PDT (Mon) From: willc%tekchips.tek.com@RELAY.CS.NET Mitch Wand, who moderated the successful meeting at Brandeis in 1984, has agreed to chair our sessions again in Cambridge. His net mail address is wand@corwin.ccs.northeastern.edu. Thanks, Mitch. Will Clinger  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 12 Jun 87 23:17:37 EDT Date: Fri, 12 Jun 87 23:15:55 EDT From: Chris Hanson Subject: no free lunch To: JAR@AI.AI.MIT.EDU cc: rrrs-authors@MC.LCS.MIT.EDU, spols@OZ.AI.MIT.EDU In-reply-to: Msg of Fri 12 Jun 87 17:54:55 EDT from Jonathan A Rees Message-ID: <213825.870612.CPH@AI.AI.MIT.EDU> I'm vegetarian. I don't know what is in pasta salad but I think sometimes it has some meat in it. If it's much trouble it is easy for me to bring my own food.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 12 Jun 87 18:13:26 EDT Date: Fri, 12 Jun 87 18:11:50 EDT From: Jonathan A Rees Subject: directions To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <213728.870612.JAR@AI.AI.MIT.EDU> One more item of business from the local-arrangements-coordinator... (Sorry to dribble them out like this, but I'm not paid to be organized) If you want to have a map of MIT with directions to the workshop mailed to you, send me your postal address. Also let me know if you need directions from the airport.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 12 Jun 87 17:56:39 EDT Date: Fri, 12 Jun 87 17:54:55 EDT From: Jonathan A Rees Subject: no free lunch To: rrrs-authors@MC.LCS.MIT.EDU cc: spols@OZ.AI.MIT.EDU Message-ID: <213724.870612.JAR@AI.AI.MIT.EDU> Lunch and 2 coffee breaks each day of the workshop will be catered by one of the MIT dining halls and will be adequate but not elaborate: cold cuts, pasta salad, cake, fruit, etc. So if you plan to attend the workshop, please send a check for $14, payable to the Massachusetts Institute of Technology, to Mary Spollen MIT Laboratory for Computer Science 545 Technology Square Cambridge MA 02139 Send only $7 if you'll only be there one of the two days. If you are vegetarian or have other requirements and the menu doesn't sound adequate, contact me or Mary and we'll see if anything can be done for you.  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 JUN 87 02:47:24 EDT Date: Fri 12 Jun 87 02:45:08-EDT From: "Gerald Jay Sussman" Subject: Re: number syntax and exactness To: bartley%home%ti-csl.csnet@RELAY.CS.NET cc: RRRS-Authors@MC.LCS.MIT.EDU In-Reply-To: <8706052216.AA18999@home> Message-ID: <12309831704.6.GJS@OZ.AI.MIT.EDU> Let's look through your points one-by-one. B: (1) Complex numbers in Scheme look like 3+4i; in Common Lisp they look like #c(3 4). And I'm persuaded that 3+4i is a worthwhile improvement over #c(3 4). Actually, I am no longer so persuaded myself. The problem is that 3+4i indicates to the reader that we are adding a real 3 to an imaginary 4. Thus it is not obvious why the syntax will not accept 4i, but requires 0+4i. I still like 5@.927 for polar numbers, but I would rather have something like 3&4 for the rectangular variety than 3+4i. On the other hand I think that the #C syntax is quite ugly. I see no reason why we shouldn't accept it, for compatability reasons, in addition to something more pretty. B: (2) The + or - sign in Scheme precedes everything else in a real number; in Common Lisp the sign may be preceded by a radix indicator. Common Lisp does not have the #D (decimal) indicator but has a general purpose #nnR indicator. Allowing the radix indicator and sign to appear in either order seems to be a reasonable extension for both languages. I agree. B: (3) Scheme separates the concept of exactness from type; Common Lisp does not. No... Exactness is intended to be a statement about the mathematical type of a quantity. Scheme tries to separate the mathematical type from the implementation representation. This is not a complete separation, but it is important to make it as separate as possible. B: I don't understand how to make exactness orthogonal to precision, however (see point 4). What does #e#s123456789 mean if an implementation can't represent the value 123456789 exactly in a short FLONUM? Your problem here is that you have conflated the size of the flonum, a property of the representation, not the mathematical type, with a mathematical exactness property. It seems to me that the example you show is just an error -- to be caught by the reader -- as it would complain about #d() or 3.4e5.6. B: (4) Scheme specifies the precision of a real number using #S(short) or #L (long); Common Lisp specifies the precision of a floating point number with an of S, F, D, or L (for Short, Single, Double, and Long). The Scheme syntax in 7.1.1 allows a precision specification for rational numbers; Common Lisp does not. I see nothing wrong with the Scheme specification. The Common Lisp one is an extension of an ancient Fortran kludge. I would not be adverse to accepting the Common Lisp syntax for compatability, in addition to our (preferred) syntax. B: In Common Lisp, precision is an attribute of (inexact) FLONUMs only. The last paragraph of 6.5.3 of R3RS says essentially the same thing, clarifying the syntax in 7.1.1. This seems inconsistent to me, though, since it relates "precision" to the FLONUM representation type whereas I see "precision" as an attribute of "inexactness." If we can speak of inexact integers, then we should perhaps be able to speak of short or long ones without requiring that they be implemented as FLONUMs. Again, David, I think that you are confusing representation type with the mathematical status of a quantity. In fact, the shortness or longness of a flonum says nothing about the precision of a numeric quantity so represented. For example, 3.14159232145678 is a rather imprecise value for pi, but it is represented in a medium of potentially large precision. Exactness is intended to be a property of the precision of a quantity, not a property of the potential precision of a representation. I don't think that there is any good reason to mix up such ideas as SHORT, LONG, FLONUM, FIXNUM, etc. with ideas such as INTEGER, REAL, EXACT, INEXACT, RATIONAL. It is to be expected that these ideas are not orthogonal. Surely the mathematical type constrains the applicable representations -- it is hard to argue for stuffing a complex number into a FIXNUM. B: I see two alternatives. We could tie the specification of precision to FLONUMs only, as we do now, or we could relate precision to exactness. I prefer the latter. I do not think that this is a matter of preference... (potential) precision is indeed only a property of the representation -- FLONUMs -- you may extend the idea to FIXNUMs/BIGNUMs, if it appears to be useful, but do not confuse the potential precision of a representation with the actual precision of a particular number. -------  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Jun 87 13:00:01 EDT Date: Thu, 11 Jun 87 12:58:07 EDT From: Jonathan A Rees Subject: on-campus accommodations To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <212975.870611.JAR@AI.AI.MIT.EDU> If anyone is interesting in staying in an MIT dorm room (cheap) during the workshop, please send me mail.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 10 Jun 87 23:56:30 EDT Date: Wed, 10 Jun 87 23:54:17 EDT From: Jonathan A Rees Subject: attending To: bartley%home%ti-csl.csnet@RELAY.CS.NET cc: RRRS-Authors@MC.LCS.MIT.EDU, spols%oz.ai.mit.edu@MC.LCS.MIT.EDU In-reply-to: Msg of Wed 10 Jun 87 17:53:41 cdt from David Bartley Message-ID: <212790.870610.JAR@AI.AI.MIT.EDU> Here is my current list of attendees. I count 29 so far, although two or three are dubious. I'm keeping track so that we will know how much food to order. I will send out a request shortly for money to pay for lunch and other munchies. If anyone has special audiovisual requests, let me know. I'll get the usual projectors, and I'll try to talk GJS into bringing his amazing projectable PC screen. Hal Abelson Norman Adams Tektronix David Bartley TI (may miss Saturday?) Alan Bawden Michael Blair Will Clinger Tektronix/Semantic Microsystems Olivier Danvy Copenhagen U. Kent Dybvig Bruce Duba Indiana Matthias Felleisen Indiana Dick Gabriel Lucid (may miss some) Ken Haase Bert Halstead Chris Hanson Anne Hartheimer Semantic Microsystems Chris Haynes Indiana Bob Hieb Indiana Richard Kelsey Yale (not verified) Eugene Kohlbecker URI David Kranz Yale Jim Miller Richard Mlynarik Jim Philbin Yale Kent Pitman Symbolics John Ramsdell MITRE Jonathan Rees Bill Rozas G J Sussman Mitch Wand Northeastern (The absence of an indicated affiliation means that the affiliation is MIT.)  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 10 Jun 87 19:40:51 EDT Received: from relay2.cs.net by RELAY.CS.NET id ab13143; 10 Jun 87 19:21 EDT Received: from ti-csl by RELAY.CS.NET id ag09642; 10 Jun 87 19:18 EDT Received: by tilde id AA16222; Wed, 10 Jun 87 17:54:33 CDT Received: by home id AA01217; Wed, 10 Jun 87 17:53:41 cdt Date: Wed, 10 Jun 87 17:53:41 cdt From: David Bartley Message-Id: <8706102253.AA01217@home> To: RRRS-Authors@mc.lcs.mit.edu Cc: Bartley%home%ti-csl.csnet@RELAY.CS.NET Subject: Agenda Here's my stab at a tentative agenda for the meeting. Jonathan has arranged for facilities from approximately 9:30am to 5:00pm on both Saturday and Sunday, June 27 and 28. An early action item will be to come up with the actual agenda; but don't wait until then to flame about this one! I. Amenities -- introductions, etc. II. Expectations for the meeting/procedure -- rules of the game (consensus, majority rule?) (who votes?) -- selection/assignment of secretary and chairperson -- discussion of the agenda -- priorities and scope, order, champions -- discussion of the documentary outcome III. Meta-language issues -- formal/informal standardization (IEEE, ACM, ANSI???) -- yeller pages -- a standardized way to enforce/ensure conformance with the standard [Jim Miller] IV. Language issues -- multiple returned values [Clinger] -- customizable reader [Clinger] -- number syntax and exactness [Bartley] -- macros [Rees] -- optional arguments [Bartley] -- pattern matching [Haynes] -- structures and opaque objects [ ? ] -- environments and modules [ ? ] -- error handling [ ? ] -- miscellaneous ... `:' in symbols [Bartley] ... `integrable' declarations I have no experience with the formalities of chairing meetings like this, but I'm willing to open the meeting, present my agenda, and see where we go from there. Jonathan suggests that we allot each group 10 minutes or so at the beginning for a brief presentation of their R&D efforts and goals, implementations, user profiles, etc. This might include some philosophy on how Scheme fits their needs, where Scheme might evolve to, and so forth. Short presentations like this should serve to introduce both the players and their philosophies. This should lead naturally into a session for determining our expectations for the meeting and the procedures to be followed. It would help if someone could explain the informal rules we've been playing by since Brandeis. After establishing ground rules, I think we should determine the scope of the issues to be debated and their relative priorities so that we can reorder the agenda as needed. We also should identify `champions' or proposers for each topic. I thought we might want to discuss meta-language topics next, since these may help shape the debate on the language issues themselves. Two evident meta-issues are the `yellow pages' concept and the question of formal standardization of the language. My list of language issues follows Will's. I've spawned `pattern matching' from `optional arguments,' combined `environments' with `modules', added `error handling' for Hal, and thrown a couple of recent topics under the umbrella of `miscellaneous.' It would help if people would announce in advance whether they are prepared to make proposals or otherwise lead the discussion on a given topic, particularly if more than one proposal is to be made on a topic. I would also appreciate some indication of who plans to attend, and which groups would like to make introductory presentations. Please post to this mailing list. Regards, David Bartley  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 9 Jun 87 05:23:15 EDT Date: Tue, 9 Jun 87 05:20:50 EDT From: Alan Bawden Subject: Better late than never To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <211811.870609.ALAN@AI.AI.MIT.EDU> Here, as promised at the Macro Summit Meeting, is a "Modified Macro Proposal". Apologies for not mailing this out sooner, Jonathan and I will share the blame for not being prompt about this. This is not a complete proposal any more than Jonathan's previous macro proposal was. There are many issues of left unaddressed. There is no simple interface for ordinary users to use, that must wait for a separate proposal. There are many minor details left unspecified. The only real difference between this proposal and the last, is that it includes a mechanism that addresses the various variable capture problems. I will assume that the reader is already familiar with Jonathan's previous proposal. (If you care about this stuff, you probably still have a copy.) I will only describe the differences between the two. The basic idea is that the thing we usually call an "environment" (a map from identifiers to locations), can be viewed as the composition of two separate maps: First, a map from identifiers to "variables", followed by a second map from variables to locations. The first map is statically determined by the program text. It is the mapping that compiler writers normally call "alpha conversion". The second map is dynamically determined at runtime. It is the mapping that is actually stored in closures. In other words, consider: (LAMBDA (X) (F X (LAMBDA (X) (F X)))) Although there is one identifier named "X" here, occurring in four places, we all recognize that there are really two separate variables named "X", each occurring just twice. The mapping that tells you which variable named "X" is meant by a particular occurrence of the identifier named "X", varies from place to place in the source code, as determined by the scoping rules of the language. Now the idea is to make this static mapping from identifiers to variables part of syntax tables. This has a nice appeal to it since it makes syntax tables contain -all- of the static, contextual information necessary for interpreting the meaning of a particular piece of code. In one package you get both the mapping from keywords to their current meanings, as well as the mapping from identifiers to their current meanings. To see how this deals with the various capture problems, here is how one might define a vanilla PUSH macro: (DEFINE PUSH-SYNTAX-TABLE (ADD-KEYWORD SCHEME-SYNTAX-TABLE 'PUSH (LAMBDA (SYNTAX-TABLE EXPR) ; (PUSH val var) (LET ((VAL (PREPROCESS SYNTAX-TABLE '() (CADR EXPR))) (VAR (PREPROCESS SYNTAX-TABLE '() (CADDR EXPR)))) (PREPROCESS SCHEME-SYNTAX-TABLE '() `(SET! ,VAR (CONS ,VAL ,VAR))))))) (There are some minor incompatibilities in argument-order here with Jonathan's original, but they should mostly be obvious. The only real difference is the second argument to PREPROCESS, which is new, and will be explained shortly. For the moment, just ignore the '()s.) As in Jonathan's original modest proposal, the writer need not be concerned that the definition of the keyword SET! might be locally redefined in the location where the PUSH-expression was used, because he uses a known syntax table to preprocess the SET! expression he constructs. In this modified proposal, he needn't worry about any local rebindings of CAR either, because the mapping from the identifier named "CAR" found in SCHEME-SYNTAX-TABLE will be the global variable named "CAR", rather than any local variables that happen to have the same name. Thus we don't need to introduce a new ABSOLUTE special form to allow macro writers to make references to known variables. Syntax tables can be used to resolve identifiers into the particular variables whose values are to be accessed. (There might, of course, be -other- reasons for wanting ABSOLUTE.) To illustrate how another kind of capture is avoided, here is a definition of a simple two-operand version of OR: (DEFINE OR2-SYNTAX-TABLE (ADD-KEYWORD SCHEME-SYNTAX-TABLE 'OR2 (LAMBDA (SYNTAX-TABLE EXPR) ; (OR2 op1 op2) (LET ((OP1 (PREPROCESS SYNTAX-TABLE '() (CADR EXPR))) (OP2 (PREPROCESS SYNTAX-TABLE '() (CADDR EXPR)))) (PREPROCESS SCHEME-SYNTAX-TABLE '() `((LAMBDA (TEMP) (IF TEMP TEMP ,OP2)) ,OP1)))))) As usual the writer doesn't need to worry about local redefinitions of the keywords LAMBDA and IF, but notice that he doesn't have to worry that his use of a variable named "TEMP" will accidentally capture any variables of the same name in the second operand. This is because the second operand is first preprocessed in the syntax table that was current where the OR2-expression occurred, and thus any identifiers it may have contained named "TEMP" have already been resolved to the correct variable named "TEMP". Thus there is no need to introduce "Gensyms" into macroexpansions in order to avoid inadvertent capture. Finally, there are situations where the programmer -wants- a capture to occur. For example it writing the LET macro, he wants certain variables in the body of the LET-expression to be captured. Here is where the new argument to PREPROCESS comes in; it gives the user control over the context sensitivity of preprocessed expressions. Specifically, it is a list of identifiers (and keywords) which are to be left syntactically free in the resulting preprocessed expression. To illustrate, here is a simple single variable version of LET: (DEFINE LET1-SYNTAX-TABLE (ADD-KEYWORD SCHEME-SYNTAX-TABLE 'LET1 (LAMBDA (SYNTAX-TABLE EXPR) ; (LET1 ) (LET ((ID (CADR EXPR)) (VAL (PREPROCESS SYNTAX-TABLE '() (CADDR EXPR)))) (PREPROCESS SCHEME-SYNTAX-TABLE '() `((LAMBDA (,ID) ,(PREPROCESS SYNTAX-TABLE (LIST ID) (CADDDR EXPR))) ,VAL)))))) Here the expression in the body of a LET1 is preprocessed using the syntax table current where the LET1-expression occurred, with the identifier-to-be-bound excepted. Thus the static meaning of all the identifiers and keywords in the expression will be correctly determined, while the identifier in question will be left free to be captured by the LAMBDA-expression it is embedded in. Now the way this new argument to PREPROCESS works may strike you as a little odd at first. I used to agree with you. However, the more I work with it, the better I like it. Perhaps the reason it works so well can been seen by thinking of the thing returned by PREPROCESS as a "syntactic closure", similar in nature to the closures returned by LAMBDA-expressions. In both cases you have an environment of some kind, a list of identifiers, and an expression. In both cases all identifiers in the expression are to be taken relative to the environment, -except- those in the given list. The identifiers in the list are to have their meanings determined later. In both cases it is a way of "parameterizing" the expression. The difference is that the LAMBDA-expression closure is invoked with positional arguments, while the syntactic closure is invoked in a kind of "call-by-context" fashion. But even that seems natural in a situation where you are constructing expressions out of other expressions; such context-dependence is just the normal way expressions are combigned! [ I can't resist pointing out that John Lamping is working on something that looks very much like this call-by-context stuff, except for ordinary closures. Anyone who doesn't know about his ideas should look into it, its definitely interesting. ] An implementation of all of this follows. ; A grammar for the core language used as the target of our simple little ; compiler. ; ; core-exp ::= core-var ; | (QUOTE datum) ; | (IF core-exp core-exp core-exp) ; | (SET! core-var core-exp) ; | (CALL core-exp core-exp ...) ; | (BEGIN core-exp core-exp ...) ; | (LAMBDA (bound-var ...) core-exp) ; ; core-var ::= bound-var ; | (FREE name) ; | (ABSOLUTE -path-) ; ; bound-var ::= (VARIABLE name counter) ; ; The bound-vars are all unique, and none are ultimately free. ; Preprocessed expressions ; Calling PREPROCESS just makes a "syntactic closure". ST is a syntax ; table, SYMS is a list of identifiers and keywords that are to remain ; syntactically free in the resulting preprocessed expression. (define (preprocess st syms exp) (vector 'preprocessed st syms exp)) (define (ppexp->st ppexp) (vector-ref (check-ppexp ppexp) 1)) (define (ppexp->syms ppexp) (vector-ref (check-ppexp ppexp) 2)) (define (ppexp->exp ppexp) (vector-ref (check-ppexp ppexp) 3)) (define (preprocessed? obj) (and (vector? obj) (= (vector-length obj) 4) (eq? (vector-ref obj 0) 'preprocessed))) (define (check-ppexp ppexp) (if (preprocessed? ppexp) ppexp (error "not a preprocessed expression" ppexp))) ; Primitive Syntax table manipulation ; ->CORE is used to compile an expression into the core language. ; Syntax tables are just procedures. Note that a syntax table now returns ; a core language expression. (Previously, a preprocessed expression was ; returned.) (define (->core st exp) (st st exp)) ; Keywords (define (add-keyword st0 keyword proc) (lambda (st exp) (if (and (pair? exp) (eq? (car exp) keyword)) ;; Macros must return context-insensitive expressions: ;; (We -could- decide that it would be convenient to use ;; scheme-syntax-table here; as long as it is a documented ;; context.) (->core empty-syntax-table (proc st exp)) (st0 st exp)))) ; Identifiers (define *counter* 0) (define (add-identifier st0 id) (set! *counter* (+ *counter* 1)) (let ((var `(variable ,id ,*counter*))) (lambda (st exp) (if (eq? id exp) var (st0 st exp))))) (define (add-identifiers st ids) (if (null? ids) st (add-identifier (add-identifiers st (cdr ids)) (car ids)))) ; Make a new syntax table in which the identifiers and keywords in SYMS are ; found in SYMS-ST, and all others are found in ELSE-ST. (define (filter-syntax-table syms syms-st else-st) (lambda (st exp) (if (if (pair? exp) (memq (car exp) syms) (memq exp syms)) (syms-st st exp) (else-st st exp)))) ; Syntax tables ; An empty syntax table; defines no keywords or identifiers. (define (empty-syntax-table st exp) (cond ((preprocessed? exp) (->core (filter-syntax-table (ppexp->syms exp) st (ppexp->st exp)) (ppexp->exp exp))) ((or (boolean? exp) (number? exp) (char? exp) (string? exp)) `(quote ,exp)) ((pair? exp) `(call ,@(map (lambda (arg) (->core st arg)) exp))) (else (error "not a syntactically valid expression" exp)))) ; Core syntax table. Understands the primitive expression types, but ; not the derived ones. (define (core-syntax-table st exp) (if (symbol? exp) `(free ,exp) ; or `(absolute ,exp) ? (case (and (pair? exp) (car exp)) ((quote absolute) exp) ((lambda) (let ((st (add-identifiers st (cadr exp)))) `(lambda ,(map (lambda (var) (->core st var)) (cadr exp)) ,(->core st (caddr exp))))) ((set!) `(set! ,(->core st (cadr exp)) ,(->core st (caddr exp)))) ((if) `(if ,(->core st (cadr exp)) ,(->core st (caddr exp)) ,(->core st (cadddr exp)))) ((begin) `(begin ,@(map (lambda (exp) (->core st exp)) (cdr exp)))) (else (empty-syntax-table st exp))))) ; The scheme syntax table defines the derived expression types. (define scheme-syntax-table (do ((st core-syntax-table (add-keyword st (caar z) (cadar z))) (z `((and ,(lambda (st exp) (let ((forms (cdr exp)) (j (lambda (exp) (preprocess st '() exp)))) (cond ((null? forms) `#t) ((null? (cdr forms)) (j (car forms))) (else (preprocess scheme-syntax-table '() `((lambda (p) (if p (and ,@(map j (cdr forms))) p)) ,(j (car forms))))))))) ;; ... (lambda ,(lambda (st exp) (preprocess core-syntax-table '() `(lambda ,(cadr exp) ,(preprocess-body st (cadr exp) (cddr exp)))))) ;; (letrec ,...) ;; ... ;; (quasiquote ,... (absolute scheme-env cons) ...) ) (cdr z))) ((null? z) st))) ; Implements implicit begin and internal defines for lambda bodies. (define (preprocess-body st ids body) (let ((definition? (lambda (exp) (and (pair? exp) (eq? (car exp) 'define)))) (definition-lhs cadr) (definition-rhs caddr)) (let loop ((l body) (lhss '()) (rhss '())) (if (null? l) (error (if (null? lhss) "empty body" "no non-definitions in body") body) (let ((exp (car l))) (if (not (definition? exp)) (let ((all-ids (append lhss ids))) (let ((body (map (lambda (exp) (preprocess st all-ids exp)) l))) (preprocess scheme-syntax-table ids (if (null? lhss) `(begin ,@body) `(letrec ,(map (lambda (lhs rhs) `(,lhs ,(preprocess st all-ids rhs))) (reverse lhss) (reverse rhss)) ,@body))))) (loop (cdr l) (cons (definition-lhs exp) lhss) (cons (definition-rhs exp) rhss)))))))) (define test-syntax-table (do ((st scheme-syntax-table (add-keyword st (caar z) (cadar z))) (z `((push ,(lambda (st exp) (let ((var (preprocess st '() (caddr exp))) (val (preprocess st '() (cadr exp)))) (preprocess test-syntax-table '() `(set! ,var (cons ,val ,var)))))) ;; Your macros here! ) (cdr z))) ((null? z) st)))  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 8 Jun 87 21:45:47 EDT Received: from relay2.cs.net by RELAY.CS.NET id aa28306; 8 Jun 87 17:32 EDT Received: from ti-csl by RELAY.CS.NET id eb24079; 8 Jun 87 17:25 EDT Received: by tilde id AA07226; Fri, 5 Jun 87 17:17:09 CDT Received: by home id AA18999; Fri, 5 Jun 87 17:16:04 cdt Date: Fri, 5 Jun 87 17:16:04 cdt From: David Bartley Message-Id: <8706052216.AA18999@home> To: RRRS-Authors@mc.lcs.mit.edu Cc: Bartley%home%ti-csl.csnet@RELAY.CS.NET Subject: number syntax and exactness I have been moderately concerned for some time that Scheme's external representation for numbers was "gratuitously incompatible" with that of Common Lisp. My worry was that people attempting to use both languages would trip over minor differences. This might be a small annoyance when interacting directly with the user at the keyboard but possibly a major problem when trying to share files containing numeric data. In retrospect, I have decided that the problem is probably not as bad as I feared. Many incompatibilities, like the representation of complex numbers, can be handled by suitably extending the reader for each language to understand the other's syntax. And I'm persuaded that 3+4i is a worthwhile improvement over #c(3 4). I still feel that we should talk through the differences between the two, however, and see if we can iron out some of them. Rather than make a specific proposal, this message outlines the differences I'm aware of and suggests possible actions we could take. I'll plan to make a proposal for discussion at the meeting, but first I want to hear your reactions to these thoughts. (1) Complex numbers in Scheme look like 3+4i; in Common Lisp they look like #c(3 4). Neither notation causes an ambiguity in the standard reader for either language, so I'm amenable to leaving it as an optional extension in each language to support the syntax of the other. (2) The + or - sign in Scheme precedes everything else in a real number; in Common Lisp the sign may be preceded by a radix indicator. Common Lisp does not have the #D (decimal) indicator but has a general purpose #nnR indicator. Allowing the radix indicator and sign to appear in either order seems to be a reasonable extension for both languages. #D and #nnR do not cause ambiguities, so each could be considered an extension to the language of the other. (3) Scheme separates the concept of exactness from type; Common Lisp does not. This is an advantage for Scheme, although the full ramifications haven't been felt yet. I don't understand how to make exactness orthogonal to precision, however (see point 4). What does #e#s123456789 mean if an implementation can't represent the value 123456789 exactly in a short FLONUM? (4) Scheme specifies the precision of a real number using #S (short) or #L (long); Common Lisp specifies the precision of a floating point number with an of S, F, D, or L (for Short, Single, Double, and Long). The Scheme syntax in 7.1.1 allows a precision specification for rational numbers; Common Lisp does not. In Common Lisp, precision is an attribute of (inexact) FLONUMs only. The last paragraph of 6.5.3 of R3RS says essentially the same thing, clarifying the syntax in 7.1.1. This seems inconsistent to me, though, since it relates "precision" to the FLONUM representation type whereas I see "precision" as an attribute of "inexactness." If we can speak of inexact integers, then we should perhaps be able to speak of short or long ones without requiring that they be implemented as FLONUMs. What might be meant in Scheme by a "short integer" like #s123456789? Surely we don't mean that the number is to be arbitrarily truncated to a machine-specific fixnum, since that may produce a result which loses all significance in the number. The only interpretation that makes sense to me is that #S and #L specify that the number is inexact and may be stored in a fixed number of bits in a way that preserves the significant digits as well as it can. Floating point is one such representation but others exist and may be more suitable for those implementations not blessed (?) by good FLONUM support. I see two alternatives. We could tie the specification of precision to FLONUMs only, as we do now, or we could relate precision to exactness. I prefer the latter. One way would be to merge the productions for and in 7.1.1 to give --> | #E | #S | #L | #I where #E specifies an exact number, #I an inexact number of default precision, #S and #L inexact numbers of (possibly) differing precision, and leaving the exactness to the discretion of the implementation, except that integers expressed without decimal points or exponent notation are assumed exact. This is an upwardly compatible liberalization of R3RS. Another way, which I prefer, is to kill three birds with one stone and use the exponent marker to indicate exactness and precision as well as scale. Suppose we took Common Lisp's S (short), F (single), D (double) and L (long) exponent markers and interpreted them essentially as Common Lisp does. That is, all denote inexactness as well as specifying precision. However, Scheme does not require numbers written with exponent notation to be FLONUMs as Common Lisp does, so we are free to represent 7.5s3 as the inexact integer 7500 if we want. Common Lisp uses the E exponent marker for the default FLONUM precision. We could do the same but it would be incompatible with R3RS for E to imply inexactness. We could instead use E to specify exact numbers, at the expense of compatibility with Common Lisp. (5) #S denotes a short precision number in Scheme and a structure object in Common Lisp. This can be lived with. However, it is the only conflict I can think of between the two languages in the use of dispatching macro characters. If we were to choose to allow precision to be specified via exponent markers, the #S notation would no longer be needed in Scheme. (6) Scheme specifies that `#' is printed rather than a digit when the format calls for more digits than are internally represented. Common Lisp does not address this issue, although some implementations use the digit `0' in this case. This seems to be a relatively harmless discrepancy, although I can imagine a Common Lisp reader choking up a bit. (7) Scheme allows ratios to have exponents; Common Lisp does not. It's their loss, I guess. ---- Summary: Let's clean up the exactness/precision problem and try to free up #S. --db--  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 3 Jun 87 11:07:54 EDT Date: 03 Jun 87 0805 PDT From: Dick Gabriel Subject: OOPSLA Lisp and Object-Oriented Programming Workshop To: rrrs-authors@MC.LCS.MIT.EDU There will be a workshop on Lisp and Object-Oriented Programming on Monday October 5 from 9am until noon at OOPSLA. The Common Lisp Object System (CLOS) will be the highlight of the workshop, with presentations about CLOS by the designers along with critiques, analyses, and responses to the Object System, the latter selected based on contributed position papers. Attendance will be limited to people who know Lisp and are familiar with existing object-oriented languages. If you would like to attend, please send me a 1-2 page description of your position regarding either the Common Lisp Object System or Lisp/object-oriented programming before August 1; netmail is acceptable. Invitations will be sent on September 1. Attendance is limited to 35 people. Richard P. Gabriel Lucid, Inc 707 Laurel Street Menlo Park, CA 94025 (415)329-8400 rpg@sail.stanford.edu  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 1 Jun 87 21:23:52 EDT Received: from relay2.cs.net by RELAY.CS.NET id aa08552; 1 Jun 87 21:02 EDT Received: from tektronix.tek.com by RELAY.CS.NET id ak19626; 1 Jun 87 20:55 EDT Received: by tektronix.TEK.COM (5.51/6.22) id AA07280; Mon, 1 Jun 87 16:11:52 PDT Received: by tekchips.TEK.COM (5.51/6.19) id AA08602; Mon, 1 Jun 87 16:14:00 PDT Message-Id: <8706012314.AA08602@tekchips.TEK.COM> To: rrrs-authors@mc.lcs.mit.edu Cc: willc%tekchips.tek.com@RELAY.CS.NET Subject: customizable reader Date: 01 Jun 87 16:13:58 PDT (Mon) From: willc%tekchips.tek.com@RELAY.CS.NET Here's a proposal for the yellow pages: a customizable reader patterned after Guy Steele's in CLtL. It adds yet another optional argument to read, but at least it doesn't have any global state. If you like global state you can, of course, redefine the READ and READ-DELIMITED-LIST procedures to use a different default readtable. The proposal does not support the following Common Lisp features: non-preservation of whitespace, eof-error-p, eof-value, recursive-p, zero return values, packages. Since the status of #\| and #\\ is not specified, it is not specified whether there are any single or multiple escape characters in the standard readtable. Et cetera. I haven't bothered to specify the token parser used by the standard readtable because the number syntax is still a topic of discussion. The description assumes two new types: the readtable and syntax types. These types do not have to be distinct from existing types. In my prototype implementation I use vectors. If we had structures, they would undoubtedly be structures. ================================================================ (read) --> object (read port) --> object (read port readtable) --> object The readtable argument defaults to the standard readtable. By specifying an explicit readtable you can inflict your own crazy syntax on the characters read from the port. (read-delimited-list char) --> object (read-delimited-list char port) --> object (read-delimited-list char port readtable) --> object Following CLtL. This packages up most of the hair involved with handling comments. I observe that CLtL does not quite give enough information for a user to write the #\( and #\) macro procedures, which must deal with the dotted pair syntax in addition to comments. Neither does this proposal: I think #\(, #\), and #\; have to be magic, which makes it hard for a user to make #\[ and #\] behave exactly like #\( and #\). (copy-readtable) (copy-readtable readtable) --> readtable The argument defaults to the standard readtable. Returns a copy of its argument. Calls to set-token-parser!, set-character-syntax!, and set-dispatch-character! on the copy do not affect the original. (get-token-parser readtable) --> parser Returns the readtable's token parser. The token parser is a procedure of three arguments s, i, and j. The token parser must return a token parsed from (substring s i j) or else signal an error. The token parser used by the standard readtable always returns a symbol or number if it doesn't signal an error. The token parser is bypassed for tokens that contain single or multiple escape characters, since these always indicate a symbol. Neither is the token parser called for whitespace, illegal, macro, or dispatch characters. Passing a string and indexes instead of just a string is an efficiency hack suggested by David Bartley. To prevent the token parser from depending on the contents of its string argument outside of (substring s i j), I propose that every token parser foo be equivalent to (lambda (s i j) (foo (substring s i j) 0 (- j i))) This also implies that the token parser is not allowed to side effect its string argument. (set-token-parser! readtable parser) --> #!unspecified This changes the token parser of the first argument to be the second argument. By changing the token parser and changing all characters to be either constituent or whitespace, you can have complete control over the parser. More realistically, this hook lets you experiment with weird number syntaxes et cetera. (get-character-syntax readtable char) --> syntax Returns the character syntax associated with the given character in the given readtable. (set-character-syntax! readtable char syntax) --> #!unspecified Changes the character syntax of the given character in the given readtable. (make-character-syntax 'constituent) --> syntax (make-character-syntax 'whitespace) --> syntax (make-character-syntax 'illegal) --> syntax (make-character-syntax 'single-escape) --> syntax (make-character-syntax 'multiple-escape) --> syntax (make-character-syntax 'non-terminating-macro proc) --> syntax (make-character-syntax 'terminating-macro proc) --> syntax (make-character-syntax 'macro proc) --> syntax Manufactures syntax objects. The 'macro option is an alias for the 'terminating-macro option. The proc is a procedure of three arguments: the macro character that has just been consumed (this is so you can use one proc for several related macro characters), a port, and a readtable. (It would gross me out if any of these arguments were optional.) See CLtL for explanation of what the options mean. (get-dispatch-character readtable char) --> proc Returns the proc associated with octathorpe macro characters. The proc takes three arguments: the macro character just consumed, a port, and a readtable. (set-dispatch-character! readtable char proc) --> #!unspecified Defines new octathorpe macro characters.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 21 May 87 15:58:45 EDT Date: Thu, 21 May 87 15:59:03 EDT From: Jonathan A Rees Subject: correction To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <203657.870521.JAR@AI.AI.MIT.EDU> In my previous message I inadvertantly omitted Don Oxley from the list of authors whose plans are unknown.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 21 May 87 14:08:08 EDT Date: Thu, 21 May 87 14:08:26 EDT From: Jonathan A Rees Subject: who will be there To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <203585.870521.JAR@AI.AI.MIT.EDU> This group has no policy on either membership or voting; should it? Membership on rrrs-authors currently depends on being nominated by someone already on the list. Is being on rrrs-authors the same as being invited to the June meeting? The meeting is apparently not open to the public -- we haven't announced it on the scheme@mc list. In fact, the membership of scheme@mc isn't even aware of the existence of rrrs-authors or the imminence of the meeting. It seems like a good idea to restrict attendance somewhat, but are we going overboard in being so exclusive? I don't necessarily want to answer yes, I just want to say that I can't remember these questions ever having been discussed. I would like to encourage Julian Padget or any of the other Eulisp designers to come. ---- Here is my current list of people who have told me they plan to attend. Norman Adams David Bartley (will probably miss Saturday) Michael Blair Matthias Felleisen Bert Halstead Chris Hanson Chris Haynes Eugene Kohlbecker David Kranz Jim Miller Jim Philbin John Ramsdell Jonathan Rees Bill Rozas G J Sussman I assume that the following people will be there, although I can't recall having received definite word from them (I forget such things): Will Clinger Richard Kelsey Mitch Wand The following people participated in the debate over the date, although they haven't confirmed that they'll attend: Kent Dybvig Dick Gabriel Kent Pitman Dan Friedman won't be able to attend. Among the authors of the R^nRS's (n = 0,1,2,3) this leaves the following people unaccounted for: Hal Abelson Gary Brooks Guy Steele I don't think there's any burning need at this point to inform me of your plans one way or the other, since the dates have been set and the room has been reserved. If you show up you show up. What time should we start in the morning? I have reserved the room for 9 to 5, but most of us are either night people or will be jet-lagging, so would 10 be better? - Jonathan  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 21 May 87 13:12:57 EDT Date: Thu, 21 May 87 13:13:15 EDT From: Jonathan A Rees Subject: June meeting -- accommodations To: rrrs-authors@MC.LCS.MIT.EDU Message-ID: <203556.870521.JAR@AI.AI.MIT.EDU> From: CSC2::EEK%ECL1.SPAN at STAR.STANFORD.EDU To: ECL1::STAR::"rrrs-authors@mc.lcs.mit.edu" at ECL1.SPAN Re: June meeting Have any local arrangements for a hotel been made? I called the Marriott reservation number this morning and found out that they don't have many rooms available at the Cambridge Marriott. I have as yet made no arrangements. Given that there are so few people it's probably best if everyone fended for themselves. But here is some information. All the big hotels seem to have special rates for official MIT visits. I'm not sure how anal the hotels are about this; I don't believe MIT has to be directly involved in order for you to get the rate, and one person I talked to said that the rate is available to people who just come to MIT for, say, a lecture. So by all means ask to get the MIT rate. If for some reason this doesn't work give me a call and I'll see what I can do. Here are some nearby hotel possibilities: name phone 617- approx distance MIT's rate regular rates from meeting per room single/double Marriott 494-6600 0.4 mile 99 (I forgot to ask) Royal Sonesta 491-3600 1 mile 95 130/145 Hyatt Regency 492-1234 1.1 mile 89 155 and up Howard Johnson 492-7777 1.4 miles 78/84 85/95 All of them said they had rooms available for 26-28 June. Note that the rate is usually per room, so if you double up you'll save a lot of money. If you'd like help finding a roommate let me know. The brand new Cambridge Marriott is extremely convenient to MIT and the T. All the heavy construction is over, so I don't think noise will be a problem. I recommend it, although I've never stayed there myself. But you should act soon if what Eugene says is true. If these prices are too steep, there are many inns and guest houses around with rates as low as $15 (as of last year), but few are close to MIT, and I have no experience with them. I have a list of these, prepared by MIT, which I can send (US mail) to anyone who wants it. - Jonathan  Received: from STAR.STANFORD.EDU (TCP 4402400005) by MC.LCS.MIT.EDU 20 May 87 12:56:57 EDT Received: from ECL1 by STAR.STANFORD.EDU via MAIL-11 with DECnet; Wed, 20 May 87 09:55:45-PST From: CSC2::EEK%ECL1.SPAN@STAR.STANFORD.EDU Subject: June meeting To: ECL1::STAR::"rrrs-authors@mc.lcs.mit.edu"@ECL1.SPAN Have any local arrangements for a hotel been made? I called the Marriott reservation number this morning and found out that they don't have many rooms available at the Cambridge Marriott. --Eugene  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 May 87 00:15:36 EDT Date: Wed, 20 May 87 00:15:53 EDT From: Alan Bawden Subject: Should ":" be an extended alphabetic character? To: RRRS-Authors@MC.LCS.MIT.EDU Message-ID: <202573.870520.ALAN@AI.AI.MIT.EDU> By my reading of the Thrice Revised Report, in implementations that truely support ":" as an extended alphabetic character it should be the case that: (eq? 'user:cons 'lisp:cons) => #F Yet in implementations where ":" provides access to a Common Lisp style package system it will be the case that this returns #T. Thus it seems to me that the two are incompatible. If you wish to permit Scheme implementations to access a package system using ":", while continuing to conform to the definition of the language, then you have to give ":" some status other than extended alphabetic.  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 19 May 87 19:09:13 EDT Received: from relay2.cs.net by RELAY.CS.NET id ab20747; 19 May 87 18:47 EDT Received: from tektronix.tek.com by RELAY.CS.NET id ad19307; 19 May 87 18:41 EDT Received: by tektronix.TEK.COM (5.51/6.21) id AA01520; Tue, 19 May 87 13:20:35 PDT Received: by tekchips.TEK.COM (5.51/6.19) id AA22634; Tue, 19 May 87 13:02:51 PDT Message-Id: <8705192002.AA22634@tekchips.TEK.COM> To: bartley%home%ti-csl.csnet@RELAY.CS.NET Cc: RRRS-Authors@mc.lcs.mit.edu, willc%tekchips.tek.com@RELAY.CS.NET Subject: Re: Should ":" be an extended alphabetic character? In-Reply-To: Your message of Mon, 18 May 87 17:38:47 cdt. <8705182238.AA17077@home> Date: 19 May 87 13:02:47 PDT (Tue) From: willc%tekchips.tek.com@RELAY.CS.NET I'm willing to be convinced otherwise, but right now I'm in favor of leaving ":" as an extended alphabetic character. Maybe somebody should explain to me how banning ":" would help. Here's how I see it: When porting Scheme code to Common Lisp (a thing few of us really want to do), you can pretty much get away with replacing all occurrences of ":" by a character that's illegal in Scheme but a constituent in Common Lisp, such as "[". When porting Common Lisp code to Scheme, there are several problems you can have with symbols and packages: 1. Symbols in the keyword package. You can pretty much get by with making ":" into a non-terminating macro character so that :FOO turns into (QUOTE FOO). My apologies for not having the customizable reader proposal out yet; you can do fairly well without a customizable reader by replacing all occurrences of " :" by " '". 2. Qualified symbols that are not in the USER package. Since ":" is an extended alphabetic character in Scheme, you can just leave these alone. 3. Qualified symbols that are in the USER package. Here you lose, unless the symbol is qualified wherever it appears. I would think, though, that even the Common Lisp community considers it poor style to intermix USER:FOO and FOO within the same file. 4. Unqualified symbols that are in the USER package. You can leave these alone. 5. Unqualified symbols that are not in the USER package. Here you lose big, but there's no way to avoid losing big without adding a package system to Scheme. I know you can use environments to fake some things, but a silk purse is a poor substitute for the sow's ear. The most severe problems come from unqualified symbols (5), so I don't see how banning ":" from Scheme identifiers would help. To the contrary, banning ":" would definitely cause new problems with qualified symbols (2). On the other hand, I've never converted any Common Lisp code that made significant use of packages so I don't know what I'm talking about. Peace, Will  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 19 May 87 12:16:22 EDT Received: from relay2.cs.net by RELAY.CS.NET id aa16101; 19 May 87 12:07 EDT Received: from ti-csl by RELAY.CS.NET id ab17227; 19 May 87 12:02 EDT Received: by tilde id AA16633; Tue, 19 May 87 09:33:05 CDT Received: by home id AA26570; Tue, 19 May 87 09:33:02 cdt Date: Tue, 19 May 87 09:33:02 cdt From: David Bartley Message-Id: <8705191433.AA26570@home> To: andy@ADS.ARPA Cc: RRRS-Authors@mc.lcs.mit.edu, Bartley%home%ti-csl.csnet@RELAY.CS.NET In-Reply-To: Andy Cromarty's message of Mon, 18 May 87 18:31:21 PDT <8705190131.AA04880@hobbes.ads.arpa> Subject: Should ":" be an extended alphabetic character? > We have experienced little difficulty with Common LISP -> R3RS > code ports, precisely because ":" is an extended alphabetic character. > I advocate leaving it this way. My problem is not porting code written in Common Lisp over to Scheme. Leaving ":" as a constituent certainly works well for that purpose. My problem is implementing the two languages in a single shared namespace. Procedures written in either language will be exposed to symbols read by the other's reader. --db--  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 19 May 87 11:17:03 EDT Date: Tue, 19 May 87 11:17:01 EDT From: Jonathan A Rees Subject: Should ":" be an extended alphabetic character? To: bartley%home%ti-csl.csnet@RELAY.CS.NET cc: RRRS-Authors@MC.LCS.MIT.EDU In-reply-to: Msg of Mon 18 May 87 17:38:47 cdt from David Bartley Message-ID: <202163.870519.JAR@AI.AI.MIT.EDU> Date: Mon, 18 May 87 17:38:47 cdt From: David Bartley To: RRRS-Authors at mc.lcs.mit.edu Re: Should ":" be an extended alphabetic character? I have no opinion on this. When it came up before, there were some objections to removing : from the list of extended alphabetics, and as editor I took the "conservative" stance of making minimal changes to the report. I have no strong opinion on this question. I wouldn't be sad to see : classified with / | [ ] { }. In fact such a change would reduce by one the number of bugs in my implementation (pseudoscheme).  Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 19 May 87 09:52:57 EDT Received: by GENEVA.AI.MIT.EDU; Tue, 19 May 87 08:25:28 edt Date: Tue, 19 May 87 08:25:28 edt From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas) Message-Id: <8705191225.AA07690@geneva> To: andy@ADS.arpa Cc: RRRS-Authors@mc.lcs.mit.edu, bartley%home%ti-csl.csnet@RELAY.CS.NET In-Reply-To: Andy Cromarty's message of Mon, 18 May 87 18:31:21 PDT <8705190131.AA04880@hobbes.ads.arpa> Subject: Should ":" be an extended alphabetic character? Reply-To: jinx@zurich.ai.mit.edu I don't think the issue here is porting code from one language to another, but rather to have implementations of both languages coexist in a single Lisp environment, so that procedures written in one or the other are mutually "callable". I suspect the problem arises when Scheme symbols reside in a Common Lisp package (called scheme ?) which is part of the startup set of packages. Then Scheme code would have a hard time referencing variables (or invoking procedures) whose names belong to packages which are not in the "current" inheritance chain. CL code would also have a hard time referencing Scheme variables (or invoking Scheme procedures) whose name had a ':' character. Note that the interpretation of ':' at read time is not really an issue, since the reader could be conditionalized according to the language being read. If the above is a correct statement of the problem, there are two possibilities: 1) Remove ':' from Scheme. The Scheme reader could then treat ':' the same way as the CL reader, and intern the symbol in the right place. What it would do with the function/value distinction in that package is quite a different matter. 2) Add some non-standard reader-syntax which allows mutual references. For example, assuming that #: is not a predefined reader macro in CL (there are so many, I don't know which mean anything and which do not), #:foo in CL would specify scheme:foo, and #:foo:bar in CL would be the symbol in the scheme package whose print name is foo:bar. Similarly #:foo in Scheme would represent the CL symbol foo (in user ?), while #:foo:bar in Scheme would be the way to type the CL symbol bar in package foo. Although I like to use ':' in my identifiers, I really don't care much either way. I'm just worried about gratuituous compatibilities with CL caused by features of CL which I consider distasteful.  Received: from grape.ads.ARPA (TCP 1200400070) by MC.LCS.MIT.EDU 18 May 87 22:12:41 EDT Received: from ads.ARPA (ads.arpa.ARPA) by grape.ads.ARPA (4.12/4.7) id AA14446; Mon, 18 May 87 18:30:22 pdt Received: by hobbes.ads.arpa (3.2/SMI-3.2) id AA04880; Mon, 18 May 87 18:31:21 PDT Date: Mon, 18 May 87 18:31:21 PDT From: andy%hobbes@ads.ARPA (Andy Cromarty) Message-Id: <8705190131.AA04880@hobbes.ads.arpa> To: RRRS-Authors@mc.lcs.mit.edu Subject: Re: Should ":" be an extended alphabetic character? Cc: bartley%home%ti-csl.csnet@RELAY.CS.NET Reply-To: andy@ADS.arpa We have experienced little difficulty with Common LISP -> R3RS code ports, precisely because ":" is an extended alphabetic character. I advocate leaving it this way. That is, (cons foo:x (list 3)) is meaningful and well-defined as an operation on the unique variable named "foo:x" in both Scheme and Common LISP, for the obvious reasons, and in nearly all cases we've encountered, it ports cleanly without any additional attention or concern. The cleanliness of this porting task is a function of the uniqueness of colon-qualified symbols in Scheme, which in turn is in a sense guaranteed by the very property of ":" being extended-alphabetic. We have implemented a macro packages, using our local definition of "macro", to map just enough of the Common LISP package system's constructs into Scheme so as to permit CL code to run, without making it desirable to use this pseudo-package kludge when writing new code. (In my view, discouraging package use in this manner is an important design feature of this approach.) asc p.s. If you want to worry about ":" and Common LISP code ports, worry about keywords. The only simple way to get your CL code to work in Scheme (as far as we've been able to see so far) is to quote all CL keywords -- which, fortuitously, happens to work, since (1) ':foo = :foo in CL and (2) R3RS doesn't contain (SYM)EVAL. But it does require either alteration of the CL source or preprocessing of the source before/during loading into the Scheme environment.  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 18 May 87 22:05:32 EDT Date: Mon, 18 May 87 21:04:26 est From: R. Kent Dybvig Received: by iuvax.cs.indiana.edu; id AA10631; Mon, 18 May 87 21:04:26 est To: RRRS-Authors@mc.lcs.mit.edu, bartley%home%ti-csl.csnet@RELAY.CS.NET Subject: Re: Should ":" be an extended alphabetic character? I remember resolving to remove ":" from the set of extended alphabetic characters, but apparently I was wrong...the report does indeed say that ":" is an extended alphabetic character. I would (again) vote that it be removed from this set. One of our stated goals (which we of course fall short of in other cases) is to avoid gratuitous incompatibilities with Common Lisp. Removing it means only that portable programs should not use it, not that we are planning to standardize on packages!  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 18 May 87 20:25:42 EDT Received: from relay2.cs.net by RELAY.CS.NET id aa09388; 18 May 87 20:18 EDT Received: from ti-csl by RELAY.CS.NET id aa12336; 18 May 87 20:15 EDT Received: by tilde id AA03760; Mon, 18 May 87 17:38:55 CDT Received: by home id AA17077; Mon, 18 May 87 17:38:47 cdt Date: Mon, 18 May 87 17:38:47 cdt From: David Bartley Message-Id: <8705182238.AA17077@home> To: RRRS-Authors@mc.lcs.mit.edu Subject: Should ":" be an extended alphabetic character? This has come up before, but not in the context of the current standardization cycle. The ":" character is defined in 2.1 of R3RS to be one of the extended alphabetic characters and thus a valid constituent of a Scheme identifier. This is a minor inconvenience to those of us who would like to carry over the C*mm*n Lisp notation for package qualifiers into Scheme implementations that are either based on C*mm*n Lisp or otherwise coresident with C*mm*n Lisp. What to do? (1) Convince everyone that ":" should not be an extended alphabetic character. (2) Allow users to declare which meaning of ":" is to be used (e.g., on a file by file basis). (3) Leave ":" alone and use a different notation for package qualifiers. Is there any hope for #1? Is #2 acceptable? Any suggestions for #3? Has anyone else faced this problem? [Note: I am not advocating packages. I hate them. I'm merely concerned that I find a reasonable way to live with them when procedures in the two languages need to talk to each other.] --db--