Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 26 May 88 13:27:27 EDT Received: by kleph.AI.MIT.EDU; Thu, 26 May 88 13:27:07 edt Date: Thu, 26 May 88 13:27:07 edt From: cph@kleph.AI.MIT.EDU (Chris Hanson) Message-Id: <8805261727.AA06410@kleph> To: net%TUB.BITNET@MITVMA.MIT.EDU Cc: scheme@mc.lcs.mit.edu In-Reply-To: Oliver Laumann's message of Wed, 25 May 88 18:59:30 +0200 <8805251659.AA00682@tub.UUCP> Subject: Macros; lexcial scope Reply-To: cph@zurich.ai.mit.edu Date: Wed, 25 May 88 18:59:30 +0200 From: Oliver Laumann Consider the following example: (define x 1) (define-macro (m) x) (let ((x 2)) (m)) in both Common Lisp (using a different syntax, of course) and C-Scheme, (m) returns 1 in the example above. You have an old version of C-Scheme. The current version (release 6 and later) gives an "unbound variable X" error while evaluating the last expression. Now consider a slighly more complex example: (define x 1) (let ((x 2)) (define-macro (m) x) (let ((x 3)) (m))) In both Common Lisp and C-Scheme, this evaluates to 1. Again, this produces an "unbound variable X" error in the current release. As one of several people who has thought about the issues you raise, I'll offer the following: 1. The semantics of special forms like `define-macro' is confusing. The naive interpretation of the meaning requires that a macro created this way should be closed in the environment in which it lexically appears. Unfortunately, that environment usually does not exist until run time, while for obvious reasons it is desirable that macros be closed at compile time. 2. C-Scheme has "solved" this problem by forcing all such macros to be closed in the global environment (actually, in a distinct child of the global environment). This alternate environment is guaranteed to exist at compile time, and under normal circumstances your other definitions won't interact with it. Thus, this explains the "unbound variable" errors. I say "solved" above because, rather than providing an acceptable solution, all we've really done is try to make it obvious when the user is confused about the closing environment. 3. My personal conclusion is that `define-macro' is a bad idea. I rarely, if ever, use it. C-Scheme provides facilities for explicitly constructing syntax tables (see the file "runtime/syntax.scm", procedures `make-syntax-table' and `syntax-table-define', and the special forms `macro' and `using-syntax') which do not have this problem. Using these facilities, the macros are closed in the environment in which they are loaded. They also appear in a different file from their references, thus reducing the confusion. 4. The R*RS committee is in the process of generating a "standard" macro facility. Keep tuned for more news.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 26 May 88 12:27:13 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 26 May 88 12:22:44 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 26 May 88 14:53:24 GMT From: krulwich-bruce@yale-zoo.arpa (Bruce Krulwich) Organization: Yale University Computer Science Dept, New Haven CT 06520-2158 Subject: Re: Macros; lexcial scope Message-Id: <30160@yale-celray.yale.UUCP> References: <8805251659.AA00682@tub.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <8805251659.AA00682@tub.UUCP> net@TUB.BITNET (Oliver Laumann) writes: >Consider the following example: > (define x 1) > (define-macro (m) x) > (let ((x 2)) > (m)) >Would you expect that (m) evaluates to 1 or to 2? In both Common Lisp >(using a different syntax, of course) and C-Scheme, (m) returns 1 in the >example above. Thus, it looks as if the first time the macro body is >evaluated, the evaluation takes place in the lexical scope of the >define-macro. Rather, that the macro is evaluated in the lexical scope in which it was defined, just like regular functions. >Now consider a slighly more complex example: > (define x 1) > (let ((x 2)) > (define-macro (m) x) > (let ((x 3)) > (m))) >In both Common Lisp and C-Scheme, this evaluates to 1. T's DEFINE-SYNTAX does what you want in both of these cases, evaluating to 1 in the first case and 2 in the second case. Bruce Krulwich  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 26 May 88 03:38:05 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 2992; Wed, 25 May 88 13:01:27 EDT Received: from DB0TUI6.BITNET (NET) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 2991; Wed, 25 May 88 13:01:24 EDT Received: by tub.UUCP; Wed, 25 May 88 18:59:30 +0200; AA00682 Date: Wed, 25 May 88 18:59:30 +0200 From: Oliver Laumann Message-Id: <8805251659.AA00682@tub.UUCP> To: scheme@mc.lcs.mit.edu Subject: Macros; lexcial scope I would like to know how you would expect macros to work in Scheme or generally in a lexically scoped Lisp. (I'm not talking about a specific Scheme implementation here) Suppose Scheme supported something like ``define-macro'' with the same syntax as ``define'', so that you could, for instance, write (define-macro (incr x) `(set! ,x (+ ,x 1))) Now my question is whether macros are lexically scoped (like functions) or whether macro expansion is performed in a purely syntactic way. Consider the following example: (define x 1) (define-macro (m) x) (let ((x 2)) (m)) Would you expect that (m) evaluates to 1 or to 2? Yes, I know, if I had written (define-macro (m) 'x), it would evaluate to 2. However, in both Common Lisp (using a different syntax, of course) and C-Scheme, (m) returns 1 in the example above. Thus, it looks as if the first time the macro body is evaluated, the evaluation takes place in the lexical scope of the define-macro. Now consider a slighly more complex example: (define x 1) (let ((x 2)) (define-macro (m) x) (let ((x 3)) (m))) In both Common Lisp and C-Scheme, this evaluates to 1. My mind boggles. The macro is local to the outer let, why is the ``x'' inside the macro body bound to the global variable? Are macro always implemented like this (in lexically scoped Lisps)? If so, why? [I'm sorry, if the answer to my question is obvious; I'm new to Scheme and Lisp.] -- Regards, Oliver Laumann, Technical University of Berlin, Germany. ...!pyramid!tub!net or net@TUB.BITNET ...!mcvax!unido!tub!net  Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 25 May 88 23:54:54 EDT Return-Path: Received: from kali.think.com by Think.COM; Wed, 25 May 88 13:19:35 EDT Received: by kali.think.com; Wed, 25 May 88 13:19:32 EDT Date: Wed, 25 May 88 13:19:32 EDT From: gls@Think.COM Message-Id: <8805251719.AA12205@kali.think.com> To: scheme@mc.lcs.mit.edu Subject: [wand@corwin.ccs.northeastern.edu: ''Update functions'' in Scheme.] In case anyone cares: Date: Wed, 25 May 88 09:56:02 EDT From: Mitchell Wand Date: Mon, 23 May 88 18:01:34 EDT From: gls@think.com Date: Sat, 21 May 88 13:59:33 EDT From: Mitchell Wand Now consider the array assignment Y(A[.]) := 2 . :-) Umm, I will admit my ignorance. Could you explain this joke? --Mitch My notation was obscure, if not erroneous. By A[.] I meant the array A considered as a unary function. So the assignment means to change A so that its fixed point (or at least one of them) is 2. Assuming a principle of least change, that means the same as A[2] := 2. (Do you agree?) I guess so. :-) --Mitch  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 May 88 11:59:06 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 25 May 88 02:04:03 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 25 May 88 03:35:19 GMT From: relph@presto.ig.com (John M. Relph) Organization: IntelliGenetics Inc., Mtn. View, Ca. Subject: Re: HELP ME!!! Message-Id: <6397@ig.ig.com> References: <5813@cup.portal.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <5813@cup.portal.com> JJ@cup.portal.com writes: $Poor College Student needs Your Help!! :-( $ $Hi. I just finished my junior year in college, and now I'm $faced with a major problem. I can't afford to pay for my senior $year. I've tried everything. I can't get any more student loans, $I don't qualify for any more scholarships, and my parents are as $broke as am I. So as you can see, I've got a major problem. But $as far as I can see, there is only one solution, to go forward. $I've come along way, and there is no chance in hell that I'm going $to drop out now! I'm not a quiter, and I'm not going to give up. $ $But here is why I'm telling you all this. I want to ask a favor of every $one out here on the net. If each of you would just send me a one $dollar bill, I will be able to finish college and go on with my life. $I'm sure a dollar is not much to any of you, but just think how it $could change a person's life. I'd really like to encourage all of you $to help me out, I've no other place to go, no other doors to knock $on. I'm counting on all of you to help me! (PLEASE!) $If you would like to help a poor boy out, please send $1 (you can $of course send more if you want!! :-) $ $Jay-Jay's College Fund $PO BOX 5631 $Lincoln, NE 68505 $ $PS. Please don't flame me for posting this to so many newsgroups, $I really am in dire need of help, and if any of you were as desparate $as I am, you just might resort to the same thing I am. Also, please $don't tell me to get a job! I already have one and work over 25 hrs $a week, plus get in all my classes, plus find time to study! So hey, $please consider it! It would really mean a lot to me. Thank you! $ $NOTE: Any extra money I receive will go to a scholarship fund to help $others in the same situation. :-) Jay-Jay's original plea ended as follows: $PS. Please don't flame me for posting this to so many conferences, $I really am in dire need of help, and if any of you were as desparate $as I am, you just might resort to the same thing I am. Someone told him to get a job. Someone also mentioned mail fraud. Jay-Jay has never replied, he just learned how to send to more newsgroups. Please folks, send a message to portal and tell his sysop to hang him up. -- John ---- John M. Relph IntelliGenetics, Inc. Internet: Relph@Bionet-20.ARPA  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 May 88 07:31:37 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 24 May 88 20:35:36 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 24 May 88 00:22:31 GMT From: portal!cup.portal.com!JJ@uunet.uu.net Organization: The Portal System (TM) Subject: HELP ME!!! Message-Id: <5813@cup.portal.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Poor College Student needs Your Help!! :-( Hi. I just finished my junior year in college, and now I'm faced with a major problem. I can't afford to pay for my senior year. I've tried everything. I can't get any more student loans, I don't qualify for any more scholarships, and my parents are as broke as am I. So as you can see, I've got a major problem. But as far as I can see, there is only one solution, to go forward. I've come along way, and there is no chance in hell that I'm going to drop out now! I'm not a quiter, and I'm not going to give up. But here is why I'm telling you all this. I want to ask a favor of every one out here on the net. If each of you would just send me a one dollar bill, I will be able to finish college and go on with my life. I'm sure a dollar is not much to any of you, but just think how it could change a person's life. I'd really like to encourage all of you to help me out, I've no other place to go, no other doors to knock on. I'm counting on all of you to help me! (PLEASE!) If you would like to help a poor boy out, please send $1 (you can of course send more if you want!! :-) Jay-Jay's College Fund PO BOX 5631 Lincoln, NE 68505 PS. Please don't flame me for posting this to so many newsgroups, I really am in dire need of help, and if any of you were as desparate as I am, you just might resort to the same thing I am. Also, please don't tell me to get a job! I already have one and work over 25 hrs a week, plus get in all my classes, plus find time to study! So hey, please consider it! It would really mean a lot to me. Thank you! NOTE: Any extra money I receive will go to a scholarship fund to help others in the same situation. :-)  Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 23 May 88 21:03:25 EDT Received: from bucsf (BUCSF.BU.EDU) by bu-it.BU.EDU (4.0/4.7) id AA24883; Mon, 23 May 88 20:59:20 EDT Return-Path: Received: by bucsf (4.12/4.7) id AA31865; Mon, 23 May 88 20:50:22 edt Date: Mon, 23 May 88 20:50:22 edt From: gjc%bucsf.BU.EDU@bu-it.BU.EDU (George J. Carrette) Message-Id: <8805240050.AA31865@bucsf> To: hes@VALLECITO.SCRC.Symbolics.COM Cc: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET, hes@VALLECITO.SCRC.Symbolics.COM, scheme@mc.lcs.mit.edu Subject: "Same Problem all these years" in Floyd-Hoare Verification When you think about it you'll have to admit that that kind of problem with arrays comes up all the time, even when writing lispmachine microcode. Anyone who has written a decent compiler has had to think about it, in fact, I've never seen a compiler book with a list price over $15.00 which didnt mention it in some respect. Example: The Manual for the Lattice C compiler version 4.0 for the AMIGA mentions it on page 4-16.  Received: from VALLECITO.SCRC.Symbolics.COM (TCP 20024224534) by MC.LCS.MIT.EDU 23 May 88 18:19:41 EDT Received: from MERLIN.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 233764; Mon 23-May-88 18:17:12 EDT Date: Mon, 23 May 88 18:15 EDT From: Howard Shrobe Subject: Floyd-Hoare Verification Harmful?? To: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET, hes@VALLECITO.SCRC.Symbolics.COM cc: scheme@mc.lcs.mit.edu In-Reply-To: <8805211818.AA02999@corwin.CCS.Northeastern.EDU> Message-ID: <19880523221557.1.HES@MERLIN.SCRC.Symbolics.COM> Date: Sat, 21 May 88 14:18:15 EDT From: Mitchell Wand Date: Thu, 19 May 88 10:35:23 EDT From: Mitchell Wand One ought not to say things like: "F(G(C)) := D ought to ensure that F(G(C)) = D afterwards." too blithely. Consider the array assignment: A[A[1]] := 2 in a two element array A, where initially A[1]=A[2]=1 . This sort of thing had program verifiers confused for a good while in the early 70's. Date: Fri, 20 May 88 12:54 EDT From: Howard Shrobe I wrote a paper that was distributed by hand to friends in the late '70s called "Floyd-Hoare Verifiers Considered Harmful" that pointed this ought. It was somewhat tongue in cheek but was based on catching Vaughn Pratt making exactly this kind of mistake. I just moved my office and found copies of the paper. Sussman would remember it well. That seems like an awfully rash conclusion to draw from this kind of bug. It would be more reasonable to say something like "Unrestricted Pointer Manipulation Considered Harmful" or "Hiding Nasty Pointer Manipulation in Innocuous-Looking Array Manipulation Considered Harmful" or... :-) Mitchell Wand College of Computer Science Northeastern University 360 Huntington Avenue #161CN Boston, MA 02115 CSNet: wand@corwin.ccs.northeastern.edu I did say that the paper was tongue in cheek and that I never circulated it, except to friends. The reason for the title at the time was that V. Pratt (who was in the next office to me) claimed to have a complete Floyd-Hoare axiom system for languages that manipulated arrays and pointers and furthermore claimed that it was proven correct with respect to a semantics based on Dynamic Logic. However, both the axiom system and the semantics had a bug similar to the one you pointed out. I chose such an obnoxious title as a way of chiding people about making inflated claims for the power of their techniques. Indeed the problem is that when allows arbitrary pointer and array manipulations one can get aliasing problems. It is very hard to write an axiom set in the Floyd-Hoare tradition that does not screw up for such languages. There are two responses, one is to weaken the language in such a way as to prevent aliasing. The other is to create a different technique stating the language axioms and verifying programs. To date, I haven't seen a proposal in either direction that seems workable. Attempts to constrain pointer manipulation seem to constrain more than you'd like. Anyhow, I'm hardly trying to resurrect my paper. I was just amused to see someone pointing out the same problem after all these years.  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 23 May 88 17:56:58 EDT Received: from [129.10.1.2] by RELAY.CS.NET id cf03483; 23 May 88 16:19 EDT Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu id aa01068; 22 May 88 11:55 EDT Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.4) id AA02999; Sat, 21 May 88 14:18:15 EDT Date: Sat, 21 May 88 14:18:15 EDT From: Mitchell Wand Message-Id: <8805211818.AA02999@corwin.CCS.Northeastern.EDU> To: hes@SCRC-VALLECITO.ARPA Cc: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET, scheme@mc.lcs.mit.edu In-Reply-To: Howard Shrobe's message of Fri, 20 May 88 12:54 EDT <19880520165408.4.HES@MERLIN.SCRC.Symbolics.COM> Subject: Floyd-Hoare Verification Harmful?? Date: Thu, 19 May 88 10:35:23 EDT From: Mitchell Wand One ought not to say things like: "F(G(C)) := D ought to ensure that F(G(C)) = D afterwards." too blithely. Consider the array assignment: A[A[1]] := 2 in a two element array A, where initially A[1]=A[2]=1 . This sort of thing had program verifiers confused for a good while in the early 70's. Date: Fri, 20 May 88 12:54 EDT From: Howard Shrobe I wrote a paper that was distributed by hand to friends in the late '70s called "Floyd-Hoare Verifiers Considered Harmful" that pointed this ought. It was somewhat tongue in cheek but was based on catching Vaughn Pratt making exactly this kind of mistake. I just moved my office and found copies of the paper. Sussman would remember it well. That seems like an awfully rash conclusion to draw from this kind of bug. It would be more reasonable to say something like "Unrestricted Pointer Manipulation Considered Harmful" or "Hiding Nasty Pointer Manipulation in Innocuous-Looking Array Manipulation Considered Harmful" or... :-) Mitchell Wand College of Computer Science Northeastern University 360 Huntington Avenue #161CN Boston, MA 02115 CSNet: wand@corwin.ccs.northeastern.edu  Received: from BLOOM-BEACON.MIT.EDU.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 23 May 88 13:09:20 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 23 May 88 12:58:29 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 17 May 88 02:13:45 GMT From: pitt!darth!tl-vaxa!grover@cadre.dsl.pittsburgh.edu (Vinod Grover) Organization: Tartan Laboratories, Pittsburgh, Pa. Subject: first class variables. Message-Id: <478@tl-vaxa.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu >*** Why didn't the designers of Scheme include locations (~anonymous variables) >as first-class values in the language? *** > >Wouldn't that fit the Scheme philosophy of orthogonality and 'first-class >everything'? After all, locations are part of the denotational semantics of >Scheme, so this wouldn't be much of an extension to Scheme from an abstract >point of view. Such an idea was explored by J.C. Reynolds in a language called GEDANKEN. GEDANKEN had functions, labels (continuations), and references (locations) as first class values. Furthermore, this domain of values is also storable in locations. A formal denotational semantics of GEDANKEN was given by R.D. Tennent. For anyone interested in following up this stuff the references are given below. 1. Reynolds, J.C., [1970], GEDANKEN - a simple typless language based on the principle of completeness and reference concept., Communications of the ACM (13, 5) May 1970. 2. Tennent, R.D., [1976], The Denotational semantics of Programming Languages, Communications of the ACM, (19,8), August 1976. disclaimer: of course, my opinions belong to me. -- Vinod  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 20 May 88 16:03:33 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 8720; Fri, 20 May 88 15:59:38 EDT Received: from UDCVAX.BITNET (WROGERS) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 8717; Fri, 20 May 88 15:59:34 EDT Date: Fri, 20 May 88 15:55 EST From: Subject: Sources to C-Scheme To: scheme@mc.lcs.mit.edu X-Original-To: scheme@mc.lcs.mit.edu, WROGERS How do I get sources to C-Scheme? I'm currently on BITNET so I don't have access to files on USENET or ARPANET. Is there a server on BITNET that has the sources or perhaps an mailing address I can send a 9 track tape? Thanks Will Rogers, WROGERS@UDCVAX.BITNET University of DC  Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 20 May 88 14:43:02 EDT Return-Path: Received: from kali.think.com by Think.COM; Fri, 20 May 88 14:38:44 EDT Received: by kali.think.com; Fri, 20 May 88 14:38:40 EDT Date: Fri, 20 May 88 14:38:40 EDT From: gls@Think.COM Message-Id: <8805201838.AA04646@kali.think.com> To: wand%corwin.ccs.northeastern.edu@relay.cs.net Cc: scheme@mc.lcs.mit.edu In-Reply-To: Mitchell Wand's message of Thu, 19 May 88 10:35:23 EDT <8805191435.AA16901@corwin.CCS.Northeastern.EDU> Subject: ''Update functions'' in Scheme. Date: Thu, 19 May 88 10:35:23 EDT From: Mitchell Wand One ought not to say things like: "F(G(C)) := D ought to ensure that F(G(C)) = D afterwards." too blithely. Consider the array assignment: A[A[1]] := 2 in a two element array A, where initially A[1]=A[2]=1 . This sort of thing had program verifiers confused for a good while in the early 70's. Mitchell Wand College of Computer Science Northeastern University 360 Huntington Avenue #161CN Boston, MA 02115 CSNet: wand@corwin.ccs.northeastern.edu Now consider the array assignment Y(A[.]) := 2 . :-) --Quux  Received: from VALLECITO.SCRC.Symbolics.COM (TCP 20024224534) by MC.LCS.MIT.EDU 20 May 88 12:57:31 EDT Received: from MERLIN.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 233375; Fri 20-May-88 12:55:25 EDT Date: Fri, 20 May 88 12:54 EDT From: Howard Shrobe Subject: Re: ''Update functions'' in Scheme. To: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET, scheme@mc.lcs.mit.edu In-Reply-To: <8805191435.AA16901@corwin.CCS.Northeastern.EDU> Message-ID: <19880520165408.4.HES@MERLIN.SCRC.Symbolics.COM> Date: Thu, 19 May 88 10:35:23 EDT From: Mitchell Wand One ought not to say things like: "F(G(C)) := D ought to ensure that F(G(C)) = D afterwards." too blithely. Consider the array assignment: A[A[1]] := 2 in a two element array A, where initially A[1]=A[2]=1 . This sort of thing had program verifiers confused for a good while in the early 70's. Mitchell Wand College of Computer Science Northeastern University 360 Huntington Avenue #161CN Boston, MA 02115 CSNet: wand@corwin.ccs.northeastern.edu I wrote a paper that was distributed by hand to friends in the late '70s called "Floyd-Hoare Verifiers Considered Harmful" that pointed this ought. It was somewhat tongue in cheek but was based on catching Vaughn Pratt making exactly this kind of mistake. I just moved my office and found copies of the paper. Sussman would remember it well.  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 19 May 88 11:29:50 EDT Received: from [129.10.1.2] by RELAY.CS.NET id ad10314; 19 May 88 10:49 EDT Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu id aa19534; 19 May 88 10:35 EDT Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.4) id AA16901; Thu, 19 May 88 10:35:23 EDT Date: Thu, 19 May 88 10:35:23 EDT From: Mitchell Wand Message-Id: <8805191435.AA16901@corwin.CCS.Northeastern.EDU> To: scheme@mc.lcs.mit.edu Subject: Re: ''Update functions'' in Scheme. One ought not to say things like: "F(G(C)) := D ought to ensure that F(G(C)) = D afterwards." too blithely. Consider the array assignment: A[A[1]] := 2 in a two element array A, where initially A[1]=A[2]=1 . This sort of thing had program verifiers confused for a good while in the early 70's. Mitchell Wand College of Computer Science Northeastern University 360 Huntington Avenue #161CN Boston, MA 02115 CSNet: wand@corwin.ccs.northeastern.edu  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 19 May 88 11:29:05 EDT Received: from [129.10.1.2] by RELAY.CS.NET id ac10314; 19 May 88 10:49 EDT Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu id aa19437; 19 May 88 10:33 EDT Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.4) id AA16884; Thu, 19 May 88 10:33:31 EDT Date: Thu, 19 May 88 10:33:31 EDT From: Mitchell Wand Message-Id: <8805191433.AA16884@corwin.CCS.Northeastern.EDU> To: scheme@mc.lcs.mit.edu Subject: Re: Cells Scheme 84 at Indiana had a notion of cells essentially identical to that proposed by Ostheimer & Nikhil. We had objects called "refs". (REF val) created a ref initially containing val (DEREF ref) got the contents (SET-REF! ref val) changed the contents. Mitchell Wand College of Computer Science Northeastern University 360 Huntington Avenue #161CN Boston, MA 02115 CSNet: wand@corwin.ccs.northeastern.edu  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 18 May 88 22:29:20 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 5751; Wed, 18 May 88 22:25:35 EDT Received: from BOSTONU.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 5750; Wed, 18 May 88 22:25:31 EDT Received: by BOSTONU (Mailer X1.25) id 9113; Wed, 18 May 88 22:26:55 EDT Date: Wed, 18 May 88 22:24:08 EDT From: "Peter Mager" Subject: Boston Sigplan Seminar on Continuation Semantics To: scheme@mc.lcs.mit.edu The following seminar may be of interest to members of the Scheme community in the Boston area: Received: from CUNYVM.BITNET by BOSTONU.BITNET (Mailer X1.25) with BSMTP id 6547; Fri, 06 May 88 16:14:19 EDT Received: from CUNYVM by CUNYVM.BITNET (Mailer X1.25) with BSMTP id 2999; Fri, 06 May 88 16:11:25 EDT Received: from SH.CS.NET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Fri, 06 May 88 16:11:17 EDT Subject: SICPLAN Mtg, 19 May 88. G F Johnson: Partial Continuations and Stores in a Programming Environment From: SICPLAN To: Sicplan-list@SH.CS.NET Cc: mooers@SH.CS.NET, met9i7n%BOSTONU.BITNET@SH.CS.NET Date: Fri, 06 May 88 15:58:18 -0400 Sender: mooers@SH.CS.NET ACM GREATER BOSTON CHAPTER SICPLAN Thursday, May 19, 1988 8 P.M. Intermetrics Atrium 725 Concord Ave., Cambridge Partial Continuations and Stores in a Programming Environment Gregory F. Johnson Computer Science Department University of Maryland ACM GREATER BOSTON CHAPTER SICPLAN It is becoming widely recognized that the quality of a programming environment has a significant impact on the productivity of programmers. The discipline of creating a formal language semantics has had a major positive influence on the design of programming languages, and we hypothesize that a similar formal approach will result in better programming environments. To test this hypothesis, we have initiated the GL research project, in which a new (small) programming language, an environment, and a denotational semantics are being designed together. In particular, both partial continuations (functions representing part of the future execution of a partially completed program execution) and stores (finite functions representing the content of a computer's memory) can be obtained from the programming environment during execution of a program. These objects can then be invoked and manipulated in a variety of ways, allowing the user a great deal of flexibility and room for interactive experimentation in arriving at understanding of the behavior of programs. These facilities give rise to a new style of interaction with a programming environment that appears to be promising. ACM GREATER BOSTON CHAPTER SICPLAN Dear Colleague, Our speaker for May has been actively investigating continuation passing semantics and the use of continuations in programming environments for a number of years. He is currently on the faculty of the University of Maryland. Some of the material in this talk was presented in papers at the Sigplan'87 Interpreters Conference and at POPL'88. Our February talk by Robert Schwartz and John Yates showed us a new and promising approach to compiler code generation based on extending table driven pattern selection through the use of vector-valued predicates and dynamic programming techniques. The resulting partial ordering of possible instruction sequences allows the code generation algorithm to achieve quasi-optimal (i.e. optimal with respect to the defined patterns and evaluation criteria) code sequences in linear time. The presentation led to some interesting discusions among the 100 or so people who attended. We will be meeting for dinner as usual at Joyce Chen's restaurant, 390 Rindge Ave., Cambridge at 6:00 p.m. before the meeting. If you wish to come, please call Karen Kelly or "Sigplan dinner" at Intermetrics (661-1840) as early as possible so we can make the appropriate dinner reservation. Peter Mager chairperson, Boston SICPLAN  Received: from clover.ucdavis.edu (TCP 20036034401) by MC.LCS.MIT.EDU 17 May 88 23:24:24 EDT Received: by clover.ucdavis.edu (5.51/4.7) id AA03350; Tue, 17 May 88 19:24:23 PDT Received: by iris.ucdavis.edu (5.51/3.14) id AA24354; Tue, 17 May 88 19:25:15 PDT Message-Id: <8805180225.AA24354@iris.ucdavis.edu> Qotw: If you can't do it with an editor, I don't want to do it. Pointers: (916) 752-7324/3168 To: scheme@mc.lcs.mit.edu Subject: scheme on AIX Date: Tue, 17 May 88 19:25:13 PDT From: Phil Windley Does anyone have any version of Scheme that runs on an IBM RT under AIX (IBM's SysV derivative)? Phil Windley | windley@iris.ucdavis.edu Robotics Research Lab | ucbvax!ucdavis!iris!windley University of California, Davis |  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 17 May 88 18:06:51 EDT Received: by iuvax.cs.indiana.edu; id AA00423; Tue, 17 May 88 17:04:27 EST Received: by iuvax.cs.indiana.edu (5.54/1.5) Date: Tue, 17 May 88 17:04:27 EST From: Chris Haynes To: scheme@mc.lcs.mit.edu, rrrs-authors@mc.lcs.mit.edu Subject: Scheme standardization meeting The proposal to form an IEEE Working Group on Scheme (let's call it the "working group" from now on) mentioned in my last note has been approved by the Microprocessor Standards Committee (MSC). There are a few more administrative steps before it is completely official, but no difficulty is expected. The standardization process has begun; wish us luck! The first meeting of the working group will be on Wednesday, July 27th, 1988, from 1:00 pm to 5:00 pm (or later if really necessary) following the Lisp and Functional Programming Conference at Snowbird, Utah. The meeting room will be posted at the conference facility. The agenda for the first working group meeting should at least include discussion of the following items: - introductions and brief remarks about the standards process - scope and purpose of standardization effort - expected time schedule for standard development - time and place of next meeting - netmail and other means of communicating between meetings - proposed ways for the standard to differ from the Revised^3 Report. The last point is clearly the most important and should take most of the time. Specific proposals should be stated in advance and included in the agenda if possible. Very briefly, my current expectation (reflecting the wishes of the study group mentioned in my last note) is that the working group will serve to "filter" the work of the Revised^n Report authors, removing features deemed too experimental for standardization and adding nothing of substance to the language. The following meeting will be in about six months, at a place as yet unknown. A "trial standard" should be completed in about two years, with a full standard perhaps two years after that. Let's use the general Scheme news group (now comp.lang.scheme) for discussion of the agenda and related matters prior to the meeting. At the meeting we may agree to form another news group for subsequent communication. Your suggestions on agenda items and candidates for filtering are welcome. -- Chris Haynes  Received: from BLOOM-BEACON.MIT.EDU.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 17 May 88 14:07:12 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 17 May 88 13:57:59 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 17 May 88 13:54:47 GMT From: ubvax!smegma!mdg@ames.arpa (Marc de Groot) Organization: A moving point in 4-space Subject: Re: MIT Scheme for Unix Message-Id: <398@smegma.UUCP> References: <128@bnr-di.UUCP>, <15180@wlbr.EATON.COM> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <15180@wlbr.EATON.COM> mh@wlbr.UUCP (0000-Mike Hoegeman) writes: >In article <128@bnr-di.UUCP> borynec@bnr-di.UUCP (James Borynec) writes: >> >>Could some kind soul mail me a copy of MIT's scheme that would >>run on UNIX SysV (in particular microport's SysV/AT). If you >>think that it would be too big to mail but are willing to help >>in some other way (establishing direct phone connection or >>via floppynet) please contact me. >I think a lot of people (myself included) are interested in how to obtain >scheme. If you know how/where to get it could you please post that information? >Thanks. Ditto. Please post to the net when you get a copy. Thanks. -Marc -- Marc de Groot (KG6KF) UUCP: {hplabs, sun, ucbvax}!amdcad!uport!smegma!mdg AMATEUR PACKET RADIO: KG6KF @ KB6IRS "Look, he's mounting a tape!" "Quick, throw cold water on him!"  Received: from IBM.COM (TCP 30001235007) by MC.LCS.MIT.EDU 17 May 88 09:09:12 EDT Date: 17 May 88 08:39:55 EDT From: Cyril Alberga To: scheme@mc.lcs.mit.edu Message-Id: <051788.083956.alberga@ibm.com> Subject: Uses of SET I am a unashamed (albeit sparing) user of SET in Lisp. The majority of uses are in functions which define, redefine or embed (? our local term for redefining a function in terms of it's previous definition) functions. (Note that our dialect of Lisp does NOT have function-value cells and assignment is used for function definition.) These function (NOT macros) accept lists of names (identifiers) and definitions, process the definitions in various ways, then use SET to install the result. This assignment is expected to modify the dynamic environment, not the global environment(s) exclusively. A second use of set is possibly more interesting. I have a function which accepts an a-list of properties and uses it to initialize a collection of dynamic variables. The a-list contains only those name/value pairs which are to differ from various defaults. The code used is: (Note that we use a-list format for property lists, not flat lists, hence GET works on a-lists.) (MAPC (LAMBDA (PROP VAR DEFLT) (SET VAR (COND ( (GET OPTIONLIST PROP) ) ( 'T DEFLT ) )) ) '(:MACRO-APP-SD :OP-RECOGNITION-SD :MESSAGE :LISTING :FILE :NOLINK :SOURCELIST :TRANSLIST :LAPLIST :BPILIST :NOMERGE :OPTIMIZE :LISPLIB-ACTION-CLASS :NOSTOP :QUIET :SILENT :DELAY-COMPILATION) '(MACRO-APP-SD OP-RECOGNITION-SD MESSAGESTREAM LISTSTREAM FILESTREAM NOLINK SOURCELIST TRANSLIST LAPLIST BPILIST NOMERGE OPTIMIZE MEMBERCLASS NOSTOP QUIET SILENT DELAY-COMPILATION) (LIST S,MACRO-APP-SD S,OP-RECOGNITION-SD CUROUTSTREAM CUROUTSTREAM () () () () () () () 4 0 () () () ())) Since this is not a common operation it was felt that the simplicity of maintaining parallel lists of property-names/variables/default values was better than writing out seventeen (currently) SETQs with conditional arguments and calls to GET. Subject: new question; macro definitions I am a new user of PCScheme (sp?), and have just ciphered out the way macros are hidden. I find it odd that macros have only global definitions, i.e. on property lists. This seems most un-Scheme-like. In our Lisp we use a distinguished form (MLAMBDA ...) for macro definitions, and use the same definition methods as we use for functions. Of course this leads to other complexities and confusions. Could anyone direct me to commentary on the relative merits of various macro definition schemes (pun intended)? Thank you, Cyril N. Alberga  Received: from THEORY.LCS.MIT.EDU (TCP 2206400134) by MC.LCS.MIT.EDU 16 May 88 19:43:37 EDT Received: from TOUCAN.LCS.MIT.EDU by THEORY.LCS.MIT.EDU (4.12/4.7); Mon, 16 May 88 19:39:53 ast Received: by TOUCAN.LCS.MIT.EDU (4.12/4.7); Mon, 16 May 88 19:39:50 ast Date: Mon, 16 May 88 19:39:50 ast From: Bard Bloom Message-Id: <8805162339.AA03068@TOUCAN.LCS.MIT.EDU> To: titan!dorai@rice.edu Cc: scheme@mc.lcs.mit.edu In-Reply-To: (Dorai Sitaram's message of 10 May 88 15:41:48 GMT <683@thalia.rice.edu> Subject: Re : set in Scheme > Here's my invaluable ;-) comment about _set_ in Scheme. As it is fairly easy > to build up a case for loss of program readability with the addition of _set_ > (as opposed to _set!_), we should perhaps be pleased that it is probably > impossible (with macros, extend-syntax, what-not) to define _set_ in Scheme. T has something more or less like the LISP SET, but it requires you to specify the environment you're modifying: (*VALUE LOCALE IDENTIFIER) gives the value of IDENTIFIER in LOCALE (locales seem to be more or less synonymous with environments) (SET (*VALUE LOCALE IDENTIFIER) NEW-VALUE) sets that value. To avoid and engender confusion, I remark that T's SET is roughly Common Lisp's SETF. How do people feel about this? It still allows some extremely confusing things. Who has used Lisp's SET, and what has it been good for? -- Bard the (LAMBDA (X) GARGOYLE)  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 16 May 88 16:19:13 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Mon, 16 May 88 16:09:46 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 10 May 88 15:41:48 GMT From: titan!dorai@rice.edu (Dorai Sitaram) Organization: Rice University, Houston Subject: Re: Re : set in Scheme Message-Id: <683@thalia.rice.edu> References: <12073@shemp.CS.UCLA.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Here's my invaluable ;-) comment about _set_ in Scheme. As it is fairly easy to build up a case for loss of program readability with the addition of _set_ (as opposed to _set!_), we should perhaps be pleased that it is probably impossible (with macros, extend-syntax, what-not) to define _set_ in Scheme. The most "correct" version of _set_ in terms of _set!_ given on the net, (herein transliterated to extend-syntax) is probably (extend-syntax (set) [(set x y) (eval (list 'set! x (quote y)))]). However, Scheme does not offer 'eval' to the user. The most it does is offer a *global* eval, which ain't the same thing. So, (define x 0) ==> x (define y 'x) ==> y (let ([x 1]) (let ([y 'x]) (set y 2) x)) ==> 1 {instead of 2} x ==> 2 {instead of 0} Continuing { with global x = 2, y = x } (define z 3) ==> z (let ([z 4]) (set y z) x) ==> 3 {instead of 4} The second problem can be appeased by evaluating the settend (to coin a word) beforehand as in, (extend-syntax (set) [(set x y) (begin (set! |weird-identifier| y) (eval (list 'set! x (quote |weird-identifier|))))]) {|weird-identifier| HAS to be a global variable, because of the globalness of eval.} But the first problem remains. A modified version of the second problem can occur if there are _set_'s inside the settee (to coin a not-so-new word), as in (set (set ) ) Any amount of tweaking the extend-syntax for set, seems destined to lead nowhere. That, as they (and Magnum) say, is "the hell of it". --dorai  Received: from F.GP.CS.CMU.EDU (TCP 20000575244) by MC.LCS.MIT.EDU 16 May 88 15:51:40 EDT Date: 16 May 1988 15:20-EDT From: Barak.Pearlmutter@F.GP.CS.CMU.EDU To: Paul Robertson Cc: scheme@mc.lcs.mit.edu Subject: Re: cells Message-Id: From: Barak Pearlmutter They [locatives] do let vectors and structures (including environments) get gc'ed when all that's left is a pointer to something in their innards, which is nice, From: Paul Robertson It is? This issue is like to the question of whether to do "tail recursion optimization." As in that case, it seems to me that the burden of proof is on you, since ceteris paribus it is better that garbage be reclaimed. In response to the "debugging ease" argument which the above analogy suggests you will use, it is simple enough to arrange things so that one can get to the object containing the cell a locative points to if the object has not been deallocated, thus complicating debugging only when the containing object has actually been freed. Do you have some coherent argument in mind, or are you just loyal to the current Symbolics technology? --Barak.  Received: from MEAD.SCRC.Symbolics.COM (TCP 20024224752) by MC.LCS.MIT.EDU 16 May 88 13:40:04 EDT Received: from JAYHAWK.SCRC.Symbolics.COM by MEAD.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 158318; Mon 16-May-88 12:21:48 EDT Date: Mon, 16 May 88 12:21 EDT From: Paul Robertson Subject: Re: cells To: Barak.Pearlmutter@F.GP.CS.CMU.EDU, JAR@AI.AI.MIT.EDU cc: scheme@mc.lcs.mit.edu In-Reply-To: Message-ID: <880516122117.8.PROBERTSON@JAYHAWK.SCRC.Symbolics.COM> They do let vectors and structures (including environments) get gc'ed when all that's left is a pointer to something in their innards, which is nice, It is?  Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 16 May 88 10:43:28 EDT Received: by kleph.AI.MIT.EDU; Mon, 16 May 88 10:44:03 edt Date: Mon, 16 May 88 10:44:03 edt From: cph@kleph.AI.MIT.EDU (Chris Hanson) Message-Id: <8805161444.AA01205@kleph> To: voder!wlbr!mh@bloom-beacon.MIT.EDU Cc: scheme@mc.lcs.mit.edu In-Reply-To: (Mike Hoegeman's message of 15 May 88 18:01:05 GMT <15180@wlbr.EATON.COM> Subject: MIT Scheme for Unix Reply-To: cph@zurich.ai.mit.edu Date: 15 May 88 18:01:05 GMT From: voder!wlbr!mh@bloom-beacon.MIT.EDU (Mike Hoegeman) I think a lot of people (myself included) are interested in how to obtain scheme. If you know how/where to get it could you please post that information? MIT CScheme can be obtained in the following ways: * Internet FTP: Telnet to "prep.ai.mit.edu" as user "scheme", password "scheme". Use the `ftp' program to obtain either the file "dist.tar" or "dist.tar.Z" (a compressed version). The directory "dist.split" contains the file "dist.tar.Z" split up into 250 kbyte pieces. Alternatively, use anonymous ftp to "zurich.ai.mit.edu" (user "anonymous", any password) and read the file "pub/scheme/README" for more directions. * Magtape: The cost of a distribution tape is $200 to cover our copying and administrative expenses. Send a check for $200 payable to MIT to: Scheme Distribution MIT Artificial Intelligence Laboratory 545 Technology Square Cambridge, Ma. 02139 Please specify the tape format: * Unix tar format, 9-track magtape, 1600 bpi * VMS backup format, 9-track magtape, 1600 bpi * Unix tar format, HP CS/80 cartridge tape  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 May 88 20:48:19 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 15 May 88 20:29:40 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 15 May 88 18:01:05 GMT From: voder!wlbr!mh@bloom-beacon.MIT.EDU (Mike Hoegeman) Organization: Eaton IMS, Westlake Village, CA Subject: Re: MIT Scheme for Unix Message-Id: <15180@wlbr.EATON.COM> References: <128@bnr-di.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <128@bnr-di.UUCP> borynec@bnr-di.UUCP (James Borynec) writes: > >Could some kind soul mail me a copy of MIT's scheme that would >run on UNIX SysV (in particular microport's SysV/AT). If you >think that it would be too big to mail but are willing to help >in some other way (establishing direct phone connection or >via floppynet) please contact me. I think a lot of people (myself included) are interested in how to obtain scheme. If you know how/where to get it could you please post that information? Thanks. -mike  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 May 88 02:48:10 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 15 May 88 02:43:55 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 13 May 88 16:15:06 GMT From: mnetor!utzoo!utgpu!bnr-vpa!bnr-di!borynec@uunet.uu.net (James Borynec) Organization: DI, Bell-Northern Research, Ottawa, Ont. Subject: MIT Scheme for Unix Message-Id: <128@bnr-di.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Could some kind soul mail me a copy of MIT's scheme that would run on UNIX SysV (in particular microport's SysV/AT). If you think that it would be too big to mail but are willing to help in some other way (establishing direct phone connection or via floppynet) please contact me. James Borynec utzoo!bnr-vpa!bnr-di!borynec borynec@bnr.bitnet (613) 765 4856 22 Westcliffe Rd Nepean, Ontario K2H 7X4  Received: from labrea.stanford.edu (TCP 4402000057) by MC.LCS.MIT.EDU 13 May 88 17:14:09 EDT Received: by labrea.stanford.edu; Fri, 13 May 88 13:17:00 PDT Received: from bhopal.lucid.com by edsel id AA12859g; Fri, 13 May 88 12:14:28 PDT Received: by bhopal id AA28001g; Fri, 13 May 88 12:17:38 PDT Date: Fri, 13 May 88 12:17:38 PDT From: Jim McDonald Message-Id: <8805131917.AA28001@bhopal.lucid.com> To: gls@think.com Cc: NIKHIL@xx.lcs.mit.edu, scheme@mc.lcs.mit.edu In-Reply-To: gls@Think.COM's message of Fri, 13 May 88 12:00:40 EDT <8805131600.AA15096@kali.think.com> Subject: Cells Guy, is that a trick bet? The CDC 6500 had a lisp (UTEXAS?) with CAR, CDR, and CZR slots for the three 18-bit addresses in their 60-bit words. However, if I remember correctly, you would technically win your bet, since there still wasn't a three-slot cons. You had to do something like: (SETQ CELL (CONS A B)) (RPLACZ CELL C) jlm  Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 13 May 88 17:12:57 EDT Return-Path: Received: from kali.think.com by Think.COM; Fri, 13 May 88 17:08:58 EDT Received: by kali.think.com; Fri, 13 May 88 17:08:51 EDT Date: Fri, 13 May 88 17:08:51 EDT From: gls@Think.COM Message-Id: <8805132108.AA15361@kali.think.com> To: edsel!jlm@labrea.stanford.edu Cc: gls@Think.COM, NIKHIL@xx.lcs.mit.edu, scheme@mc.lcs.mit.edu In-Reply-To: Jim McDonald's message of Fri, 13 May 88 12:17:38 PDT <8805131917.AA28001@bhopal.lucid.com> Subject: Cells Date: Fri, 13 May 88 12:17:38 PDT From: Jim McDonald Guy, is that a trick bet? No, just goofing around. The CDC 6500 had a lisp (UTEXAS?) with CAR, CDR, and CZR slots for the three 18-bit addresses in their 60-bit words. However, if I remember correctly, you would technically win your bet, since there still wasn't a three-slot cons. You had to do something like: (SETQ CELL (CONS A B)) (RPLACZ CELL C) jlm One of the earliest Lisp systems, when it was still just a set of Fortran subroutines, had a four-slot cons. "Therefore, ... car ... and its analogs cdr, cpr, and ctr were defined. At some point a cons(a, d, p, t) was defined, but it was regarded as a subroutine and not as a function with a value." --John McCarthy, "History of Lisp" in Wexelblat, Richard L. (ed.) History of Programming Languages. Academic Press, New York (1981), p. 175. --Guy  Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 13 May 88 14:11:14 EDT Received: by GENEVA.AI.MIT.EDU; Fri, 13 May 88 14:10:36 edt Date: Fri, 13 May 88 14:10:36 edt From: jrm@GENEVA.AI.MIT.EDU (Joe Marshall) Message-Id: <8805131810.AA22242@geneva> To: gls@Think.COM Cc: NIKHIL@xx.lcs.mit.edu, scheme@mc.lcs.mit.edu In-Reply-To: gls@Think.COM's message of Fri, 13 May 88 12:00:40 EDT <8805131600.AA15096@kali.think.com> Subject: Cells I've heard a rumor (dismissed as bunk) A three-slot CONS is called a HUNK.  Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 13 May 88 13:48:29 EDT Return-Path: Received: from kali.think.com by Think.COM; Fri, 13 May 88 12:00:46 EDT Received: by kali.think.com; Fri, 13 May 88 12:00:40 EDT Date: Fri, 13 May 88 12:00:40 EDT From: gls@Think.COM Message-Id: <8805131600.AA15096@kali.think.com> To: NIKHIL@xx.lcs.mit.edu Cc: scheme@mc.lcs.mit.edu In-Reply-To: Rishiyur S. Nikhil's message of Thu 12 May 88 20:26:02-EDT <12397843074.44.NIKHIL@XX.LCS.MIT.EDU> Subject: Cells Date: Thu 12 May 88 20:26:02-EDT From: Rishiyur S. Nikhil ... Now, VAR is nothing more than a ``one-slot CONS''. GET-VAR is the one-slot version of CAR/CDR, and SET-VAR! is the one-slot version of SET-CAR!/SET-CDR!. So, why does it make the language so different/unclean? ... The one-slot CONS Is just a cell. The two-slot CONS Makes lists as well. And I will bet A coin of bronze There isn't any Three-slot CONS. --The Great Quux (apologies to Ogden Nash)  Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 13 May 88 11:17:55 EDT Return-Path: Received: from kali.think.com by Think.COM; Fri, 13 May 88 11:13:56 EDT Received: by kali.think.com; Fri, 13 May 88 11:13:52 EDT Date: Fri, 13 May 88 11:13:52 EDT From: gls@Think.COM Message-Id: <8805131513.AA15052@kali.think.com> To: JAR@ai.ai.mit.edu Cc: umb!gerald%husc6.harvard.edu@xx.lcs.mit.edu, scheme@mc.lcs.mit.edu In-Reply-To: Jonathan A Rees's message of Wed, 11 May 88 12:36:21 EDT <375517.880511.JAR@AI.AI.MIT.EDU> Subject: cells Date: Wed, 11 May 88 12:36:21 EDT From: Jonathan A Rees Date: 10 May 88 02:16:56 GMT From: umb!gerald@husc6.harvard.edu (Gerald Ostheimer) *** Why didn't the designers of Scheme include locations (~anonymous variables) as first-class values in the language? *** A variable would then be an identifier bound to a location, and we would have true constants as well, by binding identifiers to values that are not locations. All identifier bindings would then be irreversible, only locations could be updated (thus indirectly updating identifiers bound to them). I think Steele considers this possibility in one of the notes in the Rabbit tech report. If so, I must yield credit to intellectual influence from Hewitt's PLASMA system and Wegbreit's EL1 (ECL) language and system at Harvard. In EL1 everything was consistently an lvalue. In effect, you were always one level of pointer indirection removed from the way you would do it in Lisp. To pass a cons cell to a subroutine, the argument register would contain the address of a location containing the pointer to the two-word cell. Taking the car of this cons cell resulted in the address of the cell (i.e., the address of the memory word containing the CAR pointer), and taking the cdr resulted in the address of the cell plus 1. PDP-10 byte pointers made all this fairly convenient for objects smaller than one word. --Guy  Received: from zurich (TCP 2206400260) by MC.LCS.MIT.EDU 13 May 88 10:29:24 EDT Received: from MITVMA.MIT.EDU (mitvma.mit.edu) by ZURICH.AI.MIT.EDU; Fri, 13 May 88 10:27:50 edt Message-Id: <8805131427.AA26893@zurich> Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 8136; Fri, 13 May 88 10:25:59 EDT Received: from HNYKUN52.BITNET (EDH) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 8135; Fri, 13 May 88 10:25:56 EDT Date: Fri, 13 May 88 13:25 N From: Subject: readable code to SET recordfields To: SCHEME@ZURICH.AI.MIT.EDU X-Original-To: SCHEME@ZURICH.AI.MIT.EDU, EDH To: scheme@zurich.ai.mit.edu Cc: Subject: readable code to SET recordfields From: Edward Hoenkamp (Arpa: EDH%HNYKUN52.BITNET@CUNYVM.CUNY.EDU) Date: Fri May 13 13:20:13 1988 --- ;;; What about this simple way of constructing and selecting records ;;; that will allow the fields to be globally 'set' even if the ;;; record is referred to by a variable. ;;; Edward Hoenkamp. (define (make-bar struct) (lambda (select . new-value) (if (null? (car new-value)) ; if no new-value passed (car (select struct)) ; select and leave as is (set-car! (select struct) (caar new-value))))) ;;; choose appropriate selector names (define (first:of name . new) (name (lambda(x) x) new)) (define (second:of name . new) (name cdr new)) (define (third:of name . new) (name cddr new)) ;;; etcetera. ;;; Example ; >>> (define foo (make-bar '(a b c))) ; foo ; >>> (first:of foo) ; a ; >>> (second:of foo) ; b ; >>> (define baz '(d e)) ; baz ; >>> ((lambda (x) ; (second:of x baz)) foo) ; ((d e) c) ; >>> (third:of foo) ; c ; >>> (second:of foo) ; (d e) ; ;;; Add your own syntactic sugar for macro expansion ;;; (and/or use vectors instead of lists).  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 12 May 88 23:47:25 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Thu, 12 May 88 23:32:45 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 12 May 88 12:44:19 GMT From: otter!kers@hplabs.hp.com (Christopher Dollin) Organization: Hewlett-Packard Laboratories, Bristol, UK. Subject: Updaters in Pop (reply to query) Message-Id: <1510012@otter.hple.hp.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I have seen lots of discussion in the Scheme mailing list about "setters", including this one from Jonathan A Rees (which gives just about enough context): | Someone, I don't remember who, pointed out that the "setter" idea (i.e. | a function that maps an access procedure (not its name) to a | corresponding mutator) is not original with T, but was in the language | POP2. Does anyone know of a reference for this? Does anyone know how | this was implemented (global table as in Lyn's message, or local | association as in T)? I don't know how it was done in Pop2, but I *do* know how it is done in Pop11, its indirect descendant (alive and kicking in Sussex University's Poplog and Cognitive Applications Ltd AlphaPop). Every procedure has a component called its _updater_, which is either a procedure or the object _false_. When a procedure call appears as the target of an assignment, this is treated as a call to its updater. Thus the command E -> f( x ) (Pop assignments run left-to-right) is treated as updater( f )( E, x ) The updater component is an actual field of the procedure record, although it could of course be implemented as a property (hash table) mapping procedures to their updaters. This however would make access to the updater rather expensive. _updater_ has an updater with the obvious effect, allowing the user to define the update effect of her own procedures; the language has syntax to facilitate this. Note that is the *procedure* that has the updater, not its name, so the updaters of procedures passed as parameters are accessible in the same way as procedures defined at the outermost level (well, of course they would. Wouldn't they?). I would be happy to answer any queries this incomplete account raises in email. Regards, Kers. | If anything anyone lacks, they'll find it all ready in stacks.  Received: from THEORY.LCS.MIT.EDU (TCP 2206400134) by MC.LCS.MIT.EDU 12 May 88 21:09:58 EDT Received: from TOUCAN.LCS.MIT.EDU by THEORY.LCS.MIT.EDU (4.12/4.7); Thu, 12 May 88 21:07:38 ast Received: by TOUCAN.LCS.MIT.EDU (4.12/4.7); Thu, 12 May 88 21:07:29 ast Date: Thu, 12 May 88 21:07:29 ast From: Bard Bloom Message-Id: <8805130107.AA03042@TOUCAN.LCS.MIT.EDU> To: NIKHIL@XX.LCS.MIT.EDU Cc: scheme@MC.LCS.MIT.EDU In-Reply-To: Rishiyur S. Nikhil's message of Thu 12 May 88 20:26:02-EDT <12397843074.44.NIKHIL@XX.LCS.MIT.EDU> Subject: Cells > I don't have his original message, but his proposal was something like > this (ala ML): The expression ``(VAR E1)'' would allocate a cell > containing the value of E1, and return a reference to it. If X is > bound to such a reference, then ``(GET-VAR X)'' returns the value in the cell, > and ``(SET-VAR! X E2)'' replaces the value in the cell with the value of E2. > > Now, VAR is nothing more than a ``one-slot CONS''. GET-VAR is the > one-slot version of CAR/CDR, and SET-VAR! is the one-slot version of > SET-CAR!/SET-CDR!. So, why does it make the language so > different/unclean? I withdraw most of my insult (which was "unclean"). It doesn't make the language unclean. It's actually quite nice. But I don't withdraw all of it. My point was that, in general (with most abstract datatypes), stuffing a value into a location is the wrong thing to do, and typically will break the abstraction. So, I want SETF in the language, as the way to set an arbitrary mutable object. There is a difference in connotation, if not denotation, between (SETF (VAR X) Y) and (SET-VAR! X Y): the SETF emphasizes the abstraction, the SET-VAR! emphasizes the pointers. Once we have SETF, I don't see any particular point to SET-VAR!; hence my opinion that the language would be cleaner without it. For that matter, Nihkil's "one-slot CONS" is a nice little mutable abstract data type, and a good one with an efficient implementation. Just the thing for building a lot of the abstract data types with mutators, I imagine. -- Bard the (LAMBDA (X) GARGOYLE)  Received: from NSS.Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 12 May 88 20:59:25 EDT Received: from cvaxa.sussex.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa00777; 13 May 88 1:52 BST Received: from csuna (csuna.ARPA) by cvaxa.sussex.ac.uk; Fri, 13 May 88 01:37:29 bst From: Aaron Sloman Date: Fri, 13 May 88 01:37:16 BST Message-Id: <21107.8805130037@csuna.cvaxa.sussex.ac.uk> To: jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK Subject: updaters in POP-11/POP-2 Cc: JAR@ai.ai.mit.edu, scheme@mc.lcs.mit.edu, rhr%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK Jeff, Thanks for sending me a copy of your reply to the enquiry about updaters. I had not seen the original. Which news group was it in? Just a few comments, some of which Robert may already have made direct to you. (a) There is at present no complete published specification of POP-11 (the most recent descendent of POP-2) apart from the online "REF" files distributed with Poplog. We plan to publish a proper reference manual, but other work keeps getting in the way. The two books you referred to both describe subsets of POP-11. The one by Laventhol (deliberately) describes a smaller subset corresponding to the version for the Mac known as Alphapop, reviewed in Byte May 1988. e.g. the book does not include lexical variables. Alphapop is distributed with a complete specification of Alphapop. In the USA it is distributed by Prof Robin Popplestone, Dept of computer science univ. of Amherst, and he can answer just about any question about Pop-2 or Pop-11, being one of the main inventors of the original language. (pop@cs.umass.edu) (b) adding key fields You say. >Note that the key contains entries only for certain built-in >operations. You cannot, as far as I know, define new operations >of this sort. Right. Keys as such are not extendable. However, Pop-11 also includes "properties", i.e. hash tables, and if you wished to define the notion of the class_something associated with each key, you'd make class_something a property, set up the associations, then the syntax for accessing or changing the class_something of a key would be the same as for the built in class_ procedures, e.g. 'funny string' -> class_something(datakey(1)) would do it for the integer key. (Note that properties are treated as a special type of function, and they therefore have updaters.) The main limitation of Pop-11 keys is not the lack of extendability but: 1. There is no notion of a sub-class inheriting features from a super-class (though there are OOP libraries) 2. It is hard to associate a key with a derived data type. E.g. there is a key for pairs, but no notion of a key for lists, built from pairs. Thus we can't give lists a different class_print from pairs (e.g.pairs whose backs are neither pairs nor nil). (c) A minor correction. You say >If you do > set_whatever -> updater(whatever); > then > x -> whatever(y). > will put x in the whatever part of y. This is misleading. There need not be any notion of "the whatever part of y". Strictly the only way to understand x -> whatever(y) is as follows: put x on the stack, put y on the stack, call the updater of whatever The updater of whatever can be any arbitrary procedure. It need not put x (or anything else) anywhere, although putting x somewhere associated with y is the NORMAL use of the updater mechanism. (d) Another minor correction You give the following incorrect Pop-11 syntax for defining updaters: define updater whatever(newval, object) ... enddefine; The actual keyword is not "updater" but "updaterof" This syntax was not available in Pop2 - updaters had to be assigned explicitly, using the updater of updater. (e) A point of clarification >You can do the 'define updater' even if the accessing procedure >has not yet been defined, which may put some interesting constraints >on the implementation, but I do not know what the actual >implementation is. It's simple. If "whatever" has not been defined, and you do define updaterof whatever; ... enddefine; Then a default un-executable procedure is created for whatever, and the defined updater is associated with it. So you can do x -> whatever(y) even though the procedure whatever has not been defined, only its updater. If you try running the procedure whatever(999); you'll get an error message whatever(x); ;;; MISHAP - ONLY UPDATER DEFINED ;;; INVOLVING: This could be (and probably is) achieved by making the default procedure the Pop-11 closure: mishap(%0,'ONLY UPDATER DEFINED'%); i.e. the error procedure mishap "partially applied" to the number 0 (no error objects) and the string defining the error. A new closure would be created for each undefined procedure. Since in Pop-11 a closure is just a type of procedure (as is an array or a property), it can be given an updater. If you later define whatever, itself, then its previously defined updater is transferred to the new version. This is because any time you redefine a procedure its old updater (if any) is transferred to the new procedure so that you don't have to do it explicitly. Not all users appreciate that the convenience of updaters has a slight speed penalty compared with having a separate "set" function: an extra indirection is needed to get the updater. (This is optimised away if the updater is one defined in the system or declared as a constant procedure by the user.) Cheers Aaron  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 12 May 88 20:29:13 EDT Date: Thu 12 May 88 20:26:02-EDT From: Rishiyur S. Nikhil Subject: Cells To: scheme@MC.LCS.MIT.EDU Message-ID: <12397843074.44.NIKHIL@XX.LCS.MIT.EDU> From: umb!gerald@husc6.harvard.edu (Gerald Ostheimer) *** Why didn't the designers of Scheme include locations (~anonymous variables) as first-class values in the language? *** From: Jonathan A Rees Plenty, including the designers of Algol 68, PLASMA, and ML. If you did this to Scheme I think you'd have quite a different language, different enough that it would require significant changes to implementation strategies. From: Bard Bloom ... There's no choice but to use mutator procedures. Since we have to use them anyways, why not be clean and not bother with locations? Do you really want to imitate BLISS and require explicit dereferencing for every mutable variable? I don't understand why the introduction of locations in the sense that Gerald Ostheimer suggested would make Scheme such a different or unclean language. I don't have his original message, but his proposal was something like this (ala ML): The expression ``(VAR E1)'' would allocate a cell containing the value of E1, and return a reference to it. If X is bound to such a reference, then ``(GET-VAR X)'' returns the value in the cell, and ``(SET-VAR! X E2)'' replaces the value in the cell with the value of E2. Now, VAR is nothing more than a ``one-slot CONS''. GET-VAR is the one-slot version of CAR/CDR, and SET-VAR! is the one-slot version of SET-CAR!/SET-CDR!. So, why does it make the language so different/unclean? Such cells normally must be heap-allocated, so this may seem like extra cost. But this is not obvious: A) Lifetime analysis could move them to stack frames, and B) in many situations where one currently must use a frame-variable in the heap, the one-slot cell may be a cheaper alternative. Nikhil (I agree that arbitrary locatives, e.g. pointers to the middle of cons-cells, would make things very unclean, but I don't think that was what Gerald O. was proposing). -------  Received: from NSS.Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 12 May 88 18:41:57 EDT Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa02290; 12 May 88 23:22 BST From: Jeff Dalton Date: Thu, 12 May 88 21:53:25 bst Message-Id: <5748.8805122053@aiva.ed.ac.uk> To: JAR@ai.ai.mit.edu, scheme@mc.lcs.mit.edu Subject: Re: ``Update functions'' in POP2. Cc: aarons%cvaxa.sussex.ac.uk@NSS.Cs.Ucl.AC.UK, rhr%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK > Date: Wed, 11 May 88 10:50:47 EDT > From: Jonathan A Rees > Subject: ``Update functions'' in POP2. > Someone, I don't remember who, pointed out that the "setter" idea > (i.e. a function that maps an access procedure (not its name) to a > corresponding mutator) is not original with T, but was in the language > POP2. Does anyone know of a reference for this? Does anyone know how > this was implemented (global table as in Lyn's message, or local > association as in T)? Two recent references are: Jonathan Laventhol. Programming in Pop-11. Blackwell Scientific Publications, Oxford, 1987. Rosalind Barrett, Allan Ramsay, and Aaron Sloman. Pop-11: A Practical Language for Artificial Intelligence. Ellis Horwood, 1985. Pop-11 is the descendent of Pop2 that is part of Poplog. In Pop, every object is of some type or "class". The class is re- resented by an object called a "key". So part of each object is a pointer to a key. There is, as one might expect, a "key key" for key objects, including the key key. The procedure datakey returns an object's key. The key contains a procedure for each of the primitive operations such as cons(truct), print, equal, and apply. For each primitive P, there is a procedure class_P that takes a key and returns the appropriate procedure. For example, class_apply of the vector key is a sub- scripting procedure (subscripting may therefore be written as a function call.) Note that the key contains entries only for certain built-in operations. You cannot, as far as I know, define new operations of this sort. Anyway... Class_access(i,key) returns an access procedure for the i-th field of a record class. Vector classes are similar, except there is only one accessing procedure. It takes a subscript as an argument and is obtained by class_subscr(key). So we have these access and subscipting procedures. They, and other procedures, have various fields. The field of interest here is the updater. The procedure updater returns the updater of a procedure. It has an updater too, used to assign the updater of a procedure. If you do set_whatever -> updater(whatever); where whatever and set_whataver are procedures and -> is assignment (in the obvious, but unusual, direction) then x -> whatever(y). will put x in the whatever part of y. There is a symtax for defining updaters. You say define updater whatever(newval, object) ... enddefine; instead of define set_whatever(newval, object) ... endefine; set_whatever -> updater(whatever); You can do the 'define updater' even if the accessing procedure has not yet been defined, which may put some interesting constraints on the implementation, but I do not know what the actual implementation is. -- Jeff Jeff Dalton, JANET: J.Dalton@uk.ac.ed AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton  Received: from zurich (TCP 2206400260) by MC.LCS.MIT.EDU 12 May 88 14:34:27 EDT Received: from A.ISI.EDU (a.isi.edu) by ZURICH.AI.MIT.EDU; Thu, 12 May 88 14:32:31 edt Date: Thu 12 May 88 14:28:37-EDT From: Morris Katz Subject: CPS To: scheme@ZURICH.AI.MIT.EDU Message-Id: <12397778009.46.MKATZ@A.ISI.EDU> Does anyone know of any good references on continuation passing style? (My apologies in advance for the fact that I am sure that this question has been addressed at some point in the past on this mailing list.) Morry Katz -------  Received: from uvaarpa.virginia.edu (TCP 20043601007) by MC.LCS.MIT.EDU 12 May 88 11:44:02 EDT Received: from virginia.edu by uvaarpa.virginia.edu id aa02529; 12 May 88 11:42 EDT Received: from uvacs.cs.virginia.EDU by virginia.acc.virginia.EDU id ac06432; 12 May 88 10:41 CDT Received: by uvacs.cs.virginia.edu (5.51/5.1.UVA) id AA04762; Thu, 12 May 88 11:32:10 EDT From: Alex Colvin Posted-Date: Thu, 12 May 88 11:32:09 EDT To: scheme@mc.lcs.mit.edu, mac@uvacs.cs.virginia.edu Subject: Re: ``Update functions'' in Scheme. In-Reply-To: Your message of Wed, 11 May 88 08:53:00 EDT. <19880511125310.0.STEVER@JEWEL-CAVE.S4CC.Symbolics.COM> Date: Thu, 12 May 88 11:32:09 EDT SETL, the set language, used such left-hand-side ("sinister") update functions and made them compose correctly. Unfortunately, I no longer have a SETL manual available. As I recall, evaluating nested updates can involve two calls to functions, one in a dexter context and one in a sinister context. F(G(A)) <- B should ensure that, after assignment, F(G(A)) = B It seems like you need T1 <- G(A) G dexter F(T1) <- B F sinister G(A) <- T1 G sinister Now F(G(A)) = F(T1) = B As for about F(G(A),H(B)) <- C T1 <- G(A), T2 <- H(B) F(T1,T2) <- C G(A) <- T1,H(B) <- T2 Anyone know SETL? Jeff?  Received: from BBN.COM (TCP 20026200172) by MC.LCS.MIT.EDU 12 May 88 07:15:18 EDT Received: from alice.bbn.com by BBN.COM id aa15193; 12 May 88 7:13 EDT Date: Thu May 12 07:20:04 EDT 1988 From: sas@BBN.COM To: JAR@ai.ai.mit.edu CC: scheme@mc.lcs.mit.edu In-reply-to: Jonathan A Rees's message of Wed, 11 May 88 10:50:47 EDT <375448.880511.JAR@AI.AI.MIT.EDU> Subject: ``Update functions'' in POP2. What is POP2? I remember SIMSCRIPT had setter functions back in the late 60's. It had a FORTRAN/PL/I syntax and allowed you define a function for use on the left hand side OR the right hand side of the equal sign in an assignment. They also had an inheritence based type system which was kind of neat. Does anyone want to count Algol 60's call by name as an example of implicit generation of setter functions? Seth P.S. Any other grand old approaches/solutions to the setter problem flopping around in your memory banks?  Received: from F.GP.CS.CMU.EDU (TCP 20000575244) by MC.LCS.MIT.EDU 12 May 88 02:58:33 EDT Date: 12 May 1988 02:18-EDT From: Barak.Pearlmutter@F.GP.CS.CMU.EDU To: Jonathan A Rees Cc: scheme@mc.lcs.mit.edu Subject: Re: cells Message-Id: From: Jonathan A Rees ... If you did this [added locatives] to Scheme I think you'd have quite a different language, different enough that it would require significant changes to implementation strategies. Well, I don't know. Even though I'm not a big fan of locatives we included them in our implementation of Oaklisp and I'm not sure if they haired things up at all when you take the final tally. We used two low tag bits and allocated #b10 for locatives, so they were immediates. Data representation wasn't any hairier to speak of, but the presence of "raw cells" did make the gc code about 3 times as long as it would otherwise have been, and maybe 20% slower. It's hard to say whether they were a net win, but they certainly weren't a big complication. If "computer science" really deserved its name I guess I'd reimplement Oaklisp again without them and find out. They do let vectors and structures (including environments) get gc'ed when all that's left is a pointer to something in their innards, which is nice, and they did simplify the internals considerably, especially representing environments and closing over instance variables and dealing with globals and low level stuff like that. --Barak.  Received: from THEORY.LCS.MIT.EDU (TCP 2206400134) by MC.LCS.MIT.EDU 12 May 88 00:05:54 EDT Received: from TOUCAN.LCS.MIT.EDU by THEORY.LCS.MIT.EDU (4.12/4.7); Tue, 10 May 88 11:52:58 ast Received: by TOUCAN.LCS.MIT.EDU (4.12/4.7); Tue, 10 May 88 11:52:55 ast Date: Tue, 10 May 88 11:52:55 ast From: Bard Bloom Message-Id: <8805101552.AA02100@TOUCAN.LCS.MIT.EDU> To: umb!gerald@husc6.harvard.edu Cc: scheme@mc.lcs.mit.edu In-Reply-To: (Gerald Ostheimer's message of 10 May 88 02:16:56 GMT <632@umb.umb.edu> Subject: ``Update functions'' in Scheme. > Following the discussion on assignments in Scheme, and how to have them > performed in subroutines, the following question strikes my mind: > > *** Why didn't the designers of Scheme include locations (~anonymous variables) > as first-class values in the language? *** One possible reason (for T at any rate) is that setting is more general than simply putting a value into a location. For a slightly contrived example, let's take an abstract data type of complex numbers in which all the coordinates are settable: (LSET C (MAKE-COMPLEX-FROM-RECTANGULAR 0.3 10.8)) (SET (COMPLEX-THETA C) (/ PI 2)) (SET (COMPLEX-X C) 0.0) Now, the X, Y, R, and THETA attributes of a complex number aren't all going to be stored in variables. Even if they were it wouldn't help: setting (X C) will usually change the values that (R C) and (THETA C) should have. In general, the operation of stuffing a value into a location is inappropriate for abstract data types: even when it works, it is too implementation-dependent. There's no choice but to use mutator procedures. Since we have to use them anyways, why not be clean and not bother with locations? Do you really want to imitate BLISS and require explicit dereferencing for every mutable variable? -- Bard the (LAMBDA (X) GARGOYLE) (P.S.: That's a good enough argument for theoreticians like me. T actually has locatives. I don't know how they work.)  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 May 88 21:55:38 EDT Date: Wed, 11 May 88 12:36:21 EDT From: Jonathan A Rees Subject: cells To: umb!gerald%husc6.harvard.edu@XX.LCS.MIT.EDU cc: scheme@MC.LCS.MIT.EDU In-reply-to: Msg of 10 May 88 02:16:56 GMT from umb!gerald@husc6.harvard.edu (Gerald Ostheimer) Message-ID: <375517.880511.JAR@AI.AI.MIT.EDU> Date: 10 May 88 02:16:56 GMT From: umb!gerald@husc6.harvard.edu (Gerald Ostheimer) *** Why didn't the designers of Scheme include locations (~anonymous variables) as first-class values in the language? *** A variable would then be an identifier bound to a location, and we would have true constants as well, by binding identifiers to values that are not locations. All identifier bindings would then be irreversible, only locations could be updated (thus indirectly updating identifiers bound to them). I think Steele considers this possibility in one of the notes in the Rabbit tech report. Probably it had to do with fitting in with existing Lisp implementations gracefully and efficiently; there are some sticky performance problems with locations (if pairs always consist of two locations, how do you represent those locations? Do you allocate three objects when you create the pair? That makes pairs too expensive. Do you allocate stored objects representing the locations on demand (like locatives in T)? That makes locations too expensive to be useful. Are locations immediate objects (like locatives on the MIT-derived Lisp Machine systems)? This complicates data representations and the gc. Are pairs immutable? What about arrays? Etc. etc.). Any takers? Plenty, including the designers of Algol 68, PLASMA, and ML. If you did this to Scheme I think you'd have quite a different language, different enough that it would require significant changes to implementation strategies.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 May 88 21:54:59 EDT Date: Wed, 11 May 88 10:50:47 EDT From: Jonathan A Rees Subject: ``Update functions'' in POP2. To: scheme@MC.LCS.MIT.EDU In-reply-to: Msg of Mon 9 May 88 22:51:49 edt from lyn@BASEL.AI.MIT.EDU (Franklyn Turbak) Message-ID: <375448.880511.JAR@AI.AI.MIT.EDU> Someone, I don't remember who, pointed out that the "setter" idea (i.e. a function that maps an access procedure (not its name) to a corresponding mutator) is not original with T, but was in the language POP2. Does anyone know of a reference for this? Does anyone know how this was implemented (global table as in Lyn's message, or local association as in T)?  Received: from WAIKATO.S4CC.Symbolics.COM (TCP 20024231532) by MC.LCS.MIT.EDU 11 May 88 16:14:56 EDT Received: from JEWEL-CAVE.S4CC.Symbolics.COM by WAIKATO.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 177839; Wed 11-May-88 08:53:28 EDT Date: Wed, 11 May 88 08:53 EDT From: Stephen Robbins Subject: ``Update functions'' in Scheme. To: lyn@BASEL.AI.MIT.EDU cc: scheme@mc.lcs.mit.edu In-Reply-To: <8805110237.AA09496@basel> Message-ID: <19880511125310.0.STEVER@JEWEL-CAVE.S4CC.Symbolics.COM> Date: Tue, 10 May 88 22:37:46 edt From: lyn@BASEL.AI.MIT.EDU (Franklyn Turbak) > Common LISP's SETF won't work in this example. SETF does a syntactic > transformation on its first operand. It doesn't evaluate the first operand. > > Compiling ACT-FOOLISHLY-ON will give the error that no SETF method is defined > for "accessor." This is exactly what I *DON'T* like about a "macrological" SETF - you can't abstract over it! If in fact we want to think about and manipulate the abstract relationship between accessors and mutators, a text-based model is simply not sufficient. I agree. That's one reason I'm watching this discussion so closely. > (LDB (BYTE 4 2) (AREF MY-ARRAY 0)) > returns four bits from MY-ARRAY's first element (a number). > (SETF (LDB (BYTE 4 2)) (AREF MY-ARRAY 0)) > sets the four bits in MY-ARRAY's first element (a number). > > This is a case which can't be modeled as simply turning LDB into a call to > SET-LDB. (AREF MY-ARRAY 0) may fetch a number from MY-ARRAY and pass it to > SET-LDB, but that won't change the number that's stored in MY-ARRAY. This seems to be another version of Bard's "composition" example - is it possible to get a functional SETF-like frob to work in "higher-order" cases? Like Bard, I'd be interested in any ideas on this matter. Question: The LDB example is "one order higher" than a straight SETQ. Are there any examples that are more than one order higher? - Stephen  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 11 May 88 08:02:44 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 9131; Wed, 11 May 88 08:00:10 EDT Received: from JPNSUT30.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 9130; Wed, 11 May 88 08:00:09 EDT Received: by JPNSUT30 (Mailer X1.25) id 8953; Wed, 11 May 88 17:36:53 JST DATE: WED, 11 MAY 1988 17:35 JST FROM: Toshio Matsuda TO: Please enter my name in your mailing list.  Received: from chamarti (TCP 2206400253) by MC.LCS.MIT.EDU 10 May 88 23:38:39 EDT Received: by CHAMARTIN.AI.MIT.EDU; Tue, 10 May 88 23:08:02 edt Date: Tue, 10 May 88 23:08:02 edt From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas) Message-Id: <8805110308.AA04003@chamarti> To: lyn@BASEL.AI.MIT.EDU Cc: Stever@WAIKATO.S4CC.Symbolics.COM, scheme@mc.lcs.mit.edu In-Reply-To: Franklyn Turbak's message of Tue, 10 May 88 22:37:46 edt <8805110237.AA09496@basel> Subject: ``Update functions'' in Scheme. Reply-To: jinx@zurich.ai.mit.edu Kludge of the week: (define (compose f g) (let ((the-composition (lambda (x) (f (g x))))) (if (has-setter? f) (declare-setter the-composition (let ((core (setter f))) (lambda (new-value x) (core new-value (g x)))))) the-composition)) PS: Aren't first-class procedures fun? :-)  Received: from basel (TCP 2206400245) by MC.LCS.MIT.EDU 10 May 88 21:45:51 EDT Received: by BASEL.AI.MIT.EDU; Tue, 10 May 88 22:22:13 edt Date: Tue, 10 May 88 22:22:13 edt From: lyn@BASEL.AI.MIT.EDU (Franklyn Turbak) Message-Id: <8805110222.AA09484@basel> To: net%TUB.BITNET@MITVMA.MIT.EDU Cc: scheme@mc.lcs.mit.edu In-Reply-To: Oliver Laumann's message of Tue, 10 May 88 10:35:01 +0200 <8805100835.AA17323@tub.UUCP> Subject: ``Update functions'' in Scheme. > > The key point here is that Scheme already has enough power to express > > the abstract relationship between accessors and mutators; there is no > > need to "extend" the language to provide this feature. > > If this is true, then please tell me how you would do the following > using the method you described. > > Suppose I want to write a new print function that involves a ``print length''. > The function (print-length) should serve both as an accessor and as a > mutator for the actual print length. That is, > > (print-length) > > simply returns the current print length, while > > (set! (print-length) 20) > > should be used to change the print length (changing it would include some > kind of sanity check). > > . . . > > How would you do something like this using the method you proposed > without employing a global variable? We can get a version of PRINT-LENGTH without using a global variable to hold the state as follows: ; -------------------------------------------------------------------------- ; Wrap up the print-length state variable into a "generating" ; procedure that can provide us with both the accesor and mutator (define print-length-maker (let ((*print-length* 100)) ; This state is local to the following procedure (lambda (m) (cond ((eq? m 'accessor) (lambda () *print-length*)) ((eq? m 'mutator) (lambda (new-val) (set! *print-length* new-val))) ; Could also include "sanity check" here (else (error "Don't understand!")))))) ; Now define the accessor . . . (define print-length (print-length-maker 'accessor)) ; . . . and insert the mutator into the SETTER table we defined before. (table-insert! *setter-table* print-length (print-length-maker 'mutator)) ; Test it out: (print-length) ;Value: 100 ((setter print-length) 20) ;Value: 100 (print-length) ;Value: 20 ; -------------------------------------------------------------------------- Note that the same idea could be used to get rid of the global *setter-table* as well. - Lyn -  Received: from basel (TCP 2206400245) by MC.LCS.MIT.EDU 10 May 88 21:45:29 EDT Received: by BASEL.AI.MIT.EDU; Tue, 10 May 88 22:37:46 edt Date: Tue, 10 May 88 22:37:46 edt From: lyn@BASEL.AI.MIT.EDU (Franklyn Turbak) Message-Id: <8805110237.AA09496@basel> To: Stever@WAIKATO.S4CC.Symbolics.COM Cc: scheme@mc.lcs.mit.edu In-Reply-To: Stephen Robbins's message of Tue, 10 May 88 12:12 EDT <19880510161237.7.STEVER@JEWEL-CAVE.S4CC.Symbolics.COM> Subject: ``Update functions'' in Scheme. > So SETF is NOT a function, and actually provides a set of source code > transformations that can be used to disassemble references to `place's and > reassemble them. I never claimed that SETF was a function, just that you could achieve much of its functionality with an ordinary Scheme procedure. > Common LISP's SETF won't work in this example. SETF does a syntactic > transformation on its first operand. It doesn't evaluate the first operand. > > Compiling ACT-FOOLISHLY-ON will give the error that no SETF method is defined > for "accessor." This is exactly what I *DON'T* like about a "macrological" SETF - you can't abstract over it! If in fact we want to think about and manipulate the abstract relationship between accessors and mutators, a text-based model is simply not sufficient. > (LDB (BYTE 4 2) (AREF MY-ARRAY 0)) > returns four bits from MY-ARRAY's first element (a number). > (SETF (LDB (BYTE 4 2)) (AREF MY-ARRAY 0)) > sets the four bits in MY-ARRAY's first element (a number). > > This is a case which can't be modeled as simply turning LDB into a call to > SET-LDB. (AREF MY-ARRAY 0) may fetch a number from MY-ARRAY and pass it to > SET-LDB, but that won't change the number that's stored in MY-ARRAY. This seems to be another version of Bard's "composition" example - is it possible to get a functional SETF-like frob to work in "higher-order" cases? Like Bard, I'd be interested in any ideas on this matter. - Lyn -  Received: from F.GP.CS.CMU.EDU (TCP 20000575244) by MC.LCS.MIT.EDU 10 May 88 19:45:00 EDT Date: 10 May 1988 18:55-EDT From: Barak.Pearlmutter@F.GP.CS.CMU.EDU To: scheme@mc.lcs.mit.edu Cc: bap@f Subject: Re: Update functions in Scheme. Message-Id: Interestingly, in Oaklisp the interaction between COMPOSE and SETTER that Bard Bloom desires is easy to obtain in a modular way, due to the way that settable operations are plugged into the type system: (define compose (make operation)) (add-method (compose (operation) f g) (lambda (z) (f (g z)))) (add-method (compose (settable-operation) f g) (let ((fg (make settable-operation))) (add-method (fg (object) z) (f (g z))) (add-method ((setter fg) (object) z x) (set! (f (g z)) x)) fg)) [ Lets exhibit modularity by making this work for locatable operation too: (add-method (compose (locatable-operation) f g) (let ((fg (make locatable-operation))) (add-method ((locater fg) (object) z) (make-locative (f (g z)))) fg)) ] ================== Of course, the problem of getting (DEFINE (FOO X) (BAR X)) to make FOO just as settable as BAR is not so easily addressed. The difficulty here is local variables, so one approach is to get rid of all the variable by translating everything down to a set of combinators. For instance, (define (foo a b) (if a (car b) (car (cdr b)))) would first get curried to (define foo (lambda (a) (lambda (b) (if a (car b) (car (cdr b)))))), while we note that (SET! (FOO X Y) Z) gets curried to (SET! ((FOO X) Y) Z). Some nesting gets removed (define foo (lambda (a) (lambda (b) (if a (car b) (((compose car) cdr) b))))), we get rid of B (define foo (lambda (a) (if a car ((compose car) cdr)))), and use the combinator which could be defined as follows: (define %if (lambda (f) (lambda (g) (lambda (test) (if test f g))))) to rewrite FOO to (define foo (%if car ((compose car) cdr))). Now, assuming that %IF carries through settableness (which it should do automatically the way Oaklisp COMPOSE did above), i.e. (setter ((%if f) g)) <=> ((%if (setter f)) (setter g)), our side effect attempt (set! ((foo x) y) z) gets macroexpanded to (((setter (foo x)) y) z) which works. In order to demonstrate that it works, we can work things through. Substituting in foo's definition, we have (((setter ((%if car) ((compose car) cdr))) y) z) which is the same as ((((%if (setter car)) (setter ((compose car) cdr))) y) z) which is the same as ((((%if (setter car)) ((compose (setter car)) cdr)) y) z) which, decurrying and reintroducing some variables, is the same as ((%if (lambda (b) ((setter car) b z)) (lambda (b) ((setter car) (cdr b) z)) x) y z) which is the same as (if x (set! (car y) z) (set! (car (cdr y)) z)). I find it more than a little perverse to use combinators in an effort to make side effects more convenient. --Barak. Acknowledgments: I would like to thank Peter Lee for his moral support.  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 10 May 88 12:18:25 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 1870; Tue, 10 May 88 10:19:53 EDT Received: from DB0TUI6.BITNET (NET) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 1759; Tue, 10 May 88 10:07:53 EDT Received: by tub.UUCP; Tue, 10 May 88 10:35:01 +0200; AA17323 Date: Tue, 10 May 88 10:35:01 +0200 From: Oliver Laumann Message-Id: <8805100835.AA17323@tub.UUCP> To: lyn@basel.ai.mit.edu Subject: Re: ``Update functions'' in Scheme. Cc: Ram-Ashwin@yale-zoo.arpa, scheme@mc.lcs.mit.edu > [example where a function (setter accessor) obtains the mutator for > a given accessor function by table lookup] > The key point here is that Scheme already has enough power to express > the abstract relationship between accessors and mutators; there is no > need to "extend" the language to provide this feature. If this is true, then please tell me how you would do the following using the method you described. Suppose I want to write a new print function that involves a ``print length''. The function (print-length) should serve both as an accessor and as a mutator for the actual print length. That is, (print-length) simply returns the current print length, while (set! (print-length) 20) should be used to change the print length (changing it would include some kind of sanity check). Using the extension to Scheme I outlined in a previous message, the actual variable holding the print length (say, *print-length*) could be a local variable to the combined accessor/mutator function: (define print-length (let ((*print-length* 100)) (lambda ... How would you do something like this using the method you proposed without employing a global variable? -- Regards, Oliver Laumann, Technical University of Berlin, Germany. ...!pyramid!tub!net or net@TUB.BITNET  Received: from WAIKATO.S4CC.Symbolics.COM (TCP 20024231532) by MC.LCS.MIT.EDU 10 May 88 12:17:26 EDT Received: from JEWEL-CAVE.S4CC.Symbolics.COM (JEWEL-CAVE.S4CC.Symbolics.COM) by WAIKATO.S4CC.Symbolics.COM via INTERNET with SMTP id 177644; 10 May 88 12:16:05 EDT Date: Tue, 10 May 88 12:15 EDT From: Stephen Robbins Subject: ``Update functions'' in Scheme. To: bard@THEORY.LCS.MIT.EDU, lyn@BASEL.AI.MIT.EDU, scheme@mc.lcs.mit.edu In-Reply-To: <8805100302.AA01261@TOUCAN.LCS.MIT.EDU> Message-ID: <19880510161546.8.STEVER@JEWEL-CAVE.S4CC.Symbolics.COM> Date: Mon, 9 May 88 23:02:20 ast From: Bard Bloom I'm not exactly sure what a language extension is. I am pretty sure that SETF in Lisp is a macro. Yep [see my previous message]. (SETF (UNKNOWN-SETTER v) y) expands to something like Lyn's or T's method, where the setter is looked up dynamically. This will give a compiletime error that no SETF method is known for UNKNOWN-SETTER. - Stephen  Received: from WAIKATO.S4CC.Symbolics.COM (TCP 20024231532) by MC.LCS.MIT.EDU 10 May 88 12:16:08 EDT Received: from JEWEL-CAVE.S4CC.Symbolics.COM by WAIKATO.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 177642; Tue 10-May-88 12:13:04 EDT Date: Tue, 10 May 88 12:12 EDT From: Stephen Robbins Subject: ``Update functions'' in Scheme. To: lyn@BASEL.AI.MIT.EDU, Ram-Ashwin@YALE-ZOO.ARPA cc: scheme@mc.lcs.mit.edu, stever@WAIKATO.S4CC.Symbolics.COM In-Reply-To: <8805100251.AA08745@basel> Message-ID: <19880510161237.7.STEVER@JEWEL-CAVE.S4CC.Symbolics.COM> Date: Mon, 9 May 88 22:51:49 edt From: lyn@BASEL.AI.MIT.EDU (Franklyn Turbak) > I don't know about Common Lisp's SETF, but in the T dialect of Scheme there is a > difference between the two. When you write (SET (FOO ...) ...), the operation > FOO can specify how it is to be set, i.e., it can handle the operation (SETTER > FOO) and return a setter procedure, which then does the setting appropriately. Pages 94-107 of Common Lisp The Language will probably clarify Common Lisp's SETF semantics. All SETF does is to provide a connection between an accessor and its corresponding mutator. I suggested that an appropriate naming convention served many of the same purposes as SETF. SETF is a macro. It does more complicated source-to-source transformations than simple name substitution. (LDB (BYTE 4 2) (AREF MY-ARRAY 0)) returns four bits from MY-ARRAY's first element (a number). (SETF (LDB (BYTE 4 2)) (AREF MY-ARRAY 0)) sets the four bits in MY-ARRAY's first element (a number). This is a case which can't be modeled as simply turning LDB into a call to SET-LDB. (AREF MY-ARRAY 0) may fetch a number from MY-ARRAY and pass it to SET-LDB, but that won't change the number that's stored in MY-ARRAY. For the interested, here's a brief description of SETF. (SETF place value) `place' is something that looks syntactically like a function call. You define a SETF method for a given place. The SETF method tells how to access and modify that place. For example: (SETF (CAR xxx) value) The "place" is (CAR xxx) The SETF method for CAR says that to change the value in a CAR place, expand into (RPLACA xxx value). To access the value in the place, expand into (CAR xxx). Macros other than SETF use this information. (INCF place) increments the value stored in a place. For INCF, `place' has to be read as well as written. (INCF MY-VARIABLE) has roughly the same effect as (SETF MY-VARIABLE (+ 1 MY-VARIABLE)). But SETF methods give a little more precision than that. If the expansion was just (INCF xxx) => (SETF xxx (+ 1 xxx)), consider: (INCF (AREF *MY-ARRAY* (INCF *SUBSCRIPT*))) expanding into: (SETF (AREF *MY-ARRAY* (INCF *SUBSCRIPT*)) (+ 1 (AREF *MY-ARRAY* (INCF *SUBSCRIPT*)))) We'd only like (INCF *SUBSCRIPT*) evaluated once. It only occurs once in the source code. But the straightforward expansion includes it twice. SETF methods take care of making sure that \subforms of `place'/ are only evaluated once. Written using SETF methods, INCF actually expands into: (LET ((SUBSCRIPT (INCF *SUBSCRIPT*)) (ARRAY *MY-ARRAY*)) (ARRAY-STORE ARRAY SUBSCRIPT (1+ (AREF ARRAY SUBSCRIPT)))) -------------------- So SETF is NOT a function, and actually provides a set of source code transformations that can be used to disassemble references to `place's and reassemble them. In the simplest case, SETF can be thought of as a simple link between an accessor and a mutator. But SETF's underlying mechanism, SETF methods, give far more power. unfortunately, as Bard Bloom has pointed out to me, a simple naming convention does not work if we wish to use the relationship between accessor and mutator in a more abstract way. An example derived from the one Bard showed me is: (define (act-foolishly-on accessor object) (setf (accessor object) (list (accessor object) "silly")) object) Common LISP's SETF won't work in this example. SETF does a syntactic transformation on its first operand. It doesn't evaluate the first operand. Compiling ACT-FOOLISHLY-ON will give the error that no SETF method is defined for "accessor." Notice: these are only the Common Lisp semantics for SETF. It's entirely possible that some functional (vs. macrological) definition of SETF can be reached. But my hunch is that it \will/ require some special evaluation rules. -- Stephen  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 May 88 12:01:56 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Tue, 10 May 88 11:57:36 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 9 May 88 17:17:37 GMT From: mcvax!ukc!its63b!aiva!jeff@uunet.uu.net (Jeff Dalton) Organization: Dept. of AI, Univ. of Edinburgh, UK Subject: Re: set in Scheme? Message-Id: <411@aiva.ed.ac.uk> References: <1822@uhccux.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <1822@uhccux.UUCP> chin@uhccux.UUCP (David Chin) writes: >Does anyone know how to do the equivalent of a Common Lisp "set" in >Scheme. In particular, I would like to be able to pass different >symbols as arguments to a function and then set! or define them inside >the function. Standard (R3RS) Scheme does not have anything of this sort. >Is this style of programming (global side-effects for >function calls) contrary to the Scheme philosophy? Probably. What you can do in Scheme is to use a different abstraction rather than passing symbols to set. For example: (define (make-cell contents) (list contents)) (define (cell-contents cell) (car cell)) (define (set-cell-contents! cell new-contents) (set-car! cell new-contents)) Instead of passing a symbol, you would give the symbol a cell as its value and pass the value of the symbol (the cell). Set-cell-contents! could then be used to change the value in the cell. So: (define (set-three! cell) (set-cell-contents! call 3)) (define x (make-cell 2)) (set-three! x) Then (cell-contents x) ==> 3. An alternative approach would be to pass a function instead of the symbol. This function could be called to get or set the symbol's value. This can be made to look nicer by using macros. The code below is meant to look a bit like "locatives" in T: (defmacro (symbol-locative sym) (let ((temp-name (different-symbol sym))) `(make-symbol-locative (lambda () ,sym) (lambda (,temp-name) (set! ,sym ,temp-name))))) (define (different-symbol s) (if (eq? s 'x) 'y 'x)) (define (make-symbol-locative get-thunk set!-thunk) (lambda (message) (cond ((eq? message 'get) get-thunk) ((eq? message 'set!) set!-thunk)))) (define (contents locative) ((locative 'get))) (define (set-contents! locative new-contents) ((locative 'set!) new-contents)) The example again: (define set-three! (loc) (set-contents! loc 3)) (define x 2) (set-three (symbol-locative x)) Then x ==> 3. Jeff Dalton, JANET: J.Dalton@uk.ac.ed AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 May 88 10:47:51 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Tue, 10 May 88 07:37:54 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 10 May 88 02:16:56 GMT From: umb!gerald@husc6.harvard.edu (Gerald Ostheimer) Organization: Dept of Math and CS, UMass Boston. Subject: Re: ``Update functions'' in Scheme. Message-Id: <632@umb.umb.edu> References: <411493.880427.SCHREQ@MC.LCS.MIT.EDU>, <8805031911.AA04352@basel>, <28710@yale-celray.yale.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Following the discussion on assignments in Scheme, and how to have them performed in subroutines, the following question strikes my mind: *** Why didn't the designers of Scheme include locations (~anonymous variables) as first-class values in the language? *** Wouldn't that fit the Scheme philosophy of orthogonality and 'first-class everything'? After all, locations are part of the denotational semantics of Scheme, so this wouldn't be much of an extension to Scheme from an abstract point of view. A variable would then be an identifier bound to a location, and we would have true constants as well, by binding identifiers to values that are not locations. All identifier bindings would then be irreversible, only locations could be updated (thus indirectly updating identifiers bound to them). If that sounds too abstract, consider the following hypothetical program fragment: (let ((x (var 1)) ; VAR creates a new location and (y 1)) ; initializes it to its argument (set! x 2) (set! x (+ val x) 2)) ; VAL looks up the current value of x (set! x (+ y 2))) ; y can't be set! and needn't be val'ed The cons function would have to create a pair of locations and initialize them to its arguments. (So that we could make sense of setcar!) We could now also write a 'swap' function as in (define (swap x y) ; actual arguments must be variables (let ((h (val x))) (set! x (val y)) (set! y h))) This would not violate the 'call by value' principle, since locations would _be_ values. First-class variables shouldn't give us any more headaches than side-effects per se. Separating constants from variables should even simplify some compiler optimizations (for the constants). For the very least, we would get rid of having to write macros or extend the syntax in order to abstract over assignments. Any takers? -- ------------------------------------------------------------------------------ Gerald "When I use a word, it means exactly what I want it to mean" (Humpty Dumpty, Through the Looking Glass)  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 May 88 04:02:02 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Tue, 10 May 88 03:56:16 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 10 May 88 02:58:37 GMT From: ubc-cs!faculty.cs.ubc.ca!manis@beaver.cs.washington.edu (Vincent Manis) Organization: UBC Department of Computer Science, Vancouver, B.C., Canada Subject: Re: Re : set in Scheme Message-Id: <2491@ubc-cs.UUCP> References: <12073@shemp.CS.UCLA.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Well, putting my radical hat on, not only is set evil, but also set!. Only non-destructive programming practices are safe, and everything else inevitably leads to disaster. But back here in the real world, one occasionally wants global variables. Those you can have via set! and define. I guess the frequency with which I use set in Lisp can be best judged by the fact that I hadn't realised it was absent in Scheme until reading the original posting on this subject. There are good reasons for omitting it. First of all, set makes programs opaque in that one has no idea which variable is getting modified. More to the point, Scheme dispenses with value cells, so implementing set would be non-trivial in most Schemes (though Chez Scheme's "boxes" might make it easier). My eyes glaze over when I see two levels of backquote in a macro definition, so I don't know how effective the posted solution is. However, my choice is the humble property list. Still not terribly structured, but efficiently implemented and a bit more modular (different bits of code can use plists without interfering, so long as they use different pnames). Of course, the *right* way to do this is probably a hash table or tree... Vincent Manis | manis@cs.ubc.ca The Invisible City of Kitezh | manis@cs.ubc.cdn Department of Computer Science | manis@ubc.csnet University of British Columbia | {ihnp4!alberta,uw-beaver,uunet}! <> | ubc-cs!manis  Received: from THEORY.LCS.MIT.EDU (TCP 2206400134) by MC.LCS.MIT.EDU 9 May 88 23:03:47 EDT Received: from TOUCAN.LCS.MIT.EDU by THEORY.LCS.MIT.EDU (4.12/4.7); Mon, 9 May 88 23:02:26 ast Received: by TOUCAN.LCS.MIT.EDU (4.12/4.7); Mon, 9 May 88 23:02:20 ast Date: Mon, 9 May 88 23:02:20 ast From: Bard Bloom Message-Id: <8805100302.AA01261@TOUCAN.LCS.MIT.EDU> To: lyn@BASEL.AI.MIT.EDU, scheme@mc.lcs.mit.edu In-Reply-To: Franklyn Turbak's message of Mon, 9 May 88 22:51:49 edt <8805100251.AA08745@basel> Subject: ``Update functions'' in Scheme. > The key point here is that Scheme already has enough power to express > the abstract relationship between accessors and mutators; there is no > need to "extend" the language to provide this feature. I'm not exactly sure what a language extension is. I am pretty sure that SETF in Lisp is a macro: (SETF x y) expands to something depending on the structure of x: symbol ==> (SETQ x y) (CAR x') ==> (RPLACA x' y) (VREF v i) ==> (WHATEVER-VECTOR-SET-IS v i y) ... (SETF (UNKNOWN-SETTER v) y) expands to something like Lyn's or T's method, where the setter is looked up dynamically. So, SETF is a smart macro that either knows a lot about built-in setters, or at least does the lookup once at compile time rather than repeatedly. It *is* definable in T and presumably in LISP as well. I wouldn't call it a language extension; it doesn't let the language do anything it couldn't do anyways. One thing that neither Lyn nor T can handle -- I don't know about Lisp -- is function equality: (LSET ELEMENTS '((EARTH AIR FIRE WATER))) (DEFINE (MY-PERSONAL-CAR X) (CAR X)) (SET (MY-PERSONAL-IDENTITY ELEMENTS) (APPEND '(HYDROGEN HELIUM LITHIUM ... LAWRENCIUM) (CAR ELEMENTS))) Now, MY-PERSONAL-IDENTITY is the car function, and lambda-calculus people like me would like to have (CAR X) and (MY-PERSONAL-IDENTITY X) behave precisely the same under all circumstances. I'm willing to let the programming-language people tell me that it'll run slower, it will show up in backtraces, it may overflow the stack, and so forth. I'm not so willing to learn that it doesn't behave the same in a simple usage like this. Another example: (SET (CAAR X) Y) works (SET ((COMPOSE CAR CAR) X) Y) doesn't. In particular, my high-order functional program can build up an accessor function which ought to have a corresponding mutator, but the mutator can't be found because the accessor we built isn't EQ? to the accessor in the table. I'll stop being idiotic about programming languages now, and admit that the table-lookup method is much simpler to implement that any ideas I have about getting SET to work right with higher-order programming. Still, there might be some not-too-horrible way to get it to work better. Any ideas? -- Bard the (LAMBDA (X) GARGOYLE)  Received: from basel (TCP 2206400245) by MC.LCS.MIT.EDU 9 May 88 21:51:15 EDT Received: by BASEL.AI.MIT.EDU; Mon, 9 May 88 22:51:49 edt Date: Mon, 9 May 88 22:51:49 edt From: lyn@BASEL.AI.MIT.EDU (Franklyn Turbak) Message-Id: <8805100251.AA08745@basel> To: Ram-Ashwin@yale-zoo.arpa Cc: scheme@mc.lcs.mit.edu, lyn@BASEL.AI.MIT.EDU In-Reply-To: (Ashwin Ram's message of 9 May 88 15:55:41 GMT <28710@yale-celray.yale.UUCP> Subject: ``Update functions'' in Scheme. > I don't know about Common Lisp's SETF, but in the T dialect of Scheme there is a > difference between the two. When you write (SET (FOO ...) ...), the operation > FOO can specify how it is to be set, i.e., it can handle the operation (SETTER > FOO) and return a setter procedure, which then does the setting appropriately. > This is not a matter of simple renaming; rather, it is a very useful programming > construct which lets you define new operations and their setters within the > existing syntax. The purpose of my message suggesting simple renaming vs. SETF [e.g. using (set!vector-ref v 10 'a) rather than (setf (vector-ref v 10) 'a), where SET!VECTOR-REF is just another name for VECTOR-SET!] was to emphasize that there is nothing particularly magical about SETF. All SETF does is to provide a connection between an accessor and its corresponding mutator. I suggested that an appropriate naming convention served many of the same purposes as SETF. Unfortunately, as Bard Bloom has pointed out to me, a simple naming convention does not work if we wish to use the relationship between accessor and mutator in a more abstract way. An example derived from the one Bard showed me is: (define (act-foolishly-on accessor object) (setf (accessor object) (list (accessor object) "silly")) object) That is, (act-foolishly-on car '(1 2 3)) should return ((1 "silly") 2 3) and (act-foolishly-on car '(1 2 3)) should return (1 (2 3) "silly") ACT-FOOLISHLY-ON can "make sense" for other accessor/mutator pairs as well (though not STRING-REF / STRING-SET!) But since procedures are first-class in Scheme, there is an easy way to get this more abstract behavior using a table that maps accessors to mutators. Suppose we have table abstraction based on the procedures MAKE-TABLE, TABLE-INSERT!, and TABLE-LOOKUP. Then we can obtain the more abstract behavior as follows: ; -------------------------------------------------------------------------- ; Make a 1-dimensional table (define *setter-table* (make-table)) ; Insert setting procedures into the table keyed by the accessing procedures ; | ACCESSOR | MUTATOR | (table-insert! *setter-table* car set-car! ) (table-insert! *setter-table* cdr set-cdr! ) (table-insert! *setter-table* vector-ref vector-set! ) (table-insert! *setter-table* string-ref string-set! ) (table-insert! *setter-table* table-lookup table-insert! ) ; ! ; . . . and so on. ; The procedure SETTER gets the mutator from the accessor (define (setter accessor) (table-lookup *setter-table* accessor)) ; Then we can use SETTER for the simple examples . . . ((setter car) p 5) ((setter vector-ref) v 10 'a) ; . . . as well as Bard's more complex example: (define (act-foolishly-on accessor object) ((setter accessor) object (list (accessor object) "silly")) object) ; -------------------------------------------------------------------------- The key point here is that Scheme already has enough power to express the abstract relationship between accessors and mutators; there is no need to "extend" the language to provide this feature. - Lyn -  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 9 May 88 16:46:00 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Mon, 9 May 88 16:35:00 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 9 May 88 15:55:41 GMT From: Ram-Ashwin@yale-zoo.arpa (Ashwin Ram) Organization: Computer Science, Yale University, New Haven, CT 06520-2158 Subject: Re: ``Update functions'' in Scheme. Message-Id: <28710@yale-celray.yale.UUCP> References: <411493.880427.SCHREQ@MC.LCS.MIT.EDU>, <8805031911.AA04352@basel> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <8805031911.AA04352@basel>, lyn@BASEL (Franklyn Turbak) writes: > > Did anybody already think about adding ``generalized functions'' > > (a la Common-Lisp's setf/defsetf feature) to Scheme? This would > > eliminate the need for several primitive procedures, among them > > set-car!, set-cdr!, vector-set!, and string-set!. Instead of writing > > > > (set-car! p 5) or (vector-set! v 10 'a) > > > > this would make it possible to write > > > > (set! (car p) 5) or (set! (vector-ref v 10) 'a) > > What's so great about SETF? [...] > it's easy to develop alternate naming conventions without > altering Scheme. One simple convention can be carried out > by simple renaming: > > (define set!car set-car!) [...] > > (set!car p 5) or (set!vector-ref v 10 'a) > > which, except for the missing pair of parens, looks a lot like > the SETF approach. And we didn't have to extend Scheme all! I don't know about Common Lisp's SETF, but in the T dialect of Scheme there is a difference between the two. When you write (SET (FOO ...) ...), the operation FOO can specify how it is to be set, i.e., it can handle the operation (SETTER FOO) and return a setter procedure, which then does the setting appropriately. This is not a matter of simple renaming; rather, it is a very useful programming construct which lets you define new operations and their setters within the existing syntax. For example, you could implement a two-dimensional array by defining an accessor operation (array-element A x y), where the definition of the operation would include a definition of its setter. Of course, you can do this without this feature too; it just turns out to be a nice way to program, that's all. -- Ashwin. ARPA: Ram-Ashwin@cs.yale.edu UUCP: {decvax,ucbvax,harvard,cmcl2,...}!yale!Ram-Ashwin BITNET: Ram@yalecs  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 9 May 88 16:00:59 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Mon, 9 May 88 15:51:59 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 9 May 88 17:18:45 GMT From: phoenix!crabb@princeton.edu (David W Crabb) Organization: Princeton University, NJ Subject: Re: Re : set in Scheme Message-Id: <2823@phoenix.Princeton.EDU> References: <12073@shemp.CS.UCLA.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Dybvig's extend-syntax is a natural for your problem: (extend-syntax (set) ( (set x y) (set! x y) )) -- David  Received: from clash.cisco.com (TCP 30007603430) by MC.LCS.MIT.EDU 8 May 88 21:03:13 EDT Received: from clash.cisco.com by clash.cisco.com with TCP; Sun, 8 May 88 17:59:40 PDT To: scheme@mc.lcs.mit.edu, scheme-request@mc.lcs.mit.edu Cc: bruce%hpda@hplabs.hp.com, sdawkins%hpda@hplabs.hp.com Subject: Please remove me. Date: Sun, 08 May 88 17:59:38 PDT From: cire@clash.cisco.com Sorry about troubling the entire list with this request. I have been trying for some time now to get removed from this list. I left my previous position a little while ago and the people I've left behind are still getting deluged. Please please please. Remove me from the scheme list. Also remove cire@hpda or cire%hpda@hplabs.hp.com or ucbvax!hpda!cire. Thanks, -c cire|eric Eric B. Decker cisco Systems Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415 326-1941  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 7 May 88 17:46:21 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sat, 7 May 88 11:35:12 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 4 May 88 22:43:54 GMT From: mcvax!ukc!its63b!aiva!jeff@uunet.uu.net (Jeff Dalton) Organization: Dept. of AI, Univ. of Edinburgh, UK Subject: Re: siod release 1.3 Message-Id: <397@aiva.ed.ac.uk> References: <8805020148.AA18536@bu-it.BU.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <8805020148.AA18536@bu-it.BU.EDU> gjc@BU-IT.BU.EDU (George J. Carrette) writes: >Those unable to FTP who requested direct mail have been sent four messages >today containing the siod sources and a test message. I have a copy of siod 1.3 and can make it available to sites with JANet addresses in the UK. Thanks to George for writing the thing. Jeff Dalton, JANET: J.Dalton@uk.ac.ed AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 7 May 88 17:45:46 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sat, 7 May 88 16:19:24 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 7 May 88 17:40:57 GMT From: pierce@locus.ucla.edu Organization: UCLA Computer Science Department Subject: Re : set in Scheme Message-Id: <12073@shemp.CS.UCLA.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Sorry about the last message, I wrote the set macro down a little too fast and it clearly won't work as intended. I meant to say something like this: (macro set (lambda (e) (list 'eval (list 'list ''set! (list 'eval (list 'quote (cadr e))) (list 'quote (caddr e)))))) Then if you (define a 's) (define s 'any) (define b 'r) the effect of (set a b) should be to assign the value r to s. So far so good. But what about this function? (define foo (lambda (x y) (set x y))) If we (define s 'any) then the effect of (foo a b) is the same as above. Judging by my last posting, this may not be perfect either, but at least it's a lot closer. I'd be interested in seeing a shorter or better solution. Thanks for your patience. -- Brad Pierce  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 7 May 88 03:15:13 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sat, 7 May 88 01:59:43 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 6 May 88 19:27:02 GMT From: pierce@locus.ucla.edu Organization: UCLA Computer Science Department Subject: Re : set in Scheme Message-Id: <12063@shemp.CS.UCLA.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In reply to David Chin about "set in Scheme". I'd have to agree with Pavel that it's better to recode without passing around different symbols. However, there's a lot of code out there, UCILISP for natural language processing for example, which uses "set" all over the place. If you just want to get some simple examples from a text or article running, you may not consider it worth your time to recode everything; fortunately the problems described by Pavel may not be that critical either for this type of code. If so, why not just forget about elegance for a little while and save yourself some trouble. Just hack out a horrible little ugly macro like the following: (macro set (lambda (e) `(eval ,`(set! ,(eval (cadr e)) ,(caddr e))))) But I don't think I'd be "sticking my neck out" by saying that THIS doesn't adhere to the "Scheme philosophy", so I would use it only in emergencies. -- Brad Pierce  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 6 May 88 17:02:41 EDT Date: Fri, 6 May 88 12:12:07 EDT From: Jonathan A Rees Subject: set in Scheme? To: uhccux!chin@HUMU.NOSC.MIL cc: scheme@MC.LCS.MIT.EDU In-reply-to: Msg of 5 May 88 21:58:28 GMT from uhccux!chin at humu.nosc.mil (David Chin) Message-ID: <372083.880506.JAR@AI.AI.MIT.EDU> Date: 5 May 88 21:58:28 GMT From: uhccux!chin at humu.nosc.mil (David Chin) Does anyone know how to do the equivalent of a Common Lisp "set" in Scheme. In particular, I would like to be able to pass different symbols as arguments to a function and then set! or define them inside the function. Is this style of programming (global side-effects for function calls) contrary to the Scheme philosophy? Don't pass the symbol, pass a closure that will assign the variable: (foo (lambda (new-value) (set! var new-value))) If you also need to get the value of the variable, or find out its name, pass an object that can do any operations that need doing: (foo (lambda (operation) (case operation ((value) var) ((set-value!) (lambda (new-value) (set! var new-value))) ((name) 'var)))) Global side effects are not contrary to "scheme philosophy" (although they are discouraged), but confusing variables with their names is.  Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 6 May 88 16:21:52 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 06 MAY 88 11:53:44 PDT Date: 6 May 88 11:53 PDT From: fischer.pa@Xerox.COM Subject: Re: Declarations and speed In-reply-to: Stephen Robbins 's message of Thu, 5 May 88 10:01 EDT In-reply-to: Jon L White 's message of Thu, 5 May 88 17:59:36 PDT To: Stever@WAIKATO.S4CC.Symbolics.COM, edsel!jonl@labrea.stanford.edu cc: jinx@zurich.ai.mit.edu, cph@zurich.ai.mit.edu, scheme@mc.lcs.mit.edu Message-ID: <880506-115344-4357@Xerox> Declarations, of themselves, do not obscurity make. Having to model their effect on performance is painful. What is unfathomable, both in C and Lisp, is the exact effect a given set of declarations will have on your code. For this you must either simulate the compiler's heuristics in your head or (more commonly) look at the machine code. Not a pleasant solution, but the only one todays' s/w technology offers. We could really use a more graceful interface to the machine that doesn't assume ignorance. Typically Lisp heaps more complexity on understanding performance with its memory management, although the swift will usually recycle structure when possible and forget it only when neccessary. (ron)  Received: from LISPERANTO.BBN.COM (TCP 20026201075) by MC.LCS.MIT.EDU 6 May 88 13:22:07 EDT To: HAILPERIN@SUMEX-AIM.STANFORD.EDU CC: scheme@MC.LCS.MIT.EDU In-reply-to: Max Hailperin's message of Thu, 5 May 88 08:27:19 PDT <12395909997.20.HAILPERIN@SUMEX-AIM.Stanford.EDU> Subject: Thanks for CScheme; I like it Date: Fri, 6 May 88 12:29:02 EDT From: allen@LISPERANTO.BBN.COM Sender: allen@LISPERANTO.BBN.COM I would like to second this motion. I am the manager of the group that has developed Butterfly Lisp, for the BBN Butterfly multiprocessor. Butterfly Lisp is based on CScheme and we have worked closely with the software and with the people who built it for about 3 years now. Of course the system has its flaws (though just what they are is itself debatable), many of which I attribute to its unusual history: beginning life in silicon, and moving to machine code and then to C (I'll leave it to others to decide whether this represents progress). I consider none of the "flaws" fatal -- they mostly just hair up the interpreter a bit (e.g., the s-code abstraction, which I suspect would not reappear if the system were being designed today for implementation in software, with a native-code compiler, rather than as an interpreter implemented directly in hardware). On the whole, however, we have found the system to be quality software, designed and implemented with care, and robust and highly functional in use. With the advent of the compiler, performance is beginning to approach that of fast Lisp/Scheme implementations (such as T/Orbit), and where it doesn't, the problems are understood and in the process of being fixed (mostly open-coding of arithmetic operations). I do not believe that the performance issues that tend to get flamed about (high-tag, passing args on the stack) will amount to as much (on 680x0-based hardware) as some people seem to believe -- as Chris mentioned, this belief is supported, in part, by experiment and measurement, not conjecture. And speaking of flames, I would like to register my vote for basic civility in our discussions -- questions were raised here that would have been a lot more fun to debate if the initial messages had been less acrimonious. /Don Allen  Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 6 May 88 13:16:45 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 06 MAY 88 10:07:44 PDT Date: Fri, 6 May 88 10:03:38 PDT From: Pavel.pa@Xerox.COM Subject: Re: set in Scheme? In-reply-to: <1822@uhccux.UUCP> To: scheme@mc.lcs.mit.edu Message-ID: <880506-100744-4063@Xerox> David Chin asks, ``Does anyone know how to do the equivalent of a Common Lisp "set" in Scheme? In particular, I would like to be able to pass different symbols as arguments to a function and then set! or define them inside the function. Is this style of programming (global side-effects for function calls) contrary to the Scheme philosophy?'' I won't stick my neck out by claiming to speak for ``the Scheme philosophy'', but I will point out some semantic difficulties with this idea. The problem is that in most Schemes there is no single ``global'' value for a symbol. Rather, there are a set of environments in which each symbol is bound to a corresponding set of values. Thus, it is difficult to know what such a ``set''-like operator would do. Most Schemes with multiple first-class environments, however, do provide a way to define or set! a symbol in a *particular* environment. For example, the T dialect has the procedure *LSET for this purpose. For your application, perhaps you can change things so that, rather than passing symbols around, you pass procedures of one argument that set a particular variable to the value of that argument. Thus, rather than passing the symbol FOO around, you might pass this procedure: (lambda (v) (set! foo v)) The receiving procedure would then simply apply its argument to the desired value, as opposed to calling the non-existent ``set'' operation. Hope this helps, Pavel  Received: from labrea.stanford.edu (TCP 4402000057) by MC.LCS.MIT.EDU 6 May 88 06:59:14 EDT Received: by labrea.stanford.edu; Thu, 5 May 88 20:37:49 PDT Received: from bhopal.lucid.com by edsel id AA07249g; Thu, 5 May 88 20:25:46 PDT Received: by bhopal id AA29976g; Thu, 5 May 88 20:28:25 PDT Date: Thu, 5 May 88 20:28:25 PDT From: Jon L White Message-Id: <8805060328.AA29976@bhopal.lucid.com> To: labrea!jinx@zurich.ai.mit.edu Cc: scheme@mc.lcs.mit.edu In-Reply-To: Guillermo J. Rozas's message of Thu, 5 May 88 15:55:24 edt <8805051955.AA00668@chamarti> Subject: [jinx@CHAMARTIN.AI.MIT.EDU: Extending the address space of MIT Cscheme (long reply)] re: The sad fact of life is that most of the Lisp community does not care about numeric code, and the few exceptions in the community are rare and seen as odd birds. The only widespread Lisp compiler that has provided good performance (MacLisp) required (from what I've heard) over 10 man-years of implementation (by JONL, you (GLS), and others). Ah, 10 man-years! [really, I don't think it was that much for MacLisp, but it certainly wasn't a sophmore's term project]. The sadder fact is how often, during the past 30 years of Lisp existence, that the total cost of producing a high-quality compiler and system has been grossly underestimated. At least one world-class company in Germany is reported to have embarked on a Common Lisp effort with an adequate understanding of the level of effort required. But that's just about the only one I know of; almost every other case I'm aware of is off -- on the low side -- by a factor of two or more. Say, didn't Chris mention about 10 man-years of development on CScheme, and still not much of a compiler yet? Applause for his candor. A few Lisp efforts took someone else's working, and highly portable, Lisp compiler and produced from that a working Lisp compiler for their operating-system/machine. Ocasionally I've heard someone publicly boast that he wrote "the compiler" in well under a man-year, when in fact I know it to be a case like this. But even this piggy-backing of compilers is a job whose level of effort is often underestimated. -- JonL -- P.S. I'd like to throw in the name Rod Brooks -- although he isn't one of the "others" you mention above, he was a principal on the S1 Lisp development, and he is (I would say) the principal developer of the Lucid compiler. If Quux and I et. al. are odd birds, then so is Rod.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 6 May 88 05:35:15 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Fri, 6 May 88 02:31:03 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 4 May 88 18:24:01 GMT From: mcvax!ukc!its63b!aiva!jeff@uunet.uu.net (Jeff Dalton) Organization: Dept. of AI, Univ. of Edinburgh, UK Subject: Re: compatibility/elegance & *theory* Message-Id: <395@aiva.ed.ac.uk> References: <365@aiva.ed.ac.uk>, <385@aiva.ed.ac.uk>, <922@cresswell.quintus.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu The frist 4 paragraphs or so are a review of the story so far... The original question was whether it is possible to write a correct (and complete) automatic conversion program from Prolog (or Lisp) to assembler. It was pointed out (by OK and perhaps others) that this was not possible because call/1 (in Prolog) or EVAL (in Lisp) could use arbitrary data ("source code representations") as code and so would require that the "conversion" include an interpreter for the language -- the conversion wouldn't be complete for further conversions might be required. I then suggested that Lisp's APPLY was less troublesome in this regard that call/1 or EVAL because it just called a function (which is a kind of data objetc in Lisp) rather than process some source representation that might turn out to do anything whatsoever. Richard replied that call/1 was just APPLY, not EVAL. [Aside: it isn't always implemented that way. Sometimes call/1 is an interpreter rather than having the "interpretation" put off into "fexprs" such as ','/2.] I replied that call/1 takes (and in Prolog must take) the name of a procedure while APPLY can take the actual procedure and that this causes problems for some kinds of Prolog module systems. It turns out that this name vs. procedure point isn't quite the right one though: see below. In article <922@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >There are two differences between EVAL and APPLY >(1) EVAL evaluates the arguments of its argument, APPLY does not. > In this respect, call/1 resembles APPLY, not EVAL. call/1 as such > does not do any interpretation other than to locate the predicate > which is to be called. >(2) EVAL is given (a form in which there occurs) the _name_ of a function, > not the function itself, APPLY is given a function pointer/closure &c. > In this respect call/1 resembles EVAL, not APPLY. There is no Prolog > object which "directly" represents a predicate. > >I have always regarded the essential feature of EVAL as being (1), and >have regarded (2) as a detail of implementation, so I understood "is >basically an EVAL" to mean "is like an interpreter which is responsible >for evaluating sub-forms". That is what is false. The question of whether APPLY accepts procedures or (also) procedure names is one of the key differences between Scheme and other Lisps such as Franz and CL. It is one way in which Scheme makes a clearer distinction between procedures and source representations. By saying call/1 is basically an EVAL, I meant that it brings in the problems that EVAL does while APPLY does not. One of these problems is that procedure names can be passed around rather than procedures. Then you may have do decide at call time which module to dereference the name in unless (as in Common Lisp packages) the module information is part of the name. So this is a problem. But it's not the right problem, or at least not all of it. The right problem is that EVAL means you can never completely translate Lisp without supplying an EVAL on the object side too. Call/1 shares this problem. APPLY, defined as in Scheme, does not because (a) You can call procedures but not, say, lists like (LAMBDA (X) ...). So you can't build an arbitrary expression as a list and then call APPLY to get that list evaluated. (b) You can't call fexprs, only functions of the normal sort. So you can't say (apply if '(t )) Richard's explanation of call/1 shows that it can do this. >Jeff Dalton is quite right about (2), and as he points out, you _do_ >have to work a bit to make a module system and call/1 work together. By the way, Richard, are you still opposed to the so-called atom-based module schemes? I suppose it should be a separate topic... >If Prolog were typed, with the void/N type constructor as Alan >Mycroft suggested, it would be possible to have a version of call/1 >which resembled APPLY in both respects. Tell me more. Jeff Dalton, JANET: J.Dalton@uk.ac.ed AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 6 May 88 05:29:35 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Fri, 6 May 88 05:04:11 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 5 May 88 21:58:28 GMT From: uhccux!chin@humu.nosc.mil (David Chin) Organization: U. of Hawaii, Manoa (Honolulu) Subject: set in Scheme? Message-Id: <1822@uhccux.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anyone know how to do the equivalent of a Common Lisp "set" in Scheme. In particular, I would like to be able to pass different symbols as arguments to a function and then set! or define them inside the function. Is this style of programming (global side-effects for function calls) contrary to the Scheme philosophy? Thanks, David Chin David_N_Chin@Hawaii.Edu (Internet)  Received: from NSS.Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 6 May 88 01:19:20 EDT Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa08679; 5 May 88 19:54 BST From: Jeff Dalton Date: Thu, 5 May 88 19:54:29 bst Message-Id: <24707.8805051854@aiva.ed.ac.uk> To: jinx@zurich.ai.mit.edu, shebs <@cs.utah.edu:shebs@defun> Subject: Re: Extending the address space of MIT Cscheme (long reply) Cc: scheme@mc.lcs.mit.edu > Date: Thu, 5 May 88 08:32:54 MDT > From: shebs <(Stanley T. Shebs)shebs%defun@edu.utah.cs> > These two statements seem contradictory - first you're saying that > there is no attempt to make things as fast as compiled code, but that > using functions instead of macros exacts an undue penalty. I don't > understand! Not as fast as compiled code but faster than it would be otherwise. -- Jeff  Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 5 May 88 23:14:01 EDT Received: from bucsf (BUCSF.BU.EDU) by bu-it.BU.EDU (4.0/4.7) id AA20558; Thu, 5 May 88 18:15:20 EDT Return-Path: Received: by bucsf (4.12/4.7) id AA24411; Thu, 5 May 88 18:16:31 edt Date: Thu, 5 May 88 18:16:31 edt From: gjc%bucsf.BU.EDU@bu-it.BU.EDU (George J. Carrette) Message-Id: <8805052216.AA24411@bucsf> To: scheme@mc.lcs.mit.edu Subject: C and Cscheme. I actually believe that good programmers are good programmers, and bad programmers are bad programmers, no matter what language they program in. The UBERPROGRAMMER has mastery over many languages and can learn a new one and start programming in it in less than 15 minutes. Personally, knowing the people that worked on CScheme, I think they would have been happier with a more powerful (as far as the ability to express statements that better cover the output domain of the compiler, which in this case is the machine architecture, or instruction set) and abstract language such as BLISS. (Quite possible, since the first development happened on TOPS-20 and VMS). But I'm sure that everybody is happy that it is in C, since it was intended to be ported without first porting a compiler! Now this might be a secret, but there are famous people, well know for promulgating the use of lisp, either by founding LISPMACHINE companies, or writing books, etc, who do quite a bit of programming in C and/or FORTRAN. Enquiring People Want to Know! (Motto of National Enquirer, info for you sheltered types) -gjc  Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 5 May 88 23:13:47 EDT Received: from bucsf (BUCSF.BU.EDU) by bu-it.BU.EDU (4.0/4.7) id AA21731; Thu, 5 May 88 18:33:32 EDT Return-Path: Received: by bucsf (4.12/4.7) id AA19995; Thu, 5 May 88 18:34:43 edt Date: Thu, 5 May 88 18:34:43 edt From: gjc%bucsf.BU.EDU@bu-it.BU.EDU (George J. Carrette) Message-Id: <8805052234.AA19995@bucsf> To: jinx@zurich.ai.mit.edu Cc: scheme@mc.lcs.mit.edu Subject: Maclisp revisited. Through the intervention of the Macsyma->Lisp translator which I did extensive work on and with in the days when the Macsyma Consortium had hundreds of active users, I can say I produced my share of heavy numerical code usage in Maclisp. In fact, we Plasma Fusion hackers knew well the trade of between a quick-turn-around hack in maclisp or macsyma and a heavy run in Fortran on the CRAY-1 at the MFE center at Lawrence Livermore Labs. It was not unusual for a person using that KL-10 with Maclisp and a knowlege of applicable numerical programming techniques to come up with a physically meaningful result before the guy in the next office using the CRAY-1 was able to. Of course, one would hope that we always made sure the results checked before going to publication. It is indeed sad but true that no machine/lisp implementation I have used in the ten years since has quite matched that performance. Lispmachines came very close, but that is another story. I disagree strongly however that it is actually DIFFICULT to get good number complication in Lisp. Not great, just good. Maclisp was good, not great, and that worked out just fine. The amount work supposedly put into the Maclisp compiler is not a valid measure of how much work it would be to do something equivalent today. Anyway, in a couple months DOE-Macsyma will be producing as good numerical code in a lisp enviroment (in lisp of course) as in the PDP-10 days. There actually are some decent numerical lisp's out there. -gjc  Received: from labrea.stanford.edu (TCP 4402000057) by MC.LCS.MIT.EDU 5 May 88 22:56:42 EDT Received: by labrea.stanford.edu; Thu, 5 May 88 18:14:14 PDT Received: from bhopal.lucid.com by edsel id AA06333g; Thu, 5 May 88 17:56:58 PDT Received: by bhopal id AA29419g; Thu, 5 May 88 17:59:36 PDT Date: Thu, 5 May 88 17:59:36 PDT From: Jon L White Message-Id: <8805060059.AA29419@bhopal.lucid.com> To: labrea!jinx@zurich.ai.mit.edu Cc: shebs%defun@cs.utah.edu, cph@zurich.ai.mit.edu, scheme@mc.lcs.mit.edu In-Reply-To: Guillermo J. Rozas's message of Wed, 4 May 88 22:02:40 edt <8805050202.AA29123@chamarti> Subject: Extending the address space of MIT Cscheme (long reply) re: . . . What's wrong with coding a commonly used procedure in a language which will make it more efficient? Please show me a Lisp which can compete with C in this regard. If you manage to do this, I strongly suspect that the number of arcane declarations in the Lisp code will make it at least as unreadable as C, so you're no better off. Two points: (1) nothing is wrong with coding an essentially numerical algorithm in the language classically used to code numerical algorithms (such as FORTRAN/ALGOL/ADA/PASCAL/C etc). That's one reason why "industrial strength" Common Lisps have a convenient foreign function interface. [see article in most recent issue of Lisp Pointers] (2) Here are names of two generally available Lisps which can frequently compete with C in writing numerical code like FFT: PDP10 MacLisp and Lucid Common Lisp. Furthermore, I challenge your presumption that any such Lisp-written code will be unintelligible due to "arcane" declarations [mostly I challenge the underlying assumption (if in fact you are making it) that *any* declarations in Lisp are "arcane".] While it is true that most variables in such a program will be declared of type fixnum, or float, or array-of-float (and some function types will be proclaimed too), the number of source lines of code devoted to such declarations, compared to the total amount of source code, is down in the noise. Looking ahead in the mails, I see that GLS has already sent out references to the early successes of MacLisp (1973!). It would be difficult for me to say more about Lucid Common Lisp now without appearing to be self- serving; suffice it to say that you could contact me privately, or RPG@SAIL, and ask for substantiation of the above statements. -- JonL -- P.S. I suspect that ZetaLisp on a Lisp Machine produces numerical code that competes with C/FORTRAN on such machines (to my knowledge, only Symbolics has such compilers -- but I really don't know about TI and the now-defunct LMI). You must have meant "a Lisp which can compete with C" on stock hardware.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 5 May 88 22:39:03 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Thu, 5 May 88 16:25:48 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 5 May 88 14:50:16 GMT From: THINK.COM!gls@ucbvax.berkeley.edu Organization: The Internet Subject: Extending the address space of MIT Cscheme (semi-long reply) Message-Id: <8805051450.AA03093@kali.think.com> References: <8805040747.AA21368@kleph> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Date: Wed, 4 May 88 03:47:10 edt From: cph@kleph.ai.mit.edu (Chris Hanson) Reply-To: cph@zurich.ai.mit.edu * We have virtually no documentation. This is obviously a terrible thing, and we are in fact generating some. But the bottom line for this is simply lack of time, plus the fact that none of us has much text writing experience. I have not seen the code for CScheme, and did not particularly want to jump into the middle of this flame, but I have a set of points to make about documentation in general, as one who has written a lot of a code for publication and also a lot of text. (1) The way you get experience at writing text is to write text. (When you first started programming you didn't have much experience at programming, either, but you obviously didn't let *that* stop you.) (2) Lack of documentation often stems from the belief that the code is so clear to you (because you've got it all in your head) that you'll have no trouble remembering what's going on six months from now. This belief is invariably false. Even if you don't want to write documentation for other people, write it for the you of six months from now, becase by then you'll be a different person too. (3) Writing documentation usually *saves* time in the programming process, because it takes less time to review design decisions and rediscover how little details work. (4) The writing of documentation actually *improves* the code. The reason is that it is usually easier to clean up a crock than to have to explain it. I have seen this phenomenon hundreds of times in programs of all kinds. I'm not saying that everyone should write documentation the way Knuth did for TeX. I am saying that documentation has a direct intrinsic value to the programming process, and that lack of experience in no excuse. --Best regards, Guy  Received: from SUMEX-AIM.Stanford.EDU (TCP 1200000070) by MC.LCS.MIT.EDU 5 May 88 16:52:30 EDT Date: Thu, 5 May 88 08:27:19 PDT From: Max Hailperin Subject: Thanks for CScheme; I like it To: scheme@mc.lcs.mit.edu Message-ID: <12395909997.20.HAILPERIN@SUMEX-AIM.Stanford.EDU> I can't speak with the authority of GJS, but I am an outside user who has benefited from the decision to export CScheme, imperfections and all, so let me say this: I am extremely grateful to MIT for making this system available. I would feel very uneasy turning my introductory-course students loose on any implementation with a less transparent debugging environment. My attempts at understanding the code have always been quite bareable, certainly relative to what I paid. Thanks so much for this valuable contributiion, and please don't let a few naysayers discourage you from sharing with the rest of us in the future. -------  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 5 May 88 16:44:37 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Thu, 5 May 88 16:30:50 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 5 May 88 15:04:03 GMT From: CS.UTAH.EDU!shebs%defun@ucbvax.berkeley.edu (Stanley T. Shebs) Organization: The Internet Subject: Re: Unpleasantness Message-Id: <8805051504.AA03035@defun.utah.edu> References: <8805050232.AA03440@zohar> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu > Usually I refrain from becoming involved in squabbles about the >apparent quality of one or another person's code. I can remember such >arguments when I was very small -- something of the form "My daddy is >bigger and stronger than your daddy.", so it usually feels a bit >childish to fight about things like that. I suppose we really belong to different communities. In the community I come from, "apparent quality" of code is a serious issue, possibly involving multi-million dollar expenses, so it doesn't seem particularly "childish" to discuss such matters. In the Scheme community, the same issue seems to be considered unimportant, and I apologize for bringing it up and being unnecessarily disruptive. >In this case, however, you >have said some rather unpleasant things about very good friends of >mine, and they are feeling quite bad about it, so I feel compelled to >respond. Again, I'm sorry to have insulted anybody - that was not my intention. >[...] I also suggest that if you want to >fight out the technical details I will be pleased to meet with you at >the Lisp Conference in Snowbird. Perhaps we will both learn something >useful in that context. Perhaps - although I'm afraid our viewpoints are too different. For example, (now I'm going to get flamed!), I find the differences between Scheme and Common Lisp to be mostly uninteresting, but consider that the design of efficient implementations is the most critical issue facing Lisp dialects today. If you are still willing to communicate given all that, I would be very pleased to do so! stan  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 5 May 88 16:14:24 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Thu, 5 May 88 15:59:56 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 5 May 88 14:23:49 GMT From: aiva.edinburgh.ac.UK!jeff@ucbvax.berkeley.edu (Jeff Dalton) Organization: The Internet Subject: Re: Extending the address space of MIT Cscheme Message-Id: <21122.8805051423@aiva.ed.ac.uk> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu > Date: Wed, 4 May 88 11:12:23 MDT > From: shebs <(Stanley T. Shebs)shebs%defun@edu.utah.cs> > Attempts to optimize the C code implementing a virtual machine. If > you use a virtual machine, you've already lost speedwise; doing > complicated C hacks isn't going to recover much for you. (Presumably > that's the reason for hundreds of C macros that could have been > function calls.) C hacks (if you want to call them that) can make a difference, particularly (on many machines) if they let you avoid procedure calls (slow call instructions, parameters moved from registers to stack and back). In-line procedures would be better than C macros, but C doesn't have them.  Received: from chamarti (TCP 2206400253) by MC.LCS.MIT.EDU 5 May 88 16:14:09 EDT Received: by CHAMARTIN.AI.MIT.EDU; Thu, 5 May 88 15:54:10 edt Date: Thu, 5 May 88 15:54:10 edt From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas) Message-Id: <8805051954.AA00661@chamarti> To: scheme@mc.lcs.mit.edu Subject: [jinx@CHAMARTIN.AI.MIT.EDU: Extending the address space of MIT Cscheme (long reply)] Reply-To: jinx@zurich.ai.mit.edu Date: Thu, 5 May 88 15:28:29 edt From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas) To: shebs%defun@cs.utah.edu In-Reply-To: Stanley T. Shebs's message of Thu, 5 May 88 08:32:54 MDT <8805051432.AA02983@defun.utah.edu> Subject: Extending the address space of MIT Cscheme (long reply) Reply-To: jinx@zurich.ai.mit.edu I was suggesting user-defined types, a la DEFSTRUCT. Some types are just not "important" enough to be made into primitives. User-defined types are such an important abstraction it's surprising to see CScheme not use them; it would save a lot in the many switch statements on types. CScheme has a defstruct-like macro (define-structure). Most of the types you saw in the C files are used by the implementation as GJS implied. An altogether different question is whether defstruct really provides (relatively opaque) types or merely convenient syntax for constructors, selectors and mutators for standard types. >1) Using a virtual machine is a common technique these days to >implement interpreters. We have made no claim that our interpreter >will run code as fast as code produced by native code compilers. Thus >there is no attempt to make the CScheme interpreter run as fast as >anybody else's compiled code. As far as interpreters go, it's not >great, but it's not bad in terms of speed, but provides much more >convenience and ease of debugging than any other interpreter I know. > >2) Most of the hairy C and macrology arise not from using a virtual >machine, but from the fact that the PARTICULAR virtual machine we >chose cannot be conveniently written in C without paying an undue >penalty. These two statements seem contradictory - first you're saying that there is no attempt to make things as fast as compiled code, but that using functions instead of macros exacts an undue penalty. I don't understand! They are not contradictory. The first version of the C Scheme interpreter ran about 4 times slower than the assembly language version on the same hardware. We were not attempting to achieve native code speed, merely regain the penalty imposed by naively coding in C. I found the check for the *necessity* of GC, and it was in the same place that most other implementations put it. What I didn't find was how the check actually got a GC going! No doubt it will seem straightforward to me too, once it's pointed out... The relevant macros are (in microcode/primitive.h and microcode/gc.h) #define Primitive_GC(Amount) \ { \ Request_GC (Amount); \ Primitive_Interrupt (); \ } #define Primitive_Interrupt signal_interrupt_from_primitive #define Request_GC(Amount) \ { \ REQUEST_INTERRUPT(INT_GC); \ GC_Space_Needed = Amount; \ } where signal_interrupt_from_primitive is a procedure in microcode/utils.c. I would hardly call this a maze. A good cross-reference program could easily help you sort this one out. Even grep suffices most of the time, and certainly in this case. > References to the compiler and Edwin, thus violating every principle of > abstraction known to exist. > >What? Please explain, I don't understand what that means. I'm speaking of edwin.h and com*.c. Why are they for? I don't believe that the fact that you don't know what they are for implies that some abstraction principles have been violated. compiler.c and related files are various hooks for the compiler. The default version of the system assumes that there is no compiler, so the hooks are just stubs. When the compiler is ported to a new machine/operating system, appropriate versions of these files are written reflecting some of the machine-dependent decisions made, and implementing the compiled code interface to the interpreter. It is a relatively simple and innocuous way of providing a system which can coexist with the compiler but does not require its presence. edwin.h is a spurious part of the release. rgxprim.c and syntax.c (which are the only files that need it) are files essentially taken from GNU Emacs, and could easily be spliced out of the load sequence since the system does not use them. A problem that must be faced when attempting to write a (relatively) portable EXTENSIBLE C program is that there is no standardized dynamic loader for C, so all of the C code that you may ever want to use must be linked to your interpreter at interpreter generation time. We could have attempted to write a dynamic linker for C, but the resulting system would probably have been far less portable, and even harder to read.  Received: from chamarti (TCP 2206400253) by MC.LCS.MIT.EDU 5 May 88 16:13:36 EDT Received: by CHAMARTIN.AI.MIT.EDU; Thu, 5 May 88 15:55:24 edt Date: Thu, 5 May 88 15:55:24 edt From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas) Message-Id: <8805051955.AA00668@chamarti> To: scheme@mc.lcs.mit.edu Subject: [jinx@CHAMARTIN.AI.MIT.EDU: Extending the address space of MIT Cscheme (long reply)] Reply-To: jinx@zurich.ai.mit.edu Date: Thu, 5 May 88 15:36:01 edt From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas) To: gls@Think.COM Cc: Stever@waikato.s4cc.symbolics.com, cph@zurich.ai.mit.edu In-Reply-To: gls@Think.COM's message of Thu, 5 May 88 12:15:17 EDT <8805051615.AA03188@kali.think.com> Subject: Extending the address space of MIT Cscheme (long reply) Reply-To: jinx@zurich.ai.mit.edu I was under the impression that LISP's numeric inefficiency was, in general, a fallacy. Didn't MacLISP generate better numeric code than DEC's FORTRAN, some years back? - Stephen See, for example, the following two references: Fateman, Richard J. "Reply to an Editorial." ACM SIGSAM Bulletin 25 (March 1973), 9-11. Brooks, Rodney A., Gabriel, Richard P., and Steele, Guy L., Jr. An optimizing compiler for lexically scoped LISP. Proceedings of the 1982 Symposium on Compiler Construction. ACM SIGPLAN (Boston, June 1982), 261-275. Proceedings published as ACM SIGPLAN Notices 17, 6 (June 1982). MacLisp is, unfortunately, essentially dead, and S-1 Lisp (as far as I know) only ran on the S-1. I'm not claiming that this task is impossible (I know it isn't and one of the current main goals in the MIT Scheme project is improving the efficiency of numeric code), merely that I don't believe there are widespread implementations running on stock hardware which can compete RIGHT NOW. I hope I'm wrong, but I fear I'm not. The sad fact of life is that most of the Lisp community does not care about numeric code, and the few exceptions in the community are rare and seen as odd birds. The only widespread Lisp compiler that has provided good performance (MacLisp) required (from what I've heard) over 10 man-years of implementation (by JONL, you (GLS), and others). Most Lisp compiler writers have not attempted to match this, and often good performance is obtained only by using arcane declarations which only implementors can manage.  Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 5 May 88 12:45:03 EDT Return-Path: Received: from kali.think.com by Think.COM; Thu, 5 May 88 12:15:20 EDT Received: by kali.think.com; Thu, 5 May 88 12:15:17 EDT Date: Thu, 5 May 88 12:15:17 EDT From: gls@Think.COM Message-Id: <8805051615.AA03188@kali.think.com> To: Stever@waikato.s4cc.symbolics.com Cc: jinx@zurich.ai.mit.edu, cph@zurich.ai.mit.edu, scheme@mc.lcs.mit.edu In-Reply-To: Stephen Robbins's message of Thu, 5 May 88 10:01 EDT <19880505140151.1.STEVER@JEWEL-CAVE.S4CC.Symbolics.COM> Subject: Extending the address space of MIT Cscheme (long reply) Date: Thu, 5 May 88 10:01 EDT From: Stephen Robbins Date: Wed, 4 May 88 22:02:40 edt From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas) ... few Lisp implementations (if any) can currently match the speed that can be obtained from C or FORTRAN in numeric code. What's wrong with coding a commonly used procedure in a language which will make it more efficient? Please show me a Lisp which can compete with C in this regard. If you manage to do this, I strongly suspect that the number of arcane declarations in the Lisp code will make it at least as unreadable as C, so you're no better off. I was under the impression that LISP's numeric inefficiency was, in general, a fallacy. Didn't MacLISP generate better numeric code than DEC's FORTRAN, some years back? - Stephen See, for example, the following two references: Fateman, Richard J. "Reply to an Editorial." ACM SIGSAM Bulletin 25 (March 1973), 9-11. Brooks, Rodney A., Gabriel, Richard P., and Steele, Guy L., Jr. An optimizing compiler for lexically scoped LISP. Proceedings of the 1982 Symposium on Compiler Construction. ACM SIGPLAN (Boston, June 1982), 261-275. Proceedings published as ACM SIGPLAN Notices 17, 6 (June 1982). --Guy  Received: from cs.utah.edu (TCP 1200000004) by MC.LCS.MIT.EDU 5 May 88 11:57:30 EDT Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA09148; Thu, 5 May 88 09:04:07 MDT Received: by defun.utah.edu (5.54/utah-2.0-leaf) id AA03035; Thu, 5 May 88 09:04:03 MDT Date: Thu, 5 May 88 09:04:03 MDT From: shebs%defun@cs.utah.edu (Stanley T. Shebs) Message-Id: <8805051504.AA03035@defun.utah.edu> To: gjs@zohar.ai.mit.edu Cc: shebs%defun@cs.utah.edu, scheme@mc.lcs.mit.edu In-Reply-To: Gerald Jay Sussman's message of Wed, 4 May 88 22:32:08 edt <8805050232.AA03440@zohar> Subject: Re: Unpleasantness > Usually I refrain from becoming involved in squabbles about the >apparent quality of one or another person's code. I can remember such >arguments when I was very small -- something of the form "My daddy is >bigger and stronger than your daddy.", so it usually feels a bit >childish to fight about things like that. I suppose we really belong to different communities. In the community I come from, "apparent quality" of code is a serious issue, possibly involving multi-million dollar expenses, so it doesn't seem particularly "childish" to discuss such matters. In the Scheme community, the same issue seems to be considered unimportant, and I apologize for bringing it up and being unnecessarily disruptive. >In this case, however, you >have said some rather unpleasant things about very good friends of >mine, and they are feeling quite bad about it, so I feel compelled to >respond. Again, I'm sorry to have insulted anybody - that was not my intention. >[...] I also suggest that if you want to >fight out the technical details I will be pleased to meet with you at >the Lisp Conference in Snowbird. Perhaps we will both learn something >useful in that context. Perhaps - although I'm afraid our viewpoints are too different. For example, (now I'm going to get flamed!), I find the differences between Scheme and Common Lisp to be mostly uninteresting, but consider that the design of efficient implementations is the most critical issue facing Lisp dialects today. If you are still willing to communicate given all that, I would be very pleased to do so! stan  Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 5 May 88 10:53:08 EDT Return-Path: Received: from kali.think.com by Think.COM; Thu, 5 May 88 10:50:19 EDT Received: by kali.think.com; Thu, 5 May 88 10:50:16 EDT Date: Thu, 5 May 88 10:50:16 EDT From: gls@Think.COM Message-Id: <8805051450.AA03093@kali.think.com> To: cph@zurich.ai.mit.edu Cc: defun.utah.edu!shebs@cs.utah.edu, scheme@mc.lcs.mit.edu In-Reply-To: Chris Hanson's message of Wed, 4 May 88 03:47:10 edt <8805040747.AA21368@kleph> Subject: Extending the address space of MIT Cscheme (semi-long reply) Date: Wed, 4 May 88 03:47:10 edt From: cph@kleph.ai.mit.edu (Chris Hanson) Reply-To: cph@zurich.ai.mit.edu * We have virtually no documentation. This is obviously a terrible thing, and we are in fact generating some. But the bottom line for this is simply lack of time, plus the fact that none of us has much text writing experience. I have not seen the code for CScheme, and did not particularly want to jump into the middle of this flame, but I have a set of points to make about documentation in general, as one who has written a lot of a code for publication and also a lot of text. (1) The way you get experience at writing text is to write text. (When you first started programming you didn't have much experience at programming, either, but you obviously didn't let *that* stop you.) (2) Lack of documentation often stems from the belief that the code is so clear to you (because you've got it all in your head) that you'll have no trouble remembering what's going on six months from now. This belief is invariably false. Even if you don't want to write documentation for other people, write it for the you of six months from now, becase by then you'll be a different person too. (3) Writing documentation usually *saves* time in the programming process, because it takes less time to review design decisions and rediscover how little details work. (4) The writing of documentation actually *improves* the code. The reason is that it is usually easier to clean up a crock than to have to explain it. I have seen this phenomenon hundreds of times in programs of all kinds. I'm not saying that everyone should write documentation the way Knuth did for TeX. I am saying that documentation has a direct intrinsic value to the programming process, and that lack of experience in no excuse. --Best regards, Guy  Received: from NSS.Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 5 May 88 10:34:16 EDT Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa06016; 5 May 88 15:24 BST From: Jeff Dalton Date: Thu, 5 May 88 15:23:49 bst Message-Id: <21122.8805051423@aiva.ed.ac.uk> To: cph@zurich.ai.mit.edu, shebs <@cs.utah.edu:shebs@defun> Subject: Re: Extending the address space of MIT Cscheme Cc: scheme@mc.lcs.mit.edu > Date: Wed, 4 May 88 11:12:23 MDT > From: shebs <(Stanley T. Shebs)shebs%defun@edu.utah.cs> > Attempts to optimize the C code implementing a virtual machine. If > you use a virtual machine, you've already lost speedwise; doing > complicated C hacks isn't going to recover much for you. (Presumably > that's the reason for hundreds of C macros that could have been > function calls.) C hacks (if you want to call them that) can make a difference, particularly (on many machines) if they let you avoid procedure calls (slow call instructions, parameters moved from registers to stack and back). In-line procedures would be better than C macros, but C doesn't have them.  Received: from cs.utah.edu (TCP 1200000004) by MC.LCS.MIT.EDU 5 May 88 10:33:10 EDT Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA08373; Thu, 5 May 88 08:32:58 MDT Received: by defun.utah.edu (5.54/utah-2.0-leaf) id AA02983; Thu, 5 May 88 08:32:54 MDT Date: Thu, 5 May 88 08:32:54 MDT From: shebs%defun@cs.utah.edu (Stanley T. Shebs) Message-Id: <8805051432.AA02983@defun.utah.edu> To: jinx@zurich.ai.mit.edu Cc: scheme@mc.lcs.mit.edu In-Reply-To: Guillermo J. Rozas's message of Wed, 4 May 88 22:02:40 edt <8805050202.AA29123@chamarti> Subject: Re: Extending the address space of MIT Cscheme (long reply) Thanks for your message. It clears up most of my problems with CScheme. > Gazillions of builtin types. > >What's wrong with that? It's nice (and ultimately more robust) to >allow the system to distinguish between various objects with 2, 3, or >more components. I was suggesting user-defined types, a la DEFSTRUCT. Some types are just not "important" enough to be made into primitives. User-defined types are such an important abstraction it's surprising to see CScheme not use them; it would save a lot in the many switch statements on types. >1) Using a virtual machine is a common technique these days to >implement interpreters. We have made no claim that our interpreter >will run code as fast as code produced by native code compilers. Thus >there is no attempt to make the CScheme interpreter run as fast as >anybody else's compiled code. As far as interpreters go, it's not >great, but it's not bad in terms of speed, but provides much more >convenience and ease of debugging than any other interpreter I know. > >2) Most of the hairy C and macrology arise not from using a virtual >machine, but from the fact that the PARTICULAR virtual machine we >chose cannot be conveniently written in C without paying an undue >penalty. These two statements seem contradictory - first you're saying that there is no attempt to make things as fast as compiled code, but that using functions instead of macros exacts an undue penalty. I don't understand! >[...] What's wrong with >coding a commonly used procedure [FFT] in a language which will make it more >efficient? I have no problem with that, but it's the embedding of the procedure in a language implementation that seems strange. There are any number of other ways to provide FFT in C without making it into a primitive function. > References to apparent GC in all kinds of strange places. When I followed > them, the trail disappeared in a maze of macros. > >Hmm. Maybe the Lisps you are used to don't check whether there is >enough space to allocate storage before they go ahead and do it. They >can't be very robust. I'm also surprised that you complain about this >particular "maze". It seems pretty straightforward to me. I found the check for the *necessity* of GC, and it was in the same place that most other implementations put it. What I didn't find was how the check actually got a GC going! No doubt it will seem straightforward to me too, once it's pointed out... > References to the compiler and Edwin, thus violating every principle of > abstraction known to exist. > >What? Please explain, I don't understand what that means. I'm speaking of edwin.h and com*.c. Why are they for?  Received: from WAIKATO.S4CC.Symbolics.COM (TCP 20024231532) by MC.LCS.MIT.EDU 5 May 88 10:02:51 EDT Received: from JEWEL-CAVE.S4CC.Symbolics.COM by WAIKATO.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 176764; Thu 5-May-88 10:02:02 EDT Date: Thu, 5 May 88 10:01 EDT From: Stephen Robbins Subject: Extending the address space of MIT Cscheme (long reply) To: jinx@zurich.ai.mit.edu cc: cph@zurich.ai.mit.edu, scheme@mc.lcs.mit.edu In-Reply-To: <8805050202.AA29123@chamarti> Message-ID: <19880505140151.1.STEVER@JEWEL-CAVE.S4CC.Symbolics.COM> Date: Wed, 4 May 88 22:02:40 edt From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas) ... few Lisp implementations (if any) can currently match the speed that can be obtained from C or FORTRAN in numeric code. What's wrong with coding a commonly used procedure in a language which will make it more efficient? Please show me a Lisp which can compete with C in this regard. If you manage to do this, I strongly suspect that the number of arcane declarations in the Lisp code will make it at least as unreadable as C, so you're no better off. I was under the impression that LISP's numeric inefficiency was, in general, a fallacy. Didn't MacLISP generate better numeric code than DEC's FORTRAN, some years back? - Stephen  Received: from WAIKATO.S4CC.Symbolics.COM (TCP 20024231532) by MC.LCS.MIT.EDU 5 May 88 09:52:14 EDT Received: from JEWEL-CAVE.S4CC.Symbolics.COM by WAIKATO.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 176759; Thu 5-May-88 09:51:14 EDT Date: Thu, 5 May 88 09:50 EDT From: Stephen Robbins Subject: Re: Extending the address space of MIT Cscheme (long reply) To: shebs%defun@cs.utah.edu, cph@zurich.ai.mit.edu cc: scheme@mc.lcs.mit.edu In-Reply-To: <8805041712.AA02219@defun.utah.edu> Message-ID: <19880505135059.9.STEVER@JEWEL-CAVE.S4CC.Symbolics.COM> Date: Wed, 4 May 88 11:12:23 MDT From: shebs%defun@cs.utah.edu (Stanley T. Shebs) Writing nonprimitives in C. My eye happened to fall on list_to_string, which is about three times longer and more complicated in C than in Scheme. What earthly reason could there be for this? I suppose it could be worse; KCL is an example. On the other hand, even KCL doesn't put a Fast Fourier Transform and a regular expression matcher in its C "microcode"... I dunno. The precedents are there. The VAX gives you a FORMAT statement in microcode... :-) I find it odd that haters of C would use macros to the extent that CScheme does. [I'm speaking from the vantage point of someone who has NEVER seen the CScheme sources, but who HAS tried to program abstractly in C] Unfortunately, macros are the only way to do \syntactic/ extensions of the language. I'm currently preparing a short class on code maintainability/writing "good" code. One of the things we examine is why it's hard to do reasonable abstraction in C. Part of the reason is that syntax is tightly tied to representation. The only facility around that is macros. >* We have virtually no documentation. This is obviously a terrible >thing, and we are in fact generating some. But the bottom line for >this is simply lack of time, plus the fact that none of us has much >text writing experience. I hear that excuse from froshes, and don't accept it from them either. Documentation after the fact is inherently inferior, and leaves out important details that the programmers have forgotten about. Still, I do appreciate where you're coming from - it's something that professional SEs have to contend with all the time (my own views have no doubt been colored by one of my first jobs, which was to document 40,000 lines of Fortran written by several other people). A marvelous exercise! I started my programming career working for a man who had me go through various RSTS/E V5 system programs, document them, and rewrite them "modularly." There's nothing like that kind of experience to make "writing code" a superset of "writing documentation" (n.b. a superset; the two aren't disjoint!) In fact, my almost finished thesis is all about the analysis of representation decisions. I'd be \very/ interested in a copy of this. Will they be available online? - Stephen STEVER@RIVERSIDE.SCRC.Symbolics.COM or SCRC-RIVESIDE.ARPA [arpa] stever@ATHENA.MIT.EDU ...!mit-eddie!mit-athena!stever [UUCP] (617) 621-7634 [NYNEX] 4CC 02142-1421 [USPS]  Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 4 May 88 22:27:58 EDT Received: by ZOHAR.AI.MIT.EDU; Wed, 4 May 88 22:32:08 edt Date: Wed, 4 May 88 22:32:08 edt From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman) Message-Id: <8805050232.AA03440@zohar> To: shebs%defun@cs.utah.edu Cc: scheme@mc.lcs.mit.edu In-Reply-To: Stanley T. Shebs's message of Wed, 4 May 88 11:12:23 MDT <8805041712.AA02219@defun.utah.edu> Subject: Unpleasantness Usually I refrain from becoming involved in squabbles about the apparent quality of one or another person's code. I can remember such arguments when I was very small -- something of the form "My daddy is bigger and stronger than your daddy.", so it usually feels a bit childish to fight about things like that. In this case, however, you have said some rather unpleasant things about very good friends of mine, and they are feeling quite bad about it, so I feel compelled to respond. In defense of CScheme. I teach 2 subjects at MIT that use Scheme as an integral part of the methodology of teaching. Abelson and I are in charge of the introductory computer science subject, where we use SICP. This subject serves a population of 700 students each year. Abelson and I also are involved with our introductory subject in Circuits, Signals and Systems, with about 500 students each year. In both of these subjects we use a Scheme system produced by those friends of mine you have insulted. We use CScheme in the CSS subject and a previous version of Scheme written for the HP Pascal P system in the SICP subject. In running such large subjects it is essential that we have excellent software, because even a small problem can become an educational disaster. Thus, I can assert, with considerable experience, that the Scheme software we use is of outstanding quality. It is clean. It is maintainable. It is reliable. I can be sure that when I put out a problem set that the students will not get the system into bad states and that their bugs will be clearly indicated with clear error comments. I can be sure that the Scheme system will not crash, even under the relentless pressure of hundreds of smart undergraduates. You complain about some strange things: Writing nonprimitives in C. My eye happened to fall on list_to_string, which is about three times longer and more complicated in C than in Scheme. What earthly reason could there be for this? I suppose it could be worse; KCL is an example. On the other hand, even KCL doesn't put a Fast Fourier Transform and a regular expression matcher in its C "microcode"... I can see nothing wrong with this, but I am willing to take responsibility for it, since I can explain it rather easily... Even KCL is not used in an introductory subject on Signal Processing. It just so happened that we had an excellent FFT, written in C by Yekta Gursel. I needed a good FFT for my subject, so Panayotis Skordos, one of my star graduate students, who was a teaching assistant for me in the subject, installed a slightly modified version of the Gursel FFT into the CScheme kernel for students to use in the course. It seems to me that we Lispers would be fools not to use good code that we can get from someone else. Do YOU want to write me a procedure that computes Bessel functions? -- I can probably buy a better one from IMSL. In fact, that we can assimilate code not written in Scheme is one of the virtues of the MIT CScheme system. I assert, and I believe that I can do so with authority, that CScheme is an excellent system that reliably and effectively supports teaching of massive subjects at MIT. I have tried a number of other Lisp systems, including PSL, and of those I have tried I have found no other systems, except for possibly TI PC Scheme or Semantic Microsystems' MACScheme that could stand up to this rigorous a test. Strategic Considerations You also object to a number of organizational decisions that were made in CScheme, indicating serious ignorance of the historical context of the system. Gazillions of builtin types. There are twice as many primitive types of objects as any other high-level language that I know of (3- and 4-element hunks? give me a break!). Many could have been built as nonprimitives. See T for good efforts in that direction. Attempts to optimize the C code implementing a virtual machine. If you use a virtual machine, you've already lost speedwise; doing complicated C hacks isn't going to recover much for you. (Presumably that's the reason for hundreds of C macros that could have been function calls.) Again, though I find nothing wrong with virtual machines (note that TI PC Scheme uses a virtual-machine strategy and it is roaringly fast) I am pleased to take responsibility for this. What you do not know is that CScheme evolved from the actual microcode for the Scheme-81 chip, a special-purpose architecture for executing the Scheme SCODE language efficiently. The CScheme system started as a simulator for the actual Scheme-81 machine. The SCODE language is an experimental machine language. The plethora of types you refer to are the opcodes of that language. They have nothing at all to do with the user's types. You should be amazed at CScheme's excellent performance, considering that we had not contemplated running it on a conventional architecture at all. Summary I feel that your allegations are unfounded and ill considered. However, I want you and everyone else to know that I am part of the reason why some of the things you object to came out the way they did. I suggest that we stop arguing about such things in public like little children. I will stop if you do. I also suggest that if you want to fight out the technical details I will be pleased to meet with you at the Lisp Conference in Snowbird. Perhaps we will both learn something useful in that context. Gerald Jay Sussman, Professor of Electrical Engineering, Massachusetts Institute of Technology.  Received: from chamarti (TCP 2206400253) by MC.LCS.MIT.EDU 4 May 88 22:05:08 EDT Received: by CHAMARTIN.AI.MIT.EDU; Wed, 4 May 88 22:02:40 edt Date: Wed, 4 May 88 22:02:40 edt From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas) Message-Id: <8805050202.AA29123@chamarti> To: shebs%defun@cs.utah.edu Cc: cph@zurich.ai.mit.edu, scheme@mc.lcs.mit.edu In-Reply-To: Stanley T. Shebs's message of Wed, 4 May 88 11:12:23 MDT <8805041712.AA02219@defun.utah.edu> Subject: Extending the address space of MIT Cscheme (long reply) Reply-To: jinx@zurich.ai.mit.edu I hope the following clarifies the situation somewhat about the technical/stylistic points you've raised: > * How about some specific examples of design/engineering decisions > that you consider flaws, and why? Gazillions of builtin types. There are twice as many primitive types of objects as any other high-level language that I know of (3- and 4-element hunks? give me a break!). Many could have been built as nonprimitives. See T for good efforts in that direction. What's wrong with that? It's nice (and ultimately more robust) to allow the system to distinguish between various objects with 2, 3, or more components. For example, taken the CAR of a symbol (which in CScheme has two components) will signal an error. Similarly for other kinds of objects. Implementations on custom Lisp hardware often allocate 5 or 6 tag bits so they can accomodate a large number of primitive types for the same reason. In the case of T, I suspect that they would do the same if they could afford the tag bits, but their decision (which I'm not questioning or criticizing) to use an object representation with low tag bits gives them very few primitive types, so they had to reduce their number. Attempts to optimize the C code implementing a virtual machine. If you use a virtual machine, you've already lost speedwise; doing complicated C hacks isn't going to recover much for you. (Presumably that's the reason for hundreds of C macros that could have been function calls.) You are confusing a few things: 1) Using a virtual machine is a common technique these days to implement interpreters. We have made no claim that our interpreter will run code as fast as code produced by native code compilers. Thus there is no attempt to make the CScheme interpreter run as fast as anybody else's compiled code. As far as interpreters go, it's not great, but it's not bad in terms of speed, but provides much more convenience and ease of debugging than any other interpreter I know. 2) Most of the hairy C and macrology arise not from using a virtual machine, but from the fact that the PARTICULAR virtual machine we chose cannot be conveniently written in C without paying an undue penalty. The CScheme interpreter is a recoding of an assembly language interpreter written for the Motorola MC68000 which in turn started out as an emulator for the Scheme 81 chip. The virtual machine was coded naturally in assembly language (and Scheme 81 microcode), but cannot be coded as conveniently in C. We wish we had a portable assembly language which would allow us to do these things more cleanly and efficiently, but unfortunately there is no such beast. C comes closest, but is a far cry from what we would like. As it is, the assembly language interpreter implementing the same virtual machine is considerably cleaner and still runs somewhat faster on the same hardware. Writing nonprimitives in C. My eye happened to fall on list_to_string, which is about three times longer and more complicated in C than in Scheme. What earthly reason could there be for this? I suppose it could be worse; KCL is an example. On the other hand, even KCL doesn't put a Fast Fourier Transform and a regular expression matcher in its C "microcode"... Again, you are ignoring the fact that CScheme is currently an interpreter based system, rather than a compiler based system. The trade-offs are pretty different. In the presence of an acceptable native code compiler one can easily afford to write many utilities in the language being compiled, but interpreters rarely provide enough performance. Many Basic interpreters have the same outlook: Most of the utility procedures are provided as part of the implementation and written in the implementation language rather than Basic. Even in the presence of an acceptable native code compiler (which we now have), there is no good reason to flush this code: The interpreter can still be used without having to port the compiler (which is a much harder task than bringing up the interpreter) and may give adequate performance in educational settings (which was CScheme's only goal in the first place). As far as FFT and Regexp search: - FFT is not part of the standard scheme "microcode". It is part of a special version of Scheme used in the introductory signals course at MIT. Since somebody had bothered to write it, we included it in the release (although it is not loaded by default) so that other people could use it if they wanted to or were curious. It was written in C because our interpreter could hardly compete with compiled C, but few Lisp implementations (if any) can currently match the speed that can be obtained from C or FORTRAN in numeric code. What's wrong with coding a commonly used procedure in a language which will make it more efficient? Please show me a Lisp which can compete with C in this regard. If you manage to do this, I strongly suspect that the number of arcane declarations in the Lisp code will make it at least as unreadable as C, so you're no better off. - Regexp search: It's written in C because it has been copied almost verbatim from the similar code in GNU Emacs, written in C. Why bother rewriting (and debugging) something which we can use directly with little effort? Note that this code is used only by Edwin, which has not yet been released, so it's presence in the release is spurious, and the file which contains it can be dropped from the set of loaded files since no released code uses it (to my knowledge). On the other hand, why not make it available so people can use it or read it if they are curious? References to apparent GC in all kinds of strange places. When I followed them, the trail disappeared in a maze of macros. Hmm. Maybe the Lisps you are used to don't check whether there is enough space to allocate storage before they go ahead and do it. They can't be very robust. I'm also surprised that you complain about this particular "maze". It seems pretty straightforward to me. References to the compiler and Edwin, thus violating every principle of abstraction known to exist. What? Please explain, I don't understand what that means. Strange code concerning "MIT ASCII" (that's what it said) vs regular ASCII characters. Given that CScheme is "portable", why does this get included in everybody's copy? Please read section 13.5 of the "Common Lisp the Language" book. MIT ASCII is ASCII with control, meta, hyper, and super bits, and is extremely useful when writing Emacs-like editors. CScheme only assumes the standard ASCII character set (and the assumptions are few, so converting to EBCDIC is not hard and has been done in the past), and builds MIT ASCII on top, thus portability is not compromised. Lack of documentation is an unforgivable omission, and is by far my biggest gripe about CScheme. It shouldn't take two hours to figure out what kind of garbage collection is being done, or to figure out what the "danger bit" does. I've worked with many programs on that scale during my 12 years in computing, and to be fair, most large programs are difficult to understand, even with documentation (TeX for instance). This just means that *more* documentation is required, not less! To put it another way, lesser minds can't be amazed by your cleverness if they don't even know what's going on... The hard line: CScheme was provided because other people asked for it, not because we wanted to "spread the Gospel", or were willing to support it. Quoting from the CScheme copyright notice: 4. MIT has made no warrantee or representation that the operation of this software will be error-free, and MIT is under no obligation to provide any services, by way of maintenance, update, or otherwise. This is not merely "legalese", we mean it. As a consequence of this, we feel under NO obligation to write documentation until WE need it or have the time to do it. Both of these conditions have been met recently, so the process has started. On the other hand... The CScheme system is FAR from complete or "finished". We could have waited until it was finished (including documentation) before making it available, but we decided to make it available earlier in the hope that it would be useful, but with the understanding that it would be incomplete. Please don't flame because we are not yet done. You are being impatient. A little CScheme history may explain some idiosyncrasies: - CScheme was first written, as a toy, in the fall of 1983. We did NOT use it. People asked for it, so we gave it out. - In late 1986 we decided to make it our main implementation. Previously our main implementation consisted of the assembly language interpreter, a compiler which had been running since early 1984, and Edwin, which was developed on that implementation and then ported by TI to the PC. - Up until that point we had treated CScheme mostly as a curiosity. After this, we developed a new compiler which coexists with the C interpreter. The compiler went into beta test a few weeks ago and will be released later this year. I'm fairly certain that by the end of this summer CScheme (with its compiler) will provide performance similar to that provided by other dialects of Lisp (Lucid, T), at which point we may be able to reexamine some of the issues, but so far it has been premature. We've only been really working on it for 2 years. As far as I know, most other implementations of Lisp have been around for considerably more time, so we're not doing too badly.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 4 May 88 18:43:40 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Wed, 4 May 88 18:37:19 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 4 May 88 20:07:47 GMT From: spar!freeman@decwrl.dec.com (Jay Freeman) Organization: SPAR - Schlumberger Palo Alto Research Subject: Re: R3RS number syntax Message-Id: <475@spar.SPAR.SLB.COM> References: <880427-173044-6364@Xerox> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <880427-173044-6364@Xerox> Pavel.pa@XEROX.COM writes: >It would really be nice if R4RS were to include a formal semantics for the >syntax of numbers. The more I think about it, the more glaring that omission looks. The R3 report provides a perfectly adequate BNF for determining whether or not a particular token represents a number, but provides no hint how to tell *which* number. -- Jay Freeman  Received: from cs.utah.edu (TCP 1200000004) by MC.LCS.MIT.EDU 4 May 88 17:58:01 EDT Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA11796; Wed, 4 May 88 11:13:43 MDT Received: by defun.utah.edu (5.54/utah-2.0-leaf) id AA02219; Wed, 4 May 88 11:12:23 MDT Date: Wed, 4 May 88 11:12:23 MDT From: shebs%defun@cs.utah.edu (Stanley T. Shebs) Message-Id: <8805041712.AA02219@defun.utah.edu> To: cph@zurich.ai.mit.edu Cc: scheme@mc.lcs.mit.edu In-Reply-To: Chris Hanson's message of Wed, 4 May 88 03:47:10 edt <8805040747.AA21368@kleph> Subject: Re: Extending the address space of MIT Cscheme (long reply) I suppose I was hoping that the CSchemers felt sufficiently guilty that they would agree with my remark by their silence - I see this is not the case! > * When you refer to CScheme's "coding style" are you referring to > the portion written in C, the portion written in Scheme, or both? Primarily the portion written in C. I suppose I could admire the Scheme portion if I knew why it existed and what the various pieces are supposed to do (not being a brilliant MIT student, I can't just look at a half-page long S-expression and comprehend it instantly). > * How about some specific examples of design/engineering decisions > that you consider flaws, and why? Gazillions of builtin types. There are twice as many primitive types of objects as any other high-level language that I know of (3- and 4-element hunks? give me a break!). Many could have been built as nonprimitives. See T for good efforts in that direction. Attempts to optimize the C code implementing a virtual machine. If you use a virtual machine, you've already lost speedwise; doing complicated C hacks isn't going to recover much for you. (Presumably that's the reason for hundreds of C macros that could have been function calls.) Writing nonprimitives in C. My eye happened to fall on list_to_string, which is about three times longer and more complicated in C than in Scheme. What earthly reason could there be for this? I suppose it could be worse; KCL is an example. On the other hand, even KCL doesn't put a Fast Fourier Transform and a regular expression matcher in its C "microcode"... References to apparent GC in all kinds of strange places. When I followed them, the trail disappeared in a maze of macros. References to the compiler and Edwin, thus violating every principle of abstraction known to exist. Strange code concerning "MIT ASCII" (that's what it said) vs regular ASCII characters. Given that CScheme is "portable", why does this get included in everybody's copy? There are probably others, I haven't looked at every single one of the 120+ files and 50K+ lines of the C code... > * Have you seen a lisp of comparable (or greater) functionality > that is significantly better in either respect? Please name it, > and explain why. In the absence of a manual describing the "functionality" of CScheme, it's impossible to compare it on that basis. I hope there's lots of functionality, CScheme is larger than commercial Common Lisps (which is amusing considering how Schemers abuse Common Lisp for its "bloat"). Spice Lisp/CMU Common Lisp has its flaws, but it's better overall (for one thing, it's smaller!). T/Orbit has better structure and style, but its documentation is too scanty to recommend. I would say that PSL/PCLS is cleaner, but I am biased! > * When you refer to "experiences in trying to understand CScheme", > how much of that can be attributed to lack of documentation? Have > you ever tried to understand another program of comparable > complexity? Lack of documentation is an unforgivable omission, and is by far my biggest gripe about CScheme. It shouldn't take two hours to figure out what kind of garbage collection is being done, or to figure out what the "danger bit" does. I've worked with many programs on that scale during my 12 years in computing, and to be fair, most large programs are difficult to understand, even with documentation (TeX for instance). This just means that *more* documentation is required, not less! To put it another way, lesser minds can't be amazed by your cleverness if they don't even know what's going on... > For example, while I know a great deal about compilers, I would > expect to spend a great deal of time and effort trying to > understand a good one, such as GNU CC. I'd probably get pretty > pissed off at the crummy way that certain things were designed. > But I wouldn't blame this on RMS being a poor programmer. The > real problem is that such a program is so complex that even the > best programmer can't make it perfect. A bogus argument - I'm not asking for perfection, but a minimal standard of quality. There should *at least* be a one-line justification for the existence of functions and macros. BTW, I don't want to claim that anyone is a "poor programmer"! A phrase comes to mind (don't remember from where), that there are only a few Gandhi-like programmers who are never tempted to write bad code... >A general statement like yours is easy to make and can convey false >impressions. I'd rather not have my reputation (and that of my >colleagues) tarnished by vague accusations about the quality of our >work. On the other hand, I welcome specific, well-reasoned criticism. I'm sorry to say it, but your reputation has already been tarnished by the code you've allowed to travel throughout the world. Hopefully you prefer to have someone say it to your face (so to speak :-) ) than behind your back. >* By and large, I'm very proud of the part of CScheme that is >implemented in Scheme. I believe that it captures a great deal of >modularity and abstraction, contains many fine symmetries, and in >general is very robust. It also pushes some of our language >technology to the limit: in particular it suffers from the lack of a >good module description facility. So why didn't you explain all these "abstractions" and "fine symmetries"? >* The part written in C is a very different story. I think alot of >this can be attributed to C itself. Some of it can be attributed to >the fact that most of us in the Scheme group at MIT hate C, and >therefore don't want to do the work that it would take to make it a >beautiful C program. In fact, I'm not sure it would be possible to >make it beautiful, although clearly it could be much much better. I find it odd that haters of C would use macros to the extent that CScheme does. I find it odd that haters of C would write so much of it. I find it odd that people who are aware of C's problems wouldn't try to alleviate them by commenting on what the code is up to. >One thing that everyone here has agreed upon: we would all like to >rewrite that C program in Scheme or a nice Scheme-like language if >only the compiler technology were good enough to let us keep the >portability and performance. Well, I think that will be true in >another year or two, and then maybe it will happen. This sounds like a veiled criticism of T and Orbit, since they are portable and fast. KCL compiles to C code, so it maintains portability at that level. (Someone could do a great public service by reimplementing KCL in a less idiosyncratic way - the basic idea is quite sound.) >* We have virtually no documentation. This is obviously a terrible >thing, and we are in fact generating some. But the bottom line for >this is simply lack of time, plus the fact that none of us has much >text writing experience. I hear that excuse from froshes, and don't accept it from them either. Documentation after the fact is inherently inferior, and leaves out important details that the programmers have forgotten about. >It is not widely known that CScheme, along with the Liar compiler, the >Edwin text editor, and a previous 68000-based implementation, have >largely been created by three people over about 5 years. Two of us >had significant other commitments during that time which reduced the >amount of effort that could be devoted to the project. Yet we >generated over a quarter million lines of hairy code in about 10 to 12 >person-years. It is only now that our project has expanded to the >point where we feel that time is available for documentation. Perhaps if you had thought more carefully about what you were doing, it wouldn't have been necessary to write so much code, and surely five years is enough time to think about writing more documentation! Still, I do appreciate where you're coming from - it's something that professional SEs have to contend with all the time (my own views have no doubt been colored by one of my first jobs, which was to document 40,000 lines of Fortran written by several other people). >* Various representation decisions that we have made have been >criticised at various times. In particular: high tags vs. low tags; >SCode vs. byte code; and more recently, register-based vs. stack-based >calling convention. I can produce reasonable arguments for all of >these decisions. One thing that I have noticed is that the >"community" seems to have preconceptions about some of these >alternatives being better than others. In some cases we've tested >them and found that the "common knowledge" is misleading: often the >performance difference between two of the alternatives is very slight. I would like to see the data - there are a huge number of undocumented claims like this. It is true that if you use a virtual machine, then a lot of representation decisions are unimportant. In fact, my almost finished thesis is all about the analysis of representation decisions. >* In your message you essentially are criticising us for not being >able to change a fundamental representation decision. I don't believe >this is a valid criticism. I claim that NO implementation in >existence could easily make a large change at that level. Small >changes, on the other hand, are a different matter. You are almost right. Our new Common Lisp implementation can change from tags to BBOP to separate spaces, just by changing opencodings. We can also vary the function protocol in interesting ways. This all happens in a native code compiler. Admittedly, this wasn't easy, and it is not yet complete. No publications yet (i.e. Lisp conf paper rejected), but my thesis will be available shortly, and we do have some initial reports. To summarize: CScheme is not incredibly bad, but it is disappointing, especially given the interest of the Scheme community in simplicity, modularity, and abstraction. The most serious consequence is that people interested in learning about Scheme implementation will look at CScheme, and most likely conclude that people at MIT don't really believe all those ideas being promulgated in SICP... stan  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 4 May 88 11:28:27 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Wed, 4 May 88 11:24:03 EDT Received: from USENET by bloom-beacon with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 3 May 88 19:11:14 GMT From: BASEL.AI.MIT.EDU!lyn@ucbvax.berkeley.edu (Franklyn Turbak) Organization: The Internet Subject: ``Update functions'' in Scheme. Message-Id: <8805031911.AA04352@basel> References: <411493.880427.SCHREQ@MC.LCS.MIT.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu > Did anybody already think about adding ``generalized functions'' > (a la Common-Lisp's setf/defsetf feature) to Scheme? This would > eliminate the need for several primitive procedures, among them > set-car!, set-cdr!, vector-set!, and string-set!. Instead of writing > > (set-car! p 5) or (vector-set! v 10 'a) > > this would make it possible to write > > (set! (car p) 5) or (set! (vector-ref v 10) 'a) What's so great about SETF? It doesn't eliminate the *need* for the setting primitives (after all, they conceptually must still be there); it just makes it easier to remember their "names" by providing a convention for deriving the setter from the accessor. But it's easy to develop alternate naming conventions without altering Scheme. One simple convention can be carried out by simple renaming: (define set!car set-car!) (define set!cdr set-cdr!) (define set!vector-ref vector-set!) (define set!string-ref string-set!) Here the name of each setter is the name of the accessor prefixed by set! Now we can write (set!car p 5) or (set!vector-ref v 10 'a) which, except for the missing pair of parens, looks a lot like the SETF approach. And we didn't have to extend Scheme all! - Lyn -  Received: from dumbo (TCP 2206400251) by MC.LCS.MIT.EDU 4 May 88 11:02:51 EDT Received: by DUMBO.AI.MIT.EDU; Wed, 4 May 88 11:00:47 edt Date: Wed, 4 May 88 11:00:47 edt From: mhwu@DUMBO.AI.MIT.EDU (Henry M. Wu) Message-Id: <8805041500.AA05512@dumbo> To: cph@zurich.ai.mit.edu Cc: defun.utah.edu!shebs@cs.utah.edu, scheme@mc.lcs.mit.edu In-Reply-To: Chris Hanson's message of Wed, 4 May 88 03:47:10 edt <8805040747.AA21368@kleph> Subject: More flames about CScheme Reply-To: mhwu%dumbo@mc.lcs.mit.edu * The part written in C is a very different story. I think alot of this can be attributed to C itself. Some of it can be attributed to the fact that most of us in the Scheme group at MIT hate C, and therefore don't want to do the work that it would take to make it a beautiful C program. In fact, I'm not sure it would be possible to make it beautiful, although clearly it could be much much better. I would like to add a few points: - If a large C program like CScheme could be "much much" better, I haven't seen anybody succeed trying to write one. I have certainly looked at a large amount of C code coming from various sources, and I claim that CScheme is better than MOST, if not all that I have come across. This is not to say that CScheme is anywhere near perfect; it's just that C programs are in general badly written. - Unlike a lot of C programs, CScheme does try to have SOME abstraction. Believe it or not, to some people this actually makes the program harder to understand! This isn't helped by the fact that a lot of the abstraction is implemented using hairy macros, mainly for efficiency reasons. My claim is that CScheme isn't "bad", it's just different. - A lot of claims about CScheme's so-called "bad design/engineering" are based not on people's understanding of it's design, but rather the fact that empirically CScheme is slow, and "so it must be badly designed". In fact CScheme was never supposed to be fast. All of the optimizing switches and hacks are defaultly turned off, unlike many other implementations. One of the main features of CScheme is its portability, and it is very sucessful in that regard. Some of the design decisions came from the fact that CScheme evolved from a Scheme implementation that was a teaching tool, not a [commercial] speedster for preparing programs for a Cray. But yet I have survived CScheme INTERPRETING some robust CAD tools, solving large design problems. These days I can only see CScheme getting faster, with the introduction of the compiler. I don't want to sound like I am trying to portray CScheme as this wonderful piece of software that it isn't. I do feel that making generalized attacks on issues like coding style is often too easy (and I guess I just made some myself), while sometimes even those of us close to the project fail to stop and try to appreciate the amount of effort put into a very useful tool. I like CScheme.  Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 4 May 88 03:45:47 EDT Received: by kleph.AI.MIT.EDU; Wed, 4 May 88 03:47:10 edt Date: Wed, 4 May 88 03:47:10 edt From: cph@kleph.AI.MIT.EDU (Chris Hanson) Message-Id: <8805040747.AA21368@kleph> To: defun.utah.edu!shebs@cs.utah.edu Cc: scheme@mc.lcs.mit.edu In-Reply-To: (Stanley T. Shebs's message of 2 May 88 02:37:53 GMT <5460@utah-cs.UUCP> Subject: Extending the address space of MIT Cscheme (long reply) Reply-To: cph@zurich.ai.mit.edu Date: 2 May 88 02:37:53 GMT From: defun.utah.edu!shebs@cs.utah.edu (Stanley T. Shebs) However, I suspect that either of these changes would be far too radical for CScheme, whose coding style and general design/engineering have given MIT a black eye in the Lisp/Scheme community... (Yes, it's a harsh assessment, but does accurately reflect both my own experiences in trying to understand CScheme, and a number of other people's feelings as well) As you might expect, your statement ruffled my feathers. I'd be interested in your answers to some questions: * When you refer to CScheme's "coding style" are you referring to the portion written in C, the portion written in Scheme, or both? * How about some specific examples of design/engineering decisions that you consider flaws, and why? * Have you seen a lisp of comparable (or greater) functionality that is significantly better in either respect? Please name it, and explain why. * When you refer to "experiences in trying to understand CScheme", how much of that can be attributed to lack of documentation? Have you ever tried to understand another program of comparable complexity? For example, while I know a great deal about compilers, I would expect to spend a great deal of time and effort trying to understand a good one, such as GNU CC. I'd probably get pretty pissed off at the crummy way that certain things were designed. But I wouldn't blame this on RMS being a poor programmer. The real problem is that such a program is so complex that even the best programmer can't make it perfect. A general statement like yours is easy to make and can convey false impressions. I'd rather not have my reputation (and that of my colleagues) tarnished by vague accusations about the quality of our work. On the other hand, I welcome specific, well-reasoned criticism. Here are my views on a few relevant topics: * By and large, I'm very proud of the part of CScheme that is implemented in Scheme. I believe that it captures a great deal of modularity and abstraction, contains many fine symmetries, and in general is very robust. It also pushes some of our language technology to the limit: in particular it suffers from the lack of a good module description facility. * The part written in C is a very different story. I think alot of this can be attributed to C itself. Some of it can be attributed to the fact that most of us in the Scheme group at MIT hate C, and therefore don't want to do the work that it would take to make it a beautiful C program. In fact, I'm not sure it would be possible to make it beautiful, although clearly it could be much much better. One thing that everyone here has agreed upon: we would all like to rewrite that C program in Scheme or a nice Scheme-like language if only the compiler technology were good enough to let us keep the portability and performance. Well, I think that will be true in another year or two, and then maybe it will happen. * We have virtually no documentation. This is obviously a terrible thing, and we are in fact generating some. But the bottom line for this is simply lack of time, plus the fact that none of us has much text writing experience. It is not widely known that CScheme, along with the Liar compiler, the Edwin text editor, and a previous 68000-based implementation, have largely been created by three people over about 5 years. Two of us had significant other commitments during that time which reduced the amount of effort that could be devoted to the project. Yet we generated over a quarter million lines of hairy code in about 10 to 12 person-years. It is only now that our project has expanded to the point where we feel that time is available for documentation. * Various representation decisions that we have made have been criticised at various times. In particular: high tags vs. low tags; SCode vs. byte code; and more recently, register-based vs. stack-based calling convention. I can produce reasonable arguments for all of these decisions. One thing that I have noticed is that the "community" seems to have preconceptions about some of these alternatives being better than others. In some cases we've tested them and found that the "common knowledge" is misleading: often the performance difference between two of the alternatives is very slight. * In your message you essentially are criticising us for not being able to change a fundamental representation decision. I don't believe this is a valid criticism. I claim that NO implementation in existence could easily make a large change at that level. Small changes, on the other hand, are a different matter. In this particular case, there are a number of things we can easily do, such as: reduce the size of the type field to reflect the fact that we only use 6 type bits rather than 8; reduce the number of type bits by making some of them manifest (we could probably go down to 3 or 4 without much work); or change the addressing from byte granular to word (or even pair) granular. But a BIBOP-style type representation is a fundamental change that would require alot of work. I would be surprised if any system could claim to change between such radically different representations easily. In closing: please don't feel that I'm attacking you. I am, however, trying to defend myself, my colleagues, and our work, against your rather vague condemnation. I'm sure you have some good reasons for feeling the way you do and I'd be happy to hear and discuss them. But please try to be a little more specific. General arguments of this nature do nothing to improve our software, much less the state of the art.  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 4 May 88 01:33:22 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA01819; Mon, 2 May 88 20:54:03 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 May 88 02:37:53 GMT From: defun.utah.edu!shebs@cs.utah.edu (Stanley T. Shebs) Organization: PASS Research Group Subject: Re: Extending the address space of MIT Cscheme Message-Id: <5460@utah-cs.UUCP> References: <12394354697.55.MKATZ@A.ISI.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <12394354697.55.MKATZ@A.ISI.EDU> MKATZ@A.ISI.EDU (Morris Katz) writes: >In order to effectively use CScheme on modern multiprocessors there is a real >need to extend its 24 bit address space. There is the Spice Lisp technique of divvying up the address space into areas dedicated to each type, in such a way that they still appear to have tags. There is also BIBOP or BBOP, in which objects of the same type are grouped together on a page (as in Franz or Maclisp or Interlisp). Both techniques would give you a full 32-bit address space, although BBOP may be more practical for multiprocessing. However, I suspect that either of these changes would be far too radical for CScheme, whose coding style and general design/engineering have given MIT a black eye in the Lisp/Scheme community... stan shebs shebs@cs.utah.edu (Yes, it's a harsh assessment, but does accurately reflect both my own experiences in trying to understand CScheme, and a number of other people's feelings as well)  Received: from basel (TCP 2206400245) by MC.LCS.MIT.EDU 3 May 88 14:09:36 EDT Received: by BASEL.AI.MIT.EDU; Tue, 3 May 88 15:11:14 edt Date: Tue, 3 May 88 15:11:14 edt From: lyn@BASEL.AI.MIT.EDU (Franklyn Turbak) Message-Id: <8805031911.AA04352@basel> To: SCHEME@MC.LCS.MIT.EDU In-Reply-To: Oliver Laumann's message of Wed, 27 Apr 88 14:03:41 EDT <411493.880427.SCHREQ@MC.LCS.MIT.EDU> Subject: ``Update functions'' in Scheme. > Did anybody already think about adding ``generalized functions'' > (a la Common-Lisp's setf/defsetf feature) to Scheme? This would > eliminate the need for several primitive procedures, among them > set-car!, set-cdr!, vector-set!, and string-set!. Instead of writing > > (set-car! p 5) or (vector-set! v 10 'a) > > this would make it possible to write > > (set! (car p) 5) or (set! (vector-ref v 10) 'a) What's so great about SETF? It doesn't eliminate the *need* for the setting primitives (after all, they conceptually must still be there); it just makes it easier to remember their "names" by providing a convention for deriving the setter from the accessor. But it's easy to develop alternate naming conventions without altering Scheme. One simple convention can be carried out by simple renaming: (define set!car set-car!) (define set!cdr set-cdr!) (define set!vector-ref vector-set!) (define set!string-ref string-set!) Here the name of each setter is the name of the accessor prefixed by set! Now we can write (set!car p 5) or (set!vector-ref v 10 'a) which, except for the missing pair of parens, looks a lot like the SETF approach. And we didn't have to extend Scheme all! - Lyn -  Received: from zurich (TCP 2206400260) by MC.LCS.MIT.EDU 2 May 88 13:58:04 EDT Received: from Xerox.COM (xerox.com) by ZURICH.AI.MIT.EDU; Mon, 2 May 88 13:57:35 edt Received: from Cabernet.ms by ArpaGateway.ms ; 02 MAY 88 10:49:35 PDT Date: 2 May 88 10:49 PDT From: Fischer.pa@Xerox.COM Subject: Re: Extending the address space of MIT Cscheme In-Reply-To: Morris Katz 's message of Fri, 29 Apr 88 13:03:48 EDT To: MKATZ@A.ISI.EDU Cc: scheme@ZURICH.AI.MIT.EDU Message-Id: <880502-104935-3391@Xerox> Put the type bits at the bottom of the address word. No shift, just mask if needed. Result: larger 'words.' This technique also used in Smalltalk-80, immediates were tagged with low order bit, shifted only when needed. (ron)  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 2 May 88 05:57:29 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA06911; Sun, 1 May 88 18:39:14 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 May 88 01:28:31 GMT From: spar!freeman@decwrl.dec.com (Jay Freeman) Organization: SPAR - Schlumberger Palo Alto Research Subject: Re: R3RS number syntax Message-Id: <405@spar.SPAR.SLB.COM> References: <880427-173044-6364@Xerox> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <880427-173044-6364@Xerox> Pavel.pa@XEROX.COM writes: >2. What is the meaning of the exponent part when the radix is not 10? My guess >was that ``#O3E4'' meant 3 times 8 to the 4th, Mine, too. I always thought of exponents as being merely a notational convenience for inconveniently-placed radix points. >4. Does ``123##.##'' mean anything different from ``12300'' when read? Or does >it really mean the same as ``#i12300''? I think the system should try to arrange that when it reads (and evals) something that it printed out, the object created should be as indistinguishable as possible from the one printed. (This is of course an impossible goal, if only because you can always print a number with fewer digits of precision than are implicit in its internal representation; or because you can print an inexact "1" as an integer with exactness surpressed.) I also think the purpose of the "exact" bit is very low-level; I believe it is intended to flag that all information necessary to describe a number completely is contained in the particular bit-pattern that represents the number in store. If that is true, then the system should NEVER print "#"s in any representation of an exact number. Thus for example, if you asked for the exact rational 1/3 to be printed as a decimal with six million digits of precision, you should get lots and lots of "3"s, even though no likely internal representation of a flonum has that much precision. So if the system prints "123##.##", the number printed must originally have been inexact. Thus I think the reader ought to treat "123##.##" as an inexact number. Don't take me as an authority, I certainly am not! It seems more natural to me to interpret 3/4e6 as (3/4)e6, but I certainly don't see anything in the R3 report to require it. By the way, what does C-Scheme say to "(integer? 1.0)"? To "(integer? 1)"? MacScheme (version 1.51) says the former is false and the latter true; I think both should be true. (MacScheme does say that "(= 1 1.0)" is true so I am not just a victim of roundoff.) -- Jay Freeman  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 2 May 88 05:57:13 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA07201; Sun, 1 May 88 19:06:29 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 May 88 21:11:52 GMT From: ubvax!smegma!mdg@ames.arc.nasa.gov (Marc de Groot) Organization: A moving point in 4-space Subject: SIOD release 1.1 Message-Id: <379@smegma.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I am interested in Scheme, and I know very little about it. I understand that it is LISP done in a relatively compact, symmetrical, and orderly way. That is what piqued my interest. Some questions: Is SIOD 1.1 a public-domain Scheme? If so, can I get source, and will it run on my IBM PC/AT (80286 crummy segmented architecture) under Microport UNIX SVr2? What are some good books about Scheme and where can I get them? Thanks in advance. -- Marc de Groot (KG6KF) UUCP: {hplabs, sun, ucbvax}!amdcad!uport!smegma!mdg AMATEUR PACKET RADIO: KG6KF @ KB6IRS "Look, he's mounting a tape!" "Quick, throw cold water on him!"  Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 1 May 88 21:49:51 EDT Return-Path: Received: by bu-it.BU.EDU (4.0/4.7) id AA18536; Sun, 1 May 88 21:48:30 EDT Date: Sun, 1 May 88 21:48:30 EDT From: gjc@bu-it.BU.EDU (George J. Carrette) Message-Id: <8805020148.AA18536@bu-it.BU.EDU> To: scheme@mc.lcs.mit.edu Subject: siod release 1.3 In this release the environment representation has been changed from a simple ALIST to a frame structure made up by consing the formal argument list with the actual argument list returned by eval_args. With this representation is is easy to get "define" to work properly. (It does now). Also included is a vms specific function for calling the editor within the same address space as the lisp. Same place, bu-it.bu.edu, /pub, anonymous anonymous. Those unable to FTP who requested direct mail have been sent four messages today containing the siod sources and a test message. This will be the last release before a gc-at-any-time version is available. I hope people have found this amusing, instructive, or both. -gjc  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 1 May 88 16:26:19 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA22621; Sun, 1 May 88 04:02:44 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Apr 88 04:36:10 GMT From: killer!pollux!ti-csl!mips!gateley@ames.arc.nasa.gov (John Gateley) Organization: TI Computer Science Center, Dallas Subject: Re: collect macro Message-Id: <47466@ti-csl.CSNET> References: <3200@korppi.tut.fi> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu This might help. It is an extend-syntax version of collect which has not been tested other than to show that it expands into what looks to be the right thing. The function nth is just like Common Lisp, if you want to use list-ref, just switch the order of the two arguments. I use `with' clauses to help build the let bindings. This is the only complicated feature used. Hope this helps, John Gateley ; code starts here ; This just converts (v1 v2 ...) to ((v1 (nth 0 tuple)) (v2 (nth 1 tuple)) ...) ; it should always be called w/ second argument of 0 (define make-v-fun (lambda (l n) (cond ((null? l) ()) (t (cons `(,(car l) (nth ,n tuple)) (make-v-fun (cdr l) (+ n 1))))))) ; this guy creates the flatmap expression (extend-syntax (make-flatmaps) (tuple) ((make-flatmaps ((vn setn)) (v ...)) (map (lambda (vn) (list v ... vn)) setn)) ((make-flatmaps ((vi seti)(vj setj) ...) (v ...)) (flatmap (lambda (vi) (make-flatmaps ((vj setj) ...) (v ... vi))) seti))) ; this is the main guy (extend-syntax (collect) (tuple) ((collect result ((v1 set1) ...) restriction) (with ((let-bindings (make-v-fun '(v1 ...) 0))) (map (lambda (tuple) (let let-bindings result)) (filter (lambda (tuple) (let let-bindings restriction)) (make-flatmaps ((v1 set1) ...) ()))))))  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 30 Apr 88 16:51:44 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA23376; Sat, 30 Apr 88 05:03:54 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Apr 88 17:16:08 GMT From: mnetor!spectrix!yunexus!oz@uunet.uu.net (Ozan Yigit) Organization: York U. Computing Services - Magic Group Subject: Scheme Biblio. Message-Id: <427@yunexus.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Many people have sent me additions and corrections for the bibliography posted several weeks ago. Your help is much appreciated. Due to my absence for about a month, I will not be able to post an up-to-date version of this bibliography until June. Until that time, please do keep sending me any new references suitable to be added to this scheme-only biblio. many thanks. oz -- The deathstar rotated slowly, | Usenet: ...!utzoo!yunexus!oz towards its target, and sparked | ....!uunet!mnetor!yunexus!oz an intense sunbeam. The green world | Bitnet: oz@[yulibra|yuyetti] of unics evaporated instantly... | Phonet: +1 416 736-5257x3976  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 29 Apr 88 19:53:40 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA10868; Thu, 28 Apr 88 20:41:50 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Apr 88 00:05:47 GMT From: spar!freeman@decwrl.dec.com (Jay Freeman) Organization: SPAR - Schlumberger Palo Alto Research Subject: Questions on Scheme treatment of numbers Message-Id: <380@spar.SPAR.SLB.COM> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I have been browsing through the R3 report on Scheme, and have become curious about some aspects of Scheme's treatment of numbers ... (1) The syntax given for external representations of numbers appears to require that exponents -- if present -- be in radix 10, even when the rest of the number has been explicitly declared to be in binary, octal or hex. My first reaction was that this is probably an oversight: Have I overlooked any obvious advantage or misread the BNF? (2) I think there is an abiguity in parsing hexadecimal numbers: E. g., is #x1e2 to be interpreted as one times sixteen to the power two (= 256), or as 1 * 256 + 14 * 16 + 2 (= 482). (If so, it is probably best to prefer the latter interpretation: a user who intends the former can always provide a "+" sign (#x1e+2).) (3) It looks as if there is no object foo for which (number? foo) is #t but (complex? foo) is #f. This might be a good hook for recognizing IEEE floating-point INFs, or for other similar overflow conditions. Any thoughts? -- Jay Freeman  Received: from zurich (TCP 2206400260) by MC.LCS.MIT.EDU 29 Apr 88 19:12:42 EDT Received: from A.ISI.EDU (a.isi.edu) by ZURICH.AI.MIT.EDU; Fri, 29 Apr 88 19:06:44 edt Date: Fri 29 Apr 88 13:03:48-EDT From: Morris Katz Subject: Extending the address space of MIT Cscheme To: scheme@ZURICH.AI.MIT.EDU Message-Id: <12394354697.55.MKATZ@A.ISI.EDU> In order to effectively use CScheme on modern multiprocessors there is a real need to extend its 24 bit address space. In the past I have heard two suggestions for accomplishing this task. 1) Interprest the 24 bits as a word address (object address) rather than a byte address, effectively increasing the address space by a factor of 4. (Unfortunately, this requires repeated shifting of addresses on most processors.) 2) Steal a type code bit and make it part of the address field. Neither of these solutions is really satisfactory since even in combination they do not allow one to address even 4M of memory on each of 64 processors. Does anyone have any other suggestions? I have been considering doubling the size of Scheme objects to 8 bytes, the first 4 for the type code and the second 4 for the address. This would obviously be quite wasteful of memory, but at least it would allow me to use the full 32 bit address space of my processors. How hard do people think it would be to modify CSchemme for such an object representation? Someone must have a better solution. This sounds real grim. Morry Katz -------  Received: from IBM.COM (TCP 30001235007) by MC.LCS.MIT.EDU 29 Apr 88 14:02:53 EDT Date: 29 Apr 88 12:29:47 EDT From: Cyril Alberga To: scheme@mc.lcs.mit.edu Message-Id: <042988.122947.alberga@ibm.com> Subject: TI-scheme on PS/2 I have attempted to run TI-scheme (version 3.0) on a PS/2 model 80 with 4 MB of memory installed, running under DOS 3.3. Scheme does not seem to recognize any memory above 640 KB. Is this a known condition? If so, is there a fix? Cyril N. Alberga  Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 28 Apr 88 22:55:41 EDT Return-Path: Received: by bu-it.BU.EDU (4.0/4.7) id AA02291; Thu, 28 Apr 88 22:49:52 EDT Date: Thu, 28 Apr 88 22:49:52 EDT From: gjc@bu-it.BU.EDU (George J. Carrette) Message-Id: <8804290249.AA02291@bu-it.BU.EDU> To: scheme@mc.lcs.mit.edu Cc: tower@bu-it.bu.edu Subject: SIOD release 1.2 (28-APR-88). (1) bug fixed in use of atof for VMS. (2) compiled and run on AMIGA 500 (3) name changes to conform better to recently published material. (4) bug in extend_environment fixed. (5) siod.scm file now has: * standard-fib procedure for benchmarking * cons-stream, enumerate-interval, print-stream-elements. (6) siod.doc file updated to reflect name changes. Same place, anonymous ftp to bu-it.bu.edu (128.197.20.40 or 128.197.2.40) and get /pub/siod.* I have gotten many messages from people who cannot FTP to this machine. Sorry for not responding yet. Already I have spent more time in MAIL about this than in the actual Scheme implementation. Thanks to those who have sent in bug fixes or new features. When I found out how to post to comp.sources.unix or misc I will do so. -gjc  Received: from hplabs.HP.COM (TCP 1777610007) by MC.LCS.MIT.EDU 28 Apr 88 11:17:22 EDT Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Thu, 28 Apr 88 07:12:19 PST Received: from hpda.HP.COM (hpda.itg.hp.com) by hplms2.HP.COM; Thu, 28 Apr 88 08:12:01 pdt Received: by hpda.HP.COM; Thu, 28 Apr 88 08:14:12 pdt Message-Id: <8804281514.AA13365@hpda.HP.COM> To: scheme@mc.lcs.mit.edu Subject: delete from list Date: Thu, 28 Apr 88 08:14:07 PDT From: Scott Dawkins Hi, The scheme mailing list includes "cire@hpda" or perhaps "cire@hplabs". Anyway, Eric Decker (cire) has left the company. Please delete him from the scheme mailing list. Thanks, Scott Dawkins sdawkins@hpda.hp.com Technical Data Center Manager HP - Information Technology Group (408) 447 - 6963  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 28 Apr 88 05:45:04 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA07188; Wed, 27 Apr 88 17:50:41 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Apr 88 03:19:33 GMT From: rochester!ur-tut!joss@cu-arpa.cs.cornell.edu (Josh Sirota) Organization: Univ. of Rochester, Computing Center Subject: Re: Where to mail bugs? Message-Id: <1881@ur-tut.UUCP> References: <10423@sunybcs.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <10423@sunybcs.UUCP> ugwiles@sunybcs.UUCP (Dale Wiles) writes: > Does anyone know the e-mail address to send bugs about >MIT's C-Scheme to? The address in the source code is >"BUG-CSCHEME%OZ@MC.LCS.MIT" but our postmaster bounced it back to me. bug-cscheme%oz@mc.lcs.mit.edu ... Somehow you must have it stripped. Josh -- Josh Sirota INTERNET: joss@tut.cc.rochester.edu BITNET: joss_ss@uordbv.bitnet ur-tut!joss@cs.rochester.edu UUCP: ...!rochester!ur-tut!joss  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 28 Apr 88 01:01:39 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA09164; Tue, 26 Apr 88 18:50:34 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Apr 88 17:30:21 GMT From: mcvax!unido!fauern!faui44!msurlich@uunet.uu.net (Matthias Urlichs ) Organization: CSD., University of Erlangen, W - Germany Subject: Re: Scheme Implementation for Macintosh 2 Message-Id: <246@soni.UUCP> References: <8804190413.AA11938@duke.cs.duke.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <8804190413.AA11938@duke.cs.duke.edu> gleicher@CS.DUKE.EDU (Michael Gleicher) writes: >has anyone ported Cscheme to the mac 2? I transferred r2 to MPW C and ran it thru Gnu-CP and MPW C (its preprocessor wouldn't accept CScheme's #define's; too many levels) without much difficulty. But no toolbox etc. support yet as I don't know much (read that as "anything") about the internal organization of CScheme, eg where to put your own REP interface, how to put in output to windows, ... I probably will do that if/when there's time (right now there isn't) and if I get pointers to more detailed information about CScheme. -- Matthias Urlichs CompuServe: 72437,1357 Delphi: URLICHS Rainwiesenweg 9 8501 Schwaig 2 "Violence is the last refuge West Germany of the incompetent." -- Salvor Hardin  Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 27 Apr 88 22:03:42 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 27 APR 88 17:30:44 PDT Date: Wed, 27 Apr 88 17:30:37 PDT From: Pavel.pa@Xerox.COM Subject: R3RS number syntax To: scheme@mc.lcs.mit.edu Message-ID: <880427-173044-6364@Xerox> I have a few questions about the syntax of numbers in R3RS Scheme: 1. The sequence of characters ``#x3e4'' has two very different parses. The question is whether or not the ``e'' is a digit or the exponent marker. What is intended here? 2. What is the meaning of the exponent part when the radix is not 10? My guess was that ``#O3E4'' meant 3 times 8 to the 4th, but C-Scheme, at least, treats this as 3 times 10 to the 4th. I can guess from the syntax that the digits of the exponent are always in radix 10 (since the base 10 digits are all that's allowed there), but what is the base for the exponentiation? I thought it would be more useful if the exponentiation base was the same as the number radix (so that, for example, I could say #b1E20 to make a mask that has only bit 20 turned on). 3. Does ``3/4e5'' mean the same as ``75000'' or ``.0000075''? That is, is the exponent intended to apply to the entire rational ``3/4'' or just to the denominator? 4. Does ``123##.##'' mean anything different from ``12300'' when read? Or does it really mean the same as ``#i12300''? 5. I assume that the syntax ``3@4'' is meant to denote the complex number with magnitude 3 and angle 4, but this isn't actually said anywhere in the document. The same goes for the (assumed rectangular) notation ``3+4i'', though it's more clear in that case. I had to infer the meaning from an example in the description of number-printing formats. It would really be nice if R4RS were to include a formal semantics for the syntax of numbers. I realize that some issues (such as whether or not such a literal is exact) are intended to be implementation-dependent, but I think that there could be a semantics that defined the mathematical number that each input syntax is intending to represent (perhaps the semantic function should return an interval of the reals for each expansion of the nonterminal in the grammar). Pavel  Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 27 Apr 88 18:23:58 EDT Received: by GENEVA.AI.MIT.EDU; Wed, 27 Apr 88 12:54:17 edt Date: Wed, 27 Apr 88 12:54:17 edt From: jrm@GENEVA.AI.MIT.EDU (Joe Marshall) Message-Id: <8804271654.AA12980@geneva> To: gjc@bu-it.BU.EDU Cc: scheme@mc.lcs.mit.edu Subject: SIOD release 1.1 Hi, George. What's up?  Date: Wed, 27 Apr 88 14:03:41 EDT From: Oliver Laumann @MC.LCS.MIT.EDU Sender: SCHREQ@MC.LCS.MIT.EDU Subject: ``Update functions'' in Scheme. To: SCHEME@MC.LCS.MIT.EDU Message-ID: <411493.880427.SCHREQ@MC.LCS.MIT.EDU> Date: Fri, 8 Apr 88 17:55:27 +0200 From: Oliver Laumann To: scheme-request at mc.lcs.mit.edu Re: ``Update functions'' in Scheme. Did anybody already think about adding ``generalized functions'' (a la Common-Lisp's setf/defsetf feature) to Scheme? This would eliminate the need for several primitive procedures, among them set-car!, set-cdr!, vector-set!, and string-set!. Instead of writing (set-car! p 5) or (vector-set! v 10 'a) this would make it possible to write (set! (car p) 5) or (set! (vector-ref v 10) 'a) accordingly. Of course, in implementations that support ``fluid-let'' one would also have to extend fluid-let to accept the new syntax. But how should users be able to define their own ``update functions''? Yes, I know the concept of ``settable operations'' of T, but unfortunately they are based on T's object oriented features. And I don't like the setf/defsetf concept of Common Lisp, because the accessor function and the update function have to be separate functions (if I understood it right). Consider the following example: I would like to be able to write a ``print-length'' procedure which, when called outside a set! form, returns the current ``print length'' (whatever this may be), and, when called as ``(set! (print-length) 10)'', sets the print length to 10. Ideally, only *one* function should be involved -- this function both knows how to return the current print length and how to set it to a new value. I could imagine something like this: (define print-length (let ((len 100)) (lambda (&update flag &optional val) (if flag ... ; set len to val (possibly with sanity-check) len)))) When called from within a set! form (that is, as an update function), ``flag'' would be true, otherwise false (called as accessor function). Now I can't come up with a satisfying syntax; the above &update kludge should only illustrate the concept (i.e. the function "knows" if it should act as accessor or update function). A coworker suggests adding a different lambda (which he jokingly called ``mikro'') that contains two parameter lists and two body forms, e.g. (define print-length (let ((len 100)) (mikro () len ; accessor (val) (something a la set! len val)))) ; updater Does anybody else think that a feature like this would be useful? What kind of syntax (not involving ugly &foo keys -- Scheme currently does not yet have any of them) could actually be used for this? -- Oliver Laumann, Technical University of Berlin, Germany. ...!pyramid!tub!net or net@TUB.BITNET ...!mcvax!unido!tub!net  Date: Tue, 26 Apr 88 18:20:20 EDT From: Oliver Laumann @MC.LCS.MIT.EDU Sender: SCHREQ@MC.LCS.MIT.EDU Subject: ``Update functions'' in Scheme. To: SCHEME@MC.LCS.MIT.EDU Message-ID: <411492.880426.SCHREQ@MC.LCS.MIT.EDU> Date: Fri, 8 Apr 88 17:55:27 +0200 From: Oliver Laumann To: scheme-request at mc.lcs.mit.edu Re: ``Update functions'' in Scheme. Did anybody already think about adding ``generalized functions'' (a la Common-Lisp's setf/defsetf feature) to Scheme? This would eliminate the need for several primitive procedures, among them set-car!, set-cdr!, vector-set!, and string-set!. Instead of writing (set-car! p 5) or (vector-set! v 10 'a) this would make it possible to write (set! (car p) 5) or (set! (vector-ref v 10) 'a) accordingly. Of course, in implementations that support ``fluid-let'' one would also have to extend fluid-let to accept the new syntax. But how should users be able to define their own ``update functions''? Yes, I know the concept of ``settable operations'' of T, but unfortunately they are based on T's object oriented features. And I don't like the setf/defsetf concept of Common Lisp, because the accessor function and the update function have to be separate functions (if I understood it right). Consider the following example: I would like to be able to write a ``print-length'' procedure which, when called outside a set! form, returns the current ``print length'' (whatever this may be), and, when called as ``(set! (print-length) 10)'', sets the print length to 10. Ideally, only *one* function should be involved -- this function both knows how to return the current print length and how to set it to a new value. I could imagine something like this: (define print-length (let ((len 100)) (lambda (&update flag &optional val) (if flag ... ; set len to val (possibly with sanity-check) len)))) When called from within a set! form (that is, as an update function), ``flag'' would be true, otherwise false (called as accessor function). Now I can't come up with a satisfying syntax; the above &update kludge should only illustrate the concept (i.e. the function "knows" if it should act as accessor or update function). A coworker suggests adding a different lambda (which he jokingly called ``mikro'') that contains two parameter lists and two body forms, e.g. (define print-length (let ((len 100)) (mikro () len ; accessor (val) (something a la set! len val)))) ; updater Does anybody else think that a feature like this would be useful? What kind of syntax (not involving ugly &foo keys -- Scheme currently does not yet have any of them) could actually be used for this? -- Oliver Laumann, Technical University of Berlin, Germany. ...!pyramid!tub!net or net@TUB.BITNET ...!mcvax!unido!tub!net  Date: Tue, 26 Apr 88 17:34:50 EDT From: Scheme Requestee Subject: Cross mailing between UseNet and the ArpaNet To: ramsdell@LINUS.UMD.EDU cc: SCHEME@MC.LCS.MIT.EDU In-reply-to: Msg of Mon 18 Apr 88 07:12:28 EDT from John D. Ramsdell Message-ID: <411485.880426.SCHREQ@MC.LCS.MIT.EDU> Date: Mon, 18 Apr 88 07:12:28 EDT From: John D. Ramsdell Did you get the UseNet to ArpaNet connection working? If so, please tell the rest of us so we know if we no longer need to send our contributions to MIT. It is my understanding that mail is forwarded in both directions, without danger of divergence. Submissions to comp.lang.scheme will go to scheme@mc, and vice versa. I believe we have Eric Fair at Berkeley to thank for this somewhat miraculous achievement.  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 26 Apr 88 08:10:52 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Tue, 26 Apr 88 08:05:15 EDT Received: from FRSAC11.BITNET (NETWORK) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 7892; Tue, 26 Apr 88 08:05:13 EDT Date: Tue, 26 Apr 88 14:04:43 GMT To: scheme@mc.lcs.MIT.EDU From: NETWORK%FRSAC11.BITNET@MITVMA.MIT.EDU Comment: CROSSNET mail via MAILER@MITVMA Subject: SIOD 1.1 Date: 26 April 1988, 14:00:54 GMT From: NETWORK at FRSAC11 To: SCHEME at MC.LCS I got siod 1.1 , compile it on a Unix System Vr2 (UTS/V on a IBM 3090), and IT IS working. My timing for the simple naive (fib 20) is around 0.8 seconds. (Cscheme 5.3 is around 2.1 seconds.) Now I will try to understand the code. Thank you for this exercise. Regards, Jean-Pierre H. Dumas network@frsac11 (bitnet) network%frsac11.bitnet@cunyvm.cuny.edu (arpanet) dumas@sumex-aim.stanford.edu (arpanet)  Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 25 Apr 88 22:27:09 EDT Return-Path: Received: by bu-it.BU.EDU (4.0/4.7) id AA13520; Mon, 25 Apr 88 22:21:35 EDT Date: Mon, 25 Apr 88 22:21:35 EDT From: gjc@bu-it.BU.EDU (George J. Carrette) Message-Id: <8804260221.AA13520@bu-it.BU.EDU> To: scheme@mc.lcs.mit.edu Subject: SIOD release 1.1 Well, Barak.Pearlmutter@DOGHEN.BOLTZ.CS.CMU.EDU sent me a couple fixes including a full flonum recognizer, so while I was putting these into the source I figured, what the heck, add a case tc_symbol: to the switch on TYPE(tmp) in the evaluator and boom, you have macros. Then, if you can write macros you can add syntax for things like delay, and cons-stream. Then you want to put these goodies into a file, so you want to have load. Then why not (the-environment) and add a couple special forms like and, or, let, if you are going to actually write a program or two? Then I realized I had left out predicates like consp and numberp. Then with all this stuff you better write a siod.doc file, and actually make sure the thing compiles and runs on all the nearby systems. Release 1.1 SIOD is now in three files, siod.c 25k bytes siod.doc 21k bytes siod.scm 2k bytes Same system, same anonymous ftp, same directory. Enjoy! Some people without FTP access have asked for me to mail them the file, which is now three files. Perhaps someone can suggest a proper list on which to do some kind of POSTING of this code? Any experienced posters out there? -gjc  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 24 Apr 88 16:12:25 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA25523; Sun, 24 Apr 88 08:29:13 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Apr 88 13:30:53 GMT From: mcvax!enea!tut!jh@uunet.uu.net (Juha Hein{nen) Organization: Tampere University of Technology, Finland Subject: collect macro Message-Id: <3200@korppi.tut.fi> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Has anyone written the collect macro from Abelson&Sussman in extend-syntax or in some other macro notation? -- Juha Heinanen, Tampere Univ. of Technology, Finland jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)  Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 24 Apr 88 01:37:40 EDT Received: from bucsf (BUCSF.BU.EDU) by bu-it.BU.EDU (4.0/4.7) id AA29495; Sun, 24 Apr 88 01:32:16 EDT Return-Path: Received: by bucsf (4.12/4.7) id AA28440; Sun, 24 Apr 88 01:33:18 edt Date: Sun, 24 Apr 88 01:33:18 edt From: gjc%bucsf.bu.edu@bu-it.BU.EDU (George J. Carrette) Message-Id: <8804240533.AA28440@bucsf> To: scheme@mc.lcs.mit.edu Subject: small scheme implementation. I have done a demonstration implementation called SIOD, "Scheme In One Defun" originally in zetalisp, but now in C. A reasonable effort was made to keep the size and complexity down. The result is one file under 20 thousand bytes. Features: * (double) floating pointer numbers, +,-,*,/,>,<,eql * symbols, oblist * lists, cons,car,cdr,setcar,setcdr, assq, copy-list, eq. * define,set!,lambda,quote,if,progn * garbage collection, (copy style), heap size fixed on startup. * control-c quit interrupt, floating point exception handler. * Ran on 4.2BSD and VAX/VMS It is very easy to add new subrs and special forms (e.g. cons-stream), which I plan to do, up to 5000 bytes worth. The current version is available by anonymous ftp from bu-it.bu.edu in /pub/siod.c I hope the small size and straightfoward implementation make it easy for interested parties to port it to their microcomputers. Let me know if you have any problems. The implementation is moderately fast, with (fib 20) on an Encore Multimax taking 3.5 times longer in Cscheme than in SIOD. On a SUN4-280 SIOD did (fib 20) in 4.1 seconds, consing about 100 thousand cells. N.B. I like to time fib with: (define (fib x) (if (< x 2) x (+ (fib (- x 1)) (fib (- x 2))))) -gjc  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 23 Apr 88 00:36:11 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA25783; Tue, 19 Apr 88 17:01:14 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Apr 88 21:30:45 GMT From: rochester!ur-tut!hwfe@rutgers.edu (Harlan Feinstein) Organization: Univ. of Rochester Computing Center Subject: Re: Scheme Implementation for Macintosh 2 Message-Id: <1861@ur-tut.UUCP> References: <12391721505.50.MKATZ@A.ISI.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <12391721505.50.MKATZ@A.ISI.EDU> MKATZ@A.ISI.EDU (Morris Katz) writes: >I also would like to know about any ports of Cscheme to either the Mac 2 or >any other Unix system 5 rel 2 machine. I was about to send mail on this topic >this morning when I found that someone had beaten me to it by 1 day. > Morry Katz >------- I'm wondering if CScheme could run on an IBM PC. If anyone has done this could you send me email? 'ppreciate it. Disclaimer: If what I say seems wrong or offends you, consider this: I'm writing in my own language, not English, and it's coincidence that it looks like English. ------------------------------------------------------------------------------ "_The_ Zaphod Beeblebrox?" "Count the heads." Harlan Feinstein U U RRRR hwfeccss@uorvm.bitnet Student, University of Rochester U U RRRR hwfe@tut.cc.rochester.edu "We are... U R!" UUUU R R seismo!rochester!ur-tut!hwfe ------------------------------------------------------------------------------  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 23 Apr 88 00:18:11 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA02063; Fri, 22 Apr 88 08:41:26 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Apr 88 14:46:32 GMT From: mcvax!enea!liuida!kjepo@uunet.uu.net (Kjell Post) Organization: CIS Dept, Univ of Linkoping, Sweden Subject: Followup to Stoy's book? Message-Id: <791@butterix.liu.se> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Maybe this isn't the right group but here goes: Are there any plans on a revised edition of Joe Stoy's "Denotational Semantics" (MIT Press) ? The reason I'm asking is because the book is out of print (according to our local bookstore). Any other recommendations for books in this and adjacents areas? -- ------------------------------------------------------------------------------- (Y F) = (F (Y F)) |Dept of Comp&Info Science, Linkoping Sweden "This super-amazing, clever thing" | kjepo@majestix.liu.se - G.J. Sussman _|_ ...liuida!majestix.liu.se!kjepo  Received: from chamarti (TCP 2206400253) by MC.LCS.MIT.EDU 22 Apr 88 00:38:56 EDT Received: by CHAMARTIN.AI.MIT.EDU; Fri, 22 Apr 88 00:33:18 edt Date: Fri, 22 Apr 88 00:33:18 edt From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas) Message-Id: <8804220433.AA15204@chamarti> To: sunybcs!ugwiles@boulder.colorado.edu Cc: scheme@mc.lcs.mit.edu In-Reply-To: (Dale Wiles's message of 21 Apr 88 18:21:40 GMT <10423@sunybcs.UUCP> Subject: Where to mail bugs? Reply-To: jinx@zurich.ai.mit.edu Does anyone know the e-mail address to send bugs about MIT's C-Scheme to? The address in the source code is "BUG-CSCHEME%OZ@MC.LCS.MIT" but our postmaster bounced it back to me. The correct address is BUG-CSCHEME%oz@mc.lcs.mit.edu  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 21 Apr 88 23:21:43 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA12257; Thu, 21 Apr 88 13:54:13 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Apr 88 18:21:40 GMT From: sunybcs!ugwiles@boulder.colorado.edu (Dale Wiles) Organization: SUNY/Buffalo Computer Science Subject: Where to mail bugs? Message-Id: <10423@sunybcs.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anyone know the e-mail address to send bugs about MIT's C-Scheme to? The address in the source code is "BUG-CSCHEME%OZ@MC.LCS.MIT" but our postmaster bounced it back to me. Thanks in advance: Dale (ug) Wiles  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 21 Apr 88 18:37:59 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA10001; Thu, 21 Apr 88 11:47:01 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Apr 88 17:10:26 GMT From: apatosaur.cis.ohio-state.edu!verber@TUT.CIS.OHIO-STATE.EDU (Mark Verber) Organization: Ohio State University, Computer Science Subject: Re: Scheme Implementation for Macintosh 2 Message-Id: <11244@tut.cis.ohio-state.edu> References: <12391721505.50.MKATZ@A.ISI.EDU>, <2100@ubc-cs.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu From my experience MacScheme runs very happily on a MacII. The guys from Semantics (and Will Clinger) did a go job following the Apple rules. I will also run under Multi-finder in the background and under A/UX using the toolboxdeamon. Note: Stand alone applications generated via the native code compiler also run on the MacII and under A/UX. ---------------------------------------------------------------------- Mark A. Verber MaBell: 614-292-7344 Computer Science Department MX: verber@cis.ohio-state.edu Ohio State University DUMB: verber@ohio-state.arpa 2036 Neil Ave, Columbus, Ohio 43210 UUCP: ..!att!osu-cis!verber  Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 21 Apr 88 17:46:01 EDT Return-Path: Received: from kali.think.com by Think.COM; Thu, 21 Apr 88 15:13:04 EDT Received: by kali.think.com; Thu, 21 Apr 88 15:13:00 EDT Date: Thu, 21 Apr 88 15:13:00 EDT From: gls@Think.COM Message-Id: <8804211913.AA20292@kali.think.com> To: ubc-cs!faculty.cs.ubc.ca!manis@beaver.cs.washington.edu Cc: scheme@mc.lcs.mit.edu In-Reply-To: (Vince Manis's message of 20 Apr 88 01:24:14 GMT <2100@ubc-cs.UUCP> Subject: Scheme Implementation for Macintosh 2 Date: 20 Apr 88 01:24:14 GMT From: ubc-cs!faculty.cs.ubc.ca!manis@beaver.cs.washington.edu (Vince Manis) Organization: UBC Department of Computer Science, Vancouver, B.C., Canada References: <12391721505.50.MKATZ@A.ISI.EDU> Sender: scheme-request@mc.lcs.mit.edu MacScheme is alleged to run on the Mac 2 (I haven't seen it). According to the documentation for version 1.5, it runs ok, though there are apparently some rough edges. MacScheme comes with a really good native-code compiler. Publisher is Semantic Microsystems, in Portland. ... I run MacScheme on a Mac II all the time. It works fine. (The version of Toolsmith that I have does not interface to all the new routines in Volume V of "Inside Macintosh"--I obtained Toolsmith before Volume V had even been published--but this aside I have been very happy with it. I have done nontrivial Toolbox hacking to do some nifty dialog boxes.) My wife Barbara has implemented at least one full-blown, double-clickable application in MacScheme, and uses the resulting application routinely. --Guy Steele  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 21 Apr 88 13:40:52 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA05921; Thu, 21 Apr 88 08:58:16 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Apr 88 02:35:22 GMT From: hp-pcd!uoregon!markv@hplabs.hp.com (Mark VandeWettering) Organization: University of Oregon, Computer Science, Eugene OR Subject: Engines/SCOOPS in T? Message-Id: <1856@uoregon.uoregon.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anyone have an implementation of Chris Haynes Engines facilities written for T? While I am at it, how about an implementation of SCOOPS? I am currently using T to do research in functional programming, and would like to use these facilities. Thank you... Mark VandeWettering markv@cs.uoregon.edu \ Mark Terrence VandeWettering University of Oregon \ ..!tektronix!uoregon!markv Computer Science Dept. \ Life...the final frontier...  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 21 Apr 88 13:09:08 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA04126; Thu, 21 Apr 88 07:31:48 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Apr 88 10:46:31 GMT From: imagine!pawl23.pawl.rpi.edu!jefu@itsgw.rpi.edu (Jeffrey Putnam) Organization: RPI Public Access Workstation Lab - Troy, NY Subject: C Scheme Documentation Message-Id: <749@imagine.PAWL.RPI.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Two questions... We have MIT C scheme here, and it is not exactly as described in R^3 Report on Scheme. This is certainly OK by me as long as I know what is in it. But I dont. T'other day i was trying to do something and failing miserably because i couldnt find something - I think it was named-lambda - not in R^3, but used all over the place in the scheme code. Eventually, i figured out (after a couple DAYS! of poking around) that "(enable-language-features)" turned it on, but how was anyone supposed to know that from the C scheme source or documentation? Anyway, im looking for a manual - not SICP - but a real manual - one with lists of functions and what they do. Lacking this, i was trying to browse through the Scheme source and executable to find what i needed. One of the problems seems to be that scheme has no "apropos" which might have helped. (Actually the problem is worse since im trying to get things to work on an IBM running MTS where everything is protected and i cant even figure out what has been loaded.) Is there any way to browse environments - that is, to locate environments and then to see what they have defined in them? Or am I going about this in the completely wrong way? jeff putnam jefu@pawl.rpi.edu -or- jeff_putnam%rpitsmts@itsgw.rpi.edu "People would rather believe a simple lie than the complex truth."  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 21 Apr 88 01:44:40 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA06387; Wed, 20 Apr 88 04:20:34 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Apr 88 01:24:14 GMT From: ubc-cs!faculty.cs.ubc.ca!manis@beaver.cs.washington.edu (Vince Manis) Organization: UBC Department of Computer Science, Vancouver, B.C., Canada Subject: Re: Scheme Implementation for Macintosh 2 Message-Id: <2100@ubc-cs.UUCP> References: <12391721505.50.MKATZ@A.ISI.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu MacScheme is alleged to run on the Mac 2 (I haven't seen it). According to the documentation for version 1.5, it runs ok, though there are apparently some rough edges. MacScheme comes with a really good native-code compiler. Publisher is Semantic Microsystems, in Portland. There is also an implementation called XScheme, which is still under development. The author is David Betz, who wrote XLisp. It uses a bytecoded interpreter, so it's not wildly fast, but it is highly portable. Versions exist for PC, Atari ST, and Mac. I've read the code for the prerelease Mac version that's on BIX, and I'd expect it to run ok on a Mac 2. (No toolbox support, though). XScheme is intended as a tool for experimentation, not a production system (don't try to run Macsyma on it!), but it *is* free. Vincent Manis | manis@cs.ubc.ca The Invisible City of Kitezh | manis@cs.ubc.cdn Department of Computer Science | manis@ubc.csnet University of British Columbia | {ihnp4!alberta,uw-beaver,uunet}! | ubc-cs!manis <>  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 21 Apr 88 01:08:45 EDT Posted-From: The MITRE Corp., Bedford, MA Received: from darwin.sun.uucp by linus.MENET (3.2/4.7) id AA23209; Wed, 20 Apr 88 15:20:55 EDT From: John D. Ramsdell Posted-Date: Wed, 20 Apr 88 15:20:15 EDT Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3) id AA13737; Wed, 20 Apr 88 15:20:15 EDT Date: Wed, 20 Apr 88 15:20:15 EDT Message-Id: <8804201920.AA13737@darwin.sun.uucp> To: scheme@mc.lcs.mit.edu Subject: Lisp according to one Pascal programmer Normally, I avoid reading journals with the name of a programming language in their title whenever the journal is about that programming language. Those journals tend to contain disappointing articles. My curiousity was peeked by an article by Morteza Marzjarani called "A Comparison of the Computer Languages Pascal, C, Lisp, and Ada" in the Journal of Pascal, Ada, & Modula-2, Vol. 7, No. 1, pp. 5-10, 1988. What would someone from that journal say about Lisp? Turning to the reference list of Marzjarani's article, I noticed the only Lisp reference was Abelson and Sussman's "Structure and Interpretation of Computer Programs". I concluded the dialect of Lisp for comparison was Scheme. Turning to the main text I found that Lisp is not block structured, and "LISP has two data types only, ATOM and LIST" {p. 6}. Did you know that "An A-list (association list) represents referencing environment. That is referencing in LISP is strictly according to the most recent association rule via searching the A-list from beginning to end for an entry whose CAR is the atom we are searching for."? {p. 7} Features of LISP include {p. 8} "Explicit garbage collection", "No data structures", "Explicit sequencing is eliminated; instead function calls are used", "Two reserved words only (T,NIL)", "Linked lists and property list (represented as a special case of linked lists) form the basic data structures", and "Most LISP output is automatic. For each function call the system prints out the function name, its arguments, and the value returned by the function". Somehow, I think Morteza doesn't know how to turn of tracing in his Lisp and has never opened Abelson and Sussman's book. John  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 20 Apr 88 23:26:48 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA03646; Wed, 20 Apr 88 01:38:44 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Apr 88 08:34:11 GMT From: dewey.soe.berkeley.edu!oster@ucbvax.Berkeley.EDU (David Phillip Oster) Organization: School of Education, UC-Berkeley Subject: On Beyond Abelson & Sussman Message-Id: <23666@ucbvax.BERKELEY.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I've read Abelson & Sussman's "Structure and Interpretation of Computer Programs." Great book. Do you have any suggestions for what I should read now to take the next steps in: 1.) constraint propoagation systems 2.) logic programming 3.) ? --- David Phillip Oster --When you asked me to live in sin with you Arpa: oster@dewey.soe.berkeley.edu --I didn't know you meant sloth. Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 20 Apr 88 15:00:23 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA23501; Tue, 19 Apr 88 14:41:00 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Apr 88 18:02:33 GMT From: cos!duc@uunet.uu.net (Duc Kim Nguyen) Organization: Corporation for Open Systems, McLean, VA Subject: Is there a new version of T ? Message-Id: <1455@cos.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Is there a new version of T being distributed from Yale ? The version 3 of source we got was not buildable, and the instruction was very weak. I would appreciate any help and info. cheers duc@COS.COM  Received: from SCUBED.ARPA (TCP 30004010106) by MC.LCS.MIT.EDU 20 Apr 88 14:48:59 EDT Received: from s3landrew (s3landrew.ARPA) by SCUBED.ARPA (1.2/5.20b) id AA14154; Wed, 20 Apr 88 11:47:02 pdt Received: by s3landrew (3.2/5.20b) id AA12958; Wed, 20 Apr 88 11:46:31 PDT Date: Wed, 20 Apr 88 11:46:31 PDT From: eric%s3landrew@scubed.ARPA (Eric Kennedy) Message-Id: <8804201846.AA12958@s3landrew> To: scheme@mc.lcs.mit.edu Cc: eric%s3landrew@scubed.ARPA Subject: Read Macros in PC-Scheme?? Does anyone know if it is possible to define new read macros in TI's PC-Scheme? Sincerely, eric@scubed.arpa Eric Kennedy S-CUBED 3398 Carmel Mountain Road San Diego, CA 92121 (619) 453-0060  Received: from rutgers.edu (TCP 20001402007) by MC.LCS.MIT.EDU 20 Apr 88 12:29:36 EDT Received: by rutgers.edu (5.54/1.15) with UUCP id AA16677; Wed, 20 Apr 88 11:20:08 EDT Received: by mtune.ATT.COM (smail2.6) id AA24825; 20 Apr 88 11:05:16 EDT (Wed) Received: by ihnp4.ATT.COM id AA23663; 20 Apr 88 09:11:56 CDT (Wed) Received: by richp1.UUCP (smail2.5) id AA06493; 20 Apr 88 09:45:06 EST (Wed) Received: by richsun.uucp (3.2/SMI-3.2) id AA00346; Wed, 20 Apr 88 08:38:48 CDT Date: Wed, 20 Apr 88 08:38:48 CDT From: moss!ihnp4!richsun!craig@att.arpa (Craig Peterson (consultant)) Message-Id: <8804201338.AA00346@richsun.uucp> To: MKATZ@trout.nosc.mil Cc: scheme@mc.lcs.mit.edu In-Reply-To: <12391721505.50.MKATZ@A.ISI.EDU> (ihnp4!ucsd!A.ISI.EDU!ll-xn!MKATZ@trout.nosc.mil) Subject: Scheme Implementation for Macintosh 2 Posted-Date: Tue 19 Apr 88 11:59:15-EDT Date: Tue 19 Apr 88 11:59:15-EDT From: Morris Katz I also would like to know about any ports of Cscheme to either the Mac 2 or any other Unix system 5 rel 2 machine. I was about to send mail on this topic this morning when I found that someone had beaten me to it by 1 day. Morry Katz ------- I've ported it to System VR2. I've tried to contact the people at mit to let them know so that they can integrate it into future releases, but haven't had any success. Let me know if you'd like the diffs, and I'll try to put them together. craig@richp1.UUCP  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 20 Apr 88 04:15:50 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Wed, 20 Apr 88 04:10:54 EDT Received: from FRSAC11.BITNET (NETWORK) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 7251; Wed, 20 Apr 88 04:10:51 EDT Date: Wed, 20 Apr 88 10:07:24 GMT To: scheme@mc.lcs.MIT.EDU From: NETWORK%FRSAC11.BITNET@MITVMA.MIT.EDU Comment: CROSSNET mail via MAILER@MITVMA Subject: Scheme on SysVr2 Date: 20 April 1988, 09:57:22 GMT From: NETWORK at FRSAC11 To: SCHEME at MC.LCS There is a lot of questions about CScheme port on SystemVr2: I have 5.3 running on our Vanilla 5.2 (certified by AT&T). It is UTS/V running on a IBM 3090-200. I had little problem doing it, much less than some other according to what I know. CScoops runs on it, the Gabriel benchmarks too, with one slight exception that I have to work on. I have 6.1, but did not get the time to have it compiled yet. Regards, Jean-Pierre H. Dumas network@frsac11 (bitnet) network%frsac11.bitnet@cunyvm.cuny.edu (arpanet) dumas@sumex-aim.stanford.edu (arpanet)  Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 19 Apr 88 12:04:23 EDT Date: Tue 19 Apr 88 11:59:15-EDT From: Morris Katz Subject: Scheme Implementation for Macintosh 2 To: scheme@MC.LCS.MIT.EDU Message-ID: <12391721505.50.MKATZ@A.ISI.EDU> I also would like to know about any ports of Cscheme to either the Mac 2 or any other Unix system 5 rel 2 machine. I was about to send mail on this topic this morning when I found that someone had beaten me to it by 1 day. Morry Katz -------  Received: from duke.cs.duke.edu (TCP 20033306001) by MC.LCS.MIT.EDU 19 Apr 88 01:57:08 EDT Received: by duke.cs.duke.edu (5.54/DUKE/10-20-87) id AA11938; Tue, 19 Apr 88 00:13:04 EDT Date: Tue, 19 Apr 88 00:13:04 EDT From: Michael Gleicher Message-Id: <8804190413.AA11938@duke.cs.duke.edu> To: scheme@mc.lcs.mit.edu Subject: Scheme Implementation for Macintosh 2 has anyone ported Cscheme to the mac 2? Or any other Public domain scheme (or T for that matter)? Thanks, Mike Michael Lee Gleicher (-: If it looks like I'm wandering Duke University (-: around like I'm lost . . . E-Mail: gleicher@cs.duke.edu)(or uucp (-: Or P.O.B. 5899 D.S., Durham, NC 27706 (-: It's because I am!  Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 18 Apr 88 09:28:13 EDT Posted-From: The MITRE Corp., Bedford, MA Received: from darwin.sun.uucp by linus.MENET (3.2/4.7) id AA25051; Mon, 18 Apr 88 09:23:05 EDT From: John D. Ramsdell Posted-Date: Mon, 18 Apr 88 09:22:39 EDT Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3) id AA11583; Mon, 18 Apr 88 09:22:39 EDT Date: Mon, 18 Apr 88 09:22:39 EDT Message-Id: <8804181322.AA11583@darwin.sun.uucp> To: scheme@mc.lcs.mit.edu, texhax@score.stanford.edu Subject: SchemeTeX---Simple support for literate programming in Lisp. SchemeTeX provides simple support for literate programming in any dialect of Lisp on Unix. Originally created for use with Scheme, it defines a new source file format which may be used to produce LaTeX code or Lisp code. Roughly speaking, LaTeX formats Lisp code in a verbatum-like environment, and it formats Lisp comments in an ordinary environment. SchemeTeX is available via anonymous FTP from linus (192.12.120.51) in the shar file named "pub/schemeTeX.sh". Included is an operating system independent version for the T dialect of Lisp. John  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 10 Apr 88 23:50:58 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA17748; Sun, 10 Apr 88 19:35:44 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 88 20:04:40 GMT From: pacbell!att-ih!alberta!mnetor!utzoo!yunexus!oz@ames.arpa (Ozan Yigit) Organization: York U. Computing Services - Magic Group Subject: Scheme Bibliography database (BIB/REFER format) Message-Id: <399@yunexus.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu BIB/REFER Database on SCHEME The posting contains is a reasonable bibliography database on Scheme (a *crystal* in the muddy language landscape), in BIB/REFER format, containing 50 entries sorted by date and first author, for your perusal, corrections and enjoyment. I do not consider it complete nor correct, but I am posting it nevertheless to get some feedback, new entries, corrections etc. It is somewhat surprising that such a bib database has not been made available earlier, so I had to borrow + steal (:-) some entries from on-line documents, and did a lot of typing. In this database, I have tried to keep the entries very Scheme-specific, but I am not certain about some of the entries, as I have not yet been able to track them. [Speaking of *tracking references*, the most critical MIT tech reports are also the hardest to get a hold of... I still do not have a copy of the "RABBIT" report. I kinda wonder why MIT folks never put these tech reports into a collection book, and publish it thru MIT press. It would be a great service to the Scheme/Lisp community.] ------------------------------------------------------------------- Along with this posting, I am volunteering to keep this database up-to-date (hopefully with your help) for the benefit of this newsgroup. I will also a post pre-formatted version as well as a bibTeX version of the database once corrections and missing entries are in. [Please send all corrections, new entries, etc. via e-mail] ------------------------------------------------------------------- Happy Scheming... oz Usenet: ....utzoo!yunexus!oz ....!uunet!mnetor!yunexus!oz Bitnet: oz@[yulibra|yuyetti] Phonet: +1 416 736-5257x3976 -----cut here-----cut here-----cut here-----cut here----- #!/bin/sh # shar: Shell Archiver # Run the following text with /bin/sh to create: # scheme.bib # tags.doc # This archive created: Sun Apr 10 15:48:21 1988 echo shar: extracting scheme.bib '(9125 characters)' sed 's/^XX//' << \SHAR_EOF > scheme.bib XX XX%A John Reynolds XX%T Definitional Interpreters for Higher Order Programming Languages XX%J ACM Conference Proceedings XX%P 717-740 XX%I ACM XX%D 1972 XX XX%A Gerald Jay Sussman XX%A Guy Lewis Steele, Jr. XX%T Scheme: an Interpreter for Extended Lambda Calculus XX%R MIT Artificial Intelligence Memo 349 XX%C Cambridge, Mass. XX%D December 1975 XX XX%A Guy Lewis Steele, Jr. XX%A Gerald Jay Sussman XX%T Lambda, the Ultimate Imperative XX%R MIT Artificial Intelligence Memo 353 XX%C Cambridge, Mass. XX%D March 1976 XX%K imperative XX XX%A Guy Lewis Steele, Jr. XX%T Lambda, the Ultimate Declarative XX%R MIT Artificial Intelligence Memo 379 XX%C Cambridge, Mass. XX%D November 1976 XX%K declarative XX XX%A Guy Lewis Steele, Jr. XX%T Debunking the ``Expensive Procedure Call'' Myth, or Procedure Call XXImplementations Considered Harmful, or LAMBDA, the Ultimate GOTO XX%J ACM Conference Proceedings XX%P 153-162 XX%I ACM XX%D 1977 XX XX%A Guy Lewis Steele, Jr. XX%T Macaroni is Better than Spaghetti XX%J Proceedings of the Symposium on Artificial Intelligence and XXProgramming Languages XX%P 60-66 XX%O Special joint issue of SIGPLAN Notices 12(8) and SIGART Newsletter 64. XX%D August 1977 XX XX%A Mitchell Wand XX%T Continuation-Based Program Transformation Strategies XX%J Journal of the ACM XX%V 27 XX%N 1 XX%P 174-180 XX%D 1978 XX XX%A Guy Lewis Steele, Jr. XX%A Gerald Jay Sussman XX%T The Revised Report on Scheme, a Dialect of Lisp XX%R MIT Artificial Intelligence Memo 452 XX%C Cambridge, Mass. XX%D January 1978 XX XX%A Guy Lewis Steele, Jr. XX%T Rabbit: a Compiler for Scheme XX%R MIT Artificial Intelligence Laboratory Technical Report 474 XX%C Cambridge, Mass. XX%D May 1978 XX XX%A Guy Lewis Steele, Jr. XX%A Gerald Jay Sussman XX%T The Art of the Interpreter, or the Modularity Complex XX(parts zero, one, and two) XX%R MIT Artificial Intelligence Memo 453 XX%C Cambridge, Mass. XX%D May 1978 XX%K modularity XX XX%A Drew McDermott XX%T An Efficient Environment Allocation Scheme in an Interpreter XXfor a Lexically-Scoped Lisp XX%J Conference Record of the 1980 Lisp Conference XX%P 154-162 XX%I The Lisp Conference, P.O. Box 487, Redwood Estates CA. XX%D 1980 XX%O Proceedings reprinted by ACM XX XX%A Steven S. Muchnick XX%A Uwe F. Pleban XX%T A Semantic Comparison of Lisp and Scheme XX%J Conference Record of the 1980 Lisp Conference XX%P 56-65 XX%I The Lisp Conference, P.O. Box 487, Redwood Estates CA. XX%D 1980 XX XX%A Guy Lewis Steele, Jr. XX%T Compiler Optimization Based on Viewing LAMBDA as RENAME + GOTO XX%B AI: An MIT Perspective XX%E Patrick Henry Winston XX%E Richard Henry Brown XX%I MIT Press XX%C Cambridge, Mass. XX%D 1980 XX XX%A Guy Lewis Steele, Jr. XX%A Gerald Jay Sussman XX%T The Dream of a Lifetime: a Lazy Variable Extent Mechanism XX%J Conference Record of the 1980 Lisp Conference XX%P 163-172 XX%I The Lisp Conference XX%D 1980 XX XX%A Mitchell Wand XX%T Continuation-Based Multiprocessing XX%J Conference Record of the 1980 Lisp Conference XX%P 19-28 XX%I The Lisp Conference XX%D 1980 XX XX%A Guy Lewis Steele, Jr. XX%A Gerald Jay Sussman XX%T Design of a Lisp-based Processor XX%J CACM XX%V 23 XX%N 11 XX%P 628-645 XX%D November 1980 XX XX%A Gerald Jay Sussman XX%A Jack Holloway XX%A Guy Lewis Steele, Jr. XX%A Alan Bell XX%T Scheme-79 - Lisp on a Chip XX%J IEEE Computer XX%V 14 XX%N 7 XX%P 10-21 XX%D July 1981 XX%I IEEE XX XX%A John Batali XX%A Edmund Goodhue XX%A Chris Hanson XX%A Howie Shrobe XX%A Richard M. Stallman XX%A Gerald Jay Sussman XX%T The Scheme-81 Architecture - System and Chip XX%J Proceedings, Conference on Advanced Research in VLSI XX%P 69-77 XX%E Paul Penfield, Jr. XX%C Artech House, Dedham MA. XX%D 1982 XX%K scheme81 XX XX%A Peter Henderson XX%T Functional Geometry XX%J Conference Record of the 1982 ACM Symposium on Lisp and XXFunctional Programming XX%P 179-187 XX%D 1982 XX XX%A Jonathan A. Rees XX%A Norman I. Adams XX%T T: A Dialect of Lisp or, LAMBDA: The Ultimate Software Tool XX%J Conference Record of the 1982 ACM Symposium on Lisp and XXFunctional Programming XX%P 114-122 XX%D 1982 XX XX%A Carol Fessenden XX%A William Clinger XX%A Daniel P. Friedman XX%A Christopher T. Haynes XX%T Scheme 311 version 4 Reference Manual XX%R Computer Science Technical Report 137 XX%I Indiana University XX%D February 1983 XX%O Superceded by Computer Science Technical Report 153, 1985 XX XX%A William Clinger XX%T The Scheme 311 compiler: An Exercise in Denotational Semantics XX%J Conference Record of the 1984 ACM Symposium on Lisp and XXFunctional Programming XX%P 356-364 XX%D 1984 XX%K comp311 XX XX%A Daniel P. Friedman XX%A Christopher T. Haynes XX%A Eugene E. Kohlbecker XX%T Programming with Continuations XX%B Program Transformation and Programming Environments XX%P 263-274 XX%E P. Pepper XX%I Springer-Verlag XX%D 1984 XX XX%A Christopher T. Haynes XX%A Daniel P. Friedman XX%T Engines Build Process Abstractions XX%J Conference Record of the 1984 ACM Symposium on Lisp and XXFunctional Programming XX%P 18-24 XX%D 1984 XX XX%A Christopher T. Haynes XX%A Daniel P. Friedman XX%A Mitchell Wand XX%T Continuations and Coroutines XX%J Conference Record of the 1984 ACM Symposium on Lisp and XXFunctional Programming XX%P 293-298 XX%D 1984 XX XX%A Jonathan A. Rees XX%A Norman I. Adams XX%A James R. Meehan XX%T The T manual, fourth edition XX%I Yale University Computer Science Department XX%D January 1984 XX XX%A Guillermo J. Rozas XX%T Liar, an Algol-like Compiler for Scheme XX%I S. B. Thesis, MIT Department of Electrical Engineering and Computer XXScience XX%D January 1984 XX XX%T MIT Scheme Manual, Seventh Edition XX%I Department of Electrical Engineering and Computer Science, MIT XX%C Cambridge, Mass. XX%D September 1984 XX XX%T MacScheme Reference Manual XX%I Semantic Microsystems XX%C Sausalito, Calif. XX%D 1985 XX XX%A Harold Abelson XX%A Gerald Jay Sussman XX%A Julie Sussman XX%T Structure and Interpretation of Computer Programs XX%I MIT Press XX%C Cambridge, Mass. XX%D 1985 XX%K sicp XX XX%A Amitabh Srivastava XX%A Don Oxley XX%A Aditya Srivastava XX%T An (other) Integration of Logic and Functional Programming XX%J Proceedings of the Symposium on Logic Programming XX%P 254-260 XX%I IEEE XX%D 1985 XX XX%E William Clinger XX%T The Revised Revised Report on Scheme, or An Uncommon Lisp XX%R MIT Artificial Intelligence Memo 848 XX%C Cambridge, Mass. XX%O Also published as Computer Science Department Technical Report 174, XXIndiana University, June 1985. XX%D August 1985 XX%K rrrs XX XX%A Daniel P. Friedman XX%A Christopher T. Haynes XX%T Constraining Control XX%J Proceedings of the Twelfth Annual Symposium on Principles of XXProgramming Languages XX%P 245-254 XX%I ACM XX%D January 1985 XX XX%A Daniel P. Friedman XX%A Christopher T. Haynes XX%A Eugene E. Kohlbecker XX%A Mitchell Wand XX%T Scheme 84 Interim Reference Manual XX%R Computer Science Technical Report 153 XX%I Indiana University XX%D January 1985 XX%K scheme84 XX XX%T TI Scheme Language Reference Manual XX%I Texas Instruments, Inc. XX%O Preliminary version 1.0 XX%D November 1985 XX XX%A Michael A. Eisenberg XX%T Bochser: An Integrated Scheme Programming System XX%R MIT Computer Science Technical Report 349 XX%C Cambridge, Mass. XX%D October 1985 XX%K bochser XX XX%A David H. Bartley XX%A John C. Jensen XX%T The Implementation of PC Scheme XX%J Proceedings of the 1986 ACM Conference on Lisp XXand Functional Programming XX%P 86-93 XX%D 1986 XX%K pcscheme XX XX%A R. Kent Dybvig XX%A Daniel P. Friedman XX%A Christopher T. Haynes XX%T Expansion-Passing style: Beyond Conventional Macros XX%J Proceedings of the 1986 ACM Conference on Lisp and XXFunctional Programming XX%P 143-150 XX%D 1986 XX XX%A Marc Feeley XX%A Guy LaPalme XX%T Closure Generation based on viewing LAMBDA as EPSILON plus COMPILE XX%O Submitted for Publication. Not yet available. XX%D 1986 XX XX%A Matthias Felleisen XX%A Daniel P. Friedman XX%T A Closer Look At Export and Import Statements XX%J Computer Languages XX%V 11 XX%N 1 XX%P 29-37 XX%I Pergamon Press XX%D 1986 XX XX%A Matthias Felleisen XX%A Daniel P. Friedman XX%A Eugene E. Kohlbecker XX%A Bruce Duba XX%T Reasoning with Continuations XX%J Proceedings of the Symposium on Logic in Computer Science XX%P 131-141 XX%I IEEE Computer Society Press XX%C Washigton DC XX%D 1986 XX XX%A Christopher T. Haynes XX%A Daniel P. Friedman XX%A Mitchell Wand XX%T Obtaining Coroutines With Continuations XX%J Computer Languages XX%V 11 XX%N 3/4 XX%P 143-153 XX%I Pergamon Press XX%D 1986 XX XX%A Mitchell Wand XX%T From Interpreter to Compiler: A Representational Derivation XX%B Programs as Data Objects XX%I Springer-Verlag Lecture Notes XX%D 1986 XX XX%A Eugene E. Kohlbecker XX%T Syntactic Extensions in the Programming Language Lisp XX%I PhD thesis, Indiana University XX%D August 1986 XX XX%A Christopher T. Haynes XX%T Logic Continuations XX%J Proceedings of the Third International Conference on XXLogic Programming XX%P 671-685 XX%I Springer-Verlag XX%D Jul 1986 XX XX%A David Kranz XX%A Richard Kelsey XX%A Jonathan A. Rees XX%A Paul Hudak XX%A James Philbin XX%A Norman I. Adams XX%T Orbit: An Optimizing Compiler for Scheme XX%T Proceedings of the SIGPLAN '86 Symposium on Compiler XXConstruction XX%P 219-233 XX%I ACM XX%O Published as SIGPLAN Notices 21(7), July 1986 XX%D June 1986 XX%K orbit XX XX%A Marc Feeley XX%T Deux Approches a' L'implantation du Language Scheme XX%I M.Sc. Thesis, De'partement d'Informatique et de Recherche XXOpe'rationelle, University of Montreal XX%D May 1986 XX XX%A R. Kent Dybvig XX%T The Scheme Programming Language XX%I Prentice-Hall, Inc. XX%C Englewood Cliffs, New Jersey XX%D 1987 XX%K splang XX XX%A Marc Feeley XX%A Guy LaPalme XX%T Using Cloures for Code Generation XX%J Computer Languages XX%V 12 XX%N 1 XX%P 47-66 XX%I Pergamon Press XX%D 1987 XX XX%A Daniel P. Friedman XX%A Matthias Felleisen XX%T The Little LISPer XX%I MIT Press XX%D Trade Edition 1987 XX%K littlelisper SHAR_EOF if test 9125 -ne "`wc -c scheme.bib`" then echo shar: error transmitting scheme.bib '(should have been 9125 characters)' fi echo shar: extracting tags.doc '(422 characters)' sed 's/^XX//' << \SHAR_EOF > tags.doc XXBIB (UofArizona) Field Tags XX XX%A - Author's name XX%B - Title of the book containing item XX%C - City of publication XX%D - Date XX%E - Editor(s) of book containing item XX%F - Caption XX%G - Government (NTIS) ordering number XX%I - Issuer (publisher) XX%J - Journal name XX%K - Keys for searching XX%N - Issue number XX%O - Other information XX%P - Page(s) of article XX%R - Technical report number XX%S - Series title XX%T - Title XX%V - Volume number SHAR_EOF if test 422 -ne "`wc -c tags.doc`" then echo shar: error transmitting tags.doc '(should have been 422 characters)' fi # End of shell archive exit 0 -- ... and they will all Usenet: [decvax|ihnp4]!utzoo!yunexus!oz bite the dust ... ......!seismo!mnetor!yunexus!oz comprehensively. ... Bitnet: oz@[yusol|yulibra|yuyetti] Archbishop Tutu Phonet: +1 416 736-5257 x 3976  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 9 Apr 88 12:09:01 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA15847; Sat, 9 Apr 88 06:59:31 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Apr 88 23:41:59 GMT From: decvax!sunybcs!ugwiles@ucbvax.Berkeley.EDU (Dale Wiles) Organization: SUNY/Buffalo Computer Science Subject: emacs/scheme Message-Id: <10040@sunybcs.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Has any one run into any problems using scheme and Emacs. When I try to use scheme (MIT v 10) and emacs (v 18) I get the header with no prompt and can send functions in. But when I get an error, and it drops me to level 2, I can't get back up to level 1. When I remove the "-emacs" option from "run-scheme" then everything seems to work unless I send a region to the scheme process. Only the first function is entered, and then some times it locks up. If anyone has fixxed this problem, let me know. Thanks; Dale Wiles.  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 8 Apr 88 18:41:34 EDT Received: by iuvax.cs.indiana.edu; id AA13722; Fri, 8 Apr 88 11:08:49 EST Received: by iuvax.cs.indiana.edu (iuvax/MX/4.5/02-10-87) id AA13722; Fri, 8 Apr 88 11:08:49 EST Date: Fri, 8 Apr 88 11:08:49 EST From: Chris Haynes To: scheme@mc.lcs.mit.edu, rrrs-authors@mc.lcs.mit.edu Subject: Scheme standarization On March 25, 1988, a majority of the authors of the "Revised^3 Report on the Algorithmic Language Scheme" (SIGPLAN Notices, December, 1986), together with representatives of IEEE and X3 standardization committees, met at Indiana University as a study group to consider initiation of a formal standardization effort for Scheme. It was concluded that a formal standard was desirable to improve code portability, publication uniformity, and language visibility. It was recommended that a PAR be submitted through the IEEE Microprocessor Standards Committee to initiate the formal standardization effort and establish a Scheme Working Group. Christopher Haynes and William Clinger were nominated for Chair and Vice-Chair of the Working Group, respectively. It is expected that the Working Group will meet approximately twice a year, with the first meeting to be held on July 27, 1988, following the ACM Conference on Lisp and Functional Programming at Snowbird, Utah. The study group felt strongly that the informal group that produced the existing Scheme reports should continue its language design work by holding workshops and publishing further revised reports. While these reports are likely to form the basis for future revisions of the standard, they will probably be less conservative than is appropriate for a standards document and may, for example, include experimental features that should be withheld from standardization. The study group also concluded that Scheme standardization does not conflict in any way with existing or contemplated standardization efforts for other members of the Lisp family, such as X3J13. It was recommended that liaison be maintained with these efforts, and in particular that the views of the Scheme community be taken into account by the ANSI delegate to the ISO ISLISP standardization meetings, and that an observer from the Scheme community be present at such meetings if possible. -- Chris Haynes chaynes@iuvax.cs.indiana.edu  Received: from rutgers.edu (TCP 20001402007) by MC.LCS.MIT.EDU 5 Apr 88 22:06:16 EDT Received: by rutgers.edu (5.54/1.15) with UUCP id AA02298; Tue, 5 Apr 88 20:26:07 EDT Received: by mimsy.UMD.EDU (smail2.5) id AA29522; 5 Apr 88 20:12:40 EDT (Tue) Received: from watmath.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA03929; Tue, 5 Apr 88 19:55:49 EDT Received: from csc.uucp by watmath; Tue, 5 Apr 88 19:51:38 EDT Received: by csc.UUCP (smail2.5) id AA03325; 5 Apr 88 21:33:25 EST (Tue) Received: from calgary.uucp by watmath; Fri, 1 Apr 88 19:55:03 EST Received: from vaxb by calgary.UUCP (5.51/3.1x) id AA15372; Fri, 1 Apr 88 17:55:54 MST Received: by vaxb.LOCAL (5.51/2.1i) id AA15368; Fri, 1 Apr 88 17:55:49 MST Message-Id: <8804020055.AA15368@vaxb.LOCAL> Date: Fri, 1 Apr 88 17:55:49 MST From: Kevin Jameson To: scheme@mc.lcs.mit.edu This is a test message mailed from the usenet to scheme@mc.lcs.mit.edu to see if it gets forwarded from the Internet to comp.lang.scheme on the usenet.  Received: from rutgers.edu (TCP 20001402007) by MC.LCS.MIT.EDU 5 Apr 88 22:05:50 EDT Received: by rutgers.edu (5.54/1.15) with UUCP id AA02295; Tue, 5 Apr 88 20:26:04 EDT Received: by mimsy.UMD.EDU (smail2.5) id AA29519; 5 Apr 88 20:12:37 EDT (Tue) Received: from watmath.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA03924; Tue, 5 Apr 88 19:55:41 EDT Received: from csc.uucp by watmath; Tue, 5 Apr 88 19:51:10 EDT Received: by csc.UUCP (smail2.5) id AA03303; 5 Apr 88 21:32:55 EST (Tue) Received: from calgary.uucp by watmath; Fri, 1 Apr 88 19:55:03 EST Received: from vaxb by calgary.UUCP (5.51/3.1x) id AA15372; Fri, 1 Apr 88 17:55:54 MST Received: by vaxb.LOCAL (5.51/2.1i) id AA15368; Fri, 1 Apr 88 17:55:49 MST Message-Id: <8804020055.AA15368@vaxb.LOCAL> Date: Fri, 1 Apr 88 17:55:49 MST From: Kevin Jameson To: scheme@mc.lcs.mit.edu This is a test message mailed from the usenet to scheme@mc.lcs.mit.edu to see if it gets forwarded from the Internet to comp.lang.scheme on the usenet.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 5 Apr 88 16:01:17 EDT Date: Tue, 5 Apr 88 16:02:28 EDT From: Scheme Requestee Subject: test message, ignore To: scheme@MC.LCS.MIT.EDU Message-ID: <353958.880405.SCHREQ@AI.AI.MIT.EDU> Weeding out bad addresses again, and testing many new additions. If a long time (several weeks) goes by and you haven't received any scheme mail, this is probably because you've been removed from the list. The policy is ruthless: addresses that are unreachable even once are generally removed from the list.  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 4 Apr 88 00:15:32 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.26) id AA07726; Sun, 3 Apr 88 09:42:54 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Apr 88 02:37:27 GMT From: ncc!alberta!calgary!jameson@uunet.uu.net (Kevin Jameson) Organization: U. of Calgary, Calgary, Ab. Subject: Re: MIT C Scheme design info Message-Id: <1520@vaxb.calgary.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu The following is a list (part 2 of 2) of most Scheme files used in the MIT C Scheme interpreter circa verson 4.1, along with a brief statement of their function. Most of the information has been gleaned gleaned from the short comment at the beginning of each file. This list gives a flavor of how the interpreter is organized, and should help new readers of the code to find their way around. Note that much (half?) of C Scheme is written in C, and is not listed here. The list of C files (part 1 of 2) for the microcode interpreter was posted earlier. I know now that the earlier posting of C files contained minor errors, and at the very least is somewhat out of date (my version is 4.1, vs. the current version of 6.2.0). (No doubt the same two facts will hold for this file too, but it's a start...) Any mistakes are my own. - Kevin Jameson, 31 March 88 ..!{ihnp4,ubc-vision}!alberta!calgary!jameson FILE Brief Function ============= ================================================== SCHEME SYSTEM TYPES xbuild.scm build a cross syntaxer system abuild.scm build a system for athena ubuild.scm build a unix interface scheme system sbuildmd.scm build a student (MIT 6.001 course) scheme system studentmd.scm env,syntax,& read tbl mods for 6.001 students featmd.scm std features scheme system INTERPRETER error.scm rep (read-eval-print) interface,error defs,definers,handlers parse.scm scheme parser for The REP Reader (ch class tbls,macros,atoms) print.scm The REP (read-eval-print) Printer read.scm The REP Reader (tyi/eof/input streams,with-input-from-file) rep.scm the read-eval-print loop,history,and history access funs repuse.scm REP user interface (prompts, drivers, proceeds) CROSS SYNTAXER (the byte code (scode) compiler) syntax.scm the Cross Syntaxer (byte code (scode) generator/compiler) scan.scm definition scanner reduces n of "real auxilary" vars in env xconv.scm convert declarations into integrations xpatch.scm special lambda interface xsubst.scm integration of primitives (merger, dispatcher) unsyn.scm unsyntaxer converts scode back to sexprs MISC DEFINITIONS and Data Type Stuff adapt.scm compatability defs (true/#!true,nil/'(),list*/cons*) crock.scm defs of special obj types (state & syntax tables, type obj) stypes.scm scode type setup (TC's: symbols,conditions,proctypes,etc) scode.scm scode grab bag (consts,many predicates for data types) sdata.scm abstract data field funs(ctl pts,set!s,refs,pairs,vects,etc) types.scm abstract typing funs (supremum/infimums?,lattice theory stuff) ustruc.scm microstruc? (follows scode abstraction in boot sequence) utabmd.scm ucode type tables (fixed,types,returns,prims,externs,errors) utabs.scm ucode tbl intrfc (fixed obj vec,type detection,TC,RC,TERMC..) PRIMITIVES bitvec.scm 1 bit vector ops (cons,set,size,ref,1b? predicates) char.scm character defs, bit tables, charscan table generator funs equals.scm many equality funs (eqv?,equal?,etc) explode.scm maclisp style printname utils (explode,implode,readch,ascii) format.scm output string formatters, format dispatch table gensym.scm uninterned symbol generator gprims.scm global primitives list (defs funs in global env for compiler) hash.scm object hashing, unhashing, population functions io.scm primitive io utils (channel stuff, files vector/locks,hunk3s) list.scm lisp ops (cons,pair?,length,cxr,mappers,assocs,members,etc) load.scm program loading lambda.scm lambda abstraction (lambda,lexpr,extended-lambda) narith.scm scheme math funs (+,-,trigs,floats,polys,min/max,etc) oldio.scm old io procedure names (channel io stuff) pathnm.scm pathname utils (make,drive,directroy,type,conversion funs) primlist.scm primitive list ops (cons,memq,assoc,cxr,etc) scomb.scm scode combinator abstractions stream.scm stream utilities (append,filter,accumulate,merge,etc) string.scm character string ops strmac.scm stream macros uio.scm useful file io funs (read,copy,rn,dl,exists?) unpars.scm unparsers for converting objects to string representations vector.scm vector ops (make,copy,vector references..) xlist.scm extended list ops (mapcan,mapcan*,or,and) PACKAGES advice.scm tools to advise funs (trace,break,other advice wrappers) pp.scm scheme pretty printer rrrs.scm revised report on Scheme compatability defs,macro definers wind.scm state space world model (state pts,dynamic wind,protectors..) DEBUGGER comand.scm debugger command loop support debug.scm scm level debugger w/ display,history,motion,continuation cmds stackp.scm scheme control stack parser for debugger where.scm the environment inspector(show,show-frame,print bindings...) xdebug.scm debugging primitives SYSTEM boot.scm bootload utils, run after coldmd. defs of global primitve funs datime.scm date time utils events.scm event distribution system file.scm file package (catalog,floppy,volumn,directory,misc funs) gc.scm scheme garbage collector, gc-daemon list, suspension funs gcstat.scm garbage collector meters, history modes, etc history.scm history manipulation (backbone & ribs, push/pop history, etc) intrpt.scm interrupt system (timers,keyboard ints,default handlers) link.scm links compiled byte code ? photo.scm ? takes an internal photo or something (whatever that is) sysclk.scm system clock utils (set,read,interval calculations) system.scm system funs (world dumpers,disk savers) world.scm world ops (save, disk restore, quit, exit..) MACHINE DEPENDENT (md) implmd.scm defs for implementation dependencies (mostly whtspc ch codes) spmd.scm control stack/control point funs xusermd.scm cross syntaxer user interface (pathname and string funs) coldmd.scm first scm code runs early, builds obarray, fixed obj vector runmd.scm loads compiled code for runtime system MISCELLANEOUS bgraph.scm bobcat (starbase) graphics interface emacs.scm emacs interface to scheme system future.scm part of butterfly basic band load (atom macros) graphics.scm graphics system interface (draw-line,line styles, etc) process.scm interface to unix primitives (signal,spawn,wait,pause,etc) qsort.scm a scheme quicksort sample.scm shows how microcode C funs are linked into scheme unix.scm unix scheme interface (cwd,mkdir,kill-eol,getenv,etc) 6.001 Course login.scm student login/logout utils logout.scm student logout utils (resets 6.001 student environment) namelist.scm machine names for 6.001 lab EXAMPLES chapter1.cod Scheme code from text by Abelson & Sussman, chapter2.cod Structure and Interpretation of Computer Programs chapter3.cod chapter5.cod chapter4.cod PROBLEM SETS (mostly related to SICP) adventure.scm a game compiler.scm simple scheme compiler (see Struc & Interp of Comp Progms) eceval.scm explicit control evaluator (see SICP) ecevsyn.scm expr & env defs used by explicit ctl eval (see SICP) regsim.scm register machine simulator (see SICP) ps4.scm huffman encoding funs ps5.scm basic generic math funs (ints,polys,rationals, see SICP) ps6.scm imaginary world defs (deans,trolls,etc) ps7.scm stream utils ps8eval.scm evaluator funs for explicit ctl evaluator (see SICP) ps8mods.scm environment, binding utils (see SICP) ps8putget.scm put/get procs (see SICP) ps9data.scm database for query language interpreter (see SICP) ps9query.scm query language interpreter (see SICP) ps10load.scm program loader  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 31 Mar 88 09:15:21 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Thu, 31 Mar 88 09:12:57 EST Received: from UNB by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 1391; Thu, 31 Mar 88 09:12:52 EST Received: by UNBMVS1 (Mailer 1.04.14) id 8112; Thu, 31 Mar 88 10:10:45 AST Date: Thu, 31 Mar 88 10:10:51 AST To: SCHEME@MC.LCS.MIT.EDU Subject: Porting Scheme to our IBM3090 running MVS/XA From: "Michael J. MacDonald" Message-ID: We are considering porting Scheme to our IBM3090-180/VF. I am seeking information on a number of items. We currently have the source from MIT Scheme Version 4.1.1 microcode version 8.2. What is the latest release of Scheme? What problems can I expect? Has anyone ported it to an IBM 370 (MVS) machine? Does anyone have any advice? Should we do it from scratch? Please respond direct, I am not on the List. Michael MacDonald Software Specialist, School of Computer Science University of New Brunswick Po. Box 4400 Fredericton, New Brunswick CANADA E3B 5A3 (506) 453-4566 Netnorth/BITNET: MIKEMAC@UNB  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 31 Mar 88 03:19:28 EST Received: by ucbvax.Berkeley.EDU (5.59/1.26) id AA27837; Wed, 30 Mar 88 19:21:19 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Mar 88 18:54:22 GMT From: trwrb!aero!venera.isi.edu!saus@ucbvax.Berkeley.EDU (Mark Sausville) Organization: Information Sciences Institute, Univ. of So. California Subject: availability of Scheme on Atari STs Message-Id: <5148@venera.isi.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anybody know if there is a version of Scheme available for the Atari ST? I know there's something called MacScheme and it seems like those people could adapt there product without too much trouble. thanks, Mark.  Received: from ucbvax.berkeley.edu (TCP 1200400116) by MC.LCS.MIT.EDU 30 Mar 88 08:39:13 EST Received: by ucbvax.berkeley.edu (5.59/1.26) id AA02604; Tue, 29 Mar 88 14:15:20 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Mar 88 00:17:52 GMT From: att-ih!alberta!calgary!jameson@gargoyle.uchicago.edu (Kevin Jameson) Organization: U. of Calgary, Calgary, Ab. Subject: Re: MIT C Scheme design info Message-Id: <1499@vaxb.calgary.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu The following is a list of most C files used in the MIT C Scheme interpreter, along with a brief statement of function. Most of the information is gleaned from the short comment at the beginning of each file. This list gives a flavor of how the interpreter is organized, and should help new readers of the code to find their way around. Note that much (half?) of C Scheme is written in Scheme, and is not listed here. The microcode interpreter files below actually interpret many runtime functions which are written in Scheme (such as the main read-eval-print loop). The Scheme runtime files + the host interpreter below offer a complete system to the user. Of course some of the information below may be wrong, though to the best of my knowledge it is correct. Any mistakes are my own. - Kevin Jameson, 28 March 88 ..!{ihnp4,ubc-vision}!alberta!calgary!jameson FILE Brief Function ============= ================================================== scheme.h defs for the interpreter in interpre.c config.h configuration file describes stk size,heap size, etc const.h global named constants fixobj.h format (offsets) of fixed object vector extern.h extern machine and many other interface dcls scode.h describes byte code format sdata.h describes user data object formats types.h list of object type codes TC_xxx returns.h list of return codes used by interpreter RC_xxxx errors.h list of error codes prims.h list of ids and names (PC_xxx) for all system primitives object.h defs & access macros for scheme objects primitive.h macros for defining and handling primitives boot.c main boot program for scheme interpreter interpre.h macros for interpreter zones.h time zones for performance metering hooks.c hooks into the interp - apply,catch,throw, etc storage.c prim, arg count tbls, global storage allocs interpre.c byte code interp coded in continuation passing style utils.c utils used by interpreter (backout_of_primitive,etc) lookup.c symbol lookup and manipulation usrdef.c table of external primitives produced by findprim extern.c external primitives defined by user findprim.c builds table of external prims from users files nihil.c defines unimplemented primitives reqd by scheme default.h unimplemented default hooks not def'd by user in config.h cross.doc some doc on the cross syntaxer (byte code compiler) readme.unx tells where things are in unix version MATH CODE generic.c mostly generic math funs for various numeric types missing.c math utils which wouldn't fit anywhere else mul.c portable fixnum multiplication flonum.c floating pt funs, mostly superceded by generic.c flonum.h defs for flonum.c fixnum.c fixnum (24 bit) funs, mostly superceded by generic.c bignum.c bignum arithmetic functions bignum.h bignum arithmetic declarations bitops.c extended bitops for infinite precision arithmetic bitstr.c bitstring functions DEBUGGING CODE step.c support for the debugger stepper xdebug.c useful prims for scheme memory prim debugging bkpt.c debugger breakpoint functions bkpt.h debugger breakpoint definitions, macros debug.c printing and listing functions used by debugger GARBAGE COLLECTOR purify.c much like gc, only purifies (whatever that is) instead daemon.c two gc daemons (obj hash tbl & file closer) gc.h macros for all gc code (and maybe others) gccode.h macros for code which does gc-like loops gcloop.c low level gc stuff gctype.c maps type codes into gc object type codes PRIMITIVE FUNCTIONS fetchpar.c makes implementation parms available to scheme file.c file i/o primitive scheme functions hunk.c funs to handle triplet hunk3's for file blocks io.c scheme io primitives, channel grabbing, etc list.c list manipulation functions (memq, cons, car, etc) prim.c primitives which won't fit elsewhere string.c string primitives, cv strings to/from lists vector.c vector handling and conversion (to lists) code FASTLOADER (FASL) FUNCTIONS translate.h macros for psbtobin, bintopsb (psb=portable scheme binary) schloader.c standalone prog to load a dumped scheme core? load.c common code for reading fasl files bintopsb.c converts fasl files to portable ascii breakup.c used for fasl conversion? ppband.c pretty prints fasl files in human format psbtobin.c converts portable ascii files to fasl format dump.c common code for dumping fasl files dumpworld.c core save routine, calls gnu unexec fasdump.c holds fasdump, fasload, and bandload functions fasl.h defs for fasl file format fasload.c reads fasl files, relocates and interns symbols SCHEME CODE (not related to the Scheme runtime stuff) chapter1.code from Structure and Interpretation of Computer Programs chapter2.code from SICP (Abelson & Sussman) chapter3.code from SICP chapter4.code from SICP chapter5.code from SICP MISCELLANEOUS ChangeLog only two entries install main installation notes Install.unx unix installation notes Install.vms vms installation notes Makefile main makefile Makefile.200 for the 200 series of some machine Makefile.500 for the 500 series of some machine Makefile.ind for some other operating system Makefile.unk for an unknown operating system Makefile.vax for vax Readme.vms tells where things are in vms version TO_DO a wish list UPGRADE diffs between CScheme release 3 and 4 Wsize.c tests out compiler/machine for bit & math ops athena.c athena graphics primitives for special terminals bobcat.c bobcat graphics interface for starbase package config.dst same as config.h locks.h for locking heap, etc os.c selects appropriate operating system file for build process.c utils to fork inferior processes in unix regblock.c defines registers used by compiler unexec.c from gnu-emacs. dumps core on unix systems unix.c unix specific prims (completed version of unknown.c) unknown.c os specific blank prim stubs for unknown op system valret.c emulates ITS valret on a unix system vms.c vms specific prims (completed version of unknown.c) vmsall.com vms batch file for compilation SPECIAL CODE (to handle Scheme language features) future.c support code for futures futures.h macros for futures code history.h defines history data structures intercom.c single process simulation of futures stuff  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 28 Mar 88 10:23:41 EST Date: Mon, 28 Mar 88 10:24:22 EST From: Jonathan A Rees Subject: T discussion and newsgroups To: mcvax!ukc!reading!onion!minster!SoftEng!martin@UUNET.UU.NET cc: scheme@MC.LCS.MIT.EDU In-reply-to: Msg of 19 Mar 88 22:38:32 GMT from mcvax!ukc!reading!onion!minster!SoftEng!martin at uunet.uu.net Message-ID: <348649.880328.JAR@AI.AI.MIT.EDU> Discussion pertaining T can be carried out on the T-Discussion mailing list. Send mail to t-discussion-request@MC.LCS.MIT.EDU to be added. Similarly for C Scheme; info-cscheme-request%OZ@MC.LCS.MIT.EDU. ... unless you do not have access to the Internet, as I understand many Usenet people do not. In that case, please carry on the conversation here (or on comp.lang.scheme), as there is no "comp.lang.t" newsgroup to my knowledge. Or lobby Berkeley to create one. The same goes for C Scheme (I have repeatedly requested that they create a C Scheme newsgroup, but they say they are too busy). And speaking of comp.lang.scheme: please correct me if I'm wrong, but it's my understanding that messages sent to the Scheme mailing list on the Internet are forwarded to comp.lang.scheme on Usenet, but not vice versa. It's possible that there is interesting discussion happening on comp.lang.scheme that us Internet users are missing out on, but I wouldn't know. I hear rumors that there exist mailing lists for which there is mutual forwading between Internet and Usenet (without infinite loops), but I don't know how to set one up. If anyone would like to volunteer to do so, please speak up by sending a message to me at scheme-request@mc.lcs.mit.edu. - humble moderator.  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 27 Mar 88 16:31:04 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA08205; Thu, 24 Mar 88 07:51:45 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Mar 88 22:38:32 GMT From: mcvax!ukc!reading!onion!minster!SoftEng!martin@uunet.uu.net Organization: Department of Computer Science, University of York, England Subject: T operations, etc Message-Id: <574814312.20004@minster.york.ac.uk> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I've just discovered that T version 3 has an as-far-as-I-can-tell undocumented syntax for operations. The documentation gives: (object procedure . method-clauses) where a method-clause is: ((operation-name self . args) . body) well, it turns out that a method-clause can also be: ((operation-name (self op-name next first) . args) . body) where 'self' is bound to the 'object' in which the method-clause was defined, as before, 'op-name' is bound to the operation being carried out, 'next' is bound to the next 'object' in the 'join' which would have been asked to field this operation if the present 'object' had not got it, and 'first' is bound to the first 'object' of the 'join' that was asked to field the operation. It seems obvious that these are intended to allow more control over the inheritance of operations. 'first' is the Smalltalk equivalent of self, and 'next' the equivalent of super! 'op-name' appears to allow the forwarding of operations. How many other wonderful things are hiding in T3.0 that people don't know about because of the (lack of up-to-date) documentation? On a similar note... Has anyone succeeded in re-compiling & linking T3.0, or of suspending a T system? Whenever I try to compile things I get syntax errors (or worse!), and whenever I try to suspend I get an indefinite recursion in vgc! Help! Martin usenet: ...!mcvax!ukc!minster!martin surface: Martin C. Atkins Department of Computer Science University of York Heslington York Y01 5DD ENGLAND PS I'm using the Sun-3 version of T PPS Despite the above gripes, I like T very much... It's just that I can't use it for the things I want unless I can link in some more C routines! PPPS Has anyone else in Europe/UK got T3.0?  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 27 Mar 88 13:13:37 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA04295; Sat, 26 Mar 88 17:02:52 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Mar 88 23:46:29 GMT From: darrell@sdcsvax.ucsd.edu (Darrell Long) Organization: University of California, San Diego Subject: Where can I get Scheme? Message-Id: <4806@sdcsvax.UCSD.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Hi there! Where can I get sources to Scheme? I can ftp, MILnet prefered. Thanks, DL -- Darrell Long Department of Computer Science & Engineering, UC San Diego, La Jolla CA 92093 ARPA: Darrell@Beowulf.UCSD.EDU UUCP: darrell@sdcsvax.uucp Operating Systems submissions to: comp-os-research@sdcsvax.uucp  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 27 Mar 88 13:00:35 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA29063; Sat, 26 Mar 88 10:34:53 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Mar 88 22:14:27 GMT From: mcvax!ukc!its63b!aiva!jeff@uunet.uu.net (Jeff Dalton) Organization: Dept. of AI, Univ. of Edinburgh, UK Subject: Re: T operations, etc Message-Id: <304@aiva.ed.ac.uk> References: <574814312.20004@minster.york.ac.uk> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <574814312.20004@minster.york.ac.uk> martin@minster.york.ac.uk writes: >I've just discovered that T version 3 has an as-far-as-I-can-tell >undocumented syntax for operations. [...] > ((operation-name (self op-name next first) . args) . body) I'd just noticed that myself. Perhaps it is "unreleased", as the T 2.8 release notes used to say of experimental things. > How many other wonderful things are hiding in T3.0 that people >don't know about because of the (lack of up-to-date) documentation? It works the other way too: the LOCALE special form has stopped working despite being documented in the manual and in Stephen Slade's book. Nonetheless, I suspect the release notes cover most of the changes (they cover the LOCALE one) and so expect that the number of further surprises will be small. >On a similar note... Has anyone succeeded in re-compiling & linking T3.0, >or of suspending a T system? I have not tried rebuilding T, but I have no trouble suspending it with csh job control on a Sun. > Has anyone else in Europe/UK got T3.0? Why, yes: I have one, and I know of at least two others. We should keep in touch. Jeff Dalton, JANET: J.Dalton@uk.ac.ed AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 26 Mar 88 19:26:55 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA19659; Sat, 26 Mar 88 01:23:12 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Mar 88 14:18:52 GMT From: pacbell!att-ih!alberta!calgary!jameson@AMES.ARC.NASA.GOV (Kevin Jameson) Organization: U. of Calgary, Calgary, Ab. Subject: MIT C-Scheme design info Message-Id: <1487@vaxb.calgary.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I have just been looking through the source for C Scheme v4.1.1 (via the Gnu distribution), and am almost overcome with the size of the task at hand (to understand it so I can write my a simpler version for my pc). I recognize that I could cut away code until I could isolate the major components, but I would still be left wondering why things were done the way they were. Did anyone write any design info down when it was being constructed? If so, is there any way I could obtain a copy to read? Failing that, could anyone post a design summary if they have one? Could anyone in the know suggest a starting place and method toward understanding this implementation? Is 4.1.1 the latest version? Thanks Kevin ...!{ihnp4,ubc-vision}!alberta!calgary!jameson  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 26 Mar 88 19:25:18 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA19763; Sat, 26 Mar 88 01:28:42 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Mar 88 14:25:59 GMT From: pacbell!att-ih!alberta!calgary!jameson@AMES.ARC.NASA.GOV (Kevin Jameson) Organization: U. of Calgary, Calgary, Ab. Subject: Saving a continuation Message-Id: <1488@vaxb.calgary.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu When a continuation is saved, what else must be preserved? 1) Surely the stack history prior to the save? 2) The environment at the time of the save (this is not done, as far as I can figure out) 3) Anything else? Thanks Kevin ...!{ihnp4,ubc-vision}!alberta!calgary!jameson  Received: from buita.BU.EDU (TCP 20061212055) by MC.LCS.MIT.EDU 24 Mar 88 19:13:33 EST Received: from BU-IT.BU.EDU by buita.BU.EDU (5.58/4.7) id AA24397; Thu, 24 Mar 88 19:07:20 EST Received: from bucsf (bucsf.bu.edu) by bu-it.bu.edu (3.2/4.7) id AA28602; Thu, 24 Mar 88 19:10:12 EST Return-Path: Received: by bucsf (4.12/4.7) id AA23522; Thu, 24 Mar 88 19:10:07 est Date: Thu, 24 Mar 88 19:10:07 est From: gjc%bucsf.bu.edu@buita.BU.EDU (George J. Carrette) Message-Id: <8803250010.AA23522@bucsf> To: pierce@golfer.Dayton.NCR.COM Cc: scheme@mc.lcs.mit.edu, gene.pierce%dayton.ncr.com@relay.cs.net Subject: How can you do things like ?X -> (*var* x) without Read Macros ? (1) if you are implementing your own read/eval/print loop for a random language you can write your own read, or use that CGOLREAD that someone on this list may have already ported to scheme. (1.5) you may be able to get away with a read/mung/eval/print loop. Just mung the result of read before you pass it along. I teach just this technique to transform ?x into the result of (make-variable :name 'x) (common lisp, sigh...) in a problem set on pattern matching and pattern compilation. (2) If you have evaluation macros, you can always have them mung the passed-in-structure without mercy, e.g. using the technique (1.5) (assert (append ?x () ?x)) (assert (append ?x (?a . ?y) (?a . ?y)) (append ?x ?y ?y)) (3) If you dont have evaluation macros, big deal, just quote the arguments, (assert '(append ?x () ?x)) as long as can call EVAL or COMPILE yourself there is no loss of generality. (4) In drastic situations use strings, (fortran "FUNCTION F(X,Y) F = X*Y+SIN(X) RETURN END") Note that FORTRAN 77 uses 'FOO BAR' for strings, so this actually works ok, without having to escape-quote internal double quotes. -gjc  Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 24 Mar 88 16:41:47 EST Received: from Salvador.ms by ArpaGateway.ms ; 24 MAR 88 13:37:00 PST Date: Thu, 24 Mar 88 13:36:31 PST From: Pavel.pa@Xerox.COM Subject: Re: How can you do things like ?X -> (*var* x) without Read Macros ? In-reply-to: <8803231941.AA16664@SCUBED.ARPA> To: pierce@golfer.Dayton.NCR.COM Cc: scheme@mc.lcs.mit.edu Message-ID: <880324-133700-4063@Xerox> You preprocess the input from the user, checking each symbol for a first-character of "?" and transforming all such uses into the list you mentioned. Alternatively, you write a parser/scanner for your input language that has nothing to do with the Scheme function READ. I prefer the latter idea myself. To my mind, READ's only legitimate purpose is the reading of real Scheme programs and data. Pavel  Received: from ernie.Berkeley.EDU (TCP 20010104415) by MC.LCS.MIT.EDU 24 Mar 88 14:41:14 EST Received: by ernie.Berkeley.EDU (5.58/1.26) id AA20285; Thu, 24 Mar 88 11:40:26 PST Date: Thu, 24 Mar 88 11:40:26 PST From: bh@ernie.Berkeley.EDU (Brian Harvey) Message-Id: <8803241940.AA20285@ernie.Berkeley.EDU> To: scheme@mc.lcs.mit.edu Subject: How many Schemes can your Vax take? At Berkeley we have been using Sun (3/50) systems to run rather large introductory courses. Students use Emacs, C-scheme, X-windows. While this is a noble experiment and has many advocates, it is also money-intensive and slow. We are interested in comparing this to various hypothetical alternatives. One presumably lower-cost configuration for which others may have useful experience is time-shared access to a (probably largish) VAX (ULTRIX). Can you offer data points on how many users can be supported reasonably? To make the data collection simpler, perhaps you could fill in the following table: VAX model #: megs of memory: Do you use Emacs? Jove? Vi? Do you use C-Scheme, Chez Scheme, T, other? Typical number of users for "good" response: Typical number for "marginally acceptable" response: Major advantages or disadvantages: Any other comments or advice: Please respond directly to me, rather than to the mailing list. I will summarize responses. Thanks.  Received: from UDEL.EDU (TCP 1200000140) by MC.LCS.MIT.EDU 24 Mar 88 13:05:34 EST Received: from dewey.udel.edu by Louie.UDEL.EDU id aa00431; 24 Mar 88 12:53 EST Received: from localhost by Dewey.UDEL.EDU id aa01681; 24 Mar 88 12:50 EST To: Vincent Manis cc: scheme@mc.lcs.mit.edu Subject: Re: Scheme as an introductory programming language In-reply-to: Your message of 07 Mar 88 11:35:00 -0800. <568*manis@instr.camosun.bcc.cdn> Date: Thu, 24 Mar 88 12:50:07 -0500 From: David Saunders Message-ID: <8803241250.aa01681@Dewey.UDEL.EDU> I'm responding rather late to your inquiry on Scheme use. We use scheme and SICP in our first course here at Delaware. We follow it with a course which uses Modula2. Together, they seem to provide a good basis for the rest of the program. We don't push extremely hard. From, Ableson and Sussman we cover the first 3 chapters, and introduce the interpreter of chapter 4 in the last week. Some of the students' mathematics backgrounds are weak, but that has not been a major obsticle. Many take the course concurrently with Calculus and that works fine. The use of "big O" and logs gives trouble too, but that is essential CS and we regard it as our job to build a modicum of skill with those things. Actually, I think that scheme/lisp is much gentler in its mathematical demands on novices than pascal. It allows them to get to the essence of programming without having to fight past artificial distinctions about types of numbers. The students program in C-scheme on a vax. -david saunders  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 24 Mar 88 10:54:03 EST Date: Thu, 24 Mar 88 10:54:36 EST From: Jonathan A Rees Subject: [camp: [OMAHONY: Clyde Camp's Utilities]] To: scheme@MC.LCS.MIT.EDU Message-ID: <346781.880324.JAR@AI.AI.MIT.EDU> Date: Wed, 23 Mar 88 13:26:18 CST From: Clyde Camp Re: [OMAHONY: Clyde Camp's Utilities] Organization: TI Computer Science Center, Dallas The PCS utilities I began distributing some time back have been upgraded to take advantage of some of the features of PC Scheme 3.0. For those of you interested in PCS, a set of these utilities and documentation is available (free) from: Clyde R. Camp Texas Instruments, Inc. P.O.Box 655474, MS 238 Dallas, TX 75266 *=======================================================================* Send two blank, FORMATTED disks and a SELF-ADDRESSED, STAMPED envelope. *=======================================================================* Although written primarily for the TIPC, everything except the graphics should work on IBMs and IBM clones. The directories are: UTILITY - Various text windowing, file printing and keyboard handlers which simplify writing application programs (includes a file pretty-printer and a new top-level read-eval-print loop which uses an emacs-like line-editor with the capability to scroll through and edit previous entries) SWI - A convenient mechanism for invoking 8086 ASSY routines via SWI-INT. HELP - A user-extendable on-line help facility which includes all of the PCS functions and syntax as well as other information on PCS specific quirks. GRAF - A graphics package for creating graphics "windows" somewhat analogous to text windows PLOT - A general purpose function plotter GAME1 - Self explanatory - non-graphics for IBM or TIPC GAME2 - for TIPC graphics ERR_STAT - more utilities for controlling the status window, testing for directories and disabling the gc-message MENUSHEL - two general purpose menu driven command shells handy for application development.  Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 23 MAR 88 18:07:02 EST Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ; Wed, 23 Mar 88 18:03:43 EST From: pierce@golfer.Dayton.NCR.COM Received: by XN.LL.MIT.EDU; Wed, 23 Mar 88 15:00:06 EST Posted-Date: Wed, 23 Mar 88 13:29:00 EST Received: by SCUBED.ARPA (1.2/5.20b) id AA16664; Wed, 23 Mar 88 11:41:57 pst Message-Id: <8803231941.AA16664@SCUBED.ARPA> To: scheme@mc.lcs.mit.edu Date: Wed, 23 Mar 88 13:29:00 EST Subject: How can you do things like ?X -> (*var* x) without Read Macros ? Cc: gene.pierce%dayton.ncr.com@relay.cs.net X-Mailer: Elm [version 1.5] Sometimes it is very useful to hide some underlying implementation details when writing systems such as inference engines. Since Scheme doesn't have ability to handle read macros then is it possible to do something like the following in a differnet way ? where "x" is a variable and "?" is a read macro and the "?" read macro reads the next character, which is "x" and transforms "?X" into the following list structure (*var* x) . This representation is useful to the underlying code and the "?x" is useful to a user to designate unifiable variables in a backward or forward chaining rule. Any and all responses are appreciated. thanks in advance, Gene Pierce --  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 22 Mar 88 15:33:24 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA21491; Tue, 22 Mar 88 04:37:21 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Mar 88 23:31:20 GMT From: hpcea!hpccc!ga@hplabs.hp.com (G.A. Gordon) Organization: HP Corporate Computing Center Subject: Re: xscheme Message-Id: <160001@hpccc.HP.COM> References: <1538@ncsuvx.ncsu.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu / hpccc:comp.lang.scheme / gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman) / 8:20 pm Mar 2, 1988 / You said: I'm just an undergraduate, my opinion doesn't matter. Why do you feel that way? You have an unhealthy self-image problem. Your opinion does matter, at least it does to me. ----------  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 22 Mar 88 09:46:14 EST Date: Tue, 22 Mar 88 09:46:47 EST From: Jonathan A Rees Subject: [OMAHONY: Clyde Camp's Utilities] To: scheme@MC.LCS.MIT.EDU Message-ID: <345723.880322.JAR@AI.AI.MIT.EDU> ... Received: from IRLEARN.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 7540; Mon, 21 Mar 88 08:01:25 EST ... Date: 21-MAR-1988 12:54:07 GMT From: To: scheme-request at mc.lcs.mit.edu Re: Clyde Camp's Utilities A little while back, someone sent in a request for the latest version of Clyde Camps Utilities for TI-Scheme. I have not heard of these before - what are they? Donal O'Mahony omahony@cs.tcd.ie or (older mailers) omahony@tcdcs.uucp Computer Science Dept., Trinity College, Dublin, Ireland  Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 MAR 88 18:01:03 EST Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ; Mon, 21 Mar 88 17:57:09 EST From: pierce@golfer.Dayton.NCR.COM Received: by XN.LL.MIT.EDU; Mon, 21 Mar 88 17:58:07 EST Posted-Date: Mon, 21 Mar 88 16:41:05 EST Received: by SCUBED.ARPA (1.2/5.20b) id AA08436; Mon, 21 Mar 88 14:25:56 pst Message-Id: <8803212225.AA08436@SCUBED.ARPA> To: scheme@mc.lcs.mit.edu Date: Mon, 21 Mar 88 16:41:05 EST Subject: Read Macros's in Scheme ? Cc: gene.pierce%dayton.ncr.com@relay.cs.net X-Mailer: Elm [version 1.5] I would like to know if read macros are possible in Scheme. (e.g. Symbolics uses the "setsyntax" function) Any and all reponses are appreciated. Thanks, gene pierce gene.pierce%dayton.ncr.com@relay.cs.net --  Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 20 Mar 88 11:39:52 EST Received: by ZOHAR.AI.MIT.EDU; Sun, 20 Mar 88 11:42:23 est Date: Sun, 20 Mar 88 11:42:23 est From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman) Message-Id: <8803201642.AA07040@zohar> To: dxs1521@acf3.nyu.edu Cc: scheme@mc.lcs.mit.edu In-Reply-To: (David Suyavid Suna's message of 18 Mar 88 19:12:12 GMT <607@acf3.NYU.EDU> Subject: Scheme for the PC PC Scheme is available from Texas Instruments for $95. Call 1-800-TI-PARTS.  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 19 Mar 88 13:59:36 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA16680; Sat, 19 Mar 88 07:15:17 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Mar 88 19:12:12 GMT From: dxs1521@acf3.nyu.edu (David Suyavid Suna) Organization: New York University Subject: Scheme for the PC Message-Id: <607@acf3.NYU.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I have seen discussions here of scheme for the pc. How can I get it? ftp would be fine or someplace to e-mail to for it. Thanks in advance, David Suna dxs1521@acf3.nyu.edu  Received: from att.arpa (TCP 1201200131) by MC.LCS.MIT.EDU 18 Mar 88 12:28:10 EST From: dbm@research.att.com Date: Fri, 18 Mar 88 11:23:56 EST To: scheme@mc.lcs.mit.edu Subject: ML compiler -- Standard ML of NJ Glad you asked! I am distributing copies of Standard ML of New Jersey, an incremental compiler that is currently available for Sun and Vax/Unix. Licenses are available only to academic institutions at the moment, and there is no charge. Eventually licenses should be available to anyone, and then there may be a small license fee. The version we are currently distributing is a "beta" version (Version 0.18). Version 1.0 should be out by this summer. Standard ML of New Jersey is being written by Andrew Appel of Princeton, Trevor Jim, a former student of Andrew's who is now at Bell Labs, and myself. To obtain a license contract, send me mail, including your name, phone number, mail address, and email address. It would also be useful if you would indicate whether you have arpanet ftp access. Dave MacQueen macqueen%research.att.com@relay.cs.net ...!research!macqueen Room 2C-322 AT&T Bell Laboratories Murray Hill, NJ 07974 (201) 582-7691  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 18 Mar 88 10:14:53 EST Date: Fri 18 Mar 88 10:14:24-EST From: Rishiyur S. Nikhil Subject: ML To: scheme@MC.LCS.MIT.EDU Message-ID: <12383324733.11.NIKHIL@XX.LCS.MIT.EDU> Dave Macqueen at ATT Bell Labs, Murray Hill, is distributing his implementation of Standard ML. It is not public domain (there is a token license fee), but it is meant as a research tool, not a commercial product. Try contacting him at: dbm.btl@relay.cs.net or: dbm%research.att.com@relay.cs.net Nikhil (nikhil@xx.lcs.mit.edu) -------  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 18 Mar 88 02:33:19 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA08902; Thu, 17 Mar 88 21:52:45 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Mar 88 05:42:55 GMT From: iris!windley@ucdavis.ucdavis.edu (Phil Windley) Organization: U.C. Davis - Robotics Research Laboratory Subject: ML Message-Id: <1478@ucdavis.ucdavis.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu It seems that I remember a discussion in this newsgroup about ML several months ago. At the time, I wasn't interested enough to save the stuff, but now I need to know... Is there a public domain ML interpreter available somewhere? Phil Windley Robotics Research Lab University of California, Davis  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 14 Mar 88 07:50:48 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA22196; Mon, 14 Mar 88 01:21:15 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Mar 88 06:32:38 GMT From: ncc!alberta!calgary!jameson@uunet.uu.net (Kevin Jameson) Organization: U. of Calgary, Calgary, Ab. Subject: Re: Scheme and C Message-Id: <1456@vaxb.calgary.UUCP> References: <10235@shemp.CS.UCLA.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu My version of TI Scheme came with lots of documentation for calling between Scheme, along with actual examples for ASM, Pascal, and C files.  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 12 Mar 88 17:41:53 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA15685; Sat, 12 Mar 88 14:34:05 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Mar 88 19:37:34 GMT From: tobias@locus.ucla.edu Organization: UCLA Computer Science Department Subject: Scheme and C Message-Id: <10235@shemp.CS.UCLA.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I am interested in a version of Scheme that will run on an IBM PC/AT and will allow itself either to be called by a C program or to call a C program. I have a copy of TI Scheme, but nowhere in the documentation does it refer to this issue. Plese send any information by e-mail, or if you can't reach me, feel free to post your answer. I will summarize any findings. Jay Tobias tobias@cs.ucla.edu  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 12 Mar 88 12:38:55 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA10602; Sat, 12 Mar 88 09:31:03 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Mar 88 10:07:57 GMT From: mcvax!diku!daimi!cp@uunet.uu.net (Claus Pedersen) Organization: DAIMI: Computer Science Department, Aarhus University, Denmark Subject: Scheme on IBM PC Message-Id: <1357@daimi.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu We are interested in Scheme for IBM PC's. Please mail references to. Claus H. Pedersen / cp@daimi.dk (..uunet!mcvax!diku!daimi!cp) Computer Science Department, Aarhus University Ny Munkegade 116, DK-8000 Aarhus C, DENMARK phone: +45 6 12 71 88 / telefax: +45 6 13 99 19 / telex: 64767 aausci dk  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 11 Mar 88 18:37:25 EST Received: from relay2.cs.net by RELAY.CS.NET id aa15932; 11 Mar 88 17:28 EST Received: from ubc by RELAY.CS.NET id aa07824; 11 Mar 88 17:18 EST Received: by ean.ubc.ca id AA01722; Fri, 11 Mar 88 13:54:23 pst Date: 11 Mar 88 13:54 -0800 From: Vincent Manis To: scheme@mc.lcs.mit.edu MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET Message-Id: <585*manis@instr.camosun.bcc.cdn> Subject: Paging Simon Kaplan [Sorry about this folks, but...] Simon, I've tried twice to send you mail at the above address, but both times it was rejected. Could you please send me a message with a workable return address? -- v  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Mar 88 12:58:35 EST Date: Fri, 11 Mar 88 12:58:28 EST From: Jonathan A Rees Subject: [cmb%DERRZE0.BITNET: Clyde Camp's PC Scheme utilities?] To: scheme@MC.LCS.MIT.EDU Reply-to: cmb%DERRZE0.BITNET at CUNYVM.CUNY.EDU (Clemens Beckstein, IMMD VI - Uni Erlangen) Message-ID: <339873.880311.JAR@AI.AI.MIT.EDU> Date: Thu, 10 Mar 88 12:24:06 MET From: cmb%DERRZE0.BITNET at CUNYVM.CUNY.EDU (Clemens Beckstein, IMMD VI - Uni Erlangen) To: scheme-request at mc.lcs.mit.edu Re: Clyde Camp's PC Scheme utilities? Who can show me a way to the latest version of Clyde Camp's utilities for PC Scheme (TI Scheme)? The version I have (from a colleague who is unreachable for quite some time) has compatibility problems with the new PC Scheme V3.0 (e.g. the utility package NEWSTL.FSL because of the changed READ-LINE function of Version 3.0 and UTILITY.FSL because of changes to the set of MACRO handling PC Scheme functions). I'd prefer a way via email from my BITNET account but a floppy transfer is OK too... - Clemens Beckstein c/o Dept. of Comp. Science #6 University of Erlangen Martenstr. 3 D-8520 Erlangen, W.Germany email: cmb@derrze0.bitnet (derrze zero .bitnet)  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 10 Mar 88 08:46:55 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA13279; Thu, 10 Mar 88 04:37:54 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Mar 88 22:39:36 GMT From: ola@cs.duke.edu (Owen L. Astrachan) Organization: Duke University CS Dept.; Durham, NC Subject: search for IBM-PC (compatible) scheme Message-Id: <11230@duke.cs.duke.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I would appreciate pointers to any version of scheme that will run on an IBM pc or compatible. I have heard of pc-scheme (from TI?) but don't know anything about it. Does it work well, how much does it cost, from where is it obtainable, etc. Any pointers to public domain (hah hah) schemes that run on such machines would be appreciated as well. Please respond via e-mail, I'll summarize if requested. Thanks. Owen L. Astrachan CSNET: ola@duke Dept.of Computer Science ARPA: ola@cs.duke.edu Duke University UUCP: {ihnp4!decvax}!duke!ola Durham NC 27706 Phone (919)684-5110 Ext. 229  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 7 Mar 88 18:03:24 EST Received: from relay2.cs.net by RELAY.CS.NET id ab08835; 7 Mar 88 15:04 EST Received: from ubc by RELAY.CS.NET id ag02903; 7 Mar 88 14:51 EST Received: by ean.ubc.ca id AA22993; Mon, 7 Mar 88 11:38:16 pst Date: 7 Mar 88 11:35 -0800 From: Vincent Manis To: scheme@mc.lcs.mit.edu MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET Message-Id: <568*manis@instr.camosun.bcc.cdn> Subject: Scheme as an introductory programming language About two weeks ago, I posted a request for information on the use of Scheme in first-year computer science courses. I've had a sense for a while that the Pascal paradigm isn't really suitable for introductory students (BC post-secondary institutions generally report combined failure/attrition rates of 30-40% in these courses, higher than for most other non-honours courses), and that Scheme might provide a better approach. One obvious criticism of this approach is that not all students are as smart as MIT students. (I quite often have to deal with students who have completed Grade 12 Algebra/Trigonometry/Calculus yet are functioning on about a Grade 9 or 10 level. Such students find evaluating a Pascal expression such as 3 + 4 DIV 5 * 2 a challenge.) If in fact such poorer students found Scheme completely mystifying, then it could immediately be ruled out. (One might have extensive arguments about whether such students should be in a post-secondary institution at all, but probably not in this mailing list. A propos marginal students, one of my colleagues said to me, "I only teach to that fraction of the students which doesn't suffer from 100% rigor mortis.") I did *not* receive any responses of the form "We tried it, and it was an unmitigated disaster". A few respondents had a few qualms, but nothing which argued that the use of Scheme was *worse* than the status quo. Obviously, one should take the responses below with a grain of salt: if anyone had found Scheme completely unsuitable, such a person wouldn't be terribly likely to continue reading here. I've edited the responses, mostly in the interests of brevity. On a few occasions, I've combined two or more separate messages from the same person. One note: the books referred to in the following are: Abelson, Harold, and Gerald Sussman, with Julie Sussman. "Structure and Interpretation of Computer Programs". MIT Press, 1985. ISBN 0-262-01077-1 (MIT Press) or 0-07-000-422-6 (McGraw-Hill). Dybvig, R. Kent. "The Scheme Programming Language", Prentice-Hall, 1987. ISBN 0-13-791864-X. Friedman, Daniel P., and Matthias Felleisen. "The Little LISPer (2nd ed.)". Science Research Associates, 1986. [This is also available in a Trade Edition from some other publisher, but I don't know the difference between the two editions.] If I get any followup responses, I'll post a summary. Vincent Manis manis@instr.camosun.bcc.cdn The Invisible City of Kitezh ihnp4 | Camosun College seismo |!ubc-vision!instr.camosun.bcc.cdn!manis 3100 Foul Bay Road uw-beaver| Victoria, BC V8P 4X8 manis%instr.camosun.bcc.cdn@ubc.csnet (604) 592-1281 x480 manis%instr.camosun.bcc.cdn%ubc.csnet@relay.cs.net ------------------------------------------------------------ From: Franklyn Turbak ------------------------------------------------------------ In addition to using the Sussman and Abelson book in the core computer course at MIT, several instructors have prepared a number of useful class notes. (These notes introduce new models and examples, extend and clarify some of the main themes of the book, and introduce some new material.) I have prepared several such handouts and hope to combine them with other instructor's materials to form a student workbook in the not-too-distant future (i.e. this summer). Other notes of interest (which you may or may not know): * There is a (very useful) Instructor's Manual available for the Sussman and Abelson book. [This book is published by McGraw-Hill, not MIT Press. -- vm] * You can obtain from MIT a data base of all the problem sets ever used for the course (eight year's worth!). * Mike Eisenberg (duck%oz.ai.mit.edu@xx.lcs.mit.edu) is in the final stages of preparing a new book on programming in Scheme. (It's a gentler introduction to Scheme than Sussman and Abelson, intended primarily for a high school audience.) * The Center for Advanced Engineering Study (CAES) at MIT offers the whole 6.001 course on videotape (with Gerry Sussman and Hal Abelson as lecturers). These tapes are excellent for seeing how well the course can be taught; however, I hear they're expensive. Call CAES Information at (617) 253-7400 to find out more information. (In addition to the tapes, I believe that other course materials are also available from CAES.) ------------------------------------------------------------ From: Martin Ward ------------------------------------------------------------ I was involved (in 1986) in teaching a computing option to 2nd year mathematicians at Oxford University (they choose 8 options from ^25 for the second year). T was the language used because of the simple semantics, the ability to get started quickly (using the interpreter) and the ability to write recursive functions, data directed programs etc. and not worry about details of syntax, arithmetic overflow etc. Since 1987 there has been a joint honours course in maths and computing, I rhink using T. For more up to date information try: Bernard Sufren, Programming Research Group Oxford University 8-11 Keble Rd Oxford ------------------------------------------------------------ From: Simon Kaplan ------------------------------------------------------------ I'm currently well into the first iteration of teaching scheme as an intro language here for the first time. The course is an ``experiment'', open only to selected students. The class size is around 35 students; we get around 300 students taking our intro course for majors each semester. The experience of the students ranges from >10 years programming to nothing. The students really seem to enjoy the course, I'm loving teaching it, and the sort of work you can cover is just amazing. In regular Pascal courses, you spend far too much time on the language and not enough on principles; examples tend to illustrate language constructs, not concepts. With Scheme, all that vanishes, and we focus on the concepts. Within 2 weeks, students are writing fairly complex recursive routines, and after a month are working with upward and downward funargs, and learned a lot about control abstractions. Next I plan to cover data abstractions, and then modules, object-oriented programming, and so forth. More or less I cover the first 2.5 chapters of A,S&S, and a significant part of a data structures text such as Reingold and Hansen (data structures in pascal (except i dont use pascal)). Also a fair amount on orders of evaluation and correctness. Why scheme? because there are a small number of orthognal constructs out of which almost all the programming structures the students need can be built. This allows a focus on what I think is the single most important message to give to the students, viz. the concept of building layuers of abstraction. In an article in this month's byte, A&S call this ``adding to the language'' or some such and they have a good point I am using A,S&S as the text, primarily because there is nothing else available right now (dybvig is a reference manual and doesnt count). It is not a good book for an intro course. It covers too much, gets too cute, and focuses too much on numeric examples. I think that the examples in chapter 2 are a good example of this: while they are good examples, the average student is likely to just be bored to death by them, not seeing the relevence of all this number crunching. And thereby miss the entire point of the chapter. Another problem is their use of the (define (name args) ...) form in their examples, which makes iontroducing lambda awkward. I use the form (define name (lambda (args) ...)) I built my own notes for the course. I follow A,S&S closely in the beginning (was more nervous then) and then branch off. The skeleton of the course resembles A,S&S but the details are mostly mine own. Specifically i do a lot more on non-numeric data abstraction, and object-oriented programming. And then there's a lot of stuff on data structures and algorithms that they dont get into. I believe that George Springer at Indiana is workking on a book, which should be finished soon. I'm looking forward to seeing what he has done. To conclude: I firmly believe that a better job of introducing students to programming can be done in scheme. Just read A,S&S to see that this is so!! On the software side, we use MacScheme. I highly recommend this. It's good, reliable, easy to use. The students would find operating system + editor + language as we usually do with unix/pascal a bit of a mouthful; using the macs obviates this. Some students use PC-scheme (this is just ti-scheme) and like it, but of course have to learn the edwin editor, almost emacs, and dos, almost unix. So the mac is the route of least resistance for the students. DONT use mit scheme or T if you can avoid it, mostly because their debuggers are just terrible. Mit scheme gives errors in hex. T assumes you can program continuation-style to read the debugger. while this might be true, the freshmen will get blown away... MacScheme has a lovely debugger, and a good compiler also. Some personal background: I am not an AI type; I work in programming environments. And did all my work in C/pascal till last summer. I was put on a committee to revise the 1st year courses and read abelson & sussman as part of that, and came away a convert. Would I use scheme in the future? you bet! I hope the rest of the department agrees and adopts the experimental course. ------------------------------------------------------------ From: Richard Pattis ------------------------------------------------------------ Places that I know that use Scheme are Brandies, UC Berkeley, Univ of Oregon (at Eugene). Contact Harry Mairson at Brandeis, Mike Clancy at Berkeley, and I don't know who at Oregon. I think off and on about teaching Scheme (we teach Modula-2 here) and would be interested in getting the list that you make up of other people already teaching it. Rich Pattis ------------------------------------------------------------ From: Joel Spolsky ------------------------------------------------------------ The U. of Pennsylvania Computer Science and Engineering curiculum teaches Abelson and Sussman Scheme (using TI Scheme on IBM-AT's and CScheme on a VAX) as the *second* part of the introductory programming course; the first semester is designated "Pascal and Data Structures". They also teach some ML in this second course. Of course, MIT uses A&S as their *first* course. ------------------------------------------------------------ From: Stephen Robbins ------------------------------------------------------------ I learned SCHEME at MIT in 6.001, "The Structure and Interpretation of Computer Programs." A year later, the course notes came out in now-famous book form. 6.001 is one of the most popular courses at MIT, and seems to give people an excellent (though sometimes grueling) introduction to CS. Now, I work at Symbolics as an instructor. Two weeks ago, I taught my first Common Lisp One course. The SICP approach is one I'm very fond of: use SCHEME as a vehicle for teaching people to \think/. That you're learning SCHEME, in particular, is secondary. At Symbolics, we teach students a mental model for understanding the Lisp World before they ever sit down at a terminal. That seems to work far better than the approach that most Lisp texts (e.g. LISP by Winston & Horn) take. Overall: teach students how to THINK. And SCHEME is flexible enough that it doesn't get in your way a whole lot when you try to translate thought into program. [Stephen goes on to compare Scheme with C and Pascal as an introductory language. I've omitted that in the interests of space, but would be happy to forward the details to those interested. He argues that it's possible to teach the basics of the language in about a day. -- vm] ------------------------------------------------------------ From: Erik Talvola ------------------------------------------------------------ At UC Berkeley, the introductory CS class for EE and CS majors is CS60A - namely, Scheme. We use Abelson & Sussman for the textbook, and MIT Scheme running on Sun 3/50's for the language. I found it to be an interesting approach, since, as the teacher pointed out, everyone is pretty much equal going into the class since nobody learns Scheme/Lisp in high school. In A&S, we covered up to the Meta-Circular Evaluator and some of the logic programming stuff. This year, they are doing the entire logic programming section and are doing a little on the register-machine simulator. Who knows? Maybe next year they will cover the whole book in CS60A. To summarize, I enjoyed the class because I was expecting a boring Pascal class (that is what the course catalog says about 60A!) - instead, I got a chance to use a language I had virtually no experience with (I used Lisp a little on an Apple II - but that was it). The CS60A class at Berkeley is intended for incoming freshman in their first semester. Math 1A (Calculus) is listed as a prerequisite, but no math is really necessary in the course - maybe a little knowledge of what integration and differentiation are, but that's it. ------------------------------------------------------------ From: Dan Grim ------------------------------------------------------------ The Electrical Engineering Department at the University of Delaware uses Abelson & Sussman (with Sussman) to teach our first-term freshman course in programming concepts and algorithms. We did this for the first time last fall and have not had sufficient experience to decide whether it has been more successful than the Pascal programming course that we taught previously. However, from the instructors point of view (mine), I found it much easier to concentrate on the ideas of programs and algorithms rather than the details of programming. We used CScheme on a Pyramid 98-XE for the associated lab! I think that the student reaction was somewhat negative which was not unexpected. However, the good students, who would have been bored silly by Pascal were challenged by Scheme, while the poorer students had to work harder. We made an explicit decision to try to challenge the good students rather than cater to the poorer ones. Much of what is in Abelson & Sussman is quite subtle and I was surprised how many students got it! ------------------------------------------------------------ End of summary ------------------------------------------------------------  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 6 Mar 88 08:49:42 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA25639; Sat, 5 Mar 88 23:52:30 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Feb 88 01:58:00 GMT From: render@b.cs.uiuc.edu Subject: Re: SCOOPS Message-Id: <189900005@uiucdcsb> References: <1330@daimi.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Steve Sherin at the Univ. of Penn. has an implementation of SCOOPS. His e-mail address is sherin@linc.cis.upenn.edu. The code is also available via anonymous ftp.  Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 3 Mar 88 02:48:13 EST Received: by ZOHAR.AI.MIT.EDU; Wed, 2 Mar 88 23:20:57 est Date: Wed, 2 Mar 88 23:20:57 est From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman) Message-Id: <8803030420.AA03247@zohar> To: csclea!medlin@ncsuvx.ncsu.edu Cc: scheme@mc.lcs.mit.edu In-Reply-To: (Todd Medlin's message of 27 Feb 88 23:10:46 GMT <1538@ncsuvx.ncsu.edu> Subject: xscheme You said: I'm just an undergraduate, my opinion doesn't matter. Why do you feel that way? You have an unhealthy self-image problem. Your opinion does matter, at least it does to me.  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 1 Mar 88 02:22:35 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA09677; Mon, 29 Feb 88 17:46:59 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Feb 88 18:54:39 GMT From: hao!umigw!angel@AMES.ARC.NASA.GOV (angel li) Organization: University of Miami Subject: does c scheme support X windows? Message-Id: <131@umigw.MIAMI.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I was wondering if C-scheme has support for X Windows, version 11. -- Angel Li University of Miami/RSMAS Internet: angel@miami.miami.edu UUCP: hao!umigw!angel  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 29 Feb 88 23:09:16 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA10082; Mon, 29 Feb 88 18:11:34 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Feb 88 20:23:29 GMT From: rlcarr@athena.mit.edu (Richard L. Carreiro) Organization: Massachusetts Institute of Technology Subject: CScheme5.0 Availability (Was: Scheme for Amiga) Message-Id: <3343@bloom-beacon.MIT.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I have been told that CScheme5.0 is PD and will compile *as is* on the Amiga. The same person said it was available via anonymous FTP on several sites, but neglected to mention any. Can someone post or email where these sites are? Thank you. ARPAnet: rlcarr@athena.mit.edu UUCP : rlcarr%athena@eddie(.mit.edu) BITNET : rlcarr%athena@mitvma(.mit.edu) ******************************************************************************* * Richard L. Carreiro "Havlicek stole the ball!!!!" * * rlcarr@athena.mit.edu -- Johnny Most 4/15/65 * *******************************************************************************  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 29 Feb 88 01:09:27 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA26358; Sun, 28 Feb 88 21:33:28 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Feb 88 03:44:07 GMT From: oxtrap!sendai!rich@umix.cc.umich.edu (K. Richard Magill) Organization: Digital Works Ltd, Ann Arbor Subject: looking for Cscheme on 3b1 Message-Id: <172@sendai.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Could someone who is running C-scheme on 3b1/unix-pc please get in touch with me? What version are you running? Can/will you share your configuration?  Received: from HT.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 FEB 88 15:06:58 EST Received: by ht.ai.mit.edu; 28 Feb 88 15:01:07 est Date: 28 Feb 88 15:01:07 est From: Mark Shirley To: scheme@mc Subject: Info needed on Scheme research Quoting "From: otter!ange@hplabs.hp.com (Andy Norman)" From: Will Clinger ====================================================================== There's someone at Carnegie Mellon who's applying flow analysis to the type inference problem for Scheme. Will, do you mean Olin Shivers at CMU? Or is there someone else working on flow analysis? In a vein similar to Andy's question, What is the state-of-the-art in optimizing compilers for Lisp / Scheme? If people would send references to papers, e.g. something on Orbit, I'll collect and summarize the responses. (Apologies to everybody if this question has been asked recently. I'm new to this list and looking through the archives available to me didn't turn up anything.) - Mark Shirley  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 27 Feb 88 20:03:15 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA01061; Sat, 27 Feb 88 15:54:40 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Feb 88 23:10:46 GMT From: csclea!medlin@ncsuvx.ncsu.edu (Todd Medlin) Organization: Computer Science , NCSU, Raleigh NC Subject: xscheme Message-Id: <1538@ncsuvx.ncsu.edu> References: <1079@csuna.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Can someone out there post some information on xscheme ? Thanks in advance. ---todd medlin (medlin@csclea.ncsu.edu) I'm just an undergraduate, my opinion doesn't matter.  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 27 Feb 88 10:07:06 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA23221; Sat, 27 Feb 88 06:39:04 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Feb 88 14:23:12 GMT From: mcvax!diku!daimi!zapp@uunet.uu.net (Michael Hoffmann Olsen) Organization: DAIMI: Computer Science Department, Aarhus University, Denmark Subject: SCOOPS Message-Id: <1330@daimi.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I've heard about an object oriented extension of Scheme called SCOOPS. Does anybody know where I can find something about it? Michael Olsen, Computer Science Department, Aarhus University, Ny Munkegade - DK 8000 Aarhus C - DENMARK E-Mail: zapp@daimi.dk  Received: from uunet.UU.NET (TCP 30003106601) by MC.LCS.MIT.EDU 27 Feb 88 00:53:34 EST Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA19643; Sat, 27 Feb 88 00:52:37 EST Received: by mcvax.cwi.nl; Fri, 26 Feb 88 22:05:56 +0100 (MET) Received: by inria.inria.fr; Fri, 26 Feb 88 20:40:37 +0100 (MET) Received: from crcge3.cge.fr (crcge3.ARPA) by crcge1.cge.fr, Fri, 26 Feb 88 19:39:05 -0100 Date: Fri, 26 Feb 88 19:38:51 -0100 Received: by crcge3.cge.fr, Fri, 26 Feb 88 19:38:51 -0100 From: mcvax!crcge3.cge.fr!adams@uunet.UU.NET (Drew Adams) Message-Id: <8802261838.AA09716@crcge3.cge.fr> To: HAILPERIN@sushi.stanford.edu, scheme@mc.lcs.mit.edu Subject: SICP query lang. compiler I would be interested in your compiler code. Thank you.  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 26 Feb 88 12:34:27 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA26726; Fri, 26 Feb 88 07:57:40 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Feb 88 21:14:00 GMT From: duba@iuvax.cs.indiana.edu Organization: Indiana University CSCI, Bloomington Subject: Re: ! Message-Id: <56700001@iuvax> References: <880208@<323426> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu ;; This is how we would write the "set!-free" make-cell in Scheme ;; extended with the F-operator and prompts (see Felleisen POPL88). (define (make-cell) (# (rec state (F (lambda (set-state) (lambda (op) (case op [(get) state] [(set) set-state]))))))) ;; Now with just F (define (make-cell) (F (lambda (return-cell) (rec state (F (lambda (set-state) (return-cell (lambda (op) (case op [(get) state] [(set) set-state]))))))))) ;; Of course what this code shows is that in a language with call/cc or F ;; either rec and letrec must be considered side-effects, or they must ;; be fixed so that it is not possible to find out that they are ;; implemented with side-effects. ;; Bruce Duba and Matthias Felleisen  Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 26 Feb 88 04:32:13 EST Received: by kleph.AI.MIT.EDU; Fri, 26 Feb 88 04:33:15 est Date: Fri, 26 Feb 88 04:33:15 est From: cph@kleph.AI.MIT.EDU (Chris Hanson) Message-Id: <8802260933.AA05803@kleph> To: vu-vlsi!lehi3b15!flash@psuvax1.cs.psu.edu Cc: scheme@mc.lcs.mit.edu In-Reply-To: (Stephen Corbesero's message of 17 Feb 88 18:22:08 GMT <308@lehi3b15.CSEE.Lehigh.EDU> Subject: Scheme for a 3B15/3B2 Reply-To: cph@mc.lcs.mit.edu Date: 17 Feb 88 18:22:08 GMT From: vu-vlsi!lehi3b15!flash@psuvax1.cs.psu.edu (Stephen Corbesero) I recently tried compiling the Scheme that comes with GnuEmacs on a 3B15, but ran into some run-time problems. If anyone has already ported scheme to a member of the 3Bx (x>1) family, could you please send me any pertinent info. please use E-mail as I am not a regular reader of this list. Without more information I can't help you. Unfortunately, the Scheme distributed with Emacs is an old version. I believe that the current version has been ported to those machines without much trouble.  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 26 Feb 88 02:17:23 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA16422; Thu, 25 Feb 88 22:54:27 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Feb 88 17:37:03 GMT From: otter!ange@hplabs.hp.com (Andy Norman) Organization: Hewlett-Packard Laboratories, Bristol, UK. Subject: Re: Info needed on scheme research Message-Id: <1510009@otter.hple.hp.com> References: <1510005@otter.HP.COM> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu ange@otter.HP.COM (Andy Norman) writes: >If anyone knows what work is being / has been done with _Scheme_ in the >following areas, could they please _MAIL_ me, and I will summarise to the >net. >Modules. >Formal definitions of both data types and language semantics. >Type checking. >Frames, OOPS, Active Values and Daemons. Here is a summary of the replies that I have received: -------------------------------------------------------------------------------- From: Will Clinger Mitch Wand has done a lot of work with denotational semantics expressed in Scheme. I've done a little -- I wrote the semantics of Scheme itself in Scheme in order to test it. I think Mitch is now working with formal semantics of data types, objects, and inheritance. ML would undoubtedly be a better language for this sort of thing than Scheme, but Scheme is more widely available and the implementations are often better. Mitch built an ML-style type checker for use with Scheme 311. It was buggy and crude but useful because Scheme 311 had no debugger. David Gifford and his students are currently working on FX, which is a statically typed language with type inference that can be thought of as a dialect of Scheme. TI built an object-oriented system called SCOOPS for their PC Scheme that was used in their Personal Consultant series of expert system shells. They made the source code available, and there is at least one independent implementation of SCOOPS for MacScheme. The T object system came earlier, though, and is a more elegant system. Norman Adams of Tektronix has recently been working on a system similar to the T object system. There's someone at Carnegie Mellon who's applying flow analysis to the type inference problem for Scheme. That's about it for my knowledge, but I'm sure lots of other stuff has been done. -------------------------------------------------------------------------------- From: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET Uwe Pleban's MESS system for building compilers from denotational specifications uses Scheme as well as Turbo Prolog (for the code generator) and an ML-like language (for the semantics; the ML-like language is implemented in Scheme). -------------------------------------------------------------------------------- Many thanks to Will for taking the time to reply. ange ------------------------------------------------------------------ ange%anorman@hplabs.HP.COM | Andy Norman (ange) | ange@hplb.csnet | Hewlett-Packard Labs, --+-- ange%hplb.csnet@csnet-relay.arpa | Bristol, U.K., | ...!mcvax!ukc!hplb!ange | England. BS12 6QZ |  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 26 Feb 88 02:13:00 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA16535; Thu, 25 Feb 88 23:00:30 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Feb 88 18:31:02 GMT From: sdcrdcf!csun!csuna!acphssrw@burdvax.prc.unisys.com (Stephen R. Walton) Organization: California State University, Northridge Subject: Scheme book request Message-Id: <1079@csuna.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I'm new to Scheme, having just acquired version 0.3 of David Betz's XSCHEME from BIX. (He is supposedly working on a compiler for it.) While I'm pretty well aware of the good books on Lisp, I do not know of any books for Scheme. Recommendations are wanted. As usual, please e-mail responses and I'll summarize to the net if warrented. In addition to the .signature file, {hplabs|ihnp4}!csun!csuna!acphssrw works. Stephen Walton, representing myself swalton@solar.stanford.edu Cal State, Northridge rckg01m@calstate.BITNET  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 25 Feb 88 20:07:09 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA08693; Thu, 25 Feb 88 16:51:10 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Feb 88 06:25:39 GMT From: pyramid!nsc!taux01!yuval@hplabs.hp.com (Gideon Yuval) Organization: National Semiconductor (Israel) Ltd. Subject: Re: Lisp Innards Wanted! Message-Id: <492@taux01.UUCP> References: <5274@utah-cs.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Berkeley&Bobrow's book "The Programming Language LISP" (MIT press, ISBN 0-262-59004-2) has the full PDP-1 LISP interpreter listings, plus some design documents (by Deutsch&Berkeley), on pp. 326-375. -- Gideon Yuval, +972-52-522255 (work), -2-690992 (home), yuval@taux02.nsc.com  Received: from Sushi.Stanford.EDU (TCP 4402000065) by MC.LCS.MIT.EDU 25 Feb 88 14:36:37 EST Date: Thu 25 Feb 88 11:31:10-PST From: Max Hailperin Subject: SICP query lang. compiler To: scheme@MC.LCS.MIT.EDU Message-ID: <12377604308.11.HAILPERIN@Sushi.Stanford.EDU> I want to assign some modest amount of logic programming in a class I'm teaching using Structure and Interpretation of Computer Programs, and was stymied by the molasses-like quality of the query-language interpreter. So I wrote a 99% compatable query-language compiler. It is ugly, and itself slower than it should really be, but it beats the pants off the interpreter. It runs undre CScheme version 5.3; I suspect it would take non-trivial but doable effort to port it to a different scheme. In case anyone else is in the same position, I'd be happy to send other instructors the code, on a completely and utterly as-is basis. -------  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 23 Feb 88 19:34:07 EST Received: from relay2.cs.net by RELAY.CS.NET id aa13913; 23 Feb 88 13:29 EST Received: from ubc by RELAY.CS.NET id ac05109; 23 Feb 88 13:18 EST Received: by ean.ubc.ca id AA26188; Tue, 23 Feb 88 10:04:52 pst Date: 23 Feb 88 10:03 -0800 From: Vincent Manis To: scheme@mc.lcs.mit.edu MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET Message-Id: <488*manis@instr.camosun.bcc.cdn> Subject: Scheme as an introductory programming language I'd like to get some information on the experiences of people who have used Scheme as the programming language for introductory, first-year, courses in Computer Science (at, e.g., the ACM CS-1/CS-2 level). I'm particularly interested in building a list of institutions which offer introductory programming courses using Scheme, but I'm also interested in textbooks and other resources they use, or any other information which might be available. Experience with in-class use of the various Scheme implementations which are generally available would also be helpful. If you looked at Scheme and then decided on Pascal or something instead, I'd be interested in your rationale, too. I'm well aware of Abelson and Sussman (with Sussman), as well as the Friedman and Dybvig books. I've also used PC Scheme extensively and MacScheme a little bit. I'm less interested in other Lisp dialects than Scheme (though T would certainly be of great interest). I will of course post a summary of the replies. AtDhVaAnNkCxE Vincent Manis manis@instr.camosun.bcc.cdn The Invisible City of Kitezh ihnp4 | Camosun College seismo |!ubc-vision!instr.camosun.bcc.cdn!manis 3100 Foul Bay Road uw-beaver| Victoria, BC V8P 4X8 manis%instr.camosun.bcc.cdn@ubc.csnet (604) 592-1281 x480 manis%instr.camosun.bcc.cdn%ubc.csnet@relay.cs.net  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 23 Feb 88 10:24:51 EST Received: from PEGASUS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 349236; Tue 23-Feb-88 10:20:19 EST Received: by scrc-pegasus id AA09170; Tue, 23 Feb 88 10:02:07 est Date: Tue, 23 Feb 88 10:02:07 est From: Bernard S. Greenberg To: shebs%cs.utah.edu@stony Subject: As I was saying (superseding letter) Cc: ed@stony, greenwald@stony, scheme%mc.lcs.mit.edu@stony, sgr@stony Date: 20 Feb 88 05:46:00 GMT From: shebs@cs.utah.edu (Stanley Shebs) Organization: PASS Research Group Subject: Lisp Innards Wanted! Message-Id: <5274@utah-cs.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu As part of my dissertation, I've been collecting info on the internal data representations of various Lisp systems. Lisp here is broadly defined as It has become profoundly difficult for me to edit and send computer mail. If you send me (BSG@SYMBOLICS.COM) a paper address, I will send you all the relevant representation data on Multics MacLisp, may its memory rest in peace.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 23 Feb 88 10:24:38 EST Received: from PEGASUS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 349234; Tue 23-Feb-88 10:19:54 EST Received: by scrc-pegasus id AA09162; Tue, 23 Feb 88 10:00:52 est Date: Tue, 23 Feb 88 10:00:52 est From: Bernard S. Greenberg To: shebs%cs.utah.edu@stony Subject: Lisp representation data. Cc: ed@stony, greenwald@stony, scheme%mc.lcs.mit.edu@stony, sgr@stony Date: 20 Feb 88 05:46:00 GMT From: shebs@cs.utah.edu (Stanley Shebs) Organization: PASS Research Group Subject: Lisp Innards Wanted! Message-Id: <5274@utah-cs.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu As part of my dissertation, I've been collecting info on the internal data representations of various Lisp systems. Lisp here is broadly defined as It has become profoundly difficult for me to edit and send computer mail. If you (BSG@SYMBOLICS.COM) send me a paper address, I will send you all the relevant representation data on Multics MacLisp, may its memory rest in peace.  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 22 Feb 88 20:53:44 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA05882; Mon, 22 Feb 88 17:30:20 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Feb 88 19:38:07 GMT From: rlcarr@athena.mit.edu (Richard L. Carreiro) Organization: Massachusetts Institute of Technology Subject: Scheme for Amiga Message-Id: <3088@bloom-beacon.MIT.EDU> References: <2608@gryphon.CTS.COM>, <1771@phoenix.Princeton.EDU>, <3086@bloom-beacon.MIT.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anyone have, or know where to get, Scheme for the Amiga computer? Please EMAIL or post to comp.sys.amiga. Thanks in advance, ****************************************************************************** * Richard L. Carreiro GO CELTS! * "He gets it out deep and * * rlcarr@athena.mit.edu * HAVLICEK STEALS IT!!" - J. Most * ******************************************************************************  Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 21 Feb 88 14:22:38 EST Received: from Cabernet.ms by ArpaGateway.ms ; 21 FEB 88 11:21:01 PST Date: 21 Feb 88 11:20 PST From: rabin.pa@Xerox.COM Subject: Re: Lisp Innards Wanted! In-reply-to: shebs@cs.utah.edu (Stanley Shebs)'s message of 20 Feb 88 05:46:00 GMT To: shebs@cs.utah.edu cc: scheme@mc.lcs.mit.edu Message-ID: <880221-112101-10931@Xerox> Some details on Lucid Lisp are given in papers in the 1986 Lisp and Functional Programming Conference proceedings. The bignum implementation has a paper of its own. I also recall an article on a RISC implementation in a recent (last year and a half) IEEE Computer or Software. Dan Rabin  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 20 Feb 88 03:50:19 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA09863; Sat, 20 Feb 88 00:18:18 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Feb 88 05:46:00 GMT From: shebs@cs.utah.edu (Stanley Shebs) Organization: PASS Research Group Subject: Lisp Innards Wanted! Message-Id: <5274@utah-cs.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu As part of my dissertation, I've been collecting info on the internal data representations of various Lisp systems. Lisp here is broadly defined as any language ultimately based on Lisp 1.5, and includes Scheme. What I'm looking for is the grungiest of machine-level details on the layout of cons cells, type discrimination schemes, memory organization, and storage recovery. Moon's description of the Symbolics architecture in the January 87 Computer is an excellent example, especially the pictures. Not every single detail is needed; just those that required conscious decisions by an implementor. (For instance, if arrays are tagged with a 0 to avoid masking, that is interesting, but if it was only because "array" is the first type name in the dictionary, that is not interesting.) Implementations embedded in other Lisps (Scheme 84, PCLS) are not of interest, but this does not exclude those written in other high-level languages (as can be seen from the list below). At present I have reasonably complete descriptions of the following systems, mostly derived from published material, manuals, or source code: 7090 Lisp 1.5 M-460 Lisp Q-32 Lisp Lisp 1.6 UCI Lisp MacLISP (PDP-10) Interlisp (VAX, PDP-10) LISP-11 Cambridge LISP (IBM) Zetalisp Franz Lisp PSL NIL Spice Lisp S-1 Lisp Franz Extended Common Lisp T MIT Scheme PC Scheme XLISP VT-LISP Kyoto Common Lisp On the other hand, I have only sketchy or no data on the following systems: PDP-1 Lisp PDP-6 Lisp MacLISP (Multics) muLisp TLC-Lisp Prime Lisp Lisp F3 Lisp/370 Lisp/VM Cambridge Lisp (ST) Interlisp-D Apollo Domain Lisp (the PSL deriv) Rutgers Lisp-20 Rutgers DEC-20 Common Lisp Golden Common Lisp HP Common Lisp VAXLisp Pyramid Common Lisp Lucid Lisp There are certainly others I've forgotten or simply don't know about - any info on these is quite welcome! Long-ago implementations are just as worth knowing about as more recent ones. Details received will go into my dissertation, and possibly into a separate tech report; any contributor who wants one will get a copy when this work is completed, perhaps in three months or so. The dissertation itself is about Lisp data structure design in general, and how it might be formalized. Of course, all contributions will be properly credited, not to mention greatly appreciated! stan shebs shebs@cs.utah.edu uunet!utah-cs!shebs  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 19 Feb 88 17:25:55 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA28077; Fri, 19 Feb 88 13:52:11 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Feb 88 19:04:39 GMT From: ah4h+@andrew.cmu.edu (Andrew Hudson) Organization: Carnegie Mellon University Subject: Re: Common Lisp functions for Scheme? Message-Id: References: <880218-110006-7381@Xerox> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu excerpted message follows: I'm porting a Common Lisp application to Scheme (to be run on a Mac). In so doing I've started to implement some Common Lisp semantics, notably its lambda argument types. Anyone done this already? (I can't affored Allegro CL). I understand that BBN as part of the Butterfly project implemented some form of CommonLISP in Scheme. Any takers on this, BBN? - Andrew Hudson  Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 18 Feb 88 14:50:08 EST Received: from Cabernet.ms by ArpaGateway.ms ; 18 FEB 88 11:00:06 PST Date: 18 Feb 88 10:59 PST From: Fischer.pa@Xerox.COM Subject: Common Lisp functions for Scheme? To: scheme@mc.lcs.mit.edu Reply-to: Fischer.pa@Xerox.COM Message-ID: <880218-110006-7381@Xerox> I'm porting a Common Lisp application to Scheme (to be run on a Mac). In so doing I've started to implement some Common Lisp semantics, notably its lambda argument types. Anyone done this already? (I can't affored Allegro CL). Also, is there any way to do the equivalent of macroexpand-1 in Scheme? (ron)  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 18 Feb 88 03:22:25 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA12742; Thu, 18 Feb 88 00:09:50 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Feb 88 18:22:08 GMT From: vu-vlsi!lehi3b15!flash@psuvax1.cs.psu.edu (Stephen Corbesero) Organization: CSEE Dept., Lehigh University Subject: Scheme for a 3B15/3B2 Message-Id: <308@lehi3b15.CSEE.Lehigh.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I recently tried compiling the Scheme that comes with GnuEmacs on a 3B15, but ran into some run-time problems. If anyone has already ported scheme to a member of the 3Bx (x>1) family, could you please send me any pertinent info. please use E-mail as I am not a regular reader of this list.  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 15 Feb 88 23:49:03 EST Received: from relay2.cs.net by RELAY.CS.NET id aa09662; 15 Feb 88 23:47 EST Received: from tektronix.tek.com by RELAY.CS.NET id af26831; 15 Feb 88 23:43 EST Received: by tektronix.TEK.COM (5.51/6.24) id AA08700; Mon, 15 Feb 88 16:37:05 PST Received: by tekchips.CRL.TEK.COM (5.51/6.24) id AA10267; Mon, 15 Feb 88 16:37:33 PST Message-Id: <8802160037.AA10267@tekchips.CRL.TEK.COM> To: scheme@mc.lcs.mit.edu Cc: scheme-librarian@mc.lcs.mit.edu, ayu%aquinas.csl.uiuc.edu@RELAY.CS.NET, edh%HNYKUN52.BITNET@cunyvm.cuny.edu, net%tub.bitnet@RELAY.CS.NET, dumas@SUMEX-AIM.STANFORD.EDU, mcvax!dutesta!brouw@uunet.uu.net, nttca!Shasta!ll-xn!lll-crg!lll-tis!dgis!jkrueger@SHASTA.STANFORD.EDU Subject: Gabriel benchmarks in Scheme Date: 15 Feb 88 16:37:29 PST (Mon) From: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET Someone asked for volunteers to collect/collate/report results for the Scheme versions of the Gabriel benchmarks. I volunteer, but it would be better if we had a volunteer who wasn't associated with a Scheme vendor. If you're thinking of volunteering, please re-read the comments in Gabriel's book so you'll know what you're getting into. I'm sending copies of the Gabriel benchmarks in Scheme to those of you listed in the "cc:" line. (If you don't receive a copy of this message, then maybe I need a better address.) They will be arriving in four parts, each about 20K bytes. Because the benchmarks are so large, I would in the future prefer to send a Macintosh- or IBM PC-compatible floppy disk to those of you who can use them. Please send requests for the source code to: Semantic Microsystems 4470 SW Hall Blvd Suite 340 Beaverton OR 97005 (503) 643-4539 I'd appreciate a donation of $5 or so to cover the cost of the disk and its shipping. I suspect that's much less than it costs the network to transmit these things. William Clinger  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 15 Feb 88 23:15:41 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA13502; Mon, 15 Feb 88 19:46:00 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Feb 88 03:33:21 GMT From: agate!eris!mwm@ucbvax.Berkeley.EDU (Mike (My watch has windows) Meyer) Organization: Missionaria Phonibalonica Subject: Re: Scheme for the Amiga, size constraints Message-Id: <6996@agate.BERKELEY.EDU> References: <518@acf3.NYU.EDU>, <2194@bloom-beacon.MIT.EDU>, Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article ah4h+@andrew.cmu.edu (Andrew Hudson) writes: < <>I have implemented scheme 6.1 on my Amiga. I'll tell you, it's not an <>easy thing to do. First of all,there is no way CScheme will work on a <>machine with only 0.5M of RAM. < References: <13258@cornell.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Yale T v3.0 may be able to compile itself, but the method used is an _undocumented_ feature of the system, seemingly not intended for the unwashed masses. There seem to be various compile and load scripts floating around in the source directories, but I couldn't intuit the grand scheme intended. Vincent Broman, code 632, Naval Ocean Systems Center, San Diego, CA 92152, USA Phone: +1 619 553 1641 Internet: broman@nosc.mil Uucp: sdcsvax!nosc!broman  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 11 Feb 88 18:54:35 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA06487; Thu, 11 Feb 88 15:23:19 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Feb 88 19:09:35 GMT From: rochester!neal@rutgers.edu (Neal Gafter) Organization: U of Rochester, CS Dept., Rochester, NY Subject: is make-environment really necessary for packages? Message-Id: <6722@sol.ARPA> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I do not understand the need for an explicit environment type in scheme. It seems that lambda could serve the same purpose. Suppose there were not an explicit environment type. In this case, the procedure "eval" would take only a single parameter: the expression to be evaluated (in the current environment). Packages, which are currently created this way: (define foo (make-environment (define x ...) (define y ...) ... )) and used this way: (eval '(expression) foo) Could still be created this way: (define foo (let () (define x ...) (define y ...) ... (lambda (_x) (eval _x)) )) and used this way: (foo '(expression)) It would appear that environments are unnecessary. The Revised^3 report does not include any description of "make-environment", "eval", or "access". Neal Gafter -- Arpa: neal@cs.rochester.edu (Neal Gafter) UUCP: ...{rocksvax|allegra|decvax}!rochester!neal USnail: Department of Computer Science, U. of Rochester, N.Y. 14627 phone: (716) 275 - 1348 (office) or (716) 473 - 2361 (home)  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 11 Feb 88 18:54:35 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA06487; Thu, 11 Feb 88 15:23:19 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Feb 88 19:09:35 GMT From: rochester!neal@rutgers.edu (Neal Gafter) Organization: U of Rochester, CS Dept., Rochester, NY Subject: is make-environment really necessary for packages? Message-Id: <6722@sol.ARPA> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I do not understand the need for an explicit environment type in scheme. It seems that lambda could serve the same purpose. Suppose there were not an explicit environment type. In this case, the procedure "eval" would take only a single parameter: the expression to be evaluated (in the current environment). Packages, which are currently created this way: (define foo (make-environment (define x ...) (define y ...) ... )) and used this way: (eval '(expression) foo) Could still be created this way: (define foo (let () (define x ...) (define y ...) ... (lambda (_x) (eval _x)) )) and used this way: (foo '(expression)) It would appear that environments are unnecessary. The Revised^3 report does not include any description of "make-environment", "eval", or "access". Neal Gafter -- Arpa: neal@cs.rochester.edu (Neal Gafter) UUCP: ...{rocksvax|allegra|decvax}!rochester!neal USnail: Department of Computer Science, U. of Rochester, N.Y. 14627 phone: (716) 275 - 1348 (office) or (716) 473 - 2361 (home)  Received: from THEORY.LCS.MIT.EDU (TCP 2206400134) by MC.LCS.MIT.EDU 9 Feb 88 00:18:53 EST Received: from RAVEN.LCS.MIT.EDU by THEORY.LCS.MIT.EDU (4.12/4.7); Mon, 8 Feb 88 23:24:29 est Received: by RAVEN.LCS.MIT.EDU (4.12/4.7); Mon, 8 Feb 88 21:51:32 est Date: Mon, 8 Feb 88 21:51:32 est From: Bard Bloom Message-Id: <8802090251.AA01964@RAVEN.LCS.MIT.EDU> To: Alan@AI.AI.MIT.EDU Cc: PSRG@CLS.LCS.MIT.EDU, Scheme@MC.LCS.MIT.EDU In-Reply-To: Alan@AI.AI.MIT.EDU's message of Mon, 8 Feb 88 17:44:38 EST <323426.880208.JAR@AI.AI.MIT.EDU> Subject: ! Date: Mon, 8 Feb 88 17:44:38 EST From: Alan@AI.AI.MIT.EDU Sender: JAR@AI.AI.MIT.EDU (define (make-cell) (call-with-current-continuation (lambda (return-from-make-cell) (letrec ((state (call-with-current-continuation (lambda (return-new-state) (return-from-make-cell (lambda (op) (case op ((set) (lambda (value) (call-with-current-continuation (lambda (return-from-access) (return-new-state (list value return-from-access)))))) ((get) (car state))))))))) ((cadr state) 'done))))) What the hey is this?  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 8 Feb 88 17:44:52 EST Date: Mon, 8 Feb 88 17:44:38 EST From: Alan@AI.AI.MIT.EDU Sender: JAR@AI.AI.MIT.EDU Subject: ! To: PSRG@CLS.LCS.MIT.EDU, Scheme@MC.LCS.MIT.EDU Message-ID: <323426.880208.JAR@AI.AI.MIT.EDU> (define (make-cell) (call-with-current-continuation (lambda (return-from-make-cell) (letrec ((state (call-with-current-continuation (lambda (return-new-state) (return-from-make-cell (lambda (op) (case op ((set) (lambda (value) (call-with-current-continuation (lambda (return-from-access) (return-new-state (list value return-from-access)))))) ((get) (car state))))))))) ((cadr state) 'done)))))  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 8 Feb 88 17:44:52 EST Date: Mon, 8 Feb 88 17:44:38 EST From: Alan@AI.AI.MIT.EDU Sender: JAR@AI.AI.MIT.EDU Subject: ! To: PSRG@CLS.LCS.MIT.EDU, Scheme@MC.LCS.MIT.EDU Message-ID: <323426.880208.JAR@AI.AI.MIT.EDU> (define (make-cell) (call-with-current-continuation (lambda (return-from-make-cell) (letrec ((state (call-with-current-continuation (lambda (return-new-state) (return-from-make-cell (lambda (op) (case op ((set) (lambda (value) (call-with-current-continuation (lambda (return-from-access) (return-new-state (list value return-from-access)))))) ((get) (car state))))))))) ((cadr state) 'done)))))  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 7 Feb 88 18:49:58 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA14963; Sun, 7 Feb 88 15:44:53 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Feb 88 22:44:56 GMT From: murthy@cu-arpa.cs.cornell.edu (Chet Murthy) Organization: Cornell Univ. CS Dept. Ithaca NY Subject: Yale T (compiling) Message-Id: <13258@cornell.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I just ftp-ed a copy of Yale T from prep.ai.mit.edu, and I can't figure out how on Earth to recompile it. I would really like ot be able to build one from scratch, just so I know that it really works (or at least, that there are no hidden nulled out sections of the executable or anything). Does anybody out there know how to do this? I couldn't find build instructions anywhere. --chet-- In Real Life: Chet Murthy ARPA: murthy@svax.cs.cornell.edu SnailMail: Chet Murthy North Woods Apts #20-2A 700 Warren Road Ithaca, NY 14850 Office: 4162 Upson (607) 255-2219 MaBellNet: (607)-257-2542  Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 5 Feb 88 10:12:24 EST Received: from bucsf (BUCSF.BU.EDU) by bu-it.BU.EDU (4.0/4.7) id AA04013; Fri, 5 Feb 88 10:07:34 EST Return-Path: Received: by bucsf (4.12/4.7) id AA24604; Fri, 5 Feb 88 10:13:44 est Date: Fri, 5 Feb 88 10:13:44 est From: gjc%bucsf.bu.edu@bu-it.BU.EDU (George J. Carrette) Message-Id: <8802051513.AA24604@bucsf> To: scheme@mc.lcs.mit.edu Subject: different lisp implementations confused. CScheme is written in C and has a large library of code written in Scheme loaded into it. Having seen the development in progress I can say that there was not much attention paid to size or time efficiency. Macscheme was obviously written with efficiency in mind. It should not be suprising that one implementation is much larger or slower than another. (Perhaps I'm wrong, maybe it should be suprising, since one would not expect to see such large differences between, say, two FORTRAN implementations. What is it about lisp that allows for such wide range of qualities of implementation?) Even a common-lisp implementation could be relatively small. KCL, Kyoto Common Lisp, a c-coded implementation, even contains a compiler and debugger, and checks in at about 1.7 megabytes on an Encore MultiMax. (This is not a recommendation). T from Yale checks in at 2.3 Meg on a SUN-III. Gnu Emacs by comparison is 1.3 Meg on the same machine. * As is well known to readers of the old LISP-FORUM mailing list, and also to readers of PLAYBOY FORUM, *size* is not your best measure of quality. -gjc  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 5 Feb 88 03:49:39 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA07718; Fri, 5 Feb 88 00:32:10 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Feb 88 16:33:00 GMT From: ah4h+@andrew.cmu.edu (Andrew Hudson) Organization: Carnegie Mellon University Subject: Re: Scheme for the Amiga, size constraints Message-Id: References: <518@acf3.NYU.EDU>, Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu >I have implemented scheme 6.1 on my Amiga. I'll tell you, it's not an >easy thing to do. First of all,there is no way CScheme will work on a >machine with only 0.5M of RAM.I have got it working with 2.5M, but it >really wants 4M, heavy sigh... I can hardly believe this! MacScheme ran well on a Mac with only 512k. What does a Mac have that an Amiga doesn't? This is not a rhetorical question. Here at CMU I tell people that CommonLisp is a pig for needing 6M and you are saying 4M would be nice. Has anyone given consideration to a minimally sized implementation? - Andrew Hudson  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 4 Feb 88 16:06:42 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA22724; Thu, 4 Feb 88 12:35:42 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Feb 88 00:14:55 GMT From: xanth!kahn@AMES.ARC.NASA.GOV (Gary I Kahn) Organization: Old Dominion University, Norfolk Va. Subject: Little Lisper Message-Id: <3884@xanth.cs.odu.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Could someone please mail me the address of MIT Press, or one of its outlets? I want to buy a copy of The Little LISPer, Trade Edition. A local bookstore could only give me information about an earlier (1978? or 1986) version of the book. I need the address from which to order the book, and the price with any shipping charges. Thanks. I'm buying either that book or The Scheme Programming Language. I've already ordered Structure and Interpretation of Computer Programs from a local bookstore. Thanks in advance for the information. Gary I. Kahn kahn@odu.edu  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 1 Feb 88 18:46:59 EST Date: Mon, 1 Feb 88 18:47:05 EST From: Jonathan A Rees Subject: test message To: scheme@MC.LCS.MIT.EDU Message-ID: <319681.880201.JAR@AI.AI.MIT.EDU> Test message -- weeding out bad addresses. Please ignore.  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 29 Jan 88 17:19:43 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA28785; Fri, 29 Jan 88 12:48:44 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Jan 88 04:25:00 GMT From: kaplan@b.cs.uiuc.edu Subject: Scheme for Amiga? Message-Id: <189900003@uiucdcsb> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Several people on the net have indicated they are working on Scheme ports for the Amiga. I am teaching a course using Scheme this semester and some of my students have Amiga's and want to try get Scheme for it. If anyone out there has a port they are prepared to make available, I would be most grateful. My best email addresses are: kaplan@a.cs.uiuc.edu {ihnp4, seismo, research}!uiucdcs!kaplan Thanks in advance, Simon Kaplan  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 28 Jan 88 11:26:49 EST Received: from GROUSE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 330376; Thu 28-Jan-88 11:26:29 EST Date: Thu, 28 Jan 88 11:26 EST From: Stephen G. Rowley Subject: Parallel Versions of Scheme To: fowler@pyr.gatech.edu, scheme@mc.lcs.mit.edu In-Reply-To: <4883@pyr.gatech.EDU> Message-ID: <19880128162634.3.SGR@GROUSE.SCRC.Symbolics.COM> Date: 27 Jan 88 18:25:02 GMT From: fowler@pyr.gatech.edu (FREDERICK C. FOWLER) Can anyone tell me if there are any versions of scheme designed for parallel processing? I've heard of something called Multi-Scheme, and I think that I saw a reference to a parallel Scheme in Computer Language, but that's all I've been able to find out. Here's the reference (and the author) for MultiScheme: Date: Wed, 14 Oct 87 16:13:06 EDT From: James Miller To: Scheme%MC.LCS.MIT.EDU@RELAY.CS.NET Subject: MultiScheme My dissertation, "MultiScheme: A Parallel Processing System Based on MIT Scheme," is available from the MIT Lab for Computer Science publications office (545 Technology Square, Cambridge, MA 02139), as MIT/LCS/TR-402. It reports on an implementation of Scheme extended to support the FUTURE construct and speculative computation. It has a number of examples showing relationships to: embedding logic variables in Scheme, McCarthy's AMB and fair merge, higher order streams processing, data-flow parallelism, and so forth. The current release of MIT CScheme contains a serial processor implementation of the work reported in the thesis. BBN's Butterfly Lisp product is based directly on the (truly parallel) implementation.  Received: from BBN.COM (TCP 20026200172) by MC.LCS.MIT.EDU 28 Jan 88 11:23:07 EST Received: from lisperanto.bbn.com by BBN.COM id aa10576; 28 Jan 88 11:05 EST Date: Thu Jan 28 11:05:12 EST 1988 From: allen@BBN.COM To: fowler@pyr.gatech.edu CC: scheme@mc.lcs.mit.edu In-reply-to: "FREDERICK C. FOWLER"'s message of 27 Jan 88 18:25:02 GMT <4883@pyr.gatech.EDU> Subject: Parallel Versions of Scheme we (bbn advanced computers) have implemented a version of scheme, based on MIT cscheme, for the butterfly multiprocessor. see our paper in the proceedings of aaai-87 -- "recent developments in butterfly lisp" by seth steinberg, larry stabile, and myself, for a description of the system. feel free to contact me if you have any questions not answered by the paper. /don allen  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 27 Jan 88 22:28:04 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA08001; Wed, 27 Jan 88 18:51:51 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Jan 88 18:25:02 GMT From: fowler@pyr.gatech.edu (FREDERICK C. FOWLER) Organization: Georgia Institute of Technology, Atlanta Subject: Parallel Versions of Scheme Message-Id: <4883@pyr.gatech.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Can anyone tell me if there are any versions of scheme designed for parallel processing? I've heard of something called Multi-Scheme, and I think that I saw a reference to a parallel Scheme in Computer Language, but that's all I've been able to find out. Fred Fowler  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 27 Jan 88 11:50:01 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Wed, 27 Jan 88 10:44:19 EST X-Delivery-Notice: SMTP MAIL FROM does not correspond to sender. Received: from FRSAC11.BITNET (NETWORK@FRSAC12) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 0745; Wed, 27 Jan 88 10:24:24 EST Date: Wed, 27 Jan 88 16:18:31 GMT To: scheme@mc.lcs.MIT.EDU From: NETWORK%FRSAC11.BITNET@MITVMA.MIT.EDU Subject: Cleanup needed. +From: #Hein{nen Juha +Subject: suggestions for the next revision of scheme +.. +I have a couple of suggestions for the next revision of Scheme that +all deal with orthogonality issues: +.. +Second, map and for-each should apply also to strings and vectors. +Why should Scheme provide better treatment for list than for other +structured types? +.. +Finally, do should be abolished altogether. Is far too complicated +operation compared to the rest of Scheme and seems like a relic from +ancient times. +.. I do support the above remarks. If there is generic math functions, list/vector/string generic functions seems natural. I was surprised too at the "do" construct, that is far from usual scheme elegance. (I find the current "do" quite baroque.) Regards, Jean-Pierre H. Dumas network@frsac11 (bitnet) network%frsac11.bitnet@mitvma.mit.edu (arpanet) dumas@sumex-aim.stanford.edu (arpanet)  Received: from ATHENA.CS.YALE.EDU (TCP 20011000033) by MC.LCS.MIT.EDU 27 Jan 88 09:36:37 EST Received: by ATHENA.CS.YALE.EDU; Wed, 27 Jan 88 09:34:08 EST Date: Wed, 27 Jan 88 09:34:08 EST From: James Philbin Full-Name: James Philbin Message-Id: <8801271434.AA06384@ATHENA.CS.YALE.EDU> Received: by yale-ring (node-aac0/AAC0) via WIMP-MAIL (Version 1.2/1.4) ; Wed Jan 27 09:26:49 Subject: T a dialect of Scheme To: scheme@mc.lcs.mit.edu The T Programming Language T is a superset of Scheme developed at Yale University. T's extensions to Scheme include: multiple return values - a very efficient implementation, objects - a simple and efficient object system, debugger and inspector, locales - first class environments, macros - a syntax system, unwind-protect, dynamic binding, structures - efficient and integrated into the object system, tables - a generalize package pools, weak pointers, and weak tables. Although the default environment is the T programming language (a Scheme dialect based on the Revised Report on Scheme), an environment comforming to the Revised^3 Report on Scheme is also available. T is intended for use in education, systems programming, AI programming, and for programming language design and development. The system and compiler are written almost entirely in T. A new version of T (version 3.0) was released in January 1987. This system includes both an interpreter and a highly optimizing native code compiler (described in a paper by Kranz et al. in the Proceedings of the 1986 SIGPLAN Compiler Construction Conference) that compiles closures efficiently. This compiler produces code that is competitive with the best C and Pascal compilers. The following benchmarks from "Performance and Evaluation of Lisp Systems" by Gabrial were run on a Sun 3/160 in the most optimized mode of the compiler. tak .22 rdiv2 .76 fprint 1.80 puzzle 2.40 destru .98 fread 3.08 triangle 79.18 deriv 2.44 tprint 1.46 idiv2 .50 dderiv 3.02 T is available via Internet FTP. Telnet to PREP.AI.MIT.EDU and log in as user scheme, password scheme. The login shell is an FTP program. Send one or more of the following files: /t/readme.tar.Z /t/hp.tar.Z executable image for HP-UX /t/sun.tar.Z executable image for SUN /t/aegis.tar.Z executable image for Apollo Domain /t/vax_unix.tar.Z executable image for VAX running 4.2BSD, 4.2BSD or Ultrix /t/sources.tar.Z source code for compiler and runtime system If you can't get T this way, try to get it from someone who has it, or, Yale will mail you a tape for $200 (outside US $250). For more information contact Linda Abelli or Chris Hatchell at: T Project Yale University Dept. of Computer Science PO Box 2158 Yale Station New Haven, CT 06520 Email: t-project@yale.edu, decvax!yale!t-project.uucp, or tproj@YALECS.BITNET Phone: (203) 432-2381 -------  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 23 Jan 88 03:04:42 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA22261; Fri, 22 Jan 88 23:51:38 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Jan 88 17:44:01 GMT From: jh@ohio-state.arpa (#Hein{nen Juha) Organization: Tampere University of Technology, Finland Subject: suggestions for the next revision of scheme Message-Id: <545@tutor.tut.fi> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I have a couple of suggestions for the next revision of Scheme that all deal with orthogonality issues: First, named let* and letrec should be included in Scheme. I have several times run into situations where a construct like (let* loop ((x ...) (y ...x...)) ...) would have been useful. So far I haven't needed named letrec but, at least for completenes, it shouldn't be left out. Second, map and for-each should apply also to strings and vectors. Why should Scheme provide better treatment for list than for other structured types? Finally, do should be abolished altogether. Is far too complicated operation compared to the rest of Scheme and seems like a relic from ancient times. -- Juha Heinanen Tampere Univ. of Technology Finland jh@tut.fi (internet), tut!jh (UUCP)  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 22 Jan 88 17:24:15 EST Received: from relay2.cs.net by RELAY.CS.NET id ad03422; 22 Jan 88 16:14 EST Received: from tektronix.tek.com by RELAY.CS.NET id cr18045; 22 Jan 88 16:00 EST Received: by tektronix.TEK.COM (5.51/6.24) id AA04647; Fri, 22 Jan 88 09:58:02 PST Received: by tekchips.TEK.COM (5.51/6.24) id AA09354; Fri, 22 Jan 88 09:57:49 PST Date: Fri, 22 Jan 88 09:57:49 PST From: Will Clinger Message-Id: <8801221757.AA09354@tekchips.TEK.COM> To: scheme@mc.lcs.mit.edu Subject: Re: Are the GABRIEL-benchmarks translated into SCHEME already? Cc: mcvax!dutrun!dutesta!brouw@uunet.uu.net I have translated all but two (STAK and POLY) of the Gabriel benchmarks into Scheme and have sent them to a number of people. In a couple of weeks I will submit them to the Scheme "yellow pages" after fixing the bugs and non-portable constructions that have been reported to me. In the meantime I'm willing to send them to people who can't wait. Today is my last day as an employee of Tektronix. My new address will be William Clinger Semantic Microsystems, Inc. 4470 SW Hall Blvd, Suite 340 Beaverton, OR 97005 Telephone: (503) 643-4539 Since Semantic will probably be consulting for Tektronix, I think I will still be able to read mail sent to: willc%tekchips.tek.com@relay.cs.net I will probably not log in more than once a week or so, though. Semantic has had an inactive account on Compuserve, which I expect to reactivate. Peace, Will  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 22 Jan 88 14:13:02 EST Received: from relay2.cs.net by RELAY.CS.NET id aa00502; 22 Jan 88 12:45 EST Received: from hplb by RELAY.CS.NET id ac16785; 22 Jan 88 12:33 EST Received: from CSNet-Relay by hplb.csnet; 21 Jan 88 4:37:44-WET (Thu) Received: from relay.cs.net by RELAY.CS.NET id gf00770; 20 Jan 88 11:19 EST Received: from mc.lcs.mit.edu by RELAY.CS.NET id aa21723; 20 Jan 88 5:15 EST Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 20 Jan 88 05:03:37 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA28920; Wed, 20 Jan 88 01:30:13 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Jan 88 16:48:32 GMT From: Clark Williams Organization: Intergraph Corp. Huntsville, Al Subject: Problems bringing up CScheme 6.1 Message-Id: <389@b14.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I am attempting to bring up CScheme 6.1 on two machines and am encountering difficulties on both. I am hoping that someone with a little more Lisp/Scheme experience than I have will be able to spot my problems or at least point me in the right direction. The first machine is an Intergraph InterPro-220 workstation. This machine runs System V release 3 on the Clipper RISC processor set. After editing config.h and setting the relevant parameters, a make yields this message: > cd runtime;../microcode/scheme -fasl runmd.bin <../etc/make_band.scm >Scheme Microcode Version 10.2 >MIT Scheme, unix [ATT (V)] version > >utabs.bin loaded purified evaluated >implmd.bin loaded purified evaluated >boot.bin loaded purified evaluated . . <<<-------------------18 lines deleted . >numpar.bin loaded purified evaluated >numunp.bin loaded > >Purify phase error 9a0, 99f > >Inconsistency detected. >*** Error code 1 > >Stop. My question is, where should I start looking? I am new to the Lisp/Scheme world and I don't even know what 'purify' means in this context. Should I look in the Psbtobin.c code for a problem translating the .psb file to a .bin file? Or should I look in the purify.c code? The second machine is an Intergraph Micro II (MicroVax II with our boards) running VMS 4.5 (yes I know, BLECH!). This machine gets through the initial load-purify-evaluate phase and then this happens: >Cold load finished. Type > >((access finish-load runtime-system)) > >to load the rest of the system. > >1 ]=> ((access finish-load runtime-system)) >No such file #("pathname" () () "emacs" "bin" NEWEST) > >2 Error-> It just hasn't been my day. Any insight to these problems would be greatly appreciated. -- _ /| | Clark Williams Ack Thippfft! \'o.O` | Intergraph Corp. =(___)= | {uunet|ihnp4}!ingr!b14!clark U | (205) 772-6881  Received: from NSS.Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 22 Jan 88 11:58:14 EST Received: from isis.educ.lon.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa07684; 22 Jan 88 16:53 GMT Date: 22 Jan 1988 16:51:53-GMT From: rnoss To: scheme <@NSS.Cs.Ucl.AC.UK:scheme@mc.lcs.mit.edu> Hi -- I've just been in contact with Hal Abelson who says you may be able to help us. We have a Pyramid running unix. Is there a scheme that we could run? How do we get it? How much? etc..... All information would be welcome Thanks Richard Noss (University of London -- Institute of Education)  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 21 Jan 88 22:41:45 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA18118; Thu, 21 Jan 88 19:10:18 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Jan 88 15:08:18 GMT From: mcvax!dutrun!dutesta!brouw@uunet.uu.net (Gerard Brouwer) Organization: Delft University of Technology, Netherlands Subject: Question: Are the GABRIEL-benchmarks translated into SCHEME already? Message-Id: <1068@dutesta.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In the book 'Performance and Evaluation of Lisp Systems' the writer Richard P.Gabriel presents a dozen famous benchmarks. They are written in CommonLisp. What I am looking for is a translation of these benchmarks in SCHEME. If anyone knows if these SCHEME-benchmarks do exist, and where to get them please contact me. Thanks for your cooperation. Gerard Brouwer, Delft University of Technology UUCP: MCVAX!dutrun!dutesta!brouw Department of Electrical Engeneering Section Computer Architecture Mekelweg 4 2628 CD Delft, The Netherlands  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 20 Jan 88 05:03:37 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA28920; Wed, 20 Jan 88 01:30:13 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Jan 88 16:48:32 GMT From: ingr!b14!clark@uunet.uu.net (Clark Williams) Organization: Intergraph Corp. Huntsville, Al Subject: Problems bringing up CScheme 6.1 Message-Id: <389@b14.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I am attempting to bring up CScheme 6.1 on two machines and am encountering difficulties on both. I am hoping that someone with a little more Lisp/Scheme experience than I have will be able to spot my problems or at least point me in the right direction. The first machine is an Intergraph InterPro-220 workstation. This machine runs System V release 3 on the Clipper RISC processor set. After editing config.h and setting the relevant parameters, a make yields this message: > cd runtime;../microcode/scheme -fasl runmd.bin <../etc/make_band.scm >Scheme Microcode Version 10.2 >MIT Scheme, unix [ATT (V)] version > >utabs.bin loaded purified evaluated >implmd.bin loaded purified evaluated >boot.bin loaded purified evaluated . . <<<-------------------18 lines deleted . >numpar.bin loaded purified evaluated >numunp.bin loaded > >Purify phase error 9a0, 99f > >Inconsistency detected. >*** Error code 1 > >Stop. My question is, where should I start looking? I am new to the Lisp/Scheme world and I don't even know what 'purify' means in this context. Should I look in the Psbtobin.c code for a problem translating the .psb file to a .bin file? Or should I look in the purify.c code? The second machine is an Intergraph Micro II (MicroVax II with our boards) running VMS 4.5 (yes I know, BLECH!). This machine gets through the initial load-purify-evaluate phase and then this happens: >Cold load finished. Type > >((access finish-load runtime-system)) > >to load the rest of the system. > >1 ]=> ((access finish-load runtime-system)) >No such file #("pathname" () () "emacs" "bin" NEWEST) > >2 Error-> It just hasn't been my day. Any insight to these problems would be greatly appreciated. -- _ /| | Clark Williams Ack Thippfft! \'o.O` | Intergraph Corp. =(___)= | {uunet|ihnp4}!ingr!b14!clark U | (205) 772-6881