Received: from BFLY-VAX.BBN.COM by MC.LCS.MIT.EDU 11 Jul 86 12:26:51 EDT Date: Fri, 11 Jul 86 12:22:23 EDT From: "Curtis A. Scott" To: michael@cs.columbia.edu cc: scheme@mc.lcs.mit.edu Subject: tiny scheme It depends on the level of functionality you desire. A minimal kernel with only the basic operations as primitives could be very small. I wrote a student subset kernel in Z80 assembler which was much less than 32K bytes, and I believe someone did one for the Apple II of similar size. You have then moved much of the size of the system off into interpreted code in the heap. None of the "real" systems are this small; the MIT handcoded 68000 scheme was around 64K of code.  Received: from MEDIA-LAB.MIT.EDU by MC.LCS.MIT.EDU 11 Jul 86 06:31:52 EDT Received: by MEDIA-LAB.MIT.EDU (5.31/4.8) id AA06695; Fri, 11 Jul 86 06:31:17 EDT Date: Fri, 11 Jul 86 06:31:17 EDT From: William H Coderre Message-Id: <8607111031.AA06695@MEDIA-LAB.MIT.EDU> To: scheme@mc.lcs.mit.edu Subject: MacScheme Can someone summarize the MacScheme situation? I've played briefly with a fairly old version. I heard there was a new version. Graphics? Toolbox? Editor (I remember it being a loser)? Compatibility? Thank You "Tzima Narki"......................,...........,.............bc  Received: from hplabs.HP.COM by MC.LCS.MIT.EDU 10 Jul 86 22:35:05 EDT Received: from hplabsc by hplabs.HP.COM ; Thu, 10 Jul 86 19:32:17 pdt Received: by hplabsc ; Thu, 10 Jul 86 19:33:39 pdt Date: Thu, 10 Jul 86 19:33:39 pdt From: Walt Hill Message-Id: <8607110233.AA15511@hplabsc> To: MICHAEL@CS.COLUMBIA.EDU, scheme@MC.LCS.MIT.EDU Subject: Re: [Michael van Biema : How big would a "minimal" scheme interpreter be?] MIT CScheme will run on an HP Integral PC with 1.5Meg RAM with room for only 40K items in the heap. Walt Hill  Received: from CS.COLUMBIA.EDU by MC.LCS.MIT.EDU 10 Jul 86 15:59:39 EDT Date: Thu 10 Jul 86 15:58:42-EDT From: Michael van Biema Subject: [Michael van Biema : How big would a "minimal" scheme interpreter be?] To: scheme@MC.LCS.MIT.EDU Message-ID: <12221633641.27.MICHAEL@CS.COLUMBIA.EDU> Return-Path: <@MC.LCS.MIT.EDU:Network_Server@MIT-MULTICS.ARPA> Received: from MC.LCS.MIT.EDU by CS.COLUMBIA.EDU with TCP; Thu 10 Jul 86 15:53:57-EDT Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 10 Jul 86 15:28:35 EDT Received: from MC.LCS.MIT.EDU by MIT-MULTICS.ARPA TCP; 10-Jul-1986 15:28:06-edt Received: from CS.COLUMBIA.EDU by MC.LCS.MIT.EDU 10 Jul 86 15:22:56 EDT Date: Thu 10 Jul 86 15:22:04-EDT From: Michael van Biema Subject: How big would a "minimal" scheme interpreter be? To: scheme@MC.LCS.MIT.EDU Message-ID: <12221626971.27.MICHAEL@CS.COLUMBIA.EDU> Where minimal means just the interpreter no heap etc. Michael ------- -------  Received: from CS.COLUMBIA.EDU by MC.LCS.MIT.EDU 10 Jul 86 15:22:56 EDT Date: Thu 10 Jul 86 15:22:04-EDT From: Michael van Biema Subject: How big would a "minimal" scheme interpreter be? To: scheme@MC.LCS.MIT.EDU Message-ID: <12221626971.27.MICHAEL@CS.COLUMBIA.EDU> Where minimal means just the interpreter no heap etc. Michael -------  Received: from A.ISI.EDU by MC.LCS.MIT.EDU 7 Jul 86 12:24:30 EDT Date: 7 Jul 1986 12:23-EDT Sender: VERACSD@A.ISI.EDU Subject: CL Compatiblity Package From: VERACSD@A.ISI.EDU To: scheme@MC.LCS.MIT.EDU Cc: veracsd@A.ISI.EDU Message-ID: <[A.ISI.EDU] 7-Jul-86 12:23:31.VERACSD> Does anyone have a CommonLisp compatiblity package for Scheme that they are willing to share? I have developed a rudimentary package for MacScheme, but am interested in something more complete. -- Cris Kobryn  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 JUN 86 14:59:40 EDT Date: Sun, 29 Jun 86 14:58:30 EDT From: Jonathan A Rees Subject: [INGRIA@G.BBN.COM: Scheme for LISPM] To: INGRIA@BBNG.ARPA cc: SGR@SCRC-STONY-BROOK.ARPA, Scheme@MC.LCS.MIT.EDU In-reply-to: Msg of Fri 27 Jun 86 17:02 EDT from Stephen G. Rowley Message-ID: <[AI.AI.MIT.EDU].63300.860629.JAR> Date: Thu, 26 Jun 1986 16:47 EDT Message-ID: From: INGRIA@G.BBN.COM To: INFO-LISPM@MC.LCS.MIT.EDU Subject: Scheme for LISPM Does anyone have an implementation of Scheme that runs on LISPMs? It would be useful for us to have a version that runs on Rel6 on 36XXs. Thanks in advance. I wrote one last summer. It's not great for development, since there are no debugging facilities besides TRACE, but it works. It is written in Common Lisp, but it has been comditionalized to make it also work in Rel 6 Symbolics Common Lisp (which is full of bugs). If you're at BBN, you should contact Don Allen and get a copy from him. Otherwise contact me (JAR@MIT-AI) and I'll give you more information. Jonathan  Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 27 Jun 86 19:40:24 EDT Received: from GROUSE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 31612; Fri 27-Jun-86 17:02:04 EDT Date: Fri, 27 Jun 86 17:02 EDT From: Stephen G. Rowley Subject: [INGRIA@G.BBN.COM: Scheme for LISPM] To: Scheme@MIT-MC.ARPA Message-ID: <860627170237.3.SGR@GROUSE.SCRC.Symbolics.COM> This sounds like a question for people on this list: Date: Thu, 26 Jun 1986 16:47 EDT Message-ID: From: INGRIA@G.BBN.COM To: INFO-LISPM@MC.LCS.MIT.EDU Subject: Scheme for LISPM Does anyone have an implementation of Scheme that runs on LISPMs? It would be useful for us to have a version that runs on Rel6 on 36XXs. Thanks in advance. -30- Bob  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Jun 86 15:47:20 EDT Received: from indiana by csnet-relay.csnet id ah03896; 15 Jun 86 15:44 EDT Date: Sun, 15 Jun 86 11:44:22 est From: Chris Haynes To: scheme@MC.LCS.MIT.EDU Subject: Logic Continuations (Abstract) The following abstract of a paper, to be delivered at the Third International Conference on Logic Programming (London, July 1986), may be of interest to the Scheme community. The paper is also available as Indiana University Computer Science Department Technical Report No. 183, and is to appear in The Journal of Logic Programming in a somewhat revised from. Logic Continuations by Christopher Haynes We develop a `complete' embedding of logic programming into Scheme---a lexically scoped Lisp dialect with first-class continuations. Logic variables are bound in the Scheme environment and the success and failure continuations are represented as Scheme continuations. To account for the semantics of logic variables and failure continuations, the state-space model of control is modified in a novel way that generalizes the trail mechanism. This assures that logic variable bindings are properly restored when continuations are invoked to perform `lateral' control transfers that are not possible in a traditional logic programming context. It is thereby possible to obtain greater control over logic program behavior by using continuations as first-class objects.  Received: from C.CS.CMU.EDU by MC.LCS.MIT.EDU 11 Jun 86 14:40:44 EDT Received: ID ; Wed 11 Jun 86 14:37:45-EDT Date: Wed, 11 Jun 1986 14:37 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Tim Finin Cc: scheme@MC.LCS.MIT.EDU Subject: Scheme for AI based CAI I've been involved pretty deeply in the Common Lisp design effort for several years. For what it's worth, I agree with most of what Tim Finin said about Common Lisp vs. Scheme for education. Common Lisp has a lot of ugly things in it that are there for compatibility with older Lisps, for efficiency on certain machines, and for support of large systems. There are a lot of features built into Common Lisp that increase the conceptual load on the first-time user, but that are valuable for the experienced user who has to do a big job in a hurry. Scheme is smaller, cleaner, and more willing to break with some of the bad ideas of the past. I would use Common Lisp for any really big job, especially if it needs to be portable to a lot of machines. At some point, if I were training students to go out into the world and design intelligent systems, I'd make sure that they were exposed to Common Lisp. But for teaching the fundamental principles of Computer Science, Scheme provides equal or better support, with many fewer distracting features and mis-features. I think that students trained in Scheme would have no trouble learning Common Lisp later, though it would be useful to warn them about the separate function and value namespaces in Common Lisp before they get too used to Scheme's way of doing things. And I'd try not to present Scheme in such a way that the students will be too pure to deal with a "dirty" language like Common Lisp when the time comes. Some of that dirt is there for a reason, and the rest is the price we had to pay to make Common Lisp a widely agreed-upon standard. In the long run, I don't think that the need for a larger machine to run Common Lisp will matter: the only real difference in resource needs is that Common Lisp needs a couple of megabytes more than Scheme (either real or virtual memory will do) to hold the full language, and that difference tends to wash out once megabit memory chips start turning up as the prize in Cracker Jacks. But for the next year or two, the choice on the smallest machines will be between a full Scheme and a very stripped down Common Lisp, and under those conditions Scheme wins. I hope that Scheme won't become the Pascal of the 90's. I hate Pascal. -- Scott Fahlman  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 11 Jun 86 13:16:10 EDT Received: from [1100455600] by CSNET-RELAY.ARPA id ac01092; 11 Jun 86 13:05 EDT From: Tim Finin Subject: Scheme for AI based CAI To: scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA Date: Wed, 11 Jun 86 12:59 EDT What follows is a msg from Mark Richer via the AIED digest concerning the use of Scheme for building AI based educational systems. I've included my response. Others may have relevant thoughts to share with him. Tim -------------------------------------------------------------------------- From: Mark Richer on Wed 11 Jun 1986 at 12:00 To: ai-ed-outgoing@SUMEX-AIM.ARPA Subj: 1:8 Scheme; AI-ED questionnaire AI-ED Digest Tuesday, 10 June 1986 Volume 1 : Issue 8 Today's Topics: Scheme, anyone? AI and Education questionnaire Date: Tue 10 Jun 86 08:29:38-PDT From: Mark Richer Subject: Scheme, anyone? I have been asked to give advice regarding the appropriateness of using Scheme for a development effort in Intelligent Computer Assisted Instruction. Although this is partly a research effort also, a clear goal is testing and installing the software in high school classrooms. The hardware available to this project is HP workstations. Admittedly I know little about Scheme. However, my initial reaction is that no advantages Scheme could provide over CommonLisp could offset the disadvantages of using a language without a large user base for the purposes of software development and installation. CommonLisp promises to offer portability (of course there are still problems, e.g., graphics) and a large user community, and has other obvious advantages because of the general acceptance of Lisp in the U.S. AI community. I'd appreciate some feedback from people that are familiar with Scheme, particularly if you have used it for developing a large AI-based system. Can any argument be presented to justify the resources necessary to train people in Scheme and build and maintain a system in this UnCommonLispLike language? In other words, what is so special about Scheme compared to CommonLisp? Mark ... rest of digest deleted ... ------------------------------------------------------------------------- From: Tim Finin on Wed 11 Jun 1986 at 12:49 To: Mark Richer Cc: Bonnie Webber , Ai Bulletin Board Subj: Scheme Here are some thought on Scheme vs. CommonLisp. We use Common Lisp in our research efforts (mostly) and Scheme as an instructional language. We are using it in both our graduate and undergraduate programs in the core software/programming languages courses. Scheme is Lisp. More precisely, Scheme is what Lisp should be modulo some software engineering arguments. I think that the biggest influence on the development of Common Lisp was the success of Scheme as a language. The differences between common Lisp and scheme, as programming languages, at this point, are mostly surface level phenomina. Common Lisp does have a much much bigger base of existing software, however. Scheme will be the Pascal of the 90's. Scheme is fairly standardized. There are a number of good implementations (CScheme, PC-Scheme, Chez Scheme, MacScheme) and all ashere to the unofficial standard (The Revised Revised Report on Scheme). I think it will be used in most of the good CS undergraduate programs in a few years to teach basic concepts of programming. Common Lisp, I believe, will not be used in this way. Thus, you can expect to see an increasing "user base". Scheme is simple. Scheme is inherently simpler and smaller than common lisp. There is some truth to the equation of sheme/commonlisp = pascal/ada. I think Scheme will be a beter deliverey vehicle for AIED systems. It will be hard to sell these systems if they need an HP Bobcat or a Vaxstation to run them. It will be easy to sell them if they run on a PC or a MAC. I hope these thought are relevant. Tim.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 8 Jun 86 19:47:59 EDT Received: from mit-multics.arpa by CSNET-RELAY.ARPA id a006158; 8 Jun 86 19:45 EDT Acknowledge-To: "Eric J. Swenson" Date: Sun, 8 Jun 86 19:35 EDT From: "Eric J. Swenson" Subject: Re: SCOOPS source To: Amitabh Srivastava cc: scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA In-Reply-To: Message of 3 Jun 86 16:32 EDT from "Amitabh Srivastava" Message-ID: <860608233557.811290@MIT-MULTICS.ARPA> Are you certain BBNA supports anonymous FTP? I repeatedly get rejected when attempting to "login anonymous" with an error indicating that there is no such user as "anonymous."  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 4 Jun 86 13:44:00 EDT Received: from ti-csl by csnet-relay.csnet id ac10705; 4 Jun 86 13:37 EDT Received: by tilde id AA07924; Wed, 4 Jun 86 11:55:29 cdt Date: Wed 4 Jun 86 11:47:42-CDT From: Amitabh Srivastava Subject: Re: SCOOPS source To: scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA Cc: Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA In-Reply-To: <12211940524.20.ASRIVASTAVA@CSC60> Message-Id: <12212161685.28.ASRIVASTAVA@CSC60> I am sorry - our systems people blew it. BBNA does not allow user anonymous. The sources are available on host UTEXAS-20 in the directory ps: . Use anonymous ftp to get the sources. Initially, ftp the file README.SCM . It contains list of the files needed and other information. The sources have been modified and are totally in TI Scheme. Again, my apologies for this confusion. - amitabh -------  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 3 Jun 86 17:33:42 EDT Received: from ti-csl by csnet-relay.csnet id ac02031; 3 Jun 86 17:24 EDT Received: by tilde id AA11964; Tue, 3 Jun 86 16:45:17 cdt Date: Tue 3 Jun 86 15:32:49-CDT From: Amitabh Srivastava Subject: SCOOPS source To: scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA Cc: Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA Message-Id: <12211940524.20.ASRIVASTAVA@CSC60> SCOOPS source is available now. It can be obtained by doing anonymous ftp at host BBNA to the directory PS: . Initially, ftp the file README.SCM . It contains list of the files needed and other information. The sources have been modified and are totally in TI Scheme. - amitabh -------  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 3 Jun 86 11:48:51 EDT Received: from ti-csl by csnet-relay.csnet id ac20037; 3 Jun 86 11:38 EDT Received: by tilde id AA02583; Tue, 3 Jun 86 11:06:15 cdt Date: Tue, 3 Jun 86 11:06:15 cdt From: John Maeda To: jkr%mit-oz@MC.LCS.MIT.EDU okay glen I hope this gets to you; I had written you a real l ong letter but I have no idea how to save it from this version of EMACS running on this uLTRIX machine ... (must be a ti-professional playing "multi-user") ... so I'm really ticked, I just hope this gets to you. jtm  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 MAY 86 08:34:33 EDT Date: 31 May 1986 08:33 EDT (Sat) Message-ID: From: Bill Rozas To: Edward Sciore Cc: SCHEME@MC.LCS.MIT.EDU Subject: wanted: teaching do's and dont's In-reply-to: Msg of 23 Dec 1985 14:41-EST from Edward Sciore Our experience at MIT is that it is often the case that students with previous programming experience suffer MORE in the course than students without such experience, since the latter are not biased. In particular, students familiar with BASIC and FORTRAN (and probably PASCAL) tend to have a hard time adapting to the functional style encouraged by Scheme. They view DEFINE as assignment, which it isn't, and even if they get used to the functional style, when assignment (SET!) is finally introduced, they often revert to the ugly imperative style. They sometimes have this crazy notion that imperative style is more efficient. Interestingly enough, code with side effects is often LESS efficient in T and in MIT Scheme with the new compiler. Although Pascal is, like Scheme, lexically scoped, students do not have a really hard time accepting this, so I'm not sure it's a real advantage. Obvious potential stumbling blocks, beyond style: Absence of VAR parameters, used sometimes to "return" multiple values in Pascal. This is usually done in Scheme (in dialects without multiple values) in one of two ways: returning a data structure (list or vector) with the appropriate contents, or passing an explicit continuation with many parameters to the procedure that wants to return multiple values, which will, instead of returning, invoke its explicit continuation with the multiple "returned" values. Absence of iteration constructs. Standard Scheme has DO, but it is not used in S&ICP, in fact, we did not even have it in MIT Scheme until the report describing Standard Scheme came about. Iteration has to be achieved through syntactic recursion. One of the reasons for not having syntactic sugar in MIT Scheme (originally) was to emphasize this point, and force students to deal with the issue. Absence of explicit allocation. Memory management in Scheme is automatic, rather than manual. Eventually, the fact that thanks to tail recursion and first class procedures (and worse, cwcc, but this is not covered in S&ICP), Scheme is a completely unstructured language (in the sense of "structured programming"). Procedures (lambda expressions) are labels, and application is GOTO, and any arbitrary control structure can be built on top of this. PS: There is a teacher's manual for S&ICP written by Juile Sussman. It is very good. It contains more examples, more problems, and a very detailed description of where students go wrong in various places, and what points need further emphasis. I believe (HAL or GJS can correct me here) that it can be obtained through McGraw Hill.  Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 MAY 86 06:25:28 EDT Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 23 Dec 85 15:20:57 EST Received: from bostonu by csnet-relay.csnet id ae01055; 23 Dec 85 15:15 EST Received: by bu-cs.ARPA (4.12/4.7) id AA22857; Mon, 23 Dec 85 14:41:29 est Date: Mon, 23 Dec 85 14:41:29 est From: Edward Sciore To: SCHEME@mit-mc.ARPA Subject: wanted: teaching do's and dont's I will be teaching from the "Structure and Interpretation..." book spring semester. Students will be sophmores/juniors with at least 2 semesters of Pascal behind them. Does anybody know of things that I should be wary of? How fast should I go in order to get through chapter 4? Will their previous programming experience allow the students to handle the material more easily? Any tips people have discovered will be appreciated. Thanks. Ed Sciore Boston University CS Dept sciore@bostonu.CSNET  Received: from USC-ISI.ARPA by MC.LCS.MIT.EDU 25 May 86 15:14:26 EDT Date: 25 May 1986 12:18-EDT Sender: VERACSD@USC-ISI.ARPA Subject: Addition to Mailing-List From: VERACSD@USC-ISI.ARPA To: scheme@MC.LCS.MIT.EDU Cc: veracsd@USC-ISI.ARPA Message-ID: <[USC-ISI.ARPA]25-May-86 12:18:05.VERACSD> ReSent-To: scheme@MC.LCS.MIT.EDU ReSent-From: VERACSD at USC-ISI.ARPA ReSent-Date: 25 May 1986 Please add me to your Scheme Mailing-List. I am presently running MacScheme, and have used it to work through the examples in the Abelson & Sussman book, define a Common Lisp compatibility package, and implement a PROLOG. I am particularly interested in using continuations and macros in Scheme. I have a great general interest in logic-programming, and the imple- mentation of logic-programming languages. Thanks. -- Cris Kobryn  Received: from USC-ISI.ARPA by MC.LCS.MIT.EDU 25 May 86 12:18:59 EDT Date: 25 May 1986 12:18-EDT Sender: VERACSD@USC-ISI.ARPA Subject: Addition to Mailing-List From: VERACSD@USC-ISI.ARPA To: scheme@MC.LCS.MIT.EDU Cc: veracsd@USC-ISI.ARPA Message-ID: <[USC-ISI.ARPA]25-May-86 12:18:05.VERACSD> Please add me to your Scheme Mailing-List. I am presently running MacScheme, and have used it to work through the examples in the Abelson & Sussman book, define a Common Lisp compatibility package, and implement a PROLOG. I am particularly interested in using continuations and macros in Scheme. I have a great general interest in logic-programming, and the imple- mentation of logic-programming languages. Thanks. -- Cris Kobryn  Date: Mon, 5 May 86 22:12:44 EDT From: Jonathan A Rees Subject: implementation roundup To: serafini@AMES-AERO.ARPA cc: SCHEME@MC.LCS.MIT.EDU In-reply-to: Msg of 5 May 86 18:32:00 PST from DAVE SERAFINI Message-ID: <[MC.LCS.MIT.EDU].904409.860505.JAR> Date: 5 May 86 18:32:00 PST From: DAVE SERAFINI Has anyone compiled a list of the various implementations of scheme extant, and could I be send a copy? There's a list of implementations, with brief descriptions, in the file "SCHEME;SCHEME IMPLS" on MIT-MC. I compiled it from messages sent to this mailing list. I don't think MC's FTP server requires passwords to log in; if you are asked to supply a user name or password, give arbitrary strings like GUEST and ARPA. People who don't have Internet access and want a copy of this file should send a message to JAR@MC (not to SCHEME@MC!) requesting it. I'll batch requests, except that if I get more than ten requests I'll simply send the file out to the entire Scheme mailing list. It's about 12K bytes so I'll have to mail it in two pieces (MC's mailer is limited to 10 or 11K). Jonathan  Received: from ames-aero.ARPA by MC.LCS.MIT.EDU 5 May 86 21:41:26 EDT Date: 5 May 86 18:32:00 PST From: DAVE SERAFINI Subject: implementation roundup To: scheme Reply-To: DAVE SERAFINI Has anyone compiled a list of the various implementations of scheme extant, and could I be send a copy? advTHANKSance Dave Serafini ------  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 5 MAY 86 17:01:34 EDT Date: 5 May 1986 16:26 EDT (Mon) Message-ID: From: Bill Rozas To: scheme@MC.LCS.MIT.EDU Subject: one more message about CScheme Please, send bug reports about MIT CScheme to bug-cscheme%oz@mit-mc, not to this (scheme@mit-mc) mailing list. bug-scheme%oz@mit-mc is not good either. There is more than one implementation at MIT, and bug-scheme does not refer to CScheme. General questions about CScheme should be sent to info-cscheme%oz@mit-mc. Thanks. PS: When answering bug reports incorrectly sent to this mailing list I have tried not to send the reply here. If you have run across similar bugs, and have not received a reply, send mail to bug-cscheme, since they have probably been fixed. Notices of bug fixes, etc, are sent to info-cscheme.  Received: from LOCUS.UCLA.EDU by MC.LCS.MIT.EDU 5 May 86 14:40:34 EDT Date: Mon, 5 May 86 11:26:40 PDT From: Arthur Newman To: scheme@mc.lcs.mit.edu Subject: getting C-Scheme running on HP workstations Message-ID: <860505.182640z.03031.amn@ZEUS.LOCUS.UCLA.EDU> By just installing the student version we would get the following bug: trying to set! an undefined variable would cause a bus error and kick you out of Scheme back to the system prompt. I recompiled Scheme using the normal.bin file, and eval'ed (enable-language-features). Now trying to set! undefined variables just gives an error message. Are there any reasons why we had trouble with set! in the student system that you can think of? Thanks for any help, Arthur Newman  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 MAY 86 00:55:49 EDT Date: 1 May 1986 00:43 EDT (Thu) Message-ID: From: Bill Rozas To: jcm@ORNL-MSR.ARPA (James A. Mullens) Cc: scheme@MC.LCS.MIT.EDU Subject: Questions from a newcomer In-reply-to: Msg of 30 Apr 1986 16:38-EDT from jcm at ORNL-MSR.ARPA (James A. Mullens) MIT CScheme runs on a wide variety of machines with C compilers. In particular it runs on some 68000 systems (mostly unices) and on VMS. It currently does not have a compiler, but will have one by the end of the summer (the VAX back end may not be ready at that time, however). It is public domain.  Received: from ORNL-MSR.ARPA by MC.LCS.MIT.EDU 30 Apr 86 17:18:30 EDT Received: by ORNL-MSR.ARPA (4.12/4.9) id AA16413; Wed, 30 Apr 86 16:38:46 edt Date: Wed, 30 Apr 86 16:38:46 edt From: jcm@ORNL-MSR.ARPA (James A. Mullens) Message-Id: <8604302038.AA16413@ORNL-MSR.ARPA> To: scheme@mc Subject: Questions from a newcomer Hi - I would like to learn know about an implementation of Scheme which runs on VAX VMS 4.x and an implementation which runs on a 68000 machine (especially Amiga, Macintosh Plus, Sage/Stride, or Atari 1040ST). I have seen a reference to Scheme 312 which sounded interesting. I have also seen a reference to "Chez Scheme" for VAX BSD 4.2++ which I would like to know more about. I am especially interested "native" implementations (not implemented on top of another Lisp), versions with a compiler, and versions which are public domain. I have purchased TI's PC Scheme for my IBM AT. I am interested in Scheme because I think it may run reasonably well on a micro I can afford to have at home. I have a Sage II now, but I am considering another 68000 machine. I am also hoping that Scheme will be a simple, easy to implement Lisp which is not thundering towards commercialization. I tried Golden Common Lisp on ATs and was disappointed in the unwieldiness. We have Common Lisp (DEC Lisp and NIL) on the VAXen I use at work, but I would like to investigate Scheme as an alternative. - Thanks jim mullens oak ridge national laboratory  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 Apr 86 16:39:23 EDT Received: from ti-csl by csnet-relay.csnet id a003922; 28 Apr 86 16:34 EDT Received: by tilde id AA15837; Mon, 28 Apr 86 13:50:21 cdt Date: Mon 28 Apr 86 13:42:05-CDT From: David Bartley Subject: Re: SCOOPS, and GNU support question To: dcj%jacksun%sun.com@CSNET-RELAY.ARPA, scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA In-Reply-To: <8604272304.AA11217sun.sun.uucp> Message-Id: <12202483182.63.BARTLEY@CSC60> > Date: Sun, 27 Apr 86 16:04:02 PDT > From: Donald Clark Jackson > > As a user of TI-SCHEME, I kind of like > the SCOOPS object-oriented package. > I have C-Scheme running on a Sun now, and > I would like to get SCOOPS running on it. > > Is source for SCOOPS available, or is it > TI proprietary code? Is there something > similar available? I'll look into getting formal approval from our product group to release the source for SCOOPS. The actual SCOOPS source for TI's PC Scheme has some implementation-dependent efficiency hacks built in, but we may be able to put together a sanitized portable version. However, SCOOPS is built upon first-class environments, so it wouldn't port to some dialects out there (including the standard). If we get permission to give out the source, we will of course want to make it non-proprietary, which works both ways: you owe us nothing and we owe you nothing (well, very little!). I'll see what we can work out and post the result. David Bartley -------  Received: from sun.com by MC.LCS.MIT.EDU 27 Apr 86 19:06:04 EDT Received: from snail.sun.com (snail-ptp) by sun.com (3.2-/SMI-3.0) id AA13232; Sun, 27 Apr 86 16:01:26 PDT Received: from jacksun.sun.uucp by snail.sun.com (3.2/SMI-3.0DEV4) id AA28515; Sun, 27 Apr 86 16:04:42 PDT Received: by jacksun.sun.uucp (1.1/SMI-3.0) id AA11217; Sun, 27 Apr 86 16:04:02 PDT Date: Sun, 27 Apr 86 16:04:02 PDT From: dcj%jacksun@SUN.COM (Donald Clark Jackson) Message-Id: <8604272304.AA11217@jacksun.sun.uucp> To: scheme@mc.lcs.mit.edu Subject: SCOOPS, and GNU support question As a user of TI-SCHEME, I kind of like the SCOOPS object-oriented package. I have C-Scheme running on a Sun now, and I would like to get SCOOPS running on it. Is source for SCOOPS available, or is it TI proprietary code? Is there something similar available? Also, while getting the "inferior scheme" mode in GNU Emacs to work, I had to change the following line in xscheme.el: (make-shell "scheme" scheme-program-name nil "-emacs") to (make-shell "scheme" scheme-program-name) What was the "-emacs" supposed to do? I have GNU Emacs Version 17.61, and MIT C-Scheme Version 6.1. If this is the wrong mailing list for these questions, please suggest a better forum. Mail me your replies, if possible. I'll summarize to this list if there is any demand. Thanks, Don Jackson djackson@sun.com {ucbvax,decwrl,...}!sun!djackson  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 APR 86 10:38:14 EST Date: 26 Apr 1986 10:38 EST (Sat) Message-ID: From: Bill Rozas To: andy@AIDS-UNIX.ARPA (Andy Cromarty) Cc: SCHEME@MC.LCS.MIT.EDU Subject: The generality of define In-reply-to: Msg of 23 Apr 1986 19:09-EST from andy at aids-unix (Andy Cromarty) (define square (lambda (x) (* x x))) at all, but rather to (define square (rec square (lambda (x) (* x x)))) The new version of RRRS changes this. (define (square x) (* x x)) will be equivalent to (define square (lambda (x) (* x x))) The self recursive form can be obtained by explicitely using LETREC or wRECk.  Date: Wed, 23 Apr 86 19:09:53 EST From: andy@aids-unix (Andy Cromarty) Sender: JAR@MC.LCS.MIT.EDU Subject: Re: The generality of define To: SCHEME@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].893069.860423.JAR> Date: 21 Apr 1986 09:43-PST From: andy@aids-unix (Andy Cromarty) Cc: rkirchne%carleton.csnet@CSNET-RELAY Subject: Re: The generality of define "Although I knew that (define (square x) (* x x)) is equivalent to (define square (lambda (x) (* x x))), ...." Actually, a properly implemented (define (square x) (* x x)) is not equivalent to (define square (lambda (x) (* x x))) at all, but rather to (define square (rec square (lambda (x) (* x x)))) The distinction between the rec and lambda forms is important during definition of self-recursive procedures, as is noted (albeit somewhat tersely) in the RRRS. For example, consider (define (fact1 n) (if ( 120 ; i.e. 5! (copy2 5) => 20 ; i.e. same as "(* 5 ((lambda (x) x) 4))" Since the implicit REC in the (fact1 n) definition in essence creates a pointer to the fact1 procedure at the time of creation, the semantics of that procedure becomes immune to subsequent changes in its own name. In the case of fact2, the name wasn't "protected" by a REC, so copy2 calls the new fact2 procedure after fact2 has been redefined, rather than the original fact2. Obviously, both the REC and LAMBDA forms of define can be useful, depending on the programmer's needs. asc  Date: Mon, 14 Apr 86 16:32:51 EST From: Jonathan A Rees Subject: define To: rkirchne%carleton.csnet@CSNET-RELAY.ARPA cc: SCHEME@MC.LCS.MIT.EDU In-reply-to: Msg of Sun 13 Apr 86 15:53 CST from Kirchner at CSNET-RELAY.ARPA, Roger Message-ID: <[MC.LCS.MIT.EDU].883898.860414.JAR> Date: Sun, 13 Apr 86 15:53 CST From: Kirchner at CSNET-RELAY.ARPA, Roger To: scheme at mc.lcs.mit.edu If (define (comp f g) (lambda (x) (f (g x)))) is allowed, why shouldn't (define ((comp f g) x) (f (g x))) be allowed? Evidently it is in MIT Scheme, and it is in PC Scheme, an implementation of TI Scheme. In what Schemes is it allowed, which treat it as an error, and which give it a different interpretation? This feature is documented by the Revised Revised Report on Scheme, as a non-essential feature, which means that if any scheme implementation allows this syntax, it's supposed to do what's described. Most of the Scheme implementations out there now follow this report. Although I don't think everyone's happy with the feature, I haven't heard of any movement afoot to retract it in future versions of the report. Jonathan  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 14 Apr 86 04:32:38 EST Received: from carleton by csnet-relay.csnet id aa24474; 14 Apr 86 4:22 EST Date: Sun, 13 Apr 86 15:53 CST From: Kirchner@CSNET-RELAY.ARPA, Roger To: scheme@mc.lcs.mit.edu cc: rkirchne%carleton.csnet@CSNET-RELAY.ARPA Subject: define Kent M Pitman said that there are other possible interpretations of (DEFINE (((...) ...) ...) ...) besides as an extended template for procedure definition. What would be the objections to making this interpretation standard? If (define (comp f g) (lambda (x) (f (g x)))) is allowed, why shouldn't (define ((comp f g) x) (f (g x))) be allowed? Evidently it is in MIT Scheme, and it is in PC Scheme, an implementation of TI Scheme. In what Schemes is it allowed, which treat it as an error, and which give it a different interpretation? Roger Kirchner  Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 12 Apr 86 17:35:13 EST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 462162; Sat 12-Apr-86 17:32:20-EST Date: Sat, 12 Apr 86 17:32 EST From: Kent M Pitman Subject: (DEFINE (((...) ...) ...) ...) To: Scheme@MIT-MC.ARPA cc: JINX@MIT-AI.ARPA, rkirchne%carleton.csnet@CSNET-RELAY.ARPA References: The message of 10 Apr 86 15:18-EST from rkirchne%carleton.csnet@CSNET-RELAY.ARPA, Message-ID: <860412173221.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Although Jinx didn't mention it explicitly, it's worth mentioning that although this is one possible natural interpretation of nested lists in DEFINE's name position, there are other possible interpretations and the Scheme communities are not in agreement about how to interpret this. As such, no matter how natural it feels, it's worth noting that it's not -so- natural that works in every Scheme dialect. Some dialects treat it as an error; others might assign other meanings. Hence, even though some dialects have it and some people find it fun (myself included, by the way), it's worth noting that it's not portable (at least, insofar as portable is currently defined by the Revised Revised Report on Scheme).  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 APR 86 10:03:43 EST Date: 12 Apr 1986 10:03 EST (Sat) Message-ID: From: Bill Rozas To: Kirchner@CSNET-RELAY.ARPA, Roger Cc: scheme@MC.LCS.MIT.EDU Subject: The generality of define In-reply-to: Msg of 10 Apr 1986 15:18-EST from Kirchner at CSNET-RELAY.ARPA, Roger MIT Scheme has recognized the (define ((linear a b) x) (+ a (* b x))) syntax for a few years. It was suggested by a student as an extension to the usual (define (square x) (* x x)) syntax. The (obvious) reason being that in the same way that (square 5) evaluates to the value of (* 5 5) ((linear 2 3) 4) evaluates to the value of (+ 2 (* 3 4))  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 12 Apr 86 03:42:00 EST Received: from carleton by csnet-relay.csnet id aa05699; 12 Apr 86 3:36 EST Date: Thu, 10 Apr 86 14:18 CST From: Kirchner@CSNET-RELAY.ARPA, Roger To: scheme@mc.lcs.mit.edu cc: rkirchne%carleton.csnet@CSNET-RELAY.ARPA Subject: The generality of define One of my students has discovered that the template syntax for defining procedures is quite general, a fact which might be obvious, but should be pointed out. Although I knew that (define (square x) (* x x)) is equivalent to (define square (lambda (x) (* x x))), I did not realize that something like (define ((linear a b) x) (+ a (* b x))) is possible and is equivalent to (define (linear a b) (lambda (x) (+ (* b x)))). Roger Kirchner, Carleton College  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 10 Apr 86 08:55:46 EST Received: from tektronix by csnet-relay.csnet id ae13403; 10 Apr 86 8:46 EST Received: by tektronix (5.31/5.14) id AA09072; Wed, 9 Apr 86 10:31:49 PST Received: by tekchips (5.31/5.14) id AA19944; Wed, 9 Apr 86 10:32:21 PST Message-Id: <8604091832.AA19944@tekchips> To: scheme%mit-mc%tektronix.csnet@CSNET-RELAY.ARPA Subject: arg lists to APPLY Date: 09 Apr 86 10:32:19 PST (Wed) From: willc%tekchips%tektronix.csnet@CSNET-RELAY.ARPA I haven't checked the manuals for T or Scheme but it was certainly the intent that the list passed to APPLY is unrelated to the list that a rest-parameter gets bound to. The rest-list should always be freshly consed, so e.g. the procedure LIST is equivalent to (LAMBDA X X). The last argument to APPLY must be a proper list. I think Common Lisp takes the same stance. This question came up recently on the Common-Lisp mailing list. The unofficial consensus, as I understood it, was that the book is vague on this point and requires correcting; that the last argument to APPLY should be a proper list; and that a list passed as an argument to APPLY might or might not share list structure with an eventual &REST argument resulting from the application. Until this discussion I had never heard anyone suggest that it was ok for an implementation of Scheme to allow the list passed to APPLY to share structure with the list that a rest-argument gets bound to. For what it's worth, two formal semantics for Scheme have been published (1980 and 1984) and a third is expected to be published soon. The first two define the domain of procedures as F = E* --> K --> C, and the third defines F = L x (E* --> K --> C). The sharing mentioned above is inconceivable with either definition, and the changes that would be required to allow such sharing are pretty gross. In my opinion, therefore, Scheme and Common Lisp diverge on this as on many other issues. It should not be very difficult for a compiler to arrange things so that rest arguments that are merely passed on as argument lists to APPLY never get consed. Whether this is important enough to worry about is another matter entirely. Peace, Will  Received: from .ARPA by MC.LCS.MIT.EDU 9 Apr 86 15:52:15 EST Received: from indiana by csnet-relay.csnet id ab03957; 9 Apr 86 15:38 EST Date: Wed, 9 Apr 86 13:40:53 est From: Chris Haynes To: scheme@mc.lcs.mit.edu Subject: Use at Indiana University /**** iuvax:scheme-list / iuvax!cth / 12:59 am Mar 31, 1986 ****/ Scheme is used in a broad range of teaching and research contexts throughout the Indiana University Computer Science Department. The primary courses which use Scheme are -- Programming Languages (Junior/Senior level, with some graduate students) Scheme is used throughout this course to express the semantics of programming languages and their implementation. A sequence of interpreters is developed which demonstrate a systematic approach to deriving implementation from abstract semantics. The notes for this unique course are turning into a book by Friedman, Wand, Haynes and Kohlbecker. -- Advanced Concepts in Programming Languages (graduate level) In this course Dan Friedman uses Scheme is used to study a variety of advanced PL features, such as concurrency and reflection. Typical projects require students to implement in Scheme the essence of various proposed language mechanisms, such as data flow or actors. -- Operating Systems I and II (senior and graduate level) As I teach this course (others here do it a bit differently) after a few weeks of interrupt handler programming in assembly language, the remaining course projects are done in Scheme. (I wish we had direct access to hardware interrupts and I/O controllers in a Scheme system. Some day...) This year I gave the students a process scheduler written in Scheme using engines, and asked them to add semaphores and monitors. The second semester project is to implement all of the Ada concurrency mechanisms that seem to make sense in a Scheme environment (including termination and delays). -- Compiler Construction I and II (senior and graduate level) is often taught with extensive use of Scheme, including lexical analysis, parsing and code generation. This semester Kent Dybvig's class is writing an optimizing compiler for a subset of C in Scheme. -- Denotational Semantics (advanced graduate level) is taught using a Semantic Prototyping System developed by Mitch Wand that assists in the translation of denotational semantics into running Scheme programs. (This system includes an ML-style type checker.) In most other advanced courses students are free to use any language of their choosing, and many choose Scheme, particularly in the AI courses. Scheme is also used in a variety of student projects, some of them outside of the department. Examples include (1) an oil exploration model for geology instruction that is being tied into an expert system, and uses engines for time-shared simulation, (2) a Scheme Development System, inspired by Knuth's WEB, which targets Scheme and line printers instead of Pascal and Tex, and (3) a Scheme Implementation of Neural Networks (SINN). In the fall, George Springer will teach an honors introduction to programming course using Scheme, The Little LISPer, and parts of the Abelson and Sussman text. We anticipate expanding the use of Scheme in future introductory courses. Scheme is also used in a variety of research projects, including the study of programming language sequential control, logic programming, data typing, concurrency, compilers, syntactic extension mechanisms, and hardware design methodology. /* ---------- */  Received: from DOCKMASTER.ARPA by MC.LCS.MIT.EDU 4 Apr 86 16:23:17 EST Date: Fri, 4 Apr 86 00:59 EST From: Bill Pase Subject: Scheme for the Atari ST To: scheme@MIT-MC.ARPA Message-ID: <860404055925.041933@DOCKMASTER.ARPA> Does anyone know if Scheme is available for the Atari ST? I know there are versions for the IBMPC and the Macintosh. It wouIt would seem especially with the later that an Atari version should be easy. Does anyone have any plans to develop it? /bill  Received: from GODOT.THINK.COM by MC.LCS.MIT.EDU 3 Apr 86 10:37:17 EST Received: from katherine by GODOT.THINK.COM via CHAOS; Thu, 3 Apr 86 10:34:56 est Date: Thu, 3 Apr 86 10:36 EST From: Guy Steele Subject: non-list arguments To: rhh@MIT-VAX.ARPA, JAR@MIT-MC.ARPA Cc: SCHEME@MIT-MC.ARPA, t-discussion@YALE.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: <860401152644.7.RHH@ASPEN.LCS.MIT.EDU> Message-Id: <860403103623.3.GLS@THINK-KATHERINE.ARPA> I haven't checked the manuals for T or Scheme but it was certainly the intent that the list passed to APPLY is unrelated to the list that a rest-parameter gets bound to. The rest-list should always be freshly consed, so e.g. the procedure LIST is equivalent to (LAMBDA X X). The last argument to APPLY must be a proper list. I think Common Lisp takes the same stance. A quick scan of the Common Lisp book leaves the question unresolved; maybe Guy Steele could comment. This question came up recently on the Common-Lisp mailing list. The unofficial consensus, as I understood it, was that the book is vague on this point and requires correcting; that the last argument to APPLY should be a proper list; and that a list passed as an argument to APPLY might or might not share list structure with an eventual &REST argument resulting from the application. --Guy  Received: from ZERMATT.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 APR 86 15:27:48 EST Received: from ASPEN.LCS.MIT.EDU by MIT-ZERMATT.ARPA via CHAOS with CHAOS-MAIL id 29890; Tue 1-Apr-86 15:27:29-EST Date: Tue, 1 Apr 86 15:26 EST From: Robert Halstead Subject: non-list arguments To: JAR@MIT-MC.ARPA cc: SCHEME@MIT-MC.ARPA, t-discussion@YALE.ARPA In-Reply-To: <[MC.LCS.MIT.EDU].867344.860331.JAR> Message-ID: <860401152644.7.RHH@ASPEN.LCS.MIT.EDU> I haven't checked the manuals for T or Scheme but it was certainly the intent that the list passed to APPLY is unrelated to the list that a rest-parameter gets bound to. The rest-list should always be freshly consed, so e.g. the procedure LIST is equivalent to (LAMBDA X X). The last argument to APPLY must be a proper list. I think Common Lisp takes the same stance. A quick scan of the Common Lisp book leaves the question unresolved; maybe Guy Steele could comment. However, I have seen object-oriented programs where this would probably lead to less than the most efficient implementation. Suppose we represent objects by procedures and call them using the general form ( ) where the indicates the operation to be performed on and (possibly empty) consists of operation-dependent parameters. One way to code up such an object is as (lambda (key . rest) (cond ((eq? key 'foo) (apply f1 rest)) ((eq? key 'bar) (apply f2 (cons 'barbar rest))) ...)) where we use the key to pick a function (or new object) to forward the request to, on the assumption that somebody at the end of the chain will actually use the rest of the original arguments. Putting an extra list copy in at each forwarding step seems mildly expensive and somewhat unnecessary. I don't think that LAMBDA should be prohibited from checking that its argument is a true list, or from copying it over, but I also don't think it should be required to. Why is it important for the list of rest arguments to be copied over when we don't, for example, expect quoted lists to be copied over every time an expression '(...) is evaluated? To summarize, I think it should be permissible for (eq? ((lambda x x) l) l) to return true, but it should not be a requirement. Furthermore, it should be permissible for an implementation to report an error if l in the above expression is not a true list, but an implementation should not be required to do so. Of course, it would still be true that ((lambda x x) 3 4 5) would return a freshly consed list, just like (list 3 4 5). An interesting question: do people expect (apply list l) to return a top-level copy of l? -b.  Date: Tue, 1 Apr 86 15:38:33 EST From: "George J. Carrette" Subject: MIT Scheme, linking C compiler output. To: JINX@OZ.AI.MIT.EDU cc: SCHEME@MC.LCS.MIT.EDU, puzo@PREP.AI.MIT.EDU In-reply-to: Msg of 1 Apr 1986 12:09 EST (Tue) from Bill Rozas Message-ID: <[MC.LCS.MIT.EDU].868688.860401.GJC> Franz lisp uses the unix assembler, and so has a dynamic linker for foo.o files. Yale "T" also used .o files for bootstrap in the past. The format is usually grossly simple, although the SYSTEM-V format is more general and complicated. I have to do a dynamic linker for LMI's system-V unix in order to have, well, the flexibility of dynamic linking. It will be written in either C or lisp.  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 APR 86 12:10:22 EST Date: 1 Apr 1986 12:09 EST (Tue) Message-ID: From: Bill Rozas To: scheme@MC.LCS.MIT.EDU cc: info-cscheme%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, puzo%PREP.AI.MIT.EDU@XX.LCS.MIT.EDU Subject: MIT Scheme, general information (long message) There are currently 2 implementations of MIT Scheme: "Gator" Scheme runs on HP 9000 series 200 (and old model 9836 plus variants) computers under the Pascal 3.1 operating system. It is quite dependent on this operating system and the tools provided with it. This is currently our main implementation. Most of the code is written in Scheme, but the interpreter and support procedures (operating system interface) are written in assembly language (Motorola 68000) and Pascal (HP dialect). There is a very idiosincratic compiler (Liar) in this version which with motherly care or luck can give very good performance, but which will not perform so well without pampering. There is also a very good editor (Edwin) written in Scheme. It is very similar to GNU Emacs, but its interface to Scheme is (for obvious reasons) better. CScheme (pronounced like "see-scheme") runs on a variety of machines which have C compilers. In particular, it runs on Vaxen (both BSD4.2 Unix and VMS), various flavors of Unix (HP-UX, Sun BSD), and is quite portable, but may require some work on "strange" machines and/or operating systems. This version (the interpreter and support routines, which are written in C) was originally written to illustrate how a Scheme system could be built, not as a "production" version. Its main emphasis was clarity, rather than efficiency. As of late, with (slowly) increasing efficiency and use, it is becoming the base for a variety of projects. Its performance is adequate (although not great) on the latest generation single user workstations (Suns, HP 9000 series 300, etc). There is currently no compiler for this version. There is a moderately good (although not perfect) interface to GNU Emacs, and a barely adequate interface to DEC Emacs for VMS. Both systems are pretty similar as far as "normal" users are concerned (the systems share the code written in Scheme although they are currently somewhat out of phase). Both versions also require large amounts of memory (upwards of 4 Mb for Gator Scheme with all the features, somewhat over 2 Mb for Cscheme). Within the next few months (by September '86 probably) we will shift from Gator Scheme to CScheme (CScheme will become our main implementation), and there will be a (new) compiler for CScheme with back ends at least for the common machines (68k family and Vax). Eventually we plan to have a C back end also (does anybody know of a portable dynamic loader for C/Unix ?). Edwin will also be ported to CScheme (at least under versions of Unix providing the curses(3) library). For more information about either version, send (arpa) mail to SCHEME-TEAM%MIT-OZ@MIT-MC or US Snail to Scheme Team c/o Prof. Hal Abelson 545 Technology Sq. rm 410 Cambridge MA 02139 For particular information about CScheme, send mail to INFO-CSCHEME%MIT-OZ@MIT-MC (send mail to info-cscheme-request to be added to this mailing list) To obtain a copy of MIT Scheme 1) If you want CScheme, and have access to the arpanet, a "tar" file (for Unix) exists on MIT-PREP /scheme/dist.tar . There is usually a "compressed" (dist.tar.Z) file also. If the file does not exist for any reason, log in (via telnet) to MIT-PREP as scheme (no password). The files will be re-generated by the log in program. 2) If you can use ftp over the arpanet, but cannot use a tar file, get in touch with us describing what version you want, and we may be able to arrange some way to get the sources across the net. 3) Otherwise, try to get a copy from someone who already has it. 4) As a last resort (unadvisable), send $200 to the address above, and specify what form of tape you want. We can currently provide 1600 bpi standard tar tape. 1600 bpi standard VMS backup tape. HP-UX cartridge tar tape.  Date: Mon, 31 Mar 86 16:52:27 EST From: Jonathan A Rees Subject: non-list arguments To: Fahlman@C.CS.CMU.EDU cc: SCHEME@MC.LCS.MIT.EDU, Kahn.pa@XEROX.COM, Miller.pa@XEROX.COM, t-discussion@YALE.ARPA In-reply-to: Msg of Mon 31 Mar 1986 01:51 EST from Scott E. Fahlman Message-ID: <[MC.LCS.MIT.EDU].867344.860331.JAR> Date: Mon, 31 Mar 1986 01:51 EST From: Scott E. Fahlman It certainly doesn't work in Common Lisp because lambda lists don't do destructuring in Common Lisp (though the argument lists for macros do destructure). Scheme and T don't have lambda list destructuring; they just use "." instead of "&rest". I haven't checked the manuals for T or Scheme but it was certainly the intent that the list passed to APPLY is unrelated to the list that a rest-parameter gets bound to. The rest-list should always be freshly consed, so e.g. the procedure LIST is equivalent to (LAMBDA X X). The last argument to APPLY must be a proper list. I think Common Lisp takes the same stance.  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 MAR 86 09:34:19 EST Date: 31 Mar 1986 09:33 EST (Mon) Message-ID: From: Bill Rozas To: Miller.pa@XEROX.COM Cc: Kahn.pa@XEROX.COM, scheme@MC.LCS.MIT.EDU, t-discussion@YALE.ARPA Subject: non-list arguments In-reply-to: Msg of 31 Mar 1986 01:19-EST from Miller.pa at Xerox.COM The Revised Revised Report on Scheme states that the second argument (2 argument form) to APPLY must be a "proper" list. Individual implementations are free to extend the semantics of APPLY. APPLY in MIT Scheme signals an error when given somthing other than a "proper" list.  Date: Mon, 31 Mar 86 04:05:03 EST From: Alan Bawden Subject: non-list arguments To: Miller.pa@XEROX.COM, Fahlman@C.CS.CMU.EDU cc: SCHEME@MC.LCS.MIT.EDU, Kahn.pa@XEROX.COM, t-discussion@YALE.ARPA In-reply-to: Msg of 30 Mar 86 22:19 PST from Miller.pa at Xerox.COM Message-ID: <[MC.LCS.MIT.EDU].866607.860331.ALAN> Date: 30 Mar 86 22:19 PST From: Miller.pa at Xerox (apply (lambda (x . y) (+ x y)) (cons 1 2)) Date: Mon, 31 Mar 1986 01:51 EST From: Scott E. Fahlman It certainly doesn't work in Common Lisp because lambda lists don't do destructuring in Common Lisp (though the argument lists for macros do destructure). Also, in Common Lisp you'd have to say "(function (lambda ...))". I would translate the question into Common Lisp as: (apply (function (lambda (x &rest y) (+ x y))) (cons 1 2)) which eliminates the question of "descructuring", but I would guess still preserves Ken Kahn's original question. A strict reading of the Common Lisp book would not require this to work, as far as I can see. An implementor would seem to be within his rights to insist that the last argument to APPLY always be a proper list.  Received: from C.CS.CMU.EDU by MC.LCS.MIT.EDU 31 Mar 86 02:50:32 EST Received: ID ; Mon 31 Mar 86 02:49:07-EST Date: Mon, 31 Mar 1986 02:49 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Miller.pa@XEROX.COM Cc: Kahn.pa@XEROX.COM, scheme%OZ@MC.LCS.MIT.EDU, scheme@MC.LCS.MIT.EDU, t-discussion@YALE.ARPA Subject: non-list arguments In-reply-to: Msg of 31 Mar 1986 02:33-EST from Miller.pa at Xerox.COM OK, for Common Lisp how about: (apply #'(lambda (x &rest y) (+ x y)) (cons 1 2)) Ah, I see what you're driving at now. No this is not guaranteed to work in Common Lisp in my opinion. The second argument to apply is a list of operands. In this case, you've got a list of one operand, 1, with a particularly ugly terminator, so the rest arg, Y, should end up bound to NIL. Some implementations may get this "right" by accident, but in most of them the Apply takes apart the operand list and simulates a call to the function. The lambda would be called with only one arg, and the rest arg would be NIL. The 2 has been discarded before the function ever gets called. -- Scott  Received: from Xerox.COM by MC.LCS.MIT.EDU 31 Mar 86 02:35:06 EST Received: from Cabernet.ms by ArpaGateway.ms ; 30 MAR 86 23:33:06 PST Date: 30 Mar 86 23:33 PST From: Miller.pa@Xerox.COM Subject: Re: non-list arguments In-reply-to: "Scott E. Fahlman" 's message of Mon, 31 Mar 86 01:51 EST To: Fahlman@C.CS.CMU.EDU cc: Miller.pa@Xerox.COM, Kahn.pa@Xerox.COM, scheme@MC.LCS.MIT.EDU, scheme%OZ@MC.LCS.MIT.EDU, t-discussion@YALE.ARPA Message-ID: <860330-233306-4514@Xerox> It certainly doesn't work in Common Lisp because lambda lists don't do destructuring in Common Lisp (though the argument lists for macros do destructure). Also, in Common Lisp you'd have to say "(function (lambda ...))". OK, for Common Lisp how about: (apply #'(lambda (x &rest y) (+ x y)) (cons 1 2)) In other words, "&rest" is all the destructuring I need to ask this question. "." is simply the cleaner way one can write it in the Schemes. (Sorry for the redundant scheme mailing addresses. I'm having some mail returned and I don't know which address is causing the problem)  Received: from C.CS.CMU.EDU by MC.LCS.MIT.EDU 31 Mar 86 01:52:41 EST Received: ID ; Mon 31 Mar 86 01:51:17-EST Date: Mon, 31 Mar 1986 01:51 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Miller.pa@XEROX.COM Cc: Kahn.pa@XEROX.COM, scheme@MC.LCS.MIT.EDU, t-discussion@YALE.ARPA Subject: non-list arguments In-reply-to: Msg of 31 Mar 1986 01:19-EST from Miller.pa at Xerox.COM It certainly doesn't work in Common Lisp because lambda lists don't do destructuring in Common Lisp (though the argument lists for macros do destructure). Also, in Common Lisp you'd have to say "(function (lambda ...))". -- Scott  Received: from Xerox.COM by MC.LCS.MIT.EDU 31 Mar 86 01:21:13 EST Received: from Cabernet.ms by ArpaGateway.ms ; 30 MAR 86 22:19:17 PST Date: 30 Mar 86 22:19 PST From: Miller.pa@Xerox.COM Subject: non-list arguments To: scheme@MC.LCS.MIT.EDU,t-discussion@YALE.ARPA cc: Miller.pa@Xerox.COM,Kahn.pa@Xerox.COM Message-ID: <860330-221917-4500@Xerox> (apply (lambda (x . y) (+ x y)) (cons 1 2)) Does this nescesarily work in Scheme? How about T? Common-Lisp? (Example due to Ken Kahn)  Received: from SU-SUSHI.ARPA by MC.LCS.MIT.EDU 30 Mar 86 23:58:40 EST Date: Sun 30 Mar 86 20:57:41-PST From: Andy Freeman Subject: immutable structures To: scheme@MC.LCS.MIT.EDU Message-ID: <12194993072.20.ANDY@SU-SUSHI.ARPA> Immutable cons structures bother me. Every other immutable structure in Scheme has a distinct reader syntax. (I think numbers and symbols are the only ones although strings are occasionally candidates. BTW - I think that would be a mistake. Anyone have a use for immutable strings that can't be satisfied by symbols?) Even if the necessary immutable-cons? predicate is added to RRRS, that lack is fatal. I'm reasonably convinced that there is a fundamental difference between cons structures and numbers. Would someone please enlighten me and justify immutable quoted structures without resorting to "[some] formal system is cleaner without distinguishing them" as the best reason? (Since Scheme procedures have state, mutable quoted structures are merely syntactic sugar.) -andy -------  Date: Sun, 30 Mar 86 16:48:49 EST From: Jonathan A Rees Subject: mail to scheme@mc To: SCHEME@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].866311.860330.JAR> If you send a message to Scheme@MC, and it gets bounced back to you due to what might be a problem with the mailing list (invalid destinations, etc.), please let me know (via Scheme-Request@MC) and I'll try to fix the problem so that the next person to send a message doesn't have his (hers) returned also. Thanks. Jonathan  Received: from mitre.ARPA by MC.LCS.MIT.EDU 28 Mar 86 10:05:15 EST Full-Name: DUKE BRISCOE Message-Id: <8603281504.AA07255@mitre.ARPA> Organization: The MITRE Corp., Washington, D.C. To: scheme@mc.lcs.mit.edu Cc: duke@mitre.ARPA Subject: A bug in my version of MIT Scheme Date: Fri, 28 Mar 86 10:04:24 -0500 From: Duke Briscoe We have found a bug in the multiplication, *, procedure of our version of Scheme. The deeper root of the problem is apparently in the primitive for multiplying fixnums. Multiplying 0 times a negative number results in #[(undefined-type-code 81) 0] . It is easy enough to work around this, but someone maintaining MIT Scheme might look into this if it hasn't already been fixed. The version we're using is the VAX/VMS version of MIT Scheme, Microcode 6.1, Runtime 11.2, Features 1.1, Student 11.1, and is dated Thursday May 31, 1985.  Received: from Cs by MC.LCS.MIT.EDU 26 Mar 86 08:52:41 EST Received: from computer-science.nottingham.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a004186; 26 Mar 86 0:34 BST Date: Tue, 25 Mar 86 17:10:16 GMT From: Andy Cheese To: scheme@mc.lcs.mit.edu Subject: Scheme wanted Sender: abc%computer-science.nottingham.ac.uk@cs.ucl.ac.uk Unfortunately for me and many of my colleagues the file dist.tar sitting at prep.ai.mit.edu is much to big to anonymous ftp across the atlantic all in one go, it breaks down half way thro usually. could somebody arrange to have it split into manageable chunks or mail it to me and i'll act as a distribution site for the uk. Andy Cheese Department of Computer Science University of Nottingham University Park Nottingham NG7 2RD England abc@uk.ac.nott.cs abc@uk.ac.nott.cs@uk.ac.ucl.cs  Date: Sun, 23 Mar 86 20:43:45 EST From: Jonathan A Rees Subject: Scheme implementation guide To: F.AE@DEEP-THOUGHT.MIT.EDU cc: SCHEME@MC.LCS.MIT.EDU In-reply-to: Msg of Sun 23 Mar 86 18:27:39-EST from Antonio Elias Message-ID: <[MC.LCS.MIT.EDU].859975.860323.JAR> You can FTP this from "SCHEME; SCHEME IMPLS" on MC. One of these days I'll compress it down to fewer than 10K bytes so that it's easy for me to mail - MC's mailer doesn't like messages bigger than that, and it's currently almost 17K. I still don't have information about T or MIT Scheme in that file; sure would be nice if someone from those groups would send out a message about status, availability, etc., hint hint. E.g. word comes to me that T has or will soon have the same "free software" copyright notice that MIT Scheme does.  Received: from DEEP-THOUGHT.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 23 MAR 86 18:27:44 EST Date: Sun 23 Mar 86 18:27:39-EST From: Antonio Elias Subject: Scheme implementation guide To: scheme@MC.LCS.MIT.EDU Message-ID: <12193097983.16.F.AE@DEEP-THOUGHT.MIT.EDU> I, too, would be interested in a "guide to scheme implementations", maintained in a friendly (and ftp-able) system, listing all the known real or quasi-real implementations with perhaps some words of wisdom on each of them, availability, etc. etc. - Antonio -------  Received: from WISCVM.WISC.EDU by MC.LCS.MIT.EDU 21 Mar 86 18:21:48 EST Received: from (VM1MAIL)WSUVM1.BITNET by WISCVM.WISC.EDU on 03/21/86 at 17:19:46 CST Received: by WSUVM1 (Mailer X1.23) id 3041; Fri, 21 Mar 86 14:52:27 PLT Date: Fri, 21 Mar 1986 14:50 PLT From: George Cross To: Is there a list of available SCHEME implementations around that someone could mail to me? Thanks. ---- George - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - George R. Cross cross@wsu.CSNET Computer Science Department cross%wsu@csnet-relay.ARPA Washington State University faccross@wsuvm1.BITNET Pullman, WA 99164-1210 (509)-335-6319/6636 Acknowledge-To: George Cross  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 MAR 86 13:57:37 EST Date: 21 Mar 1986 12:38 EST (Fri) Message-ID: From: Bill Rozas To: "Raymond A. Schnitzler" Cc: scheme@MC.LCS.MIT.EDU Subject: A chipmunk scheme compiler In-reply-to: Msg of 21 Mar 1986 11:47-EST from Raymond A. Schnitzler Which chipmunks are you using? If you are using the ones in bldg 34 they are running an old version of MIT-Scheme for which there is no compiler. The new version has one but it is relatively idiosincratic. If you'd like a copy of the new system, get in touch with CPH@OZ (Chris Hanson) or me.  Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 MAR 86 11:48:44 EST Date: Fri 21 Mar 86 11:47:06-EST From: Raymond A. Schnitzler Subject: A chipmunk scheme compiler To: scheme@MC.LCS.MIT.EDU Is there one? That is, is there any way to get my scheme code to run faster on the chipmunks? I am using scheme because I inherited a lot of code, and the chipmunks because that is all that I know I have access to. Can anyone help? Thanks Ray Schnitzler -------  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 19 Mar 86 00:04:23 EST Received: from uhcl by csnet-relay.csnet id aa21067; 18 Mar 86 23:35 EST Date: Tue, 18 Mar 86 15:35 CST From: "Dede.Chris" To: scheme@mc.lcs.mit.edu cc: dede%uhcl.csnet@CSNET-RELAY.ARPA Subject: scheme community I am hoping eventually to be able to offer a SCHEME course at my university and am interested in sharing ideas about instructional materials. Would like to be involved in the information exchange--what do I need to do? --Chris Dede  Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 13 Mar 86 15:40:54 EST Date: Thu, 13 Mar 86 14:03:25 est From: rjk@mitre-bedford.ARPA (Ruben J. Kleiman) Full-Name: Ruben J. Kleiman Message-Id: <8603131903.AA04584@mitre-bedford.ARPA> Organization: The MITRE Corp., Bedford, MA To: scheme@MIT-MC.ARPA Subject: Unexpected Message I received the following message addressed to you: From daemon Thu Mar 13 13:17:37 1986 Received: from nrl-aic by MC.LCS.MIT.EDU 13 Mar 86 10:56:34 EST Date: Thu, 13 Mar 86 10:54:39 est From: Patrick Harrison Message-Id: <8603131554.AA12040@nrl-aic> To: scheme@MIT-MC.ARPA Subject: corrected address Reference mailing list, my address Message-Id: <8603131554.AA12040@nrl-aic> To: scheme@MIT-MC Subject: corrected address Reference mailing list, my address Message-Id: <8603131553.AA12034@nrl-aic> To: scheme@MIT-MC Subject: mailing list Please put me on the mailing list. We are using SCHEME for testing concepts for a larger project being conducted in the Multi-sensor Integration area. Two students at the U.S. Naval are currently using the object oriented package in SCHEME to implement a small subset of this problem. Pat Harrison  Date: Tue, 4 Mar 86 16:45:27 EST From: Yekta Gursel Subject: PC Scheme Information To: Jensen%ti-csl.csnet@CSNET-RELAY.ARPA cc: SCHEME@MC.LCS.MIT.EDU In-reply-to: Msg of Mon 3 Mar 86 17:08:22-CST from John Jensen Message-ID: <[MC.LCS.MIT.EDU].838646.860304.YEKTA> Could you please send both of these ( 1 and 2 ) to me? There are a few people around here which is very interested in having those... Best, --Yekta  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 4 Mar 86 10:51:41 EST Received: from ti-csl by csnet-relay.csnet id ap03450; 4 Mar 86 9:43 EST Received: by tilde id AA10368; Mon, 3 Mar 86 17:15:45 cst Date: Mon 3 Mar 86 17:08:22-CST From: John Jensen Subject: PC Scheme Information To: SCHEME%MIT-MC@CSNET-RELAY.ARPA Message-Id: <12187851592.66.JENSEN@CSL60> The following information may be of interest to you if you are using PC Scheme Version 1.0 (18 Nov 85): 1. If you are running on a PC manufactured by a vendor other than IBM or TI and are unable to execute the EDWIN editor or graphics, there is a patch available which may correct this problem. 2. If you need to interface PC Scheme to assembly language support (e.g., to communicate with device drivers), a description of how to do this is available. If either of these apply to you, contact me at one of the network addresses below and I'll send the appropriate description to your network address. Regards, John Jensen CSNET: JENSEN@TI-CSL ARPA: JENSEN%TI-CSL@CSNET-RELAY.ARPA USENET: {ut-sally,convex!smu,texsum}!ti-csl!jensen -------  Received: from GODOT.THINK.COM by MC.LCS.MIT.EDU 3 Mar 86 17:28:23 EST Received: from guido by GODOT.THINK.COM via CHAOS; Mon, 3 Mar 86 17:28:05 est Date: Mon, 3 Mar 86 17:30 EST From: Guy Steele Subject: COMMON LISP is the PL/I of LISPs To: SMC%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, sas@BBN-VAX.ARPA Cc: scheme@MC.LCS.MIT.EDU, gls@THINK-AQUINAS.ARPA In-Reply-To: Message-Id: <860303173003.7.GLS@GUIDO.THINK.COM> Date: 3 Mar 1986 15:37 EST (Mon) From: "Stewart M. Clamen" From: Seth Steinberg To: scheme at mit-mc.ARPA Re: COMMON LISP is the PL/I of LISPs Actually, I think COMMON LISP will do better than PL/I did as a usable standard. Personally I think Scheme is the APL of LISPs. It's great for writing clever, unreadable hacks. Actually, the analogy could go: I take exception to that. Unlike APL, Scheme uses the popular set of characters known as ASCII, which is a superset of the English characters, and is therefore quite readable. I believe that the APL character set is also a superset of "English" characters, except for not having lower case, which shouldn't matter. --Guy  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 MAR 86 16:00:00 EST Date: 3 Mar 1986 15:37 EST (Mon) Message-ID: Sender: SMC%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU From: "Stewart M. Clamen" To: Seth Steinberg Cc: scheme@MC.LCS.MIT.EDU Subject: COMMON LISP is the PL/I of LISPs In-reply-to: Msg of 3 Mar 1986 13:48-EST from Seth Steinberg From: Seth Steinberg To: scheme at mit-mc.ARPA Re: COMMON LISP is the PL/I of LISPs Actually, I think COMMON LISP will do better than PL/I did as a usable standard. Personally I think Scheme is the APL of LISPs. It's great for writing clever, unreadable hacks. Actually, the analogy could go: I take exception to that. Unlike APL, Scheme uses the popular set of characters known as ASCII, which is a superset of the English characters, and is therefore quite readable. In fact, by definition, Scheme programs are also trivialy parseable (sic). Take, for example, this simple procedure (attributable to GJS, I believe): 1 ==> (pp mapcar) (LAMBDA (F . LISTS) (IF LISTS (LET LOOP ((LISTS LISTS)) (LET SCAN ((LISTS LISTS) (C (LAMBDA (CARS CDRS) (ACCUMULATOR (APPLY F CARS) (LOOP CDRS))))) (IF LISTS (IF (CAR LISTS) (SCAN (CDR LISTS) (LAMBDA (CARS CDRS) (C (CONS (CAR (CAR LISTS)) CARS) (CONS (CDR (CAR LISTS)) CDRS)))) INITIAL-VALUE) (C () ())))) (ERROR "No arguments to mapping function" (LIST (LIST MAPPER-GENERATOR ACCUMULATOR INITIAL-VALUE) F)))) SMC  Received: from BBN-VAX.ARPA by MC.LCS.MIT.EDU 3 Mar 86 14:33:17 EST Date: Mon, 3 Mar 86 13:48 EST From: Seth Steinberg Subject: COMMON LISP is the PL/I of LISPs To: scheme@mit-mc.ARPA Actually, I think COMMON LISP will do better than PL/I did as a usable standard. Personally I think Scheme is the APL of LISPs. It's great for writing clever, unreadable hacks. Actually, the analogy could go: 1960's APL 1970's PASCAL PL/I 1980's Scheme ADA 1990's COMMON LISP PASCAL is teleologically similar to Scheme. Seth  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 3 Mar 86 11:42:26 EST Received: from wiscvm.wisc.edu by CSNET-RELAY.ARPA id a000814; 3 Mar 86 11:23 EST Received: from (SIG)CARLETON.BITNET by WISCVM.WISC.EDU on 03/03/86 at 10:19:32 CST Received: from SIG by CARLETON.BITNET on 03 Mar 86 10:38:31 EST Date: 03 Mar 86 09:56:45 EST From: SIG To: Scheme%MIT-MC%csnet-relay@CSNET-RELAY.ARPA MMDF-Warning: Parse error in original version of preceding line at CSNET-RELAY.ARPA Subject: We are using scheme! Hi, My name is Mike Wilson. I'm working for the Carleton University School of Computer Science (my job description says "Computer Scientist" believe it or not). Carleton U. has both TI scheme and MacScheme, as well as Some flavour of scheme running on the engineering department vaxen. Scheme is being used for courses at Carleton at both the undergrad and graduate levels. Currently, I am working on porting Portable CommonLoops (PCL) xerox's "common" object-oriented extension to COMMON LISP to run under TI scheme. In the process of doing this, I've written quite a large common lisp compatability package (keyworded defun and defmacro, format, defstruct, etc.). Given the complexity of the CommonLoops code, I may never get it running completely, but it has certainly been a useful test of the compatability code. I must say though, that I would much rather see people doing scheme compatability packages in common lisp, than the other way around. In their desparate grasping for efficiency, the common lisp people have lost *much* of the elegence of lisping. "If ADA is the PL/1 of the '80s, then COMMON LISP will be the PL/1 of the '90s!"  Received: from SU-SCORE.ARPA by MC.LCS.MIT.EDU 27 Feb 86 19:01:48 EST Received: from camelot ([36.48.0.3].#Internet) by SU-SCORE.ARPA with TCP; Thu 27 Feb 86 15:02:02-PST Received: by camelot with TCP; Thu, 27 Feb 86 14:58:22 pst Date: 27 Feb 1986 1458-PST (Thursday) From: Orca.Starbuck@camelot, To: scheme%mc.lcs.mit.edu@score Cc: starbuck@camelot Subject: Scheme use As a sophomore at Oberlin College last year, I took two courses that involved extensive use of Scheme: 1. a course in functional programming, using Abelson & Sussman's book as the main text. We also used a draft version (?) of a book entitled Fundamental Abstractions of Programming Languages, by W. Clinger, D. Friedman, C. Haynes, E. Kohlbecker, and M. Wand. This book was written for a course at Indiana (natch) on the design and implementation of programming languages. Our version was copyright 1984. I'd heartily recommend it to anyone who can get a copy of it. 2. an introductory course in the denotational semantics. For this course we used M. Gordon's book, The Denotational Description of Programming Languages, as a basic text, and Stoy's book entitled Denotational Semantics for more depth. Most of the work in this class was done directly in Scheme. We wrote general interpreters that took as input denotational descriptions of a language and returned interpreters for that language, which made our work in semantics much easier because we could actually run and debug the semantics for each language. There were also other classes at Oberlin involving Scheme, such as classes in theory and AI. Last year all of our work was done in Scheme 84. I believe that this year they are using Chez Scheme. You can contact my teacher at the following address: Prof. Richard Salter Department of Mathematics Oberlin College Oberlin, Ohio 44074 Oberlin is not, as far as I know, on any computer network. -------  Date: Thu, 27 Feb 86 18:19:27 EST From: Jonathan A Rees Subject: Scheme in Common Lisp To: entropy!jam@UW-BEAVER.ARPA cc: SCHEME@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 25 Feb 86 23:23:34 PST from John Alan McDonald Message-ID: <[MC.LCS.MIT.EDU].832991.860227.JAR> Date: Tue, 25 Feb 86 23:23:34 PST From: John Alan McDonald I would appreciate any information about implementations of Scheme that run on a Symbolics or implementations of Scheme in Common Lisp or Zetalisp. Implementation: CLSCH (Scheme embedded in Common Lisp) Implemented by: Jonathan Rees Support: Unsupported, although I'll probably continue to improve it. No promises. Hardware: Will run, I hope, in any implementation of Common Lisp; has been tested in Symbolics Common Lisp and TOPS-20 CLISP. Availability: Free. Distributed as source via electronic mail or FTP. May eventually become part of Common Lisp "Yellow Pages." Dialect: Subset. All of the essential features of RRRSS exist, except for a correct CALL-WITH-CURRENT-CONTINUATION; also some of the rest of RRRSS, and most of the S&ICP dialect. Intended use: Running existing scheme programs in any Common Lisp. Not an ideal development system, since debugging tools are weak. Implementation: Low-tech. A simple compiler translates Scheme into Common Lisp, making sure that variable binding and tail recursion are done right. The output of the compiler can be interpreted by a CL interpreter or compiled by a CL compiler. Remarks: I did this mostly for my own personal use. Maybe other people will find it useful too. Contact: Jonathan Rees (JAR@MC.LCS.MIT.EDU), MIT Artificial Intelligence Laboratory, 545 Technology Square, Cambridge MA 02139, (617) 253-8581. A list of blurbs of this sort for all known scheme implementations (except MIT scheme) is available in the file "SCHEME; SCHEME IMPLS" on MIT-MC.  Received: from DEEP-THOUGHT.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 FEB 86 15:12:47 EST Date: Thu 27 Feb 86 15:14:02-EST From: Jeff Siegal Subject: Use of Scheme. To: SCHEME@MC.LCS.MIT.EDU In-Reply-To: Message from ""Glenn O. Veach" " of Thu 27 Feb 86 13:00:39-EST Message-ID: <12186771281.32.JBS@DEEP-THOUGHT.MIT.EDU> I don't think I've seen anyone mention this, but of course MIT uses Scheme for 6.001, "Structure and Interpretation of Computer Programs" Jeff Siegal - MIT EECS -------  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 27 Feb 86 12:03:45 EST Received: from ukans by csnet-relay.csnet id aa19363; 27 Feb 86 11:46 EST Date: Wed, 26 Feb 86 12:22:55 CST From: "Glenn O. Veach" To: SCHEME%mc.lcs.mit.edu@CSNET-RELAY.ARPA cc: OXLEY%%ti-csl.csnet@CSNET-RELAY.ARPA Subject: Use of Scheme. This past year at the University of Kansas we used Scheme in two classes. In an undergraduate "Programming Languages" class we went through Abelson and Sussman's book while using Scheme for homework and class projects. In a graduate level "Artificial Intelligence" class we went through Kowalski's book and assigned a project to develop a Horne clause theorem prover which some implemented using Scheme. We are now trying to a curriculum for our "Introductory Programming" course in which we would use MacScheme (we now use Pascal) and would use Abelson and Sussman as a text (probably not the entire book). We would hope to use the remaining chapters of the text for our second semester programming course. We are of course encountering some resistance as we try to forge ahead with Lisp as a basic instructional language. Has anyone been involved with the review process of ACM or IEEE for CS or ECE programs and suggested the use of Lisp as a basic language? What are some of the more compelling arguments for and against such an effort? If anyone could direct me to any B-Boards on ARPA net which would appreciate such a discussion I would appreciate it. I intend to send such an inquiry to AIList and Prolog. Glenn O. Veach Artificial Intelligence Laboratory Department of Computer Science University of Kansas Lawrence, KS 66045-2192 (913) 864-4482 veach%ukans.csnet@csnet-relay  Received: from uw-beaver.arpa by MC.LCS.MIT.EDU 26 Feb 86 02:24:42 EST Received: by uw-beaver.arpa (4.42/4.2) id AA08139; Tue, 25 Feb 86 23:29:30 PST Return-Path: Received: by entropy.UUCP (5.31/1.0.Entropy) id AA23296; Tue, 25 Feb 86 23:23:34 PST Date: Tue, 25 Feb 86 23:23:34 PST From: John Alan McDonald Posted-Date: Tue, 25 Feb 86 23:23:34 PST Message-Id: <8602260723.AA23296@entropy.UUCP> To: scheme@mit-mc Subject: Scheme for a Symbolics I would appreciate any information about implementations of Scheme that run on a Symbolics or implementations of Scheme in Common Lisp or Zetalisp. John Alan McDonald Statistics, GN-22, U of W Seattle, Wa. 98195 (206) 545 7438 jam%entropy@uw-beaver.arpa {decvax,ihnp4,ucbvax!lbl-csam}!uw-beaver!entropy!jam  Received: from LOCUS.UCLA.EDU by MC.LCS.MIT.EDU 26 Feb 86 00:36:04 EST Date: Tue, 25 Feb 86 21:13:06 PST From: Charles Dolan To: scheme@mit-mc Subject: Re: Who is using scheme? Message-ID: <509778786-3011-cpd@ZEUS.LOCUS.UCLA.EDU> At the Hughes Aircraft AI Center we are using MacScheme for research in: natural language, learning, and knowledge based decisions aids. The we are using have 2Mb or memory and 20Mb disks. The main reason we are using Scheme is that it make agenda based programming easier. Charles Dolan Hughes AI Center 23901 Calabasas Rd. Calabasas, CA 91302-1579 cpd@locus.ucla.edu  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 25 Feb 86 17:27:00 EST Received: from ti-csl by csnet-relay.csnet id am09166; 25 Feb 86 16:07 EST Received: by tilde id AA11237; Tue, 25 Feb 86 14:20:19 cst Date: Tue 25 Feb 86 14:09:33-CST From: Ed Subject: Re: Who Is Using Scheme? For What? To: SCHEME%MIT-MC@CSNET-RELAY.ARPA In-Reply-To: <12184956321.17.OXLEY@CSL60> Message-Id: <12186246175.15.FERGUSON@CSL60> I have used Scheme to demonstrate discrete simulation in LISP. I made a presentation last November at the Expert Systems and Simulation Models Seminar in Tucson that included the source text for two versions of a discrete simulation package: event scheduling based on closures and processing interaction based on continuations. About 200 lines of Scheme suffice to illustrate the basic control mechanisms for a simulator. (A copy of my foils (suitable for input to LaTEX) and the Scheme text is available upon request on an "as is" basis.) Ed ================================================================ Ed Ferguson ARPA: FERGUSON%TI-CSL@CSNET-RELAY.ARPA Texas Instruments Inc. CSNET: FERGUSON@TI-CSL POB 226015, M/S 238 USENET: {ut-sally,convex!smu,texsun}!ti-csl!ferguson Dallas, Texas 75266 VOICE: (214) 995-0348 -------  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 25 Feb 86 17:26:32 EST Received: from ti-csl by csnet-relay.csnet id ag09166; 25 Feb 86 16:03 EST Received: by tilde id AA01226; Tue, 25 Feb 86 09:00:32 cst Date: Tue 25 Feb 86 08:49:58-CST From: Clyde Subject: PC SCHEME UTILITIES AND ON-LINE HELP To: scheme%mit-mc@CSNET-RELAY.ARPA Cc: Camp%ti-csl.csnet@CSNET-RELAY.ARPA Message-Id: <12186187998.74.CAMP@CSL60> For anyone seriously (or unseriously) using PCS on the TI Professional Computer, I have a written a set of utilities which make some of the systems functions easier to use. The utilities include procedures to: - easily create/delete popup and non-popup windows as well as manipulate their attributes - pretty-print or verbatum-print source files to the screen or printer - set-up the 850 or 855 printer modes - easily interact with the keyboard at the keystroke level - edit files with the editor of your choice (PFM, WS, PMATE, whatever) and then load, compile, or fsl them automatically. Online HELP and user's manual are included. The procedures are: [8] (help1) SCHEME UTILITY PACKAGE #1 (c) Clyde R. Camp v 3.0 12-18-85 SCREEN: (pp_file source-filespec [output-port/file [line-length]]) (show_file source-filespec [output-port/file [line-length]]) WINDOWS: (make-static-window name top left bot right [text border]) (inside window) (window-pixil-size window) (clear-text [window]) (make-popup-window name top left bot right [text [border]]) (delete-popup-window name) (set-text attr1 [attr2 [window]]) (set-border attr1 [attr2 [window]]) CONSOLE: (split-console at-line) (reset-console) (get-console-key [port]) (wait-for-key [port]) (getchar [port]) (was-key? char [port]) PRINTER: (print_file source-filespec [line-length]) (set850! 'parm ['parm.....]) (set855! 'mode ['parm.....]) MISC: (beep) (help1) (ed/ld/cmp/el/ec/ef/cf/fsl [filename]) ***default-editor***: edit.exe ***default-memory-size***: 8190 ***default-file*** : test.s =============================================================================== For new scheme'ers using the TIPC I have an on-line help facility which condenses the language reference manual into a (approx) 60K byte syntax and information manual. The procedures are organized into generic classes such as WINDOWS, LISTS, NUMBERS, GRAPHICS, I/O, etc. A transcript of a typical usage follows: [3] (help) PCS ON-LINE VERBOSE HELP Version 1.2 01-09-86 (C) Copyright 1985 by Texas Instruments All Rights Reserved (help 'foo) where foo is a valid symbol will return the proper syntax for the function foo or a notification that it is unbound or bound in a specific environment (help 'class) where class is one of the following classes of procedures will return the syntax of all functions within that class CONTROL ENVIRONMENTS FLUIDS GLOBALS SYSTEM DEBUG PREDICATES LISTS SYMBOLS NUMBERS VECTORS CHARACTERS STRINGS WINDOWS I/O GRAPHICS STREAMS SCOOPS ENGINES AUTOLOAD (help 'taciturn) will load a smaller help file with syntax only [4] (help 'fluids) (FLUID VAR) (FLUID-BOUND? VAR) (FLUID-LAMBDA (VAR ...) EXP1 ...) (FLUID-LET ((VAR FORM) ...) EXP1 ...) (SET-FLUID! VAR OBJ) (SET! (FLUID VAR) EXP) INPUT-PORT OUTPUT-PORT SCHEME-TOP-LEVEL [5] (help 'scheme-top-level) SCHEME-TOP-LEVEL This fluid variable is bound to the value of the standard read-eval-print loop. It can be re-bound to a user-defined read-eval-print loop if desired. (reset) will return to this binding. To return the binding to the standard r-e-p loop, use (reset-scheme-top-level). (define user-loop (lambda (...) (fluid-let ((scheme-top-level #!false)) (call/cc (lambda (k) (set! (fluid scheme-top-level) (lambda () (k '()))))) ... body of REP loop ... [6] (help 'graphics) All of the graphics functions are autoloaded. See AUTOLOAD. (CLEAR-GRAPHICS) (CLEAR-POINT X Y) (DRAW-BOX-TO X Y) (DRAW-FILLED-BOX-TO X Y) (DRAW-LINE-TO X Y) (DRAW-POINT X Y) (GET-VIDEO-MODE) (IS-POINT-ON? X Y) (POSITION-PEN X Y) (SET-PALETTE! VALUE DISPLAY-VALUE) (SET-PEN-COLOR! COLOR) (SET-VIDEO-MODE! N) *GRAPHICS-COLORS* For those with smaller systems there is a smaller version (about 20K bytes) which has syntax only. - Clyde Camp Texas Instruments MS238 P.O.Box 226015 Dallas, TX 75266 (214) 995-0407 -------  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 25 Feb 86 06:40:05 EST Received: from upenn by csnet-relay.csnet id bj03692; 25 Feb 86 6:41 EST From: Tim Finin Subject: who's using Scheme To: scheme@mc.lcs.mit.edu Date: Mon, 24 Feb 86 14:36 EST At Penn we are using Scheme as a major component of our introductory programming languages courses at both the graduate and undergraduate level. Our first undergraduate CIS course is still being offered using Pascal, but the second CIS course (taken primarily be second semester freshman) now uses TI's PCS Scheme and Sussman and Abelson's book. This course is currently being taught be Bonnie Webber and myself. We try to cover all of the book and some additional material on strongly typed languages and concurrency. I'm interested in sharing information, assignment ideas, interesting exam problems, etc. with others using Scheme in early undergraduate courses. Tim  Received: from aids-grape.ARPA by MC.LCS.MIT.EDU 25 Feb 86 02:30:27 EST Date: 24 Feb 1986 22:43-PST From: andy@aids-unix.ARPA (Andy Cromarty) Subject: Scheme use To: Scheme@mit-mc Cc: andy@aids-unix.ARPA The computer systems group at Advanced Decision Systems (ADS) in Mountain View, CA, is using Scheme for a variety of purposes: o As a systems programming language o As a vehicle for language design research o As an implementation language for testbed development o As a matter of moral principle Two specific ways in which we are employing Scheme that may be of interest are: o As the implementation language for a heterogeneous distributed systems testbed, and correspondingly, o As the language substrate into which we embed programming language constructs for distributed processing, as we design them, for study and use. (Some of you may not know ADS. Formerly known as Advanced Information & Decision Systems, ADS likely has the distinction -- some would say the "dubious distinction" -- of being the largest concentration of DoD-relevant applied AI expertise in the world. We also do commercial AI work. We are 100% employee-owned, and for the most part we are engaged in contract R&D. End of advertisement.) Our Scheme-hacking staff includes people who learned Scheme both at MIT in 6.001 and at Indiana under Friedman et alia, as well as designers and implementors of other large non-Scheme LISPs. Needless to say, this makes for some interesting (perhaps that should read "raging") ethical debates during group design meetings. We currently employ four Schemes to varying extents: o MIT C-Scheme, which we have retargeted for the Pyramid 90X and SUN-3 in addition to using it on a VAX 11/780. (We've already provided the trivial SUN-3 mods to SUN, and will be shipping the lot of them back to MIT soon for redistribution, along with a package that brings MIT C-Scheme up to the RRRS standard.) o Indiana's Scheme-84, which we have running on all the above machines, with a port to the Lisp Machine marginally in progress. (We also have some mods to the Scheme-84 compiler in completion now that bring it more in line with the RRRS standard.) o MacScheme for the Apple Macintosh. (Will, you did a nice job; no mods on this one yet.) o A Scheme compiler/interpreter we've written ourselves and on which work is actively under way. More details will follow when we feel we have something significant to contribute. We also have a Butterfly processor and expect to use BBN's Scheme for the Butterfly whenever it emerges from the cocoon, so to speak (sorry, bad pun), and TI PC Scheme is or soon will be on order. cheers, asc p.s. I recently convinced a friend and collleague to use Scheme as the implementation language for a commercial dial-in system providing economic modeling services. (He used TI's PC Scheme.) The demo was to be today; if he made the deadline, I imagine that must represent one of the first practical commercial uses of Scheme.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 25 Feb 86 00:16:02 EST Received: from ucbvax.berkeley.edu by CSNET-RELAY.ARPA id a000649; 24 Feb 86 23:47 EST Received: by ucbvax.berkeley.edu (5.45/1.9) id AA09340; Mon, 24 Feb 86 20:42:32 PST Received: from image.UCSB (image.ARPA) by ucsbcsl.UCSB (4.12-sdp/3.0.UCSB-sdp) id AA22913; Mon, 24 Feb 86 13:24:42 pst Received: by image.UCSB (2.0/2.0.UCSB-sdp) id AA07510; Mon, 24 Feb 86 13:25:14 pst Date: Mon, 24 Feb 86 13:25:14 pst From: Ken Zeger Posted-Date: Mon, 24 Feb 86 13:25:14 pst Message-Id: <8602242125.AA07510@image.UCSB> To: Scheme%MIT-MC%csnet-relay@CSNET-RELAY.ARPA Subject: Re: Who is using Scheme? For What? I alone am using scheme at UCSB (University of California, Santa Barbara). I use it in my speech coding research, and for genearl programming purposes. I've been trying to get others to try it out with little success. There seems to be some here that enjoy Franz Lisp that they learned in CS course taught. My address is ucbvax!zeger%image@ucsbcsl.ARPA Ken Zeger (805)-685-2676  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 24 Feb 86 21:32:39 EST Received: from cisl-service-multics.arpa by CSNET-RELAY.ARPA id a002763; 24 Feb 86 21:08 EST Acknowledge-To: "Eric J. Swenson" Date: Mon, 24 Feb 86 21:03 EST From: "Eric J. Swenson" Subject: Re: Who Is Using Scheme? For What? To: Rusty Haddock cc: Scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA In-Reply-To: Message of 24 Feb 86 16:09 EST from "Rusty Haddock" Message-ID: <860225020338.096619@CISL-SERVICE-MULTICS.ARPA> Ok, thanks for the info on PCS and the Z-100.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 24 Feb 86 17:35:36 EST Received: from ti-csl by csnet-relay.csnet id ab00901; 24 Feb 86 17:36 EST Received: by tilde id AA12842; Mon, 24 Feb 86 15:20:16 cst Date: Mon 24 Feb 86 15:09:42-CST From: Rusty (Fe2O3)Haddock (N. Atlantic fish) Subject: Re: Who Is Using Scheme? For What? To: Scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA In-Reply-To: <860224160818.006238@CISL-SERVICE-MULTICS.ARPA> Message-Id: <12185994981.14.HADDOCK@CSL60> >Question: Does the TI PC-SCHEME work on Zenith Z-100s running MSDOS version 2? Sorry, but PCS doesn't due to the Zenith Z-100 not having a BIOS (in the I/O areas) similar enough to the IBM-PC (TI's is close, just moves the vectors around and sometimes expects arguments in different registers) . Most everything on this Zenith model, as I understand it, uses ESCape sequences to hand screen functions as well as some keyboard functions. It would entail some major work to modify the current PCS to work on the Z-100. As an employee of Texas Instruments I have looked into this problem and found no quick or painless way around the Z-100. -Rusty- ================================================================ *hardcopy* *electr{onic, ic}* Rusty Haddock ARPA: HADDOCK%TI-CSL@CSNET-RELAY.ARPA POB 226015 M/S 238 CSNET: HADDOCK@TI-CSL Texas Instruments Inc. USENET: {ut-sally,convex!smu,texsun}!ti-csl!haddock Dallas, Texas VOICE: (214) 995-0330 75266 -------  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 24 Feb 86 12:44:38 EST Received: from ti-csl by csnet-relay.csnet id ab27770; 24 Feb 86 12:37 EST Received: by tilde id AA06119; Mon, 24 Feb 86 10:20:16 cst Date: Mon 24 Feb 86 10:08:44-CST From: Don Oxley Subject: Re: Who Is Using Scheme? For What? To: OXLEY%%ti-csl.csnet@CSNET-RELAY.ARPA, Scheme%MIT-MC <@CSNET-RELAY.ARPA:Scheme%MIT-MC@mit-mc%csnet-relay> In-Reply-To: <12184956321.17.OXLEY@CSL60> Message-Id: <12185940193.17.OXLEY@CSL60> In replying to my own request for uses of Scheme: We at TI are using Scheme (primarily PCS) in a number of different projects - both in support of our research and for personal projects. I am hopeful that others will reply in more detail on some of the individual projects. In addition to our interest in PCS as a product, TI has announced new versions of our Personal Consultant and Arborist software packages which are written in Scheme (support for these packages was one of the primary reasons that PCS was created). In our research efforts within my branch, we are using Scheme as a systems programming language. We have developed packages for the PC which allow us to control a TI Explorer as a microengine for architectural research (the package is somewhat specific to our particular needs, it is not a truly general facility). We are also using Scheme (and PCS) as an implementation vehicle for our continuing research in compilation techniques. We have used Scheme as a vehicle to study problem solving techniques such as the integration of logic and functional programming. We have also used it as a vehicle to discuss systems programming issues - particularly with the Indiana folk on continuation based programming. I am using Scheme to develop an architectural simulator (currently on PCS, I also plan to port to Chez Scheme on the VAX for more horsepower) for an "Optically Interconnected Dataflow Signal Processor" which we are developing on an ONR contract. Interestingly, I am able to simulate about a 40 node system on my PC with a (marginally) acceptable throughput. Elsewhere in TI, we are using Scheme and the MIT Structure and Interpretation course as one of the offerings in TI's internal continuing education curiculum. We are also developing our own course at a somewhat lower level in programming with Scheme. I am also aware of a number of other projects which are using Scheme for developing expert systems or simulation for various purposes. I don't know details on many of them. Hopefully some of them will repsond separately. Altogether, I would say that at least a few hundred persons at TI have had at least an introductory course which involves Scheme. I'm not sure how many projects are actively using it, but there are several. --Don -------  Received: from BBNJ.ARPA by MC.LCS.MIT.EDU 24 Feb 86 12:04:55 EST To: scheme@mit-mc.ARPA cc: allen@BBNJ.ARPA Subject: Butterfly Lisp Date: 24 Feb 86 09:50:24 EST (Mon) From: allen@BBNJ.ARPA At BBN, we are basing our implementation of a Lisp for the Butterfly multiprocessor on MIT's implementation of Scheme. Although ultimately the surface language the users of our system will see will be Common Lisp, we chose Scheme in part because of its relative simplicity and conceptual cleanliness, making it a good setting for working out parallel processing issues. /Don Allen  Received: from CISL-SERVICE-MULTICS.ARPA by MC.LCS.MIT.EDU 24 Feb 86 11:15:45 EST Posted-Date: 24 Feb 86 11:10 EST Acknowledge-To: "Eric J. Swenson" Date: Mon, 24 Feb 86 11:08 EST From: "Eric J. Swenson" Subject: Re: Who Is Using Scheme? For What? To: Don Oxley , SCHEME@MC.LCS.MIT.EDU In-Reply-To: Message of 20 Feb 86 17:04 EST from "Don Oxley" Message-ID: <860224160818.006238@CISL-SERVICE-MULTICS.ARPA> This is a reply to your query about SCHEME users: I am taking a graduate course at Boston University entitled "Data Abstractions and Object-Oriented Programming" in which SCHEME is the primary language being used as a vehicle to discuss these topics. Our instructor has several copies of the TI PC-SCHEME and is offering student prices for the PC-SCHEME from TI to those students with IBM-PCs. We also use a version of SCHEME for the VAX. I am on the SCHEME mailing list, but I'm not sure if the professor is. His name is Peter Mager and his Internet address is: met128%bostonu.bitnet -at csnet-relay.arpa Question: Does the TI PC-SCHEME work on Zenith Z-100s running MSDOS version 2?  Received: from LOCUS.UCLA.EDU by MC.LCS.MIT.EDU 23 Feb 86 17:54:05 EST Date: Sun, 23 Feb 86 14:33:32 PST From: "Dr. Josef Skrzypek" To: SCHEME@MIT-MC Subject: SCHEME based PC Vision Station Message-ID: <509582012-13086-skrzypek@DIANA.LOCUS.UCLA.EDU> PCVS Project Scheme-based Personal Computer Vision Station is being developed by a group my graduate students in Computer Science Dept. We are using version 1.0 for software and Imaging Technology board FG100AT as a front-end hardware for image acquisition. The PCVS will be used for instructional purposes in the undergraduate and graduate courses on Computer Vision. --josef skrzypek  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 22 Feb 86 15:33:37 EST Received: from uoregon by csnet-relay.csnet id a009777; 22 Feb 86 15:31 EST Received: from uo-vax1.UONET (uo-vax1) by uo-vax3.UONET with TCP (4.12/1.0.UofO) id AA01281; Sat, 22 Feb 86 11:49:53 pst Received: by uo-vax1.UONET (4.12/1.0.UofO) id AA21105; Sat, 22 Feb 86 11:46:26 pst Date: Sat, 22 Feb 86 11:46:26 pst From: Steve Fickas Posted-Date: Sat, 22 Feb 86 11:46:26 pst Message-Id: <8602221946.AA21105@uo-vax1.UONET> To: scheme@mc.lcs.mit.edu Subject: Use of MacScheme Cc: fickas%uo-vax1%uoregon.csnet@CSNET-RELAY.ARPA, art%uo-vax2%uoregon.csnet@CSNET-RELAY.ARPA In answer to Don Oxley's call for information, we are just concluding an experimental Scheme section of our intro course for CS majors. We used MacScheme on the Macintosh (from Semantic Microsystems) and Abelson and Sussman's book over two quarters. We judged the experiment to have been a qualified success, and at this point plan to use Scheme (along with Modula-2) for all sections next year. We have built a moderate amount of instructional software in support of the course; we would be glad to share it, although most of it relies on the Mac's toolbox. We'd also be happy to discuss problems we ran into, what will change next year, etc. Steve Fickas and Art Farley Computer Science Department University of Oregon Eugene, Or. 97403 (503) 686-4408 fickas@uoregon, art@uoregon  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 22 Feb 86 01:45:39 EST Received: from ti-csl by csnet-relay.csnet id ak04008; 22 Feb 86 1:43 EST Received: by tilde id AA07158; Thu, 20 Feb 86 16:26:20 cst Date: Thu 20 Feb 86 16:04:10-CST From: Don Oxley Subject: Who Is Using Scheme? For What? To: Scheme%MIT-MC%csnet-relay@CSNET-RELAY.ARPA Message-Id: <12184956321.17.OXLEY@CSL60> Over the few weeks since PC Scheme has become available, I have had a number of questions about who is using Scheme, what they are doing, etc. There seems to be a number of persons/groups who are undertaking interesting projects and or courses involving Scheme (PCS or otherwise) but there is very little evidence of communication among the users themselves. (There is getting to be a moderate volume of communication between users and many of us here at TI.) We at TI would like to encourage the development of an active community which is discussing Scheme and its use, sharing ideas and code, etc. The existing SCHEME mailing list at MIT seems to be the appropriate forum for discussion if we can convince people to sign up and/or exploit it. In particular, we at TI would like to assist and participate in the process, but would NOT like to become any focal point or filter because of our proprietary interests. I encourage you to do two things: (1) Reply to this message (to SCHEME@MIT-MC, not to me) with a brief summary of how/why... you are using Scheme along with any particulars you can supply (eg., dialect, status of effort...). If you have particularly interesting code or code segments, problem sets, instructional materials, ... which you would be willing to share please describe them. If there are issues or topics on which you would like to see a discussion, please include them as well. (2) If you know of other Scheme users who may not see this message, forward it to them and ask them to get on the list. This can be done by sending mail to Scheme-Request@MIT-MC and asking to be included on SCHEME@MIT-MC. I am particularly interested in the experiences of our new PC Scheme users. I hope to use the feedback to further the cause of Scheme here at TI and to help us improve the product itself. I'm sure the other system developers will welcome such feedback also. Thanks, --Don Oxley -------  Received: from yale by MC.LCS.MIT.EDU 29 Jan 86 13:19:18 EST Received: by Yale-Bulldog.YALE.ARPA; 29 Jan 86 09:49:57 EST (Wed) Date: 29 Jan 86 09:49:57 EST (Wed) From: Message-Id: <8601291449.AA11227@Yale-Bulldog.YALE.ARPA> Subject: Re: Of growing code and diminishing hacks... To: Cc: t-discussion@YALE.ARPA, scheme@mit-mc.arpa In-Reply-To: , 29 Jan 86 01:14 PST And another thing. The only reason NIL == #F usually works out so well in lisps is that the most common domain of concern is lists. In both C and APL, FALSE == 0 since a very common domain of concern is numbers. I didn't say that NIL was in any way the best choice for FALSE across all languages. In Lisps, NIL = #F is just as reasonable as 0 = FALSE in C or APL. Try telling a C programmer that 0 won't be FALSE anymore. -------  Received: from yale by MC.LCS.MIT.EDU 29 Jan 86 13:05:55 EST Received: by Yale-Bulldog.YALE.ARPA; 29 Jan 86 09:39:05 EST (Wed) Date: 29 Jan 86 09:39:05 EST (Wed) From: Message-Id: <8601291439.AA10931@Yale-Bulldog.YALE.ARPA> Subject: Re: Of growing code and diminishing hacks... To: Cc: t-discussion@YALE.ARPA, scheme@mit-mc.arpa In-Reply-To: , 28 Jan 86 23:36 PST (define (overloaded-cdr val) (if (null? val) nil (cdr val))) (overloaded-cdr (assq key a-list)) In other words, if you want a cdr that horribly overloads nil, then write one. As for me, I think of a cons cell as an object with car and cdr fields in it, just as a point is an object with x and y fields in it. How about: (define (overloaded-x point) (if (null? point) nil (x point))) So now we have a proliferation of functions. You could just as well think of CAR and CDR as operations, and NIL as an object that handles them by returning NIL. Much cleaner. Well, maybe not; I guess that's debatable. I think the code is cleaner even though the semantics that the compiler must implement may become a little hairier. But that's what compilers are for :-). -------  Date: Wed, 29 Jan 86 08:58:51 EST From: "George J. Carrette" Subject: Overloading of empty list as false. To: Miller.pa@XEROX.COM cc: SCHEME@MC.LCS.MIT.EDU, t-discussion@YALE.ARPA, ram@YALE-RING.ARPA In-reply-to: Msg of 29 Jan 86 01:14 PST from Miller.pa at Xerox.COM Message-ID: <[MC.LCS.MIT.EDU].800287.860129.GJC> The primacy of lists in lisp is due to the fact that lisp is its own meta language and the vocabulary of that meta language is constructed inductively from lists, symbols and other constants. Furthermore, the most general graphs can be constuctured entirely in terms of bifurcations represented as cons cells; and bifurcations have a primacy over trifurcations etc. Topping this off by using the logical falsity constant as the token to mark the end of certain kinds of graphs is entirely natural definition to use. The lists themeselves will remain in their primacy as a prefered construct of efficient assembly language programming, (especially if this means your assembly language is LISP on a LISPMACHINE). Take note Plummer's multilisp emulator that he implemented on the 3600: Comments in the code indicating that using (SETQ *STACK* (CONS ELEMENT *STACK*)) was more efficient than using the C/FORTRAN/PASCAL style INDEX plus ARRAY, because the GC overhead was smaller than the expense of the extra instructions and memory references needed to manipulate the more complicated data structure. But I am arguing the barn door closed after the cows have left. The recent slant of revised-revised-report-on-scheme has indeed cleaned up things to make them more acceptable to the general community; throwing out all the obvious meta language machinery and with it much of the preference for lists. The reason that FALSE == 0 in C is not due to the concern for the domain of numbers. (Since in C one will often mark the end of character strings with 0, and represent the NULL pointer as 0 also). FALSE == 0 because of the instruction sets and memory organizations of the machines on which C was developed. Similarly in PDP10 Maclisp and CADR Lispmachine NIL == 0 (as a machine location address).  Received: from Xerox.COM by MC.LCS.MIT.EDU 29 Jan 86 04:21:45 EST Received: from Salvador.ms by ArpaGateway.ms ; 29 JAN 86 01:20:42 PST Date: 29 Jan 86 01:14 PST From: Miller.pa@Xerox.COM Subject: Re: Of growing code and diminishing hacks... In-reply-to: 's message of 28 Jan 86 06:22:59 EST (Tue) To: ram%YALE-RING@YALE.ARPA cc: t-discussion@YALE.ARPA, scheme@MC.LCS.MIT.EDU Message-ID: <860129-012042-1051@Xerox> And another thing. The only reason NIL == #F usually works out so well in lisps is that the most common domain of concern is lists. In both C and APL, FALSE == 0 since a very common domain of concern is numbers. Hopefully we are moving towards a programming style that is more abstract datatype or object based, and so the primacy of lists will diminish. In any case, I don't want my programming language prejudging for me what types of object should be my major concern, and compromising its foundations to optimize for that one type.  Received: from Xerox.COM by MC.LCS.MIT.EDU 29 Jan 86 02:52:42 EST Received: from Cabernet.ms by ArpaGateway.ms ; 28 JAN 86 23:49:12 PST Date: 28 Jan 86 23:36 PST From: Miller.pa@Xerox.COM Subject: Re: Of growing code and diminishing hacks... In-reply-to: 's message of 28 Jan 86 06:22:59 EST (Tue) To: ram%YALE-RING@YALE.ARPA cc: t-discussion@YALE.ARPA, scheme@MC.LCS.MIT.EDU Message-ID: <860128-234912-1014@Xerox> (define (overloaded-cdr val) (if (null? val) nil (cdr val))) (overloaded-cdr (assq key a-list)) In other words, if you want a cdr that horribly overloads nil, then write one. As for me, I think of a cons cell as an object with car and cdr fields in it, just as a point is an object with x and y fields in it. How about: (define (overloaded-x point) (if (null? point) nil (x point)))  Received: from yale by MC.LCS.MIT.EDU 28 Jan 86 13:47:21 EST Received: by Yale-Bulldog.YALE.ARPA; 28 Jan 86 06:22:59 EST (Tue) Date: 28 Jan 86 06:22:59 EST (Tue) From: Message-Id: <8601281122.AA16563@Yale-Bulldog.YALE.ARPA> Subject: Of growing code and diminishing hacks... To: t-discussion@YALE.ARPA, scheme@mit-mc.arpa A SHORT BALLAD DEDICATED TO THE GROWTH OF PROGRAMS ================================================== by Ashwin Ram This is a tale of a sorry quest To master pure code at the T guru's behest I enrolled in a class that appealing did seem For it promised to teach fine things like T3 and Scheme The first day went fine; we learned of cells And symbols and lists and functions as well Lisp I had mastered and excited was I For to master T3 my hackstincts did cry I sailed through the first week with no problems at all And I even said "closure" instead of "function call" Then said the master that ready were we To start real hacking instead of simple theory Will you, said he, write me a function please That in lists would associate values with keys I went home and turned on my trusty Apollo And wrote a function whose definition follows: (cdr (assq key a-list)) A one-liner I thought, fool that I was Just two simple calls without a COND clause But when I tried this function to run CDR didn't think that NIL was much fun So I tried again like the good King of yore And of code I easily generated some more: (cond ((assq key a-list) => cdr)) It got longer but purer, and it wasn't too bad But then COND ran out and that was quite sad Well, that isn't hard to fix, I was told Just write some more code, my son, be bold Being young, not even a moment did I pause I stifled my instincts and added a clause (cond ((assq key a-list) => cdr) (else nil)) Sometimes this worked and sometimes it broke I debugged and prayed and even had a stroke Many a guru tried valiantly to help But undefined datums their efforts did squelch. I returneth once more to the great sage of T For no way out of the dilemma I could see He said it was easy -- more lines must I fill with code, for FALSE was no longer NIL. (let ((val (assq key a-list))) (cond (val (cdr val)) (else nil))) You'd think by now I might be nearing the end Of my ballad which seems bad things to portend You'd think that we could all go home scot-free But COND eschewed VAL; it wanted #T So I went back to the master and appealed once again I said, pardon me, but now I'm really insane He said, no you're not really going out of your head Instead of just VAL, you must use NOT NULL instead (let ((val (assq key a-list))) (cond ((not (null? val)) (cdr val)) (else nil))) My song is over and I'm going home to bed With this ineffable feeling that I've been misled And just in case my point you have missed Somehow I preferred (CDR (ASSQ KEY A-LIST)) :-) ================================================== -------  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 23 Jan 86 16:01:14 EST Received: from indiana by csnet-relay.csnet id aj13046; 23 Jan 86 15:52 EST Date: Thu, 23 Jan 86 15:45:07 est From: Kent Dybvig To: scheme@mc.lcs.mit.edu Subject: Re: Industrial-strength Scheme class. I think you might do well to look at the new "Little Lisper", by Dan Friedman and Matthias Felleisen. Every program seems to work without modification in Chez Scheme, and I believe there is no problem with other Schemes either (i.e., Scheme84, TIPC Scheme). The Little Lisper starts out the way the old one did, teaching the student about recursion, lists, etc. But the new edition also covers first-class functions, even going so far as to introduce a "by-value" Y-combinator. The code for a Scheme interpreter is given in the book. Assignments, continuations, and engines are not covered in the LL, but that's alright since these topics are better left until after you cover the material in the LL. You should definitely cover set! after you get through the LL. As for continations and engines, I find that people are able to pick up and enjoy engines in a short time period, but that continuations confuse them. So if you have extra time left over, I would definitely cover engines. I think the LL is more suited to a short class than the A&S text; for a longer class I would cover the LL first, then A&S. The LL is also a "self-study" text, so that what you don't cover in class the students can pick up easily on their own. Dan may be able to tell you more about it (dfried@indiana). I'm sure that SRA would send you a copy if you tell them what you need it for. Kent Dybvig dyb.indiana@csnet-relay (CSNET) ...!ihnp4!iuvax!dyb (USENET)  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 JAN 86 17:42:37 EST Date: Tue, 21 Jan 1986 17:41 EST Message-ID: From: HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: marick%fang@GSWD-VMS.ARPA (Brian Marick) Cc: scheme@MC.LCS.MIT.EDU Subject: Industrial-strength Scheme class. In-reply-to: Msg of 21 Jan 1986 14:45-EST from marick%fang at gswd-vms (Brian Marick) MIT runs summer courses in this material for industry types. The courses are two weeks of very intense full-time work. If I were you, I'd be really nervous about teaching this to people who are simultaneously holding full-time jobs. Given your goals, I would not attempt to do more than the first 4 chapters. It is VERY IMPORTANT that people do some programming, not just listen to you lecture. Contact McGraw-Hill and get hold of Julie Sussman's instructor's manual for the course, which has some problem-set material. Good luck.  Received: from gswd-vms.ARPA by MC.LCS.MIT.EDU 21 Jan 86 14:48:47 EST Received: from fang.GSD (fang.ARPA) by gswd-vms.ARPA (5.9/5.6) id AA00332; Tue, 21 Jan 86 13:47:44 CST Message-Id: <8601211947.AA00332@gswd-vms.ARPA> Date: Tue, 21 Jan 86 13:45:09 cst From: marick%fang@gswd-vms (Brian Marick) To: scheme@mc.lcs.mit.edu Subject: Industrial-strength Scheme class. I am planning to teach a class in Scheme at work this summer. I'll be using _Structure and Interpretation of Computer Programs_ and Indiana's version of Scheme. The people in the class will mostly be experienced C programmers, along with a scattering of technical writers (with some Pascal experience) and ex-programmers-now-managers. I'm teaching the class to expose these people to new styles of programming, styles that (I hope) are becoming increasingly important. I'm not an experienced teacher, though I have taught such a classlet before. Does anyone have any suggestions as to how I ought to go about this? What should I skim over? What should I concentrate on? Does the book contain too much or too little to be covered in a summer, considering that the people are experienced but also have full-time-or-more jobs? How should I supplement the book, and with what? Thanks. Brian Marick Gould CSD - Urbana  Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 DEC 85 14:22:18 EST Date: Fri, 20 Dec 1985 14:17 EST Message-ID: From: CPH%MIT-OZ@MIT-MC.ARPA To: Duke Briscoe Cc: SCHEME@MC.LCS.MIT.EDU Subject: Editors used with Scheme In-reply-to: Msg of 20 Dec 1985 13:37-EST from Duke Briscoe Folks around here seem to use Emacs almost exclusively. I think that most people find it pretty adequate, although, not being familiar with the Interlisp structure editor, I may not know what I'm missing. Perhaps your Emacs is deficient? You mentioned mocklisp, which leads me to believe that you are using Gosling Emacs. If you are using BSD Unix, maybe you should try GNU Emacs, which is available free and is the best Emacs there is (Stallman wrote it). If you try that and still find it lacking, then perhaps Emacs implementors should make some changes.  Received: from mitre.ARPA by MC.LCS.MIT.EDU 20 Dec 85 13:38:08 EST Full-Name: DUKE BRISCOE Message-Id: <8512201837.AA03811@mitre.ARPA> Organization: The MITRE Corp., Washington, D.C. To: SCHEME@MIT-MC Subject: Editors used with Scheme Date: 20 Dec 85 13:37:37 EST (Fri) From: Duke Briscoe I'm not very happy using my version of Emacs with Scheme, because of deficiencies in the pretty printer and the general lack of commands specialized for editing lisp. What I would like would be a structure editor like the one in Interlisp, along with the necessary integration with a file package. Does anybody have something like that? Is everybody else using some version of Emacs or something similar? Does somebody have some huge amount of mocklisp code to make Emacs comparable to the Interlisp structure editor? I may attempt to put together a structure editor in Scheme if I don't hear any satisfactory alternatives.  Date: Sun, 15 Dec 85 19:42:55 EST From: Jonathan A Rees Subject: [CPH%MIT-OZ: HP 300s] To: SCHEME@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].755222.851215.JAR> I'm forwarding this because I though it might be of general interest. - Jonathan Date: Thu, 12 Dec 1985 18:45 EST From: CPH%MIT-OZ at MIT-MC.ARPA To: KGK%Brown.CSNet at CSNET-RELAY.ARPA Re: HP 300s Have you people put Scheme on these putative ai machines yet? As a matter of fact, would you know of any good source of information for these machines? We just got a few and I may be the one to have to figure out what they're good for. Like whether it's a research machine or an educational machine, things like that. We have yet to receive the remaining pieces of our model 320s, so I suppose that the answer to your first question is no. However, within several months we will undoubtedly have transferred all of our implementation to them. As for your other questions: we have alot of experience with the 200 series machines, which are reputed to be about half the speed of the 300 series. They seem to have adequate memory for some fairly big programs, and with the compiler we are now using they run many benchmarks within a factor of 3 or 4 of a 3600. So I would say that they are very adequate for a number of research purposes, and much more than adequate for educational purposes.  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 14 DEC 85 08:25:33 EST Date: Sat, 14 Dec 1985 08:22 EST Message-ID: From: HAL%MIT-OZ@MIT-MC.ARPA To: scheme@MIT-MC.ARPA Subject: intro computer science course at Brandeis This past semester, Brandeis University changed its introductory computer science subject to use "Structure and Interpretation of Computer Programs" and Scheme (running on Texas Instruments PCs). The following essay is by Harry Mairson, who was in charge of the subject. \magnification = 1200 \centerline {\bf Structure and Interpretation of Computer Programs} \centerline{Autumn Semester, 1985} \medskip \centerline{\sl by Harry Mairson} \bigskip \bigskip \parskip = 5pt plus1pt minus .5pt This year, the Brandeis computer science department introduced a new introductory course for its prospective majors. {\sl Structure and Interpretation of Computer Programs}, a textbook and novel curriculum under development at MIT for several years, replaced a standard course teaching Pascal and modular programming. I taught the course in cooperation with Harold Abelson, one of the MIT professors who developed the curriculum. As the course comes to a conclusion this term, I would like to make a few comments about its contents, and why I believe it has been and will continue to be a success at Brandeis. First of all, ``Structure and Interpretation of Computer Programs'' is a sophisticated and high-powered course, presenting to students with no presumed background in computer science an intensive introduction to the subject of computation. Among the subjects presented in this course are: induction and recursion, lambda calculus, actor models, tail recursion, orders of growth, abstraction mechanisms, data-driven and procedure-driven (i.e., ``message passing'') computation, data structures, substitution and environment models of computation, stream processing, applicative- and normal-order evaluation, how interpreters and compilers work, and logic programming. All this as an {\sl introduction} to computer science! I did not learn about many of these subjects until I was in graduate school, and some I learned only while teaching this innovative course. Such an ambitious curriculum cannot succeed without a substantial commitment of resources from both students and the University. Students worked 15 to 20 hours a week on this course, sometimes more. The computer science department bought 18 Texas Instruments Professional Computers, with the latest version of the Scheme programming language that was practically hot off the press; there were fewer than three students per personal computer. Hal Abelson gave a two-hour master class each week. I gave two one-hour recitation lectures, plus interminable tutorials. (I had no fixed office hours, tried to be in as much as possible, and students badgered me with questions constantly, sometimes until early morning...) Three teaching assistants, Brandeis graduate students Larry Bookman, Xiru Zhang, and Brandeis senior Moises Lejter ran one-hour tutorials every week in groups of four to five students, and worked as tutors in the laboratory. They were unflagging in their dedication and patience. In addition, they were joined by three MIT undergraduates, David Alcocer, Jos\'e Capo, and Scott Heeschen, providing on-the-spot counseling and tutoring in the midst of programming crises. The MIT students were great, but as I joked to them on their arrival, ``I'm delighted to have you help, and I can't wait to throw you out.'' Next year, Brandeis undergraduates will take their places. The kids in the class knew every resource we could conceivably provide them was there. Given that total commitment, they showed beyond any doubt their own commitment and willingness to work real hard and absorb the material. This course has something new and profound to say about computation and learning. With no time wasted, it immediately plunges into a discusssion of the {\sl semantics} of computation, and treats almost peripherally the questions of syntax. The importance of this approach can best be explained by considering the difference between learning a foreign language (say, French) and a computer language. Before learning my first word of French, I already understood the semantics of the language, since ``meaning'' means the same thing in English as it does in French, despite any Gallic claims to the contrary: the French talk about tables, chairs, families, taxes, good food, vacations; they use the same verbs, adjectives, and adverbs as we do, and essentially the same notions of time. So ``learning French'' meant learning a new grammar to express the same ideas and thoughts I already knew how to express in English. The same cannot be said for learning a computer language, because there the overriding questions of the {\sl d\'ebutant} are: what is the computer doing, what {\sl can} it do, and what does my program {\sl mean?} The grammar of any programming language is far simpler than that of French; given enough compulsiveness, anyone can learn to make sure that all the semicolons are in the right place, that for every {\tt BEGIN} there is an {\tt END}, that left and right parentheses match. These grammatical rules are annoying, but not conceptually deep. It happens that this course is taught using the Scheme language, a dialect of a more famous programming language called Lisp. But as the authors of the text write, ``After a short time we forget about syntactic details of the language (because there are none), and get on with the real issues.'' The Scheme language is used because it expresses easily a wide range of computational processes, but these processes, and not the language itself, are the centerpiece of this course. Such an emphasis, as well as many other aspects of the course, is in the best tradition of liberal education. The course is not simply a compendium of ``current'' tricks of the programming trade that will doubtless change in the next six months, but presents a foundation from which today's and tomorrow's issues and controversies in computer science can be understood and put into perspective. I expect this course will teach students to think for themselves. Computer science often attracts the ire of specialists in other academic fields, principally physicists and mathematicians, but philosophers and just about everyone else too, because it seems so narrow and self-referential that it doesn't relate to other fields of study. This course goes a long way to healing the wounds of that misconception, as well as teaching students a healthy appreciation for the respective fields that are not simply the ancestors of computer science, but its much needed partners in the pursuit of knowledge and understanding. That means I want my students to take lots of math, physics, and philosophy courses, and know what these subjects are about! For example, no discussion of the meaning of language can take place outside the tradition of philosophy and its profound contribution to the understanding of language. In the Scheme language, for example, the meaning of a simple expression like {\tt (cons x y)} can be explored on many levels, none of them artificial. The mechanism used by the computer to evaluate this expression can be implemented in several ways that are substantially different: {\tt (cons x y)} could be interpreted as a memory structure, an integer, or a procedural abstraction. On the other hand, the expression has precise meaning simply in its fixed use with respect to the other constructs of the Scheme language. I spent one lecture describing these two radically different points of view, showing how the former view of ``meaning as implementation'' is the direct descendant of logical atomism in the tradition of Bertrand Russell and his followers, while the latter idea of ``meaning as use'' is a natural consequence of the philosophy of language as proposed in the later writings of Ludwig Wittgenstein. Similarly, in a discussion of the so-called ``environment model'' of computation, the subject of denotation is explored: we understand how classical problems of referential transparency in language are resolved, and how conceptions of meaning and time relate to each other. The semantics of computation becomes a controlled laboratory where we can discover more about the complex relationship of meaning and language. Apart from the usual arithmetic programming examples, the course draws on problems and examples from mathematics and physics. In one two-week problem set, for example, the students implemented a video game called ``Lunar Lander,'' where a spaceship with a fixed amount of fuel must be landed under a gravitational force without crashing. In doing so, they experimented with a variety of landing strategies. The principal goal of the problem set is to teach the students how to use something called lambda expressions, a programming language construct borrowed from mathematical logic. But the problem set also makes the students think about models of physical reality, where computation is not simply {\sl sui generis} but an analog of the physical world. They implemented an optimal fuel-efficient landing strategy, and I made them understand the ideas of calculus and elementary physics that justifies calling the strategy optimal. In other material developed in the course, methods of data structuring are used to implement symbolic differentiation as in the differential calculus. Stream processing provides a method for understanding integration, and shows how the arithmetic of infinite power series can be automated. The connections of these methods to the Macsyma system of ``symbolic mathematics,'' a computer system of great use to researchers in science and mathematics, are no mere coincidences. Finally and most profoundly, the material presented in this course teaches a wonder and respect for computation. It is true, as often repeated in that hackneyed phrase, that computers only do what we tell them to. Stated otherwise, a computational process evolves in a deterministic fashion from an initial state, subject to fixed and mechanical constraints on the nature of that evolution. But the potential richness, depth, and variety of that evolution, as this course teaches, is truly mind-boggling. In the introduction to their book, Harold Abelson and his co-author Gerald Jay Sussman, also of MIT, write the following: \bigskip \item{} We are about to study the idea of a {\sl computational process.} Computational processes are abstract beings that inhabit computers. As they evolve, processes manipulate other abstract things called {\sl data.} The evolution of a process is directed by a pattern of rules called a {\sl program.} People create programs to direct processes. In effect, we conjure the spirits of the computer with our spells. \item{} A computational process is indeed much like a sorcerer's idea of a spirit. It cannot be seen or touched. It is not composed of matter at all. However, it is very real. It can perform intellectual work. It can answer questions. It can affect the world by disbursing money at a bank or by controlling a robot arm in a factory. The programs we use to conjure processes are like a sorcerer's spells. They are carefully composed from symbolic expressions in arcane and esoteric {\sl programming languages} that prescribe the tasks that we want our processes to perform. \item{} A computational process, in a correctly working computer, executes programs precisely and accurately. Thus, like the sorcerer's apprentice, the novice programmer must learn to understand and to anticipate the consequences of his conjuring. \bigskip In the same way that a biochemist marvels at DNA as a code that directs the amazing growth and development of living organisms, I marvel as I watch computer programs provide the code for the creation and interaction of Abelson and Sussman's computational ``spirits.'' Just as a chemist sees the elementary chemical building blocks of nature interact, combine, and recombine as she pours solutions together, the computer scientist sees the rich and seemingly unpredictible interaction of computational processes as a result of her procedural incantations. For all those who have looked askance at the existence of computer science in the university, Abelson and Sussman have written, ``Underlying our approach to this subject is our conviction that `computer science' is not a science and its significance has little to do with computers. The computer revolution is a revolution in the way we think and in the way we express what we think.'' I believe that nothing could be more exciting or more important at a university than to understand the way we think and how we express those thoughts. This new introductory course comes face-to-face with these profound issues, and brings its students into the heart of the consequent intellectual debate, sometimes pushing them to within striking distance of the frontiers of research. I believe it will provide them with tools to strike out on frontiers of their own, frontiers of personal discovery, creativity, understanding and synthesizing of knowledge, driven on by the powerful metaphors that the study of computational processes provide, and by the personal intellectual success that this course provides them. This new course demands a great commitment from its students and teaching staff. Students have five official ``contact hours'' per week with the teaching staff, and many more on an informal basis. Because of that great contact, I believe that this course has another thing to say that is also profound, though perhaps peripheral to the issues of computation. The University is a place for teaching and learning, not simply for the transmission of information. Teaching and learning reinforce the respect, encouragement, and love that any society or university needs to flourish. I hope this class says loudly and clearly that students have a place in the crucial function of this University, not as passive receivers of knowledge that spouts from the end of a pedagogical assembly line, but as partners in an important dialogue that defines what the University is. I want the students in this class to have learned two things. First, how much there is that they don't know. And second, that they can learn anything they want. I hope that they will never forget the former, and always be inspired by the latter. Every conceivable thing was done in this course to provide a fertile and inspiring environment for learning and discovery. What could students possibly do under such circumstances but mature, grow, and learn? The lesson for the teaching staff in this course is not so different. While Newton said he saw further because he stood on the shoulders of giants, I have always preferred Nietzsche's remark that a teacher is poorly repaid if one only remains a student. What a tremendous debt we teachers owe to those who nurtured us! We honor those who taught us by nurturing students, and the way we express that nurturing is to teach students to grow and think for themselves, so they don't need us any longer. A friend of mine who is a physician once said that the responsibility of a doctor is to love your patients. I believe above all that the responsibility of a teacher is to love your students, to show them what is known, and to inspire them to confront the unknown. The territory is vast, and because computer science is still so new, largely unexplored. The rewards are great for those who simply press forward. \bye  Received: from rice.ARPA by MIT-MC.ARPA 4 Dec 85 18:08:15 EST Received: by rice.ARPA (AA28225); Wed, 4 Dec 85 17:01:38 CST Date: Wed, 4 Dec 85 16:56:44 CST From: Mark Riggle Subject: Query: Scheme on a Sun? To: scheme@mit-mc.ARPA Message-Id: <168.msr.Dione@Rice> Does anyone know of any good implementations of Scheme that runs on a 68000 Unix based workstation, specifically a Sun workstation? Replies to msr@rice.arpa. Many thanks.  Received: from CSNET-RELAY.ARPA by MIT-MC.ARPA 27 Nov 85 23:47:07 EST Received: from indiana by csnet-relay.csnet id a015950; 27 Nov 85 23:29 EST Date: Wed, 27 Nov 85 17:30:50 est From: Perry Wagle To: scheme%indiana.csnet@CSNET-RELAY.ARPA Subject: EQ? on pointers to functions re: the great EEEK! (I mean EQ?) debate, or Is "(EQ? (call/cc (lambda (k) (k k))) (call/cc (lambda (k) k)))" true? - - - - - - - - - - - - - - - - - - - - - - - - - - - The generic LISP semantics I carry around in my head says that if an expression terminates, it returns a pointer. The things pointers point to have types (like "function", "integer", "string", etc). Therefore my functionality equations are meta Will Clinger's equations. That is, where he has "integer", I have "pointer to integer". As what I deal with are pointers, my semantics are very simple if I ignore type. I can well imagine that Will's semantics wants to barf when it tries to incorporate the wierdness of EQ? on its level. EQ? is very natural in my semantical domain. I resist "flattening" as then we get Pascal, where we can't talk about eval, interpreters, and all those powerful meta tools that made LISP better. Yeah, Pascal is simpler and more tractable to our puny proof methods, but watching SCHEME backslide to Pascal is horrifying to watch from here on the outside (I do CogSci). - - - - - - - - - - - - - - - - - - - - - - - - - - - The problem is not that you shouldn't have the type "pointer to function", but that the collapsing of the same or different texts at different times to an identical pointer is very complex and potentially unpredictable to a user (unlike symbol or number collapsing). I don't see that this is cause to spaz and declare EQ? undefined on pointers to functions, or to remove EQ? altogether (?!?), as I can still write useful and correct programs that EQ?s on pointers to functions. (I use ASSQ a lot). - - - - - - - - - - - - - - - - - - - - - - - - - - - Proposal: Expressions that evaluate to a pointers to functions return UNIQUE pointers. How this is done is up to the implementation. My abstraction is that a function consists of a unique head, and a potentially shared body. The head might be a cons cell with some sort of unique timestamp in the CAR and a pointer to the body in the CDR, or the head might be a box pointing to the body; these two methods would allow EQUAL? to work on functions. Another way is the have the head be a "jump body" machine instruction, but this would kill EQUAL?, though one could keep a pointer to body in the type info of the function... - - - - - - - - - - - - - - - - - - - - - - - - - - - Another proposal would be to be to have a way to tell the compiler that "HEY!, this is a UNIQUE function, dammit! Don't you dare try to point something else here!". This might be part of a more general facility to prevent sharing of environment tails, etc. - - - - - - - - - - - - - - - - - - - - - - - - - - - I am trying more to be provocative here than "here's the solution!"ish.  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 25 NOV 85 20:57:36 EST Date: 25 Nov 1985 20:42 EST (Mon) Message-ID: From: Bill Rozas To: tekchips!adams%tektronix.csnet@CSNET-RELAY.ARPA Cc: scheme@MIT-MC.ARPA, tektronix!jinx%MIT-OZ@MIT-MC.ARPA Subject: trace, language vs. implementation In-reply-to: Msg of 25 Nov 1985 14:06-EST from tekchips!adams%tektronix.csnet at CSNET-RELAY.ARPA When I said >>>> TRACE cleary implies a side effect since the behaviour >>>> of some procedure changes. I did not mean to imply that the side effect was done on the procedure (variable, etc.) but that a side effect was done somewhere. In particular, APPLY can be changed to take care of TRACE. >There is no requirement that the procedure print the message. My >analogy to a logic analyzer still holds. Something external to the >procedure could be report on the activity of the procedure. You've moved the side effect one level out. Conceptually SOMETHING, SOMEWHERE, is taking some action which it would not have taken before. I do not know what you call this if it is not a side effect. 1>You seem to be unwilling to consider the behavior of TRACE separate 1>from its implementation. >> What you say is similar to saying that SET-CAR! does not really change >> the appropriate pair, but rather changes the CAR procedure so that if >> it sees that its argument is the "modified" pair, it gives the new >> "car" as its answer, as opposed to the "real" car. Sorry, but I think >> you are just playing word games. 2>I find this comparison unconvincing. First, SET-CAR! is a construct of 2>the language; TRACE is a command to the programming environment. My 2>guess would be that you do not make this distinction; though, I think it 2>would be a mistake not to. Second, SET-CAR! is defined to have a side 2>effect, TRACE can be specified without resorting to side effects: 2>"After issuing (TRACE ) the procedure trace facility with report 2>calls to and returns from ." I note that you wrote "TRACE", not 2>"TRACE!". I think there is more to what I am saying than word games. Please be consistent. Either TRACE is a part of the language (vs. "the programming environment") or it isn't. If it is part of the programming environment we should not worry about semantics since no portable code will (hopefully) depend on its behaviour. Its implementation is the only interesting part. If it is part of the language my analogy holds and we lose anyway since it involves a side effect (which was my original point). I agree with JAR in that we should not attempt to agree on debugging tools, since debugging is a highly personal activity, and we would be asking people to support models which do not necessarily agree with their own. In other words, TRACE is part of the programming system and we should not constrain it in any way in the same way that we do not ask people to use a particular editor. There is too much personal taste involved.  Received: from CSNET-RELAY.ARPA by MIT-MC.ARPA 25 Nov 85 18:50:25 EST Received: from tektronix by csnet-relay.csnet id ag04345; 25 Nov 85 18:40 EST From: Norman Adams To: tektronix!jinx%mit-oz@mit-mc.ARPA Cc: scheme@mit-mc.ARPA Fcc: Out Received: from tekchips by tektronix with smtp ; 25 Nov 85 12:25:15 PST Date: Monday, 25 Nov 85 12:09:52 PST Subject: Re: trace In-reply-to: Your message of 23 Nov 1985 00:32 EST (Sat)., > > .. is undesirable that the effect depends on the form of the DEFINE. I > > also think it is confusing to have indirect recursions appear in the > > TRACE output, when the self recursions are ommitted. > > What do you mean by indirect recursions? I think you are too harsh on > DEFINE. It seems from your message that you would be upset if in the > following > > (define (fact n) > (if (= n 0) > 1 > (* n (fact (-1+ n))))) > > self recursive calls were not displayed, but you would be perfectly willing > to tolerate that behaviour in > > (define fact > (letrec ((fact (lambda (n) > (if (= n 0) > 1 > (* n (fact (-1+ n))))))) > fact)) > > . I see no difference. There may be no good answer. My point was that if I write (define (foo x) ... (foo x) ... ... (bar x) ... ) (define (bar x) ... (foo x) ... ... (bar x) ... ) that I am going to see calls from FOO to BAR, and from BAR to FOO, but not from FOO to FOO, or from BAR to BAR. I find this property of this variant of DEFINE strange. At least is this version: > (define fact > (letrec ((fact (lambda (n) > (if (= n 0) > 1 > (* n (fact (-1+ n))))))) > fact)) > there are two different variables named FACT apparent in the code the user wrote. > As far as I'm concerned, I would like to see > all instances where the object which FOO is bound to (eq? problems > again) is (conceptually) invoked. This obviously presupposes a > particular model of evaluation, but that is probably true of each > user. Great! Here are some possible trace facilities (specified in terms of the language): (1) Trace all calls to the procedure which is the value of a given variable (what you said). "trace the closure" (2) Trace all evaluations of a particular combination (specify a call in a particular piece of source). "trace the source" (3) Trace all evaluations of all combinations where the procedure in the combination was obtained by evaluating a given variable. "trace the variable" (4) Trace all evaluations of all combinations where the procedure is a value that resulted from the evaluation of a given lambda-expression. (You choose how to specify the lambda). "trace the code" Given that we decided that some or all of these were useful, we might discuss the relative difficulty of implementing them; or perhaps, how these might or might not be supported in the presence of an optimizing compiler. This was the point of my first message. I do not think that TRACE merrits all this discussion. I do think there is an important issue at hand: how to implement a language that is both efficient and easy to debug. Perhaps a change in the focus of this discussion would show up some interesting differences in Scheme implementation philosophies. -Norman  Received: from CSNET-RELAY.ARPA by MIT-MC.ARPA 25 Nov 85 18:50:13 EST Received: from tektronix by csnet-relay.csnet id ae04345; 25 Nov 85 18:39 EST From: Norman Adams To: tektronix!jinx%mit-oz@mit-mc.ARPA Cc: scheme@mit-mc.ARPA Fcc: Out Received: from tekchips by tektronix with smtp ; 25 Nov 85 11:15:24 PST Date: Monday, 25 Nov 85 11:06:35 PST Subject: trace, language vs. implementation In-reply-to: Your message of 23 Nov 1985 00:32 EST (Sat)., >>> TRACE cleary implies a side effect since the behaviour >>> of some procedure changes. >> >> This is not obvious to me. TRACE reports on an activity in the >> system. The action of the traced procedure is unchanged. Just to >> be extreme, TRACE might be implemented with external hardware, >> something like a really smart logic analyzer. > > The values returned by the traced procedure are the same (hopefully), > but there is certainly a change in behaviour in the procedure. It > prints (writes?) some stuff which it was not printing before, so its > behaviour has changed, irrelevant of whether you implement the TRACE > facility by modifying the procedure (closure, code, or variable), or > APPLY. There is no requirement that the procedure print the message. My analogy to a logic analyzer still holds. Something external to the procedure could be report on the activity of the procedure. You seem to be unwilling to consider the behavior of TRACE separate from its implementation. > What you say is similar to saying that SET-CAR! does not really change > the appropriate pair, but rather changes the CAR procedure so that if > it sees that its argument is the "modified" pair, it gives the new > "car" as its answer, as opposed to the "real" car. Sorry, but I think > you are just playing word games. I find this comparison unconvincing. First, SET-CAR! is a construct of the language; TRACE is a command to the programming environment. My guess would be that you do not make this distinction; though, I think it would be a mistake not to. Second, SET-CAR! is defined to have a side effect, TRACE can be specified without resorting to side effects: "After issuing (TRACE ) the procedure trace facility with report calls to and returns from ." I note that you wrote "TRACE", not "TRACE!". I think there is more to what I am saying than word games. Your example demonstrates that the semantics of "side-effect" can be implemented without apparent side effect; the reverse is also possible (you can implement FP in C). -Norman  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 23 NOV 85 00:59:34 EST Date: 23 Nov 1985 00:32 EST (Sat) Message-ID: From: Bill Rozas To: tekchips!adams%tektronix.csnet@CSNET-RELAY.ARPA Cc: scheme@MIT-MC.ARPA, tektronix!jinx%MIT-OZ@MIT-MC.ARPA, willc%tektronix.csnet@CSNET-RELAY.ARPA Subject: trace In-reply-to: Msg of 22 Nov 1985 15:32-EST from tekchips!adams%tektronix.csnet at CSNET-RELAY.ARPA TRACE cleary implies a side effect since the behaviour of some procedure changes. This is not obvious to me. TRACE reports on an activity in the system. The action of the traced procedure is unchanged. Just to be extreme, TRACE might be implemented with external hardware, something like a really smart logic analyzer. The values returned by the traced procedure are the same (hopefully), but there is certainly a change in behaviour in the procedure. It prints (writes?) some stuff which it was not printing before, so its behaviour has changed, irrelevant of whether you implement the TRACE facility by modifying the procedure (closure, code, or variable), or APPLY. What you say is similar to saying that SET-CAR! does not really change the appropriate pair, but rather changes the CAR procedure so that if it sees that its argument is the "modified" pair, it gives the new "car" as its answer, as opposed to the "real" car. Sorry, but I think you are just playing word games. .. is undesirable that the effect depends on the form of the DEFINE. I also think it is confusing to have indirect recursions appear in the TRACE output, when the self recursions are ommitted. What do you mean by indirect recursions? I think you are too harsh on DEFINE. It seems from your message that you would be upset if in the following (define (fact n) (if (= n 0) 1 (* n (fact (-1+ n))))) self recursive calls were not displayed, but you would be perfectly willing to tolerate that behaviour in (define fact (letrec ((fact (lambda (n) (if (= n 0) 1 (* n (fact (-1+ n))))))) fact)) . I see no difference. As far as I'm concerned, I would like to see all instances where the object which FOO is bound to (eq? problems again) is (conceptually) invoked. This obviously presupposes a particular model of evaluation, but that is probably true of each user. I don't think that we will be able to agree on what the "right" behaviour is since the "right" behaviour depends on the situation, and there are probably cases which we have not included in our classification where any of them will not do exactly what we want.  Received: from CSNET-RELAY.ARPA by MIT-MC.ARPA 22 Nov 85 19:24:05 EST Received: from tektronix by csnet-relay.csnet id ai07029; 22 Nov 85 18:41 EST From: Norman Adams To: tektronix!jinx%mit-oz@mit-mc.ARPA Cc: willc%tektronix.csnet@CSNET-RELAY.ARPA, scheme@mit-mc.ARPA Fcc: Out Received: from tekchips by tektronix with smtp ; 22 Nov 85 12:45:49 PST Date: Friday, 22 Nov 85 12:32:13 PST Subject: Re: trace In-reply-to: Your message of 21 Nov 1985 10:36 EST (Thu)., TRACE cleary implies a side effect since the behaviour of some procedure changes. This is not obvious to me. TRACE reports on an activity in the system. The action of the traced procedure is unchanged. Just to be extreme, TRACE might be implemented with external hardware, something like a really smart logic analyzer. I think we can understand the meaning of the phrases "trace the variable," "trace the closure," and "trace the code" independent of the particular implementations. Is there some concurrence about what an unsophisticated user expects when he or she writes (TRACE FOO)? I think it is undesirable that the effect depends on the form of the DEFINE. I also think it is confusing to have indirect recursions appear in the TRACE output, when the self recursions are ommitted. I guess this is a result of (define (v0 v1...) ...) being subtley different than (define v0 (lambda (v1 ...) ...)) in the treatment of v0. I don't see any advantage to having this difference, aside from possible runtime efficiency. In the presence of "hairy" enough compilers all implementations lose. Given that we know the desired effect of TRACE in terms of the language, the implementor of an optimizing compiler can choose to support TRACE or provide some coherent preemption of it. In the presence of an optimizing compiler, I don't see how to make trace independent of the compiler without preemting either the compiler or the TRACE facility. -Norman Adams  Date: Thu, 21 Nov 85 12:04:39 EST From: Jonathan A Rees Subject: description of MacScheme To: SCHEME@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].726747.851121.JAR> Date: Wednesday, 20 Nov 85 15:31:49 PST From: Will Clinger To: Scheme-Request at mit-mc.ARPA Re: description of MacScheme Implementation: MacScheme Implemented by: Will Clinger, Liz Heller, and John Ulrich Supported by: Semantic Microsystems Hardware: Apple Macintosh or Lisa (Mac XL). Requires 512K RAM, can use up to 16M. Operating Systems: Finder (Macintosh); MacWorks (Lisa). Price/Availability: $125. Available since August 1985. Implementation: Compiles to interpreted byte code. Intended Use: Education, personal computing, AI applications Contact: Semantic Microsystems 4470 S.W. Hall St., Suite 340 Beaverton, OR 97005 (503) 643-4539 MacScheme supports all essential and many optional features of the Revised Revised Report on Scheme. It includes a compatibility package for use with the Abelson and Sussman text, but environments are not supported. The compiler and byte code architecture were described in Clinger's paper at the 1984 Lisp conference. Numbers are implemented as a union of 30-bit fixnums, bignums, and 32-bit flonums; bignum arithmetic is slow. The system includes facilities for breaking, tracing, and debugging; most run-time errors can be repaired in the debugger. There is a pretty printer. An escape to machine code is documented for direct access to the Macintosh Toolbox. The system includes a simple editor that understands Scheme syntax and makes good use of multiple windows and the mouse. This editor runs as a foreground process while Scheme runs in the background. MacScheme's speed is comparable to that of similar interpreters (MIT Scheme on the HP 9836, TI Scheme) when hardware is taken into account. Non-tail- recursive procedure calls are relatively slow in MacScheme but tight tail- recursive loops are relatively fast. Interpreted MacScheme seems to run about half as fast as compiled ExperLisp on the Macintosh.  Date: Thu, 21 Nov 85 11:44:01 EST From: Jonathan A Rees Subject: trace To: willc%tekchips%tektronix.csnet@CSNET-RELAY.ARPA cc: SCHEME@MIT-MC.ARPA In-reply-to: Msg of 20 Nov 85 16:52:06 PST from Will Clinger Message-ID: <[MIT-MC.ARPA].726726.851121.JAR> Date: Wednesday, 20 Nov 85 16:52:06 PST From: Will Clinger A long time ago Jonathan asked what people did to trace self-recursive calls to FACT when FACT is defined using the (DEFINE (FACT ...) ...) syntax. It seems to me there are three obvious implementations of the trace facility, with three distinct semantics: 1. Trace the variable. That is, (TRACE FACT) is a special form that turns into something like (SET! FACT (MAKE-TRACED FACT)). This is how most implementations seem to do it, though in some of them (e.g. MacScheme) TRACE is a procedure and you have to say (TRACE 'FACT). The disadvantage is that the self-recursive calls are not traced. ... Thanks for your exposition. I was too lazy to articulate all this when I sent out my earlier message, but it's what I had in mind. For alternative 1., note that the procedure MAKE-TRACED could, in principle, "look inside" the code for the procedure and produce a new procedure, with new code, whose self-calls were traced. This still does not imply a side-effect on the traced procedure or on its code. I think all three alternatives have their place, but that (1) is probably the safest and most useful, and if MAKE-TRACED did as I suggest, I think it would be adequate. The others are potentially dangerous, especially when applied to "system" procedures like WRITE-CHAR. [Of course this is implementation-specific; I'm certainly not suggesting that a standard debugging interface should exist.]  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 21 NOV 85 11:07:36 EST Date: Thu, 21 Nov 1985 10:46 EST Message-ID: From: CPH%MIT-OZ@MIT-MC.ARPA To: Will Clinger Cc: scheme@MIT-MC.ARPA Subject: trace In-reply-to: Msg of 20 Nov 1985 19:52-EST from Will Clinger It seems to me that all three of the options are reasonable, and users should be able to choose any of them.  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 21 NOV 85 10:39:58 EST Date: 21 Nov 1985 10:36 EST (Thu) Message-ID: From: Bill Rozas To: Will Clinger Cc: scheme@MIT-MC.ARPA Subject: trace In-reply-to: Msg of 20 Nov 1985 19:52-EST from Will Clinger Some comments about your TRACE implementation classification: I do not think that the disadvantage you point out for option 2 is undesirable. TRACE cleary implies a side effect since the behaviour of some procedure changes. The point you make is no worse than the fact that if A and B have the same (eq?) pair as their value, the effect of SET-CAR! on one will be observed on the other also. Note also that an optimizing compiler may decide to invoke FACT on self-recursive calls bypassing the closure (by directly branching to the entry point, for example), so this implementation is not guaranteed to work on self-recursive calls either. 3 is not unreasonable either. There are situations in which this is the desired behaviour. Consider the case of a procedure that returns procedures, so there may be many instances of these procedures around. This is common in message passing situations. It is occasionally useful to be able to observe the invocations of all these procedures, rather than the particular one we have a handle on. A TRACE option which modifies the code would accomplish this task under most circumstances. In the presence of "hairy" enough compilers all implementations lose. A compiler may decide, for example, to have 27 entry points to a given procedure, each used by something else, and the TRACE facility would have to know a fair amount about the actual code generated to be able to "trap" all possible paths. Even worse if it decides to open code the procedure in some places. The only possible solution in the worst case is modifying the source code, recompiling and re-generating the running environment, but even this may not work if the runtime behaviour depended on events which cannot be duplicated. MIT-Scheme has switched back and fourth between implementations 2 and 3. As far as I know it has never used implementation 1. I like implementation 2 better, but there are occasions when 3 is desirable, and the current implementation is implementation 3. It is also more likely (though not without problems) that we can make this work even in the case of compiled code.  Received: from CSNET-RELAY.ARPA by MIT-MC.ARPA 21 Nov 85 02:48:32 EST Received: from tektronix by csnet-relay.csnet id ac18731; 21 Nov 85 2:38 EST From: Will Clinger To: scheme@mit-mc.ARPA Received: from tekchips by tektronix with smtp ; 20 Nov 85 17:05:17 PST Date: Wednesday, 20 Nov 85 16:52:06 PST Subject: trace A long time ago Jonathan asked what people did to trace self-recursive calls to FACT when FACT is defined using the (DEFINE (FACT ...) ...) syntax. It seems to me there are three obvious implementations of the trace facility, with three distinct semantics: 1. Trace the variable. That is, (TRACE FACT) is a special form that turns into something like (SET! FACT (MAKE-TRACED FACT)). This is how most implementations seem to do it, though in some of them (e.g. MacScheme) TRACE is a procedure and you have to say (TRACE 'FACT). The disadvantage is that the self-recursive calls are not traced. 2. Trace the closure. That is, TRACE is a procedure and (TRACE FACT) clobbers some field(s) of the data structure used to represent the procedure stored in the variable FACT. This will trace the self-recursive calls. The disadvantage is that it also will trace calls to FOO where FOO is any variable that happens to hold the same closure as is stored in the variable FACT. 3. Trace the code. That is, TRACE is a procedure and (TRACE FACT) clobbers the first instruction(s) of the code portion of the closure. This will trace the self-recursive calls. The disadvantage is that it also will trace calls to any procedure obtained by closing the same lambda expression. In fact, the precise semantics of this option is likely to depend upon small details of an optimizing compiler. It seems to me that implementations 1 and 2 are the most reasonable. Perhaps users should be able to choose between the two. Thanks to Norman Adams for his criticisms of the three implementations. Peace, Will Clinger  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 18 NOV 85 21:34:42 EST Date: 18 Nov 1985 21:31 EST (Mon) Message-ID: From: Bill Rozas To: scheme@MIT-MC.ARPA Subject: Incomplete message Sorry. I must have spazzed and sent the message too early.  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 18 NOV 85 21:32:21 EST Date: 18 Nov 1985 21:29 EST (Mon) Message-ID: From: Bill Rozas To: "John D. Ramsdell" Cc: scheme@MIT-MC.ARPA Subject: Stream command processing (long message) In-reply-to: Msg of 15 Nov 1985 15:06-EST from John D. Ramsdell filter-cstream symbol? single-level-list.scm into (call-with-output-file "single-level-list.scm" (filter-cstream (map-cstream (call-with-input-file "lists.scm" read-cstream) list) symbol?)) ---------------------------------------------------------------------- Why the extraneous syntax when you can do the following (define (>> file-name stream) (call-with-output-file file-name stream)) (define (<< file-name) (call-with-input-file file-name read-cstream)) (define (|| what . args) (lambda (stream) (apply what (cons stream args)))) (>> "single-level-list.scm" ((|| filter-cstream symbol?) ((|| map-cstream list) (<< "lists.scm")))) which except for the parentheses and the fact that it is left-to-right inverted with respect to Unix is extremely close. Sorry, but I feel that (call-with-output-file "single-level-list.scm" (filter-cstream (map-cstream (call-with-input-file "lists.scm" read-cstream) list) symbol?)) is considerably clerarer than Unix-like syntax. It is also more powerful since the Unix shell syntax does not allow (as far as I know) forking or merging streams in interesting ways, both of which scheme procedures can easily accomodate. A portable continuation stream top level of the sort you suggest is an afternoon's worth of work, and does not really add any power or interesting functionality to the language, so it might as well be provided as part of the continuation stream utilities.  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 18 NOV 85 21:05:03 EST Date: 18 Nov 1985 21:01 EST (Mon) Message-ID: From: Bill Rozas To: "John D. Ramsdell" Cc: scheme@MIT-MC.ARPA Subject: Stream command processing (long message) In-reply-to: Msg of 15 Nov 1985 15:06-EST from John D. Ramsdell Why the syntax when For a more complex example, SCP would translate the following: filter-cstream symbol? single-level-list.scm into (call-with-output-file "single-level-list.scm" (filter-cstream (map-cstream (call-with-input-file "lists.scm" read-cstream) list) symbol?))  Received: from mitre-bedford.ARPA by MIT-MC.ARPA 18 Nov 85 20:35:00 EST Organization: The MITRE Corp., Bedford, MA Received: by linus.RESEARCH (4.12/4.7) id AA00913; Mon, 18 Nov 85 07:39:48 est Date: Mon, 18 Nov 85 07:39:48 est From: John D. Ramsdell Posted-Date: Mon, 18 Nov 85 07:39:48 est Message-Id: <8511181239.AA00913@linus.RESEARCH> To: scheme@mit-mc.ARPA Subject: read-cstream fix ; read-cstream that checks for EOF. (define (read-cstream port) (lambda (c) (let ((element (read port))) (if (eof-object? element) (ecs c) ; close port? (c element (read-cstream port)))))) I sent out some undebuged code for read-cstream. The above version does the correct thing for EOF. In some applications it may be desirable to delay the reading of the port. (define (read-cstream port) (let ((element (delay (read port)))) (lambda (c) (if (eof-object? (force element)) (ecs c) (c (force element) (read-cstream port)))))) John  Received: from mitre-bedford.ARPA by MIT-MC.ARPA 17 Nov 85 18:42:26 EST Full-Name: Organization: The MITRE Corp., Bedford, MA Received: by linus.RESEARCH (4.12/4.7) id AA26603; Fri, 15 Nov 85 15:06:32 est Date: Fri, 15 Nov 85 15:06:32 est From: John D. Ramsdell Posted-Date: Fri, 15 Nov 85 15:06:32 est Message-Id: <8511152006.AA26603@linus.RESEARCH> To: scheme@mit-mc.ARPA Subject: Stream command processing (long message) While I am an avid fan of Scheme, I find myself frustrated by how difficult it is to program some stream processing tasks in Scheme compared with the difficulty of programming the same tasks in UNIX. Your typical UNIX hacker can whip together some concoction of awk, grep, sed, yacc, etc. to solve these kinds of problems very quickly. But it is quite a pain in Scheme. Even more painful is the fact that it is very hard to use someone else's stream processing programs. I would like to propose having two standard top level environments for Scheme. One is the one we all know and love, and the other would be the stream command processor (SCP). This top level environment would map a stream like syntax into a simple composition of Scheme functions. The map would follow a simple convention, so that inexperienced users could easily modify or creat new functions to be used in the composition. I have no suggestion as to the particular syntax to be used; I will use a UNIX like syntax with no implied endorsement. I will give an example of a simple map from this syntax to compositions of Scheme functions using continuation streams (CSTREAMS). The continuation is not the same one you get when you use call-with-current-continuation. Cstreams are defined by: ; Continuation streams are procedures of one argument ; which is the procedure's continuation. ; A continuation is a procedure of two arguments, ; a stream element, and a the next stream. ; cstream = (lambda (continuation) ; Compute element and next-cstream. ; (continuation element next-cstream)) A port is turned into a cstream with: (define (read-cstream port) (lambda (c) (c (read port) (read-cstream port)))) and a cstream is turned into something that works as an argument to call-with-output-port using: (define (print-cstream cstream) (lambda (port) (letrec ((continuation (lambda (element cstream) (if (ecse? element) 'print-done (begin (print element port) (cstream continuation)))))) (cstream continuation)))) Cstream manipulation functions have the signature: (lambda (input-cstream . arguments) ...) ==> output-cstream. For example, the cstream mapping function looks like: ; => a cstream that results from mapping elements of cstream ; with a procedure of one argument. (define (map-cstream cstream procedure) (letrec ((next-cstream (lambda (cstream) (lambda (c) (cstream (lambda (element cstream) (if (ecse? element) (ecs c) (c (procedure element) (next-cstream cstream))))))))) (next-cstream cstream))) The SCP would translate a command that looks like map-cstream list more-parens.scm into the expression (call-with-output-file "more-parens.scm" (map-cstream (call-with-input-file "lists.scm" read-cstream) list)) For a more complex example, SCP would translate the following: filter-cstream symbol? single-level-list.scm into (call-with-output-file "single-level-list.scm" (filter-cstream (map-cstream (call-with-input-file "lists.scm" read-cstream) list) symbol?)) The set of stream functions are easily extended by writting functions that expect a cstream for their first argument and return a cstream. I am not particularly attached to my representation of streams, and the streams in Sussman and Abelson's book would also do the trick. I am most interested in an commonly aggreed upon stream processing system that encourages the interchange of stream functions, just as the Revised Revised Report on Scheme encourages interchange of Scheme functions. Then Scheme hackers will definitely be kings of stream processing. John Here is some code to play with: ----------- ;;; -*- Mode: LISP -*- ; Continuation Streams. ; Continuation streams are procedures of one argument ; which is the procedure's continuation. ; A continuation is a procedure of two arguments, ; a stream element, and a the next stream. ; cstream = (lambda (continuation) ; Compute element and next-cstream. ; (continuation element next-cstream)) (define (error-cstream message) (lambda (c) c ; ignore continuation. (error message))) (define *ecse* ; Used to identify the empty continuation stream. '*ecse*) ; Is the cstream element the empty cstream element? (define (ecse? x) (eq? x *ecse*)) (define past-end-of-cstream (error-cstream "Read past end of cstream")) ; the empty continuation stream. (define ecs (lambda (c) (c *ecse* past-end-of-cstream))) (define (ecs? cstream) (cstream (lambda (element cstream) cstream ; ignore cstream. (ecse? element)))) ; => cstream which is cstream0 appended to cstream1. (define (append-cstreams cstream0 cstream1) (letrec ((next-cstream (lambda (cstream) (lambda (c) (cstream (lambda (element cstream) (if (ecse? element) (cstream1 c) (c element (next-cstream cstream))))))))) (next-cstream cstream0))) ; => cstream which is a fair merge of cstream0 and cstream1. (define (interleave-cstreams cstream0 cstream1) (lambda (c) (cstream0 (lambda (element cstream) (if (ecse? element) (cstream1 c) (c element (interleave-cstreams cstream1 cstream))))))) ; => a cstream that results from mapping elements of cstream ; with a procedure of one argument. (define (map-cstream cstream procedure) (letrec ((next-cstream (lambda (cstream) (lambda (c) (cstream (lambda (element cstream) (if (ecse? element) (ecs c) (c (procedure element) (next-cstream cstream))))))))) (next-cstream cstream))) ; Returns a cstream containing elements that satisfy the predicate. (define (filter-cstream cstream predicate) (letrec ((next-cstream (lambda (cstream) (lambda (c) (cstream (lambda (element cstream) (if (ecse? element) (ecs c) (let ((next-cstream (next-cstream cstream))) (if (predicate element) (c element next-cstream) (next-cstream c)))))))))) (next-cstream cstream))) (define (list->cstream l) ; => cstream with elements in l. (if (null? l) ecs (let ((element (car l)) (l (cdr l))) (lambda (c) (c element (list->cstream l)))))) (define (cstream->list cstream) ; => list of elements in the cstream. (let ((l '())) ; The reverse of the result is held here. (letrec ((continuation (lambda (element cstream) (if (not (ecse? element)) (begin (set! l (cons element l)) (cstream continuation)))))) (cstream continuation)) (reverse! l))) (define (read-cstream port) (lambda (c) (c (read port) (read-cstream port)))) (define (print-cstream cstream) (lambda (port) (letrec ((continuation (lambda (element cstream) (if (ecse? element) 'print-done (begin (print element port) (cstream continuation)))))) (cstream continuation)))) ; For more, see J. D. Ramsdell "An Implementation of a Domain Calculus ; Query Language Using Continuation Streams", M84-56, MITRE Corp. ; Bedford, MA, December 1984.  Date: Fri, 15 Nov 85 15:57:41 EST From: Jonathan A Rees Subject: testing, testing, ... To: SCHEME@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].719559.851115.JAR> Several people have wondered whether they are still on the list. This message is intended to confirm that y'all still are. The two most recent messages were: Date: 12 Nov 1985 1035-CST From: Don Oxley Subject: PC Scheme Implementation Information Date: Fri, 1 Nov 85 14:47:58 EST From: Paul Hudak Subject: Re: will the real current continuation please stand up Don Oxley's message may have been lost (although I've never before known MC's mailer to lose a message); I'll re-send it if I get deluged with reports of non-receipt.  Date: Tue, 12 Nov 85 22:04:47 EST From: Jonathan A Rees Subject: test message To: RRRS-AUTHORS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].716206.851112.JAR> Please ignore. (I want to make sure that sending to this list actually works.)  Received: from CSNET-RELAY.ARPA by MIT-MC.ARPA 12 Nov 85 16:33:12 EST Received: from ti-csl by csnet-relay.csnet id ae14406; 12 Nov 85 16:17 EST Date: 12 Nov 1985 1035-CST From: Don Oxley Subject: PC Scheme Implementation Information To: Scheme@mit-mc.arpa Received: from csl60 by ti-csl; Tue, 12 Nov 85 12:48 CST The following description of TI's PC Scheme product is a (belated) response to Jonathan's request for implementation information: Implementation: PC Scheme Developed by: Texas Instruments Computer Science Lab Supported by: Texas Instruments Digital Systems Group Hardware: TI Professional and TI Business-Pro Computers, IBM PC, PC/XT, PC/AT and IBM compatibles Operating Systems: MS(tm)-DOS 2.1 (PC-DOS) or better (at least 320K, dual floppy) Price/Availability: List price - $95, available in December 1985 Implementation: Incrementally compiled to byte-codes Intended Use: Education, research, and support of AI software on PCs PC Scheme is an implementation of Scheme for the TI Professional Computer and IBM(r) Personal Computer families. The product consists of an optimizing compiler, a byte-code interpreter, extensive run time support, an interactive, display-oriented editor, a language reference manual, and a user's guide. The system was developed on the TI Professional Computer in Scheme itself, with critical run time routines coded in C and assembly language for increased performance. PC Scheme provides all the essential and most of the optional features of the Revised Revised Report on Scheme. It fully supports the dialect used in the book "Structure and Interpretation of Computer Programs" by Abelson and Sussman as well as many extensions developed at Indiana University, MIT, and TI. These include first-class engines and environments and an experimental, object-oriented programming system with dynamic multiple inheritance called SCOOPS. Data type support includes symbols, lists, vectors, strings, fixnums, bignums, flonums (64 bit IEEE floating point), characters, closures, continuations, environments, and I/O ports. Evaluation is based on incremental compilation to byte-coded "virtual machine" code which is emulated using threaded code techniques. Informal benchmarks, including some of the Gabriel set, show PC Scheme programs to be about 3-10 times faster than interpreted IQLISP(tm) and 2-4 times faster than interpreted Golden Common LISP(tm). PC Scheme is oriented primarily towards compilation and fast execution rather than extensive source-level debugging. However, it does provide trace and breakpoint facilities and an interactive Inspector with commands to display and manipulate call stack frames and lexical environments, edit variable bindings, trace back through a chain of procedure calls, and evaluate expressions in the environment of a breakpoint. All user-correctable errors trap to the Inspector. The display-oriented editor supplied with PC Scheme is a subset of EDWIN, a version of EMACS written by the Scheme project at MIT and adapted to PC Scheme by TI. 512K bytes of RAM are required to use EDWIN. Other PC Scheme run time support includes windowed screen input/output, graphics, a pretty-printer, and an editor of in-memory list structures. Compiled files can be converted to a "fast-load" format to speed up load times. Files containing variable definitions can be "autoloaded" on demand. A Winchester disk minimizes the inconvenience of autoloading, but is not required. Documentation includes a 286-page language reference manual and a 93-page user's guide. Neither manual attempts to be a tutorial manual for Scheme itself. PC Scheme is being used extensively within Texas Instruments and is the basis for future releases of TI's PC-based AI products, including Arborist (tm) and the Personal Consultant Plus (tm). It is currently in use at approximately 25 universities in various settings (classes, experimentation, evaluation). PC Scheme may be ordered beginning November 15 for shipment in December. To order, write to Texas Instruments, 12501 Research Blvd., MS 2151, Austin, TX 78759 and ask for TI Part number #2537900-0001. You may also order by telephone using MasterCard or VISA by calling 1-(800)-TI-PARTS. Questions or comments on the product may be directed to the address given above. We also welcome less formal technical questions and comments, which may be directed via CSNET to Oxley@TI-CSL. --Don -------  Received: from CSNET-RELAY.ARPA by MIT-MC.ARPA 8 Nov 85 12:49:59 EST Received: from ti-csl by csnet-relay.csnet id ad09069; 8 Nov 85 12:44 EST Date: 7 Nov 1985 1112-CST From: David Bartley Subject: Syntactic extensions to Scheme To: RRRS-Authors@mit-mc.arpa cc: Bartley%CSL60%ti-csl.csnet@CSNET-RELAY.ARPA Received: from csl60 by ti-csl; Fri, 8 Nov 85 10:09 CST One of the issues shunted aside a year ago was the question of how to provide users with the ability to make syntactic extensions. I think it would be fruitful to have some calm discussion on this topic in the RRRS-AUTHORS mailing list. I doubt if we're ready to standardize on any particular approach, but it would be helpful if we all knew more about the alternatives and people's experiences with them. I'm particularly interested in experiments such as T's with extensive support for syntax tables. What are their strengths and weaknesses? What do they cost in terms of compiler or runtime complexity? Do users make effective use of them? How flexible are they---would they suffice for major language changes? Should syntactic extensions be specified entirely in source terms, or should the user have access to internal representations? Should simple source-to-source optimizations be communicated to the compiler using the same mechanism, or is something else more appropriate? Regards, David Bartley -------  Received: from yale by MIT-MC.ARPA 1 Nov 85 16:50:27 EST Received: by Yale-Bulldog.YALE.ARPA; 1 Nov 85 14:46:13 EST (Fri) Message-Id: <8511011946.AA01493@Yale-Bulldog.YALE.ARPA> Received: from YALE-RING by YALE-RES via CHAOS; Fri, 1 Nov 85 14:47:57 EST Subject: Re: will the real current continuation please stand up Date: Fri, 1 Nov 85 14:47:58 EST From: Paul Hudak To: Bill Rozas Cc: SCHEME@MIT-MC In-Reply-To: Bill Rozas , 30 Oct 1985 20:32 EST (Wed) As far as HUDAK@YALE's original question: He distinguished between the continuation to the CALL-WITH-CURRENT-CONTINUATION invocation (outer continuation), and the continuation to the argument (inner continuation), but the way I see it both are the same. I see your point. I guess it all depends on how one defines "continuation." I was interpreting it as "what happens next," so in your definition: (define (call-with-current-continuation *cont* receiver) (receiver *cont* *cont*)) what happens next is a call to receiver, so the (eventual) call to *cont* is "delayed." On the other hand, in: (define (current-continuation *cont*) (*cont* *cont*)) the current continuation is called immediately (i.e., passed to itself), which is of course what you pointed out in the first part of your message. -Paul  Received: from CSNET-RELAY.ARPA by MIT-MC.ARPA 31 Oct 85 13:21:54 EST Received: from indiana by csnet-relay.csnet id ac00927; 31 Oct 85 13:18 EST Date: Thu, 31 Oct 85 11:27:02 est From: Kent Dybvig To: SCHEME@mit-mc.ARPA Subject: Scheme Implementation Blurb: Chez Scheme Implementation: Chez Scheme Authored by: Kent Dybvig Supported by: limited support by the author Hardware: VAX Operating Systems: 4.2 BSD UNIX (or ULTRIX) Implementation: incrementally compiled to native code Intended Use: education and research Chez Scheme was first released earlier this year and is now being used at about 10 universities for classes and research. Chez Scheme supports almost all of the required and optional features of the RRRS. The next major release (in spring or summer 1986) will support 100% of the required features of the standard. In addition to the features of the RRRS, Chez Scheme provides error and exception handling, engines, programmable cafes and waiters (fancy read-eval-print loops), tracing and statistics- gathering facilities, and fast-loading compiled files. Chez Scheme provides floating point numbers, arbitrary-precision ratios, and arbitrary-precision integers, but no imaginary numbers at this time. Bruce Smith of UNC and myself have written a book on Scheme that is scheduled to be published in the spring. This book serves as the reference manual for Chez Scheme and is sent in draft form with Chez Scheme distributions. Chez Scheme's biggest claim to fame is the speed and size of its implementation. It outperforms Franz Lisp and DEC Common Lisp on most programs, but the initial core image is less than 500K bytes, about half of which is read-only and sharable. Sue Dybvig and myself have started a small consulting business, named Cadence Research Systems, primarily for the purpose of distributing and supporting Chez Scheme. We charge a license fee to cover costs of distribution. The license fee per site is $400 for US colleges and universities and $1000 for companies who will use the system for research and education only. For the license forms and ordering information, contact: Kent Dybvig Cadence Research Systems 620 Park Ridge Road Bloomington, IN 47401 812/333-9269 You can also reach me during the day at 812/335-8653. Kent Dybvig dyb.indiana@csnet-relay  Received: from yale by MIT-MC.ARPA 30 Oct 85 21:25:22 EST Received: by Yale-Bulldog.YALE.ARPA; 30 Oct 85 21:12:27 EST (Wed) Message-Id: <8510310212.AA00384@Yale-Bulldog.YALE.ARPA> Received: from YALE-RING by YALE-RES via CHAOS; Wed, 30 Oct 85 20:40:10 EST Subject: Re: will the real current continuation please stand up Date: Wed, 30 Oct 85 20:40:11 EST From: Paul Hudak To: Jonathan A Rees Cc: SCHEME@MIT-MC In-Reply-To: Jonathan A Rees , Wed, 30 Oct 85 18:02:44 EST I think they're equipotent, if you allow a little bit of kludgery. ... Very nice -- although I'd call it "cleverness" rather than "kludgery." I think it's somewhat more natural to take call-with-current-continuation as primitive. I can't argue with that. But it's satisfying to know that call-with-current-continuation can be implemented with something that in a sense is more primitive. Thanks. -Paul  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 30 OCT 85 20:33:57 EST Date: 30 Oct 1985 20:32 EST (Wed) Message-ID: From: Bill Rozas To: Jonathan A Rees Cc: Hudak@YALE.ARPA, SCHEME@MIT-MC.ARPA Subject: will the real current continuation please stand up In-reply-to: Msg of 30 Oct 1985 18:02-EST from Jonathan A Rees The main difference that I see between CALL-WITH-CURRENT-CONTINUATION and CURRENT-CONTINUATION is that when CURRENT-CONTINUATION is used, the continuation returned has already been invoked (namely to return itself), thus any further (explicit) invocations are additional invocations. In the CALL-WITH-CURRENT-CONTINUATION world this continuation has not yet been "used". While there is no difference if continuations are re-entrant (they can be invoked more than once), CURRENT-CONTINUATION can only be used under this assumption. As far as HUDAK@YALE's original question: He distinguished between the continuation to the CALL-WITH-CURRENT-CONTINUATION invocation (outer continuation), and the continuation to the argument (inner continuation), but the way I see it both are the same. The continuation-passing definition of CALL-WITH-CURRENT-CONTINUATION that I use is: (define (call-with-current-continuation *cont* receiver) (receiver *cont* *cont*)) where procedures always receive an additional argument (the first) which is the implicit continuation. Clearly then both continuations (outer and inner) are the same. In other words, since CALL-WITH-CURRENT-CONTINUATION reduces (tail-recurses) into its argument, the continuations are the same.  Date: Wed, 30 Oct 85 18:02:44 EST From: Jonathan A Rees Subject: will the real current continuation please stand up To: Hudak@YALE.ARPA cc: SCHEME@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].698732.851030.JAR> I think they're equipotent, if you allow a little bit of kludgery. I take it you would define (current-continuation) to mean the same as (call-with-current-continuation (lambda (c) c)) ? Then e.g. (let ((c (current-continuation))) (cond ((eq? c 'a) 'b) (else (c 'a)))) would evaluate to b. Then I think you could just do this: (define (call-with-current-continuation p) (let ((c (current-continuation))) (cond ((pair? c) (car c)) (else (p (lambda (val) (c (cons val nil)))))))) I think it's somewhat more natural to take call-with-current-continuation as primitive.  Date: Wed, 30 Oct 85 17:10:56 EST From: Jonathan A Rees Subject: Continuations To: Meehan@YALE.ARPA cc: SCHEME@MIT-MC.ARPA, cpd@LOCUS.UCLA.EDU In-reply-to: Msg of Wed 30 Oct 85 08:37:27 PST from Charles Dolan Message-ID: <[MIT-MC.ARPA].698607.851030.JAR> Let's not quibble over terminology. CPD's question is perfectly clear and well-informed. T supports continuations like Fortran does: they exist but aren't first-class; they can't be returned as values of procedures. I think that when talking about continuations it's OK to omit the qualifier "first-class," since it's usually understood, the same way it's understood when you say "closure." It's vacuous to say that a language has or doesn't have closures or continuations unless the adjective first-class is assumed; therefore assume it. (Some people will always choose to be confused.) I think first-class continuations are generally good for the soul, and I think it's good that the new Scheme report requires them. I've never claimed that T was really a Scheme dialect. (Maybe one of these days it will be.) But the question of what one legitimately does with continuations is nontrivial. I'd like for people out there who have real experience with them (e.g. someone from Indiana) to say something about this. The main problem I have with continuations is that a truly correct implementation would dictate that a compiler cannot beta-convert in many places where beta-conversion would otherwise be desirable. This problem is discussed on page 92 of Steele's tech report on RABBIT.  Received: from yale by MIT-MC.ARPA 30 Oct 85 16:45:38 EST Received: by Yale-Bulldog.YALE.ARPA; 30 Oct 85 15:33:19 EST (Wed) Message-Id: <8510302033.AA12517@Yale-Bulldog.YALE.ARPA> Received: from YALE-RING by YALE-RES via CHAOS; Wed, 30 Oct 85 15:35:25 EST Subject: will the real current continuation please stand up Date: Wed, 30 Oct 85 15:35:29 EST From: Paul Hudak To: scheme@MIT-MC Cc: I have a question for the Scheme philosophers, which relates somewhat to pedagogy: Why was CALL/CC designed in just the way it was? In particular, I tend to think of CALL/CC as "providing a way to grab the current continuation," which makes especially good sense to those familar with denotational semantics. But then the immediate question raised is, "why not just have a procedure CURRENT-CONTINUATION that, when called with no arguments, returns the current continuation?" The answer, of course, is that then no real "fork" in the processing occurs, which brings up the following point: In a sense CALL/CC does *not* pass the current continuation to its argument; it passes the continuation corresponding to the point *surrounding* the call to CALL/CC. The *real* current continuation is the one that passes control to the functional argument to CALL/CC. So my question is this: Has anyone considered alternate ways of providing the CALL/CC capability? And does it make any sense at all to use something like the CURRENT-CONTINUATION suggested above? (I am *almost* convinced that I can't implement CALL/CC with CURRENT-CONTINUATION, but maybe I haven't thought hard enough.) -Paul  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 30 OCT 85 14:03:53 EST Date: 30 Oct 1985 14:02 EST (Wed) Message-ID: From: Bill Rozas To: Charles Dolan Cc: Jim Meehan , scheme@MIT-MC.ARPA Subject: Continuations In-reply-to: Msg of 30 Oct 1985 11:37-EST from Charles Dolan Unfortunately, I think that Common Lisp style multiple-values provide something which cannot be conveniently obtained with explicit continuation passing. Consider the problem of writting a mapping procedure, MVMAP, like MAP (previously MAPCAR) with the constraint that (MVMAP f . lists) return as many lists of values as f returns values (assuming that f returns the same number of values on every invocation). Then (MAP f . lists) is equivalent to (MVMAP f . lists) if f returns a single value. The problem writting it in continuation passing style is that f must expect a continuation given to it by MVMAP, but then +, for example, cannot be used since it does not expect an explicit continuation. I agree that this can be "patched" by doing something like (mvmap explicit->implicit (implicit->explicit +) . lists) where EXPLICIT->IMPLICIT is the explicit continuation to MVMAP, used to pass on the "return" value to the implicit continuation, and is defined by (define (explicit->implicit val) val) ; Gives error if more than one value and IMPLICIT->EXPLICIT makes a procedure, which only expects an implicit continuation, accept an explicit continuation: (define (implicit->explicit f) (lambda (cont . args) (cont (apply f args)))) but this is somewhat clumsy, especially if MVMAP were to replace MAP, as it probably should if it were implemented. The problem arises because in Common Lisp returning one value is not much different from returning several, since almost all of the burden is put on the "receiving" end (and, of course, in VALUES). By implementing multiple values in terms of explicit continuation passing, we make procedures which potentially "return" multiple values (even if they happen to always "return" one) quite different from "normal" procedures since these do not expect an explicit continuation.  Received: from LOCUS.UCLA.EDU by MIT-MC.ARPA 30 Oct 85 11:43:50 EST Date: Wed, 30 Oct 85 08:37:27 PST From: Charles Dolan To: Jim Meehan CC: scheme@mit-mc.arpa Subject: Re: Continuations In-reply-to: Message of Tue, 29 Oct 85 16:15:37 EST from "Jim Meehan " <8510292121.AA02629@Yale-Bulldog.YALE.ARPA> Message-ID: <499538247-20492-cpd@HERA.LOCUS.UCLA.EDU> Heresy! Internally, T uses continuations all the time (surely you've seen these while crawling through the stack with DEBUG). Users can also write them either by passing LAMBDAs or by using CATCH (which is even implemented as CALL-WITH-CONTINUATION). The current T compiler doesn't take as much advantage of them as the prototype T 3.0 compiler does. In terms of running Lisp code, continuations are important for eliminating tail-recursion, etc. Take a peek at Abelson & Sussman, "Sturcture and Interpretation of Computer Programs." But for general programming, passing continuations is very useful, particularly when you pass more than one; each indicates "what to do next" (i.e., how to continue the computation) in some particular case, which can lead to code that's much more elegant than code that returns flags to the caller, or worse, multiple flags. Continuations are described in the first edition of Charniak, Riesbeck, and McDermott, "Artificial Intelligence Programming," (Chapter 17, I think). That section has been rewritten in the new edition (which Chris and I are just now finishing). T does indeed use continuations internally and you can make them yourself with LAMBDA expressions. In fact I do just that when compile TLOG (logic programming) into T. What T does not support is just the type of continuations decribed in AI Programming, the kind that let you return to a previous state of the computation. Doing it with LAMBDAs is not as nice, and its supported in COMMON LISP. You might also want to read the "LAMBDA papers," a collection of tech reports from MIT written by Steele and Sussman in the days when Scheme was still being invented. Steele's thesis also gives a pretty thorough description of the continuation-passing style (CPS), e.g., how any Lisp program can be transformed into CPS, which permits all sorts of optimizations. "Returning" a value means calling the continuation with that value as an argument. The reason multiple-values (in Common Lisp) are semantically nice is that they can (should) be viewed as a notation/mechanism for calling the continuation with several arguements, not just one. Thanks for the pointers.  Received: from yale by MIT-MC.ARPA 30 Oct 85 10:36:44 EST Received: by Yale-Bulldog.YALE.ARPA; 30 Oct 85 09:59:36 EST (Wed) Message-Id: <8510301459.AA07860@Yale-Bulldog.YALE.ARPA> Received: from YALE-RING by YALE-RES via CHAOS; Wed, 30 Oct 85 09:51:03 EST Subject: Re: moderation Date: Wed, 30 Oct 85 09:51:05 EST From: Paul Hudak To: Sanjai Narain Cc: scheme@MIT-MC In-Reply-To: Sanjai Narain , 28 Oct 85 10:24:25 PST (Mon) Hudak made the mysterious comment that Scheme/T doesn't need to quote either. ... Sorry to sound mysterious. My intent was to point out, as others have by now, that quoting wasn't *necessary*, just as it isn't in the lambda calculus; it is simply convenient, as most meta-tools are. So it seems to me that the only issue is that if one decides to have a "meta-language," how should it be manifested -- perhaps that's what you were refering to. Lisp chose quote, Prolog has a different mechanism, Barak's "Scheme0" uses yet another. I suppose they all have their advantages/disadvantages. I should clarify one other aspect of my "mysterious" comment: QUOTE is really just a way to create a data structure, and thus is not much different from using, say, strings. However, it's combination with EVAL is what makes me shy away from macros. It's usually the case that if one is using QUOTE plus EVAL, there's a "cleaner" way to do it with closures. -Paul P.S. I agree with you that these discussions are OK for this mailing-list, but then again I'm not a Scheme expert who has perhaps hashed through these issues a hundred times before.  Received: from LOCUS.UCLA.EDU by MIT-MC.ARPA 29 Oct 85 15:32:05 EST Date: Tue, 29 Oct 85 12:11:06 PST From: Charles Dolan To: scheme@mit-mc.arpa Subject: Continuations Message-ID: <499464666-2399-cpd@ZEUS.LOCUS.UCLA.EDU> At UCLA we use T which does not support continuations. I was wondering what I am missing. What are people out there using continuations for? Do you have simple examples which demonstrate how continuations make you solution more elegant, efficient, ...? -Charlie Dolan  Date: Tue, 29 Oct 85 11:44:06 EST From: Jonathan A Rees Subject: administrivia To: SCHEME@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].696740.851029.JAR> At least one person was confused about this, so I'll reiterate just to make sure this is clear. This list is not moderated. If you send mail to SCHEME@MIT-MC you're sending a message out to about 150 people. Some of these people would like to receive only pithy and extremely interesting messages. If you have any doubt about the appropriateness of a message, send it to SCHEME-REQUEST@MIT-MC and it will be moderated, forwarded, answered, edited, critiqued, ignored, or subjected to some combination of the the above. Thanks. Actually I think it's been going pretty well, but I'd like to hear more about the following: (a) implementations and (b) pedagogy.  Received: from GODOT.THINK.COM by MIT-MC.ARPA 29 Oct 85 10:58:57 EST Received: from polycarp by GODOT.THINK.COM via CHAOS; Tue, 29 Oct 85 10:59:07 est Date: Tue, 29 Oct 85 11:00 EST From: Guy Steele Subject: Re: need for quoting in Lisp To: Barak.Pearlmutter@G.CS.CMU.EDU, scheme@MIT-MC.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <499381673/bap@G.CS.CMU.EDU> Message-Id: <851029110027.1.GLS@THINK-POLYCARP.ARPA> Date: 28 Oct 1985 16:07-EST From: Barak.Pearlmutter@G.CS.CMU.EDU ... To illustrate very concretely, imagine a Schemelike language which is NOT it's own metalanguage, in which there are no macros. For any construct, we can tell unambiguously whether we have code or data in our hands, and hence quoting will be unnecessary. ... To Mr. Pearlmutter's excellent exposition I would like to add the observation that, 25 years ago, LISP was originally conceived in exactly these terms. Allow me to add to the table of examples the representation as LISP "M-expressions" ("meta-expressions"): Regular Scheme Scheme0 M-expressions (car (append x y)) (car (append x y)) car[append[x; y]] (car (quote (append x y))) (car [APPEND X Y]) car[(APPEND X Y)] (append (f x) (g (quote y)) (append (f x) (g Y) [H Z]) append[f[x]; g[Y]; (H Z)] (quote (h z))) --Guy  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 28 OCT 85 21:14:26 EST Date: 28 Oct 1985 21:13 EST (Mon) Message-ID: From: Bill Rozas To: HAL%MIT-OZ@MIT-MC.ARPA Cc: scheme@MIT-MC.ARPA Subject: quote In-reply-to: Msg of 28 Oct 1985 17:58-EST from HAL I don't understand why people object to quote and not to double-quote. For me the identifier (variable name) FOO and 'FOO are two distinct objects which have no relation except potential similarity in printed form (like "FOO" when display is used). It is EVAL that is funny, in the same way that linkers for all operating systems are funny in that they transform what was previously considered passive data into active data or programs.  Received: from BBNG.ARPA by MIT-MC.ARPA 28 Oct 85 19:58:55 EST Date: Mon 28 Oct 85 17:58:28-EST From: SRIDHARAN@BBNG.ARPA Subject: Why quote? To: scheme@MIT-MC.ARPA 1. Prolog does not have evaluation of function terms in its semantics. All terms are what a Lisper might say always quoted. The counterpart of the problem for Prolog is how to introduce evaluated terms. Since it feasible to write term rewrite rules (albeit only directional ones) some form of evaluation can be introduced, producing various degrees of partial and lazy evaluation methods. But, there would be questions similar to that of quoting, on under what circumstances what terms will be evaluated. 2. It is true but somewhat misleading to say that Lambda-calculus has no quoting. (a) pure Lambda-calculus has no data structures; one can simulate data structures by using closures in much the same way a cons-cell is defined (in A&S book but also many other places) by a closure that returns its first or second argument. If one wants not simulated data structures, but a machine-dependent real data structures (or at least dependent upon some architectural feature such as dereferencing of pointers), one has to introduce quotation. (b) simulated data structures will also introduce the confusion of quoting, (car (lambda () a)) will be an irreducible expression; Scheme will generate an error. 3. In Lisp implementations, since functions are called by value, one needs to resort to tricks to get call by expression/reference. In most realistic cases, the difference between these is one of efficiency. If an operation can be done on the expression once and used many times, one perhaps wishes to macro expand it or advise the compiler to do the processing once. Since efficiency is a legitimate concern of programmers, macros/quotes/compiling are in the game. 4. There is another mechanism besides macros one might use - partial compilation or compile time calculation. If an expression e contains a subexpression s that one wishes to be evaluated, and its value used in its place, quite a bit of optimization can be handled this way. Especially for people trying to do knowledge-based programming (not only in rules but inother forms as well) a good deal of knowledge-dependency might be evaluated in once and for all - only if a compiler allows us to use evaluate-once expressions. -------  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 28 OCT 85 17:58:03 EST Date: Mon, 28 Oct 1985 17:58 EST Message-ID: From: HAL%MIT-OZ@MIT-MC.ARPA To: scheme@MIT-MC.ARPA Subject: quote This is a comment on Sanji Narain's response to Paul Hudak's response to his remark about quote: The question I asked is not as trivial as it sounds to people who seem to have objected to it. It has to do with the necessity of quoting expressions, something which is absent from other systems such as Prolog. Hudak made the mysterious comment that Scheme/T doesn't need to quote either. Well, if you want to set x to the symbol a try typing (set x a). In Prolog you can do X=a quite legitimately. The problem is simply that in Lisps there is no way of distinguishing variables from constant symbols of the same name. So, you must use quote. This is an important issue that is very much misunderstood. Lisp chooses to blur the line between data structures that can be manipulated, and expressions in the language itself. The reason for doing this is that it leads to increased programming power. For instance, one could make a pattern matcher in which various elements of the patterns are simply (names of) Lisp procedures, thus leading to ability to explicitly EVAL parts of the pattern. If one wanted to give up this power, then one could choose essentially any ad hoc way to distinguish expressions from data (e.g., one could capitalize all identifiers, as does Prolog). Thus, in Prolog, one can unambiguously write X=a (as Narain points out) but one cannot unambiguously write X=Y, if the intent of this is to assign to X a constant (written as Y), which is later to be assembled into a data structure that is to be later interpreted as a Prolog program with an identifier named Y. Of course, there is nothing to stop one from writing a Prolog evaluator in Prolog (and there are good reasons for doing so) but then the quotation problem (distinguishing expressions in the Prolog that is performing the evaluation from expression in the Prolog that is being evaluated) arises just as it does in Lisp. This is not to say that Lisp's (or Scheme's) treatment of quote is the last word in handling this problem. See Brian Smith's thesis for an alternative, and perhaps more consistent approach. A couple of people have suggested to Sussman and me that we give up using quote in our book, since it would make things easier for students, and also make a simpler language from a theoretical point of view. Our opinion is that quote (hence the ability to mix data and expressions) provides a real source of power that is intimately related to Lisp's ability to serve as an implementation vehicle for embedded languages and programming environments. But we do make this point in our book. It would be nice to assemble a collection of good examples that use quote in this way. Note that the same issues underly the use of macros. Contrary to what Narain asserts, macro expansion is not just lambda reduction. This is true for SOME macros (like defining IF in terms of COND) but not true for others (such as DO) where the elements of the from may not even be syntactically valid Lisp (or Scheme) expressions.  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 28 OCT 85 17:41:02 EST Date: 28 Oct 1985 17:40 EST (Mon) Message-ID: From: Bill Rozas To: Sanjai Narain Cc: scheme@MIT-MC.ARPA Subject: moderation There are 2 possible uses of macros: - To provide SYNTACTIC EXTENSIONS to the language for convenience and clarity. This is the only legitimate use (as far as I'm concerned) of a macro facility. Examples of this are COND (in terms of IF) and LET (in terms of LAMBDA). Note that macros are needed for this case not because of order of evaluation (the main difference, besides assignment, between lambda calculus and Scheme), but rather because the forms do not make sense as procedure applications. For example, consider (let ((y (+ 2 3))) (* y y)) in a position where y is not bound. If LET were a procedure, it would receive 2 arguments ((y (+ 2 3))) and (* y y). But then y would be a free variable in the above expression, irrelevant of the order of evaluation, which is certainly not the desired effect. To obtain the desired effect, something like a macro would be needed even in a system which more closely modelled the lambda calculus. Thus there is something to macros which normal order evaluation in the lambda calculus does not provide. When used this way they are mere re-write rules (even character level) and evaluation plays no part in them. The re-write can be seen as happening before the program is evaluated, since these expressions would have no reasonable meaning otherwise. Back-quote and comma can be seen as ways of specifying string substitution. - To obtain the effects of normal order evaluation, locatives, or fexprs in a simple applicative order system like Scheme. Consider, for example, the standard Lisp SETF macro (not the T version which falls into the previous category). This is however a MISUSE, as far as I am concerned, and the desired effect should be obtained otherwise. I believe it is in this case that all of the problems about order of evaluation, etc. arise, which is not too surprising, since a tool is being used for something other than its real purpose. Just because a tool can be abused, it does not mean that it is wrong or that it is inherently broken if it does not work when it is used for a purpose other than its intended one.  Date: Mon, 28 Oct 85 17:59:04 EST From: "George J. Carrette" Subject: moderation To: narain@RAND-UNIX.ARPA cc: SCHEME@MIT-MC.ARPA In-reply-to: Msg of 28 Oct 85 10:24:25 PST (Mon) from Sanjai Narain Message-ID: <[MIT-MC.ARPA].695690.851028.GJC> I think the problem was one of "oh no, not that again," for some of the more experienced scheme/lisp hackers here. Even the most intense personal discussions with participants such as Sussman, Hanson, etc. never quite resolved some of these issues. There have been good suggestions to solving the scoping problems of macros. Anyway, people dont seem willing to rehash the elementary arguments again.  Date: Mon, 28 Oct 85 17:41:39 EST From: "George J. Carrette" To: JAR@MIT-MC.ARPA cc: SCHEME@MIT-MC.ARPA In-reply-to: Msg of Mon 28 Oct 85 15:27:44 EST from Jonathan A Rees Message-ID: <[MIT-MC.ARPA].695676.851028.GJC> OK, Jonathon, here's my info message resent: - Name of implementation: SIOD (Scheme In One Defun) - Implemented by whom: GJC (George Carrette) - Supported by whom, and to what extent: GJC, for use in LMI lisp classes. - Hardware and operating system(s): LMI-LAMBDA, ZETA(FOO?)LISP. - Availability: Given out at my "guest lectures" to LMI lisp classes. - Description of dialect: Sufficient to run S&ICP problems I find most interesting. Especially streams, the meta-linguistic abtraction section, and the interpreter/hardware sections. - Intended use: education. Both to introduce S&ICP and to show interpreter implementation, also "WHY MACROS OR BAD, or WHY CANT YOU READ MY CODE?" - Implementation style: The function SEVAL (scheme EVAL) is one DEFUN. The "text" being interpreted is syntax-checked first, but is otherwise just the obvious s-expression. The environment representation is an ALIST. Because of the underlying simplicity it was possible to code special cases such as look-ahead for simple variable lookup, and primitives such as +,/,CAR,CDR, applied to simple variable lookups without fear. There is very little overhead in the interpreter besides variable lookup (a single instruction, %ASSQ) and environment consing, (cheaper by the dozen and with the volatility based GC). The resulting interpreter is somewhat gross because of its use of specialized macrology, but is extremely fast, especially when compiled into MICROCODE by the Microcompiler. - Remarks: One reason for this was to see just how far a few hours work on a simple idea implemented somewhat grossly could go. Whenever I was too burned out to do design-level work or debugging work (presumably on jobs that I was paid to do) I might feel like trying to code another SIOD special case. It is also a study for "how much effort should go into avoiding CONS, vs other things?" It could be interesting to compare its efficiency with JAR's compiler-style CLSCH. - Whom to contact for more information: GJC@MC.  Received: from G.CS.CMU.EDU by MIT-MC.ARPA 28 Oct 85 16:51:34 EST Date: 28 Oct 1985 16:07-EST From: Barak.Pearlmutter@G.CS.CMU.EDU To: scheme@mit-mc Subject: Re: need for quoting in Lisp Message-Id: <499381673/bap@G.CS.CMU.EDU> At first glance it seems odd that Lisp requires quoting while Prolog and lambda-calculus do not. The reason is that Lisp attempts to be it's own meta-language, allowing chunks of code to be treated as data. This power carries with it the danger that code and data might be confused, and QUOTE is the way in which the confussion is averted. To illustrate very concretely, imagine a Schemelike language which is NOT it's own metalanguage, in which there are no macros. For any construct, we can tell unambiguously whether we have code or data in our hands, and hence quoting will be unnecessary. Let's call our emasculated Scheme Scheme0. In Scheme0, the symbols manipulated by code will not be used to represent variables. Rather, we will have two different kinds of symbols, which both have the identity property but are distinguished. The read/print convention I use will be that v-symbols will be lower case and d-symbols will be upper case. V-symbols will never be allowed into data structures manipulated by code; rather they can only be part of programs themselves. Similarly, we will have two different kinds of cons cells: the cons cells that make up the lists used to represent function calls and special forms, and another kind of cons cell used to construct lists manipulated by Scheme0 programs. The read/print convention for these will be that program cons cells use (...) and data cons cells use [...]. We now have a situation much like that with numbers and strings in regular lisps: data cons cells can never be used to mean program, so need not be quoted, and similarly with data symbols. Semantics by example: Regular Scheme Scheme0 (car (append x y)) (car (append x y)) (car (quote (append x y))) (car [APPEND X Y]) (append (f x) (g (quote y)) (append (f x) (g Y) [H Z]) (quote (h z))) (f (lambda (x) (f x (quote (f x))))) (f (lambda (x) (f x [F X]))) There are many routes to add metarepresentational power to Scheme0. One is to identify v-symbols with d-symbols, and the same with lists, thus requiring QUOTE to distinguish constants from code, but allowing macros to be written. Another would be to force macros to be written in another language, say Scheme0-1, which can manipulate both v-data and d-data, and is written using v-prime-datatypes. Unfortunately, this requires more and more datatypes as we move up levels in the tower. Thus, a DOLIST macro written to apply to Scheme0 code would be written in Scheme0-1, but then DOLIST couldn't be used in Scheme0-1 unless you rewrote it in Scheme0-2, etc. There is a way out of this dilemma, as with 3LISP, but Lisp has chosen to take the first road and bite the QUOTE bullet. It remains to be seen if Prolog will be able to integrate more natural source to source transformations without going the same route. --Barak.  Received: from rand-unix.ARPA by MIT-MC.ARPA 28 Oct 85 14:57:35 EST Return-Path: Received: by rand-unix.ARPA; Mon, 28 Oct 85 10:24:33 pst From: Sanjai Narain Message-Id: <8510281824.AA14691@rand-unix.ARPA> Date: 28 Oct 85 10:24:25 PST (Mon) To: scheme@mit-mc Subject: Re: moderation In-Reply-To: Your message of Mon, 28 Oct 85 10:41:43 EST. <[MIT-MC.ARPA].695148.851028.JAR> The question I asked is not as trivial as it sounds to people who seem to have objected to it. It has to do with the necessity of quoting expressions, something which is absent from other systems such as Prolog. Hudak made the mysterious comment that Scheme/T doesn't need to quote either. Well, if you want to set x to the symbol a try typing (set x a). In Prolog you can do X=a quite legitimately. The problem is simply that in Lisps there is no way of distinguishing variables from constant symbols of the same name. So, you must use quote. The matter is further complicated in the use of backquotes and by the dubious distinction between evaluation and macroexpansion. What is the purpose of this distinction? In the lambda calculus evaluation is simply repeated macroexpansion to the normal form. What distinguishes Scheme/T from other Lisps but language issues such as lexical scoping and higher order functions? Yes, what indeed? If people don't seem to be interested in discussing such issues here, as Jonathan implies, I understood the purpose of this list quite incorrectly. Sorry. FYI hardly anyone objects like yba@athena.mit in other language-oriented lists like Prolog, or Franz-friends. -- Sanjai  Date: Mon, 28 Oct 85 13:25:34 EST From: Jonathan A Rees Subject: implementations To: SCHEME@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].695199.851028.JAR> Since no one has responded to my request for implementation info, I'll send out excerpts from the standard letter that MIT sends to people who ask about Scheme implementations. I hope this is useful to some of you. Some of this information may be out of date. Please correct whatever's wrong. I didn't include the paragraph on Chez Scheme since it gave a UNC address and phone number, and it was my understanding that Chez Scheme now comes from Cadence Research Inc., not UNC. Also, I don't know who the official contact, if any, is for T. Information on the MIT scheme implementations was too detailed, and most of you probably have it already, so a condensed version will arrive under separate cover. - Jonathan @b[MacScheme] is a commercially-available implementation of Scheme for the 512K Apple Macintosh. It meets the requirements of the Revised Revised Report. A compatibility file is supplied for use with the Abelson and Sussman book. The system features a byte-code interpreter and Macintosh-style user interface. MacScheme sells for $125; site licenses are available. For more information, write to: @begin(display) Semantic Microsystems 1001 Bridgeway Suite 543 Sausalito CA 94965 (415) 332-8094 @end(display) @b[PC Scheme] (unofficial name) is an implementation of Scheme that is being developed at Texas Instruments. It runs on the Texas Instruments Personal Computer and the IBM Personal Computer. Besides the Scheme interpreter itself, the system includes graphics, windowing capabilities, and a text editor implemented in Scheme. The implementation adheres to the Scheme standard, and it is completely compatible with the MIT course material. The Scheme interpreter itself will run in 256K, but successful course use (easily invoking the editor, loading the largest MIT material) requires a system with at least 512K and preferably a hard disk. PC Scheme is still under development and is not available commercially. However, Texas Instruments is conducting an instructional beta test program under which they will make implementations available to institutions wishing to use Scheme in conjunction with courses and other instructional projects. For information on the program contact @begin(display) Texas Instruments PO Box 2909 Austin, Texas 78769 Attn: Scheme Product Center, M/S 2244 @end(display) @b[Scheme84] is a version of Scheme that has been under development at Indiana University for the past few years, and is used there to support half a dozen different computer science courses. The system runs on the Vax under either VMS or Berkeley Unix. The developers of Scheme84 intend to supply a compatibility package that will allow the MIT materials to be run without modification. The Scheme84 software is in the public domain, and can be obtained by writing to@foot{The current distribution policy for Scheme84 is that Indiana University will supply it for free, if you send them a tape and return postage. (Please specify whether the system is to be for VMS or for Unix.) On the other hand, the University reserves the right to begin charging a fee to recover the cost of distribution, should this become necessary.} @begin(display) Scheme84 Distribution Nancy Garrett c/o Dan Friedman Department of Computer Science Indiana University Bloomington, Indiana (812)-335-9770 E-mail address nlg@@indiana @end(display) @b[T] is a version of Scheme that was developed at Yale University, and is available for distribution. The system runs on Vaxes under VMS or Unix (Berkeley 4.1 or 4.2) and on the Apollo Domain. For more information, contact [???] at Yale (203-436-0802) or write to @begin(display) Yale University Dept. of Computer Science PO Box 2158 Yale Station New Haven, CT 06520 @end(display)  Date: Mon, 28 Oct 85 11:25:33 EST From: Jonathan A Rees Subject: implementations To: SCHEME@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].695198.851028.JAR> Since no one has responded to my request for implementation info, I'll send out excerpts from the standard letter that MIT sends to people who ask about Scheme implementations. I hope this is useful to some of you. Some of this information may be out of date. Please correct whatever's wrong. I didn't include the paragraph on Chez Scheme since it gave a UNC address and phone number, and it was my understanding that Chez Scheme now comes from Cadence Research Inc., not UNC. Also, I don't know who the official contact, if any, is for T. Information on the MIT scheme implementations was too detailed, and most of you probably have it already, so a condensed version will arrive under separate cover. - Jonathan @b[MacScheme] is a commercially-available implementation of Scheme for the 512K Apple Macintosh. It meets the requirements of the Revised Revised Report. A compatibility file is supplied for use with the Abelson and Sussman book. The system features a byte-code interpreter and Macintosh-style user interface. MacScheme sells for $125; site licenses are available. For more information, write to: @begin(display) Semantic Microsystems 1001 Bridgeway Suite 543 Sausalito CA 94965 (415) 332-8094 @end(display) @b[PC Scheme] (unofficial name) is an implementation of Scheme that is being developed at Texas Instruments. It runs on the Texas Instruments Personal Computer and the IBM Personal Computer. Besides the Scheme interpreter itself, the system includes graphics, windowing capabilities, and a text editor implemented in Scheme. The implementation adheres to the Scheme standard, and it is completely compatible with the MIT course material. The Scheme interpreter itself will run in 256K, but successful course use (easily invoking the editor, loading the largest MIT material) requires a system with at least 512K and preferably a hard disk. PC Scheme is still under development and is not available commercially. However, Texas Instruments is conducting an instructional beta test program under which they will make implementations available to institutions wishing to use Scheme in conjunction with courses and other instructional projects. For information on the program contact @begin(display) Texas Instruments PO Box 2909 Austin, Texas 78769 Attn: Scheme Product Center, M/S 2244 @end(display) @b[Scheme84] is a version of Scheme that has been under development at Indiana University for the past few years, and is used there to support half a dozen different computer science courses. The system runs on the Vax under either VMS or Berkeley Unix. The developers of Scheme84 intend to supply a compatibility package that will allow the MIT materials to be run without modification. The Scheme84 software is in the public domain, and can be obtained by writing to@foot{The current distribution policy for Scheme84 is that Indiana University will supply it for free, if you send them a tape and return postage. (Please specify whether the system is to be for VMS or for Unix.) On the other hand, the University reserves the right to begin charging a fee to recover the cost of distribution, should this become necessary.} @begin(display) Scheme84 Distribution Nancy Garrett c/o Dan Friedman Department of Computer Science Indiana University Bloomington, Indiana (812)-335-9770 E-mail address nlg@@indiana @end(display) @b[T] is a version of Scheme that was developed at Yale University, and is available for distribution. The system runs on Vaxes under VMS or Unix (Berkeley 4.1 or 4.2) and on the Apollo Domain. For more information, contact [???] at Yale (203-436-0802) or write to @begin(display) Yale University Dept. of Computer Science PO Box 2158 Yale Station New Haven, CT 06520 @end(display)  Date: Mon, 28 Oct 85 10:41:43 EST From: Jonathan A Rees Subject: moderation To: SCHEME@MIT-MC.ARPA In-reply-to: Msg of 27 Oct 85 00:21:50 EDT (Sun) from yba at ATHENA.MIT.EDU Message-ID: <[MIT-MC.ARPA].695148.851028.JAR> I have received several messages of the following form: Date: 27 Oct 85 00:21:50 EDT (Sun) From: yba at ATHENA.MIT.EDU Or could we at least get it moderated so as to ensure it discusses scheme instead of backquotes in T? How about just asking folks not to cc the entire list? Please? If you have any doubt as to whether a message you want to send is appropriate for the list, send it to SCHEME-REQUEST@MIT-MC, and I'll either forward it or reply to it. For the moment, I'll act as "moderator" when that's needed. I don't want to spend too much time on this, so please, moderate yourselves. Remember that turnaround can be very slow, since many people are only connected through CSNET or uucp. That explains why there were redundant replies to the backquote question. In defense of the recent backquote flurry, I'll say that the question had nothing to do with T; backquote is a common feature of RRRSS, Common Lisp, and many other Lisps. However, I agree that the question had little to do with Scheme either. My perception is that most people are on the list not because they're interested in language issues per se, but rather because they want to talk about how people actually use the unique aspects of Scheme in teaching and discussing computation. (Tell me if I'm wrong.)  Received: from USC-ECL.ARPA by MIT-MC.ARPA 26 Oct 85 13:06:47 EDT Date: 26 Oct 1985 1002-PDT From: WAXMAN@USC-ECL.ARPA Subject: PLASE REMOVE MY NAME FROM SCHEME MAILING LIST To: JAR@MIT-MC.ARPA cc: SCHEME@MIT-MC.ARPA JONATHON, PLEASE REMOVE MY NAME FROM THE SCHEME ELECTRONIC MAIL LIST. IT HAS MORE DETAIL THAN I NEED. THANKS, MILT WAXMAN WAXMAN@USC-ECLA -------  Received: from yale by MIT-MC.ARPA 25 Oct 85 10:23:27 EDT Received: by Yale-Bulldog.YALE.ARPA; 25 Oct 85 10:10:52 EDT (Fri) Message-Id: <8510251410.AA08341@Yale-Bulldog.YALE.ARPA> Received: from YALE-RING by YALE-RES via CHAOS; Fri, 25 Oct 85 10:10:41 EDT Subject: Re: Q. on backquote Date: Fri, 25 Oct 85 10:10:42 EDT From: Paul Hudak To: Sanjai Narain Cc: scheme@MIT-MC In-Reply-To: Sanjai Narain , 24 Oct 85 12:18:45 PDT (Thu) ... Fundamentally, it is a question of what is the need to quote and what is evaluation. Note that Prolog doesn't need to quote, neither does the lambda calculus. Please -- T/Scheme doesn't need to quote either -- one can usually use closures to do what you want. It's just that macros are useful for defining *syntax*, and there's no reason that Prolog designers won't reach the same conclusion. Although I personally shy away from using macros, they are generally viewed as a *feature* of Lisps, but not necessarily fundamental to the language or its semantics. -Paul  Date: Thu, 24 Oct 85 16:31:38 EDT From: Jonathan A Rees Subject: T mailing lists. To: narain@RAND-UNIX.ARPA cc: SCHEME@MIT-MC.ARPA In-reply-to: Msg of Thu 24 Oct 85 13:06:14 EDT from Ashwin Ram Message-ID: <[MIT-MC.ARPA].691724.851024.JAR> I'll put you, and anyone else who wants to be, on the T lists. I think their existence is mentioned in the front of the T Manual. In general, requests should be sent to T-Discussion-Request@MIT-MC. (T-Users was intended as a one-way communications channel from implementors to users for announcements, etc., and T-Discussion was intended to be a forum.)  Received: from rand-unix.ARPA by MIT-MC.ARPA 24 Oct 85 15:32:29 EDT Return-Path: Received: by rand-unix.ARPA; Thu, 24 Oct 85 12:18:48 pdt From: Sanjai Narain Message-Id: <8510241918.AA29049@rand-unix.ARPA> Date: 24 Oct 85 12:18:45 PDT (Thu) To: scheme@mit-mc Subject: Q. on backquote Thanks to all of you for taking the time to respond to my question. I realize much of what you say for I have been using the facility for quite a while. My intention was to understand it precisely. Fundamentally, it is a question of what is the need to quote and what is evaluation. Note that Prolog doesn't need to quote, neither does the lambda calculus. -- Sanjai  Received: from yale by MIT-MC.ARPA 24 Oct 85 14:00:07 EDT Received: by Yale-Bulldog.YALE.ARPA; 24 Oct 85 13:31:16 EDT (Thu) Message-Id: <8510241731.AA00535@Yale-Bulldog.YALE.ARPA> Received: from YALE-RING by YALE-RES via CHAOS; Thu, 24 Oct 85 13:06:11 EDT Subject: Re: Elementary question about backquote in T. Date: Thu, 24 Oct 85 13:06:14 EDT From: Ashwin Ram To: Sanjai Narain Cc: scheme@MIT-MC In-Reply-To: Sanjai Narain , 23 Oct 85 21:59:49 PDT (Wed) I'm sure you'll get a lot of responses to your question, but anyway... I hope it is okay to send a T question to this list, since I am not aware of a separate list for T. There are two: T-USERS and T-DISCUSSION. There was once a reason for having separate lists but in practice everyone now reads both and there doesn't seem to be any real difference in the type or level of questions. If we define: (define-macro (bar x) `(list ,(car x))) then (macro-expand '(bar '(1 2)) *scratch-env*) ==> (list quote). That is, an attempt to evaluate (bar '(1 2)) will give an error to the effect that quote is unbound. This appears to me rather confusing. A macro is ideally a rewrite rule. So I expect (bar '(1 2)) to be rewritten to the form (list u) where u = (car '(1 2)) i.e. (list u) must be rewritten to (list 1). This expectation is supported by the following observations: > (set x '(1 2)) ;; x is bound to '(1 2) > `(list ,(car x)) ==> (list 1) What am I missing? By the way, Franzlisp backquote behaves similarly. Thanks for any comments. -- Sanjai --------- The single-quote character is a read macro that wraps a QUOTE around its argument. In T terms, that means the following: > (stream-read-table (standard-input)) #{Read-table 53 *STANDARD-READ-TABLE*} > (read-table-entry (stream-read-table (standard-input)) #\') #{Procedure 54 READ-QUOTATION} and, from TSYS/READ.T: (DEFINE (READ-QUOTATION STREAM CH RT) (IGNORE CH) (LIST *QUOTE* (READ-OBJECT-REFUSING-EOF STREAM RT))) Thus '(1 2) gets read in as (QUOTE (1 2)), and (bar '(1 2)) expands to (LIST u) where u is the CAR of (QUOTE (1 2)), i.e., the symbol QUOTE. In other words, (bar '(1 2)) expands to (list QUOTE) as you noted. Macros are rewrite rules, but on list structures (like "(QUOTE (1 2))"), not on ASCII text (like "'(1 2)"). In your transcript, x gets bound, not to "'(1 2)" as you say, but to a list structure represented as (1 2). The CAR of this structure is the atom 1, and thus you get (list 1), i.e., the list (1) as your result. Hope this helps... Ashwin. -------  Received: from GODOT.THINK.COM by MIT-MC.ARPA 24 Oct 85 11:57:26 EDT Received: from jehosephat by GODOT.THINK.COM via CHAOS; Thu, 24 Oct 85 11:57:31 edt Date: Thu, 24 Oct 85 11:59 EDT From: Guy Steele Subject: Elementary question about backquote in T. To: narain@RAND-UNIX.ARPA, scheme@MIT-MC.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <8510240459.AA18070@rand-unix.ARPA> Message-Id: <851024115916.2.GLS@THINK-JEHOSEPHAT.ARPA> Date: 23 Oct 85 21:59:49 PDT (Wed) From: Sanjai Narain ... If we define: (define-macro (bar x) `(list ,(car x))) then (macro-expand '(bar '(1 2)) *scratch-env*) ==> (list quote). That is, an attempt to evaluate (bar '(1 2)) will give an error to the effect that quote is unbound. This appears to me rather confusing. A macro is ideally a rewrite rule. So I expect (bar '(1 2)) to be rewritten to the form (list u) where u = (car '(1 2)) i.e. (list u) must be rewritten to (list 1). No, u = (car ''(1 2)). This expectation is supported by the following observations: > (set x '(1 2)) ;; x is bound to '(1 2) No, x is bound to (1 2). The car of this is then 1. > `(list ,(car x)) ==> (list 1) What am I missing? By the way, Franzlisp backquote behaves similarly. Thanks for any comments. -- Sanjai For absolute precision, in the following remarks I will use double-quotes as metasyntactic quote marks, rather than as string delimiters. In the macro call "(bar '(1 2))" the macro parameter "x" is bound to an unevaluated argument, so the value of "x" is "'(1 2)", which is the same as "(quote (1 2))". When you write ",(car x)" within the backquote, it means to take the car of the macro-expand-time value of "x". The value of "x" is "(quote (1 2))", so the car of that is "quote". The resdult of expanding "(bar (1 2))" (without a single quote) would be "(list 1)", which wpould then evaluate to "(1)". One could also define "bar" as (define-macro (bar x) `(list (car ,x))) with the comma in a different place, so as to make the "car" operation take place at evaluation time (run time) rather than expansion time (compile time). Then the macro call "(bar '(1 2))" would expand to "(list (car '(1 2)))" which would in turn also evaluate to "(1)". --Guy  Received: from rand-unix.ARPA by MIT-MC.ARPA 24 Oct 85 01:02:18 EDT Return-Path: Received: by rand-unix.ARPA; Wed, 23 Oct 85 21:59:52 pdt From: Sanjai Narain Message-Id: <8510240459.AA18070@rand-unix.ARPA> Date: 23 Oct 85 21:59:49 PDT (Wed) To: scheme@mit-mc Subject: Elementary question about backquote in T. I hope it is okay to send a T question to this list, since I am not aware of a separate list for T. If we define: (define-macro (bar x) `(list ,(car x))) then (macro-expand '(bar '(1 2)) *scratch-env*) ==> (list quote). That is, an attempt to evaluate (bar '(1 2)) will give an error to the effect that quote is unbound. This appears to me rather confusing. A macro is ideally a rewrite rule. So I expect (bar '(1 2)) to be rewritten to the form (list u) where u = (car '(1 2)) i.e. (list u) must be rewritten to (list 1). This expectation is supported by the following observations: > (set x '(1 2)) ;; x is bound to '(1 2) > `(list ,(car x)) ==> (list 1) What am I missing? By the way, Franzlisp backquote behaves similarly. Thanks for any comments. -- Sanjai  Date: Thu, 24 Oct 85 00:08:44 EDT From: Jonathan A Rees Subject: Implementation blurb: Vincennes Scheme To: SCHEME@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].690739.851024.JAR> Since I doubt anyone from Univ. de Paris 8 is on this list, I'll send out what information I have on Vincennes Scheme. - Jonathan --- Vincennes Scheme is a version of Scheme written entirely in portable C, for Unix V7 and Berkeley 4.1 and 4.2. It runs on 32-bit machines (e.g. 68K or Vax) as well as on 16-bit machines (e.g. Z8000 in which it can fit in 128K). This Scheme is compatible with the MIT version, and includes an interpreter with the basic environment: debugger, history, break, stepper, where. A compiler that generates C code is available. For more information, contact Patrick Greussay Universite Paris-8-Vincennes 2 rue de la Liberte Saint-Denis CEDEX 02 93526 France  Date: Mon, 21 Oct 85 20:27:49 EDT From: Jonathan A Rees Subject: Implementation blurb: Scheme in Common Lisp To: SCHEME@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].687556.851021.JAR> - Name of implementation: CLSCH (Scheme embedded in Common Lisp) - Implemented by whom: Jonathan Rees - Supported by whom, and to what extent: Unsupported, although I'll probably continue to improve it. No promises. - Hardware and operating system(s): Will run in any implementation of Common Lisp. - Availability: In alpha-test now (looking for guinea pigs). Free. Distributed as source via electronic mail or FTP. (I won't make tapes.) May eventually become part of Common Lisp "Yellow Pages." - Description of dialect: Subset. All of the essential features of RRRSS exist, except for a correct CALL-WITH-CURRENT-CONTINUATION (some of you will say that it's not Scheme at all, and I don't disagree); also some of the rest of RRRSS, and most of the S&ICP dialect. - Intended use: Running existing ERRRSS programs in any Common Lisp. Not an ideal development system, since debugging tools are weak. - Implementation style: Low-tech. A simple compiler translates Scheme into Common Lisp, making sure that variable binding and tail recursion are done right. The output of the compiler can be interpreted by a CL interpreter or compiled by a CL compiler. - Remarks: I did this mostly for my own personal use. Maybe other people will find it useful too. - Contact: Jonathan Rees (JAR@MIT-MC), MIT Artificial Intelligence Laboratory, 545 Technology Square, Cambridge MA 02139, (617) 253-8581.  Date: Mon, 21 Oct 85 16:08:06 EDT From: Jonathan A Rees Subject: scheme implementations To: SCHEME@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].687283.851021.JAR> To make sure that everyone out there has current information, I want to ask people who have or are actively working on Scheme implementations to send out a SHORT message, giving the following information: - Name of implementation - Implemented by whom - Supported by whom, and to what extent - Hardware and operating system(s) - Availability: when, approximate pricing, copyright status - Description of dialect (esp. compare with RRRSS [*] and with the dialect used in S&ICP) - Intended use: education, number crunching, systems programming, etc. - Implementation style (S-code, native-code-compiler-based, or whatever) - Remarks, interesting features, misfeatures, and applications, etc. - Whom to contact for more information In particular, I'd like to hear blurbs from the groups at Indiana, MIT, Semantic Microsystems, TI, Yale, Vincennes, and Cadence. No hype please. [* Sorry, I use the following abbreviations: S&ICP = the book "Structure and Interpretation of Computer Programs" by Abelson & Sussman RRRSS = the Scheme dialect described in the Revised Revised Report ERRRSS = the "essential" subset of RRRSS] If you have written books or articles about or using Scheme or are in the process of doing so, I think people would be interested in hearing about that too.  Received: from mit-eddie by MIT-MC.ARPA 21 Oct 85 14:22:10 EDT Received: from MIT-CHARON (d003a12) by mit-eddie (4.12/4.7) id AA25774; Mon, 21 Oct 85 14:19:13 edt Received: by MIT-CHARON (4.12/4.7) id AA02813; Mon, 21 Oct 85 14:23:10 edt Message-Id: <8510211823.AA02813@MIT-CHARON> To: scheme@mit-mc, ai-ed@sumex-aim Cc: meltsner@mit-charon Subject: Scheme for Thermo. Date: 21 Oct 85 14:22:51 EDT (Mon) From: meltsner%athena@mit-eddie.MIT.EDU This is both a request and an announcement: I have been working on a "microworld" for thermodynamics. The world would support common thermodynamic objects like gases and solids, and would allow objects to be interconnected, and equilibriums found with a variety of constraints on mass, energy, volume, etc. transfer. ("would" because not all features have been implemented) It has proved to be useful in an introductory (graduate) level thermo course, and I am currently planning to rewrite it to remedy a number of deficiencies. Questions: 1) Would you prefer an english-language (command-driven) interface or a windowed one? Does "make an gas with 10 moles of neon temperature 298" make more sense than a dialog box after one has selected a menu item "Make Gas"? 2) Are windowed graphics useful? What sort of graphics?(x-time, x-y, contour, dials, gauges, empty/full bar indicators) 3) Would you sacrifice speed for numeric accuracy? (1% accuracy vs. .01% might triple the iteration time) 4) How important are on-line help, explanations of internal processes, examples? 5) What would you like to have it run on? (4.2 Unix, Macintosh, IBM, ??) 6) What would it have to run on to be useful for use in a class at your institution? The program is currently written in T, and will be moved to Cscheme (MIT Vax 4.2 Unix Scheme in C). The program is available for trade or (in a few months) for a nominal fee from our group at MIT. Planned expansions include the ability to change thermodynamic state variables, a thermo methods database (rule-driven thermo), and a clock for kinetic problems. Please send all answers and questions to: meltsner@athena.MIT.EDU or Ken Meltsner MIT Room 13-5142 Cambridge, MA 02139 617-253-3139 Ken  Date: Sun, 20 Oct 85 21:46:23 EDT From: Jonathan A Rees Subject: welcome To: SCHEME@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].686441.851020.JAR> Welcome to the "Scheme" mailing list. The list is intended to be a forum for discussing anything related to the Scheme programming language(s), with particular emphasis on the use of Scheme in education. There are over 100 people on the list now, with about 70 institutions represented. Most have signed up as the result of a recent message on AILIST. Send all communication concerning the administration of the list (additions, removals) to Scheme-Request@MIT-MC. Some of you may be unwittingly on this list (e.g., indirectly through some other list). Send mail to Scheme-Request@MIT-MC if you don't want to be on and I'll try to fix things somehow. Messages will accrete in the file "LSPMAI; SCHEME MAIL" on MIT-MC. Several people have asked about MIT AI memo 848, the "Revised Revised Report on Scheme," Will Clinger, editor. It can be ordered from: Elizabeth Heepe Publications, Room NE43-818 MIT Artifical Intelligence Laboratory 545 Technology Square Cambridge MA 02139 Enclose a check for $6.00 per copy (U.S. funds) payable to the MIT Artificial Intelligence Laboratory. Coming soon: information on available and unavailable Scheme implementations. Jonathan Rees JAR@MIT-MC