Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 10 Mar 90 17:23:51 EST Received: from schizo.samsung.com by mintaka.lcs.mit.edu id aa08060; 10 Mar 90 17:20 EST Received: by schizo.samsung.com from mitech.UUCP via UUCP (vers 5.61+) for scheme@mc.lcs.mit.edu (from gjc@mitech.com) id ; Sat, 10 Mar 90 17:20:17 -0500 Message-Id: <9003102220.AA03912@schizo.samsung.com> Reply-To: gjc@mitech.com MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Received: by mitech.com (DECUS UUCP w/Smail); Fri, 9 Mar 90 20:05:29 EDT Date: Fri, 9 Mar 90 20:05:29 EDT From: gjc@mitech.com MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu To: Scheme@mc.lcs.mit.edu Subject: Lisp implementation techniques and tools (looking for) X-Vms-Mail-To: UUCP%"Scheme@mc.lcs.mit.edu" It is not unusual to want to have an interpreted language as a front-end for intensive numerical computations. I know of at least one case of a serious physics simulation efforts at Livemore Labs that uses Scheme as a toplevel for both interactive and Batch jobs for programs mostly written in C. Even a casual look at more advanced solution/simulation techniques for partial differential equations shows a rather heavy use of LIST STRUCTURE, even if this codes are written in FORTRAN. But considering what data to have as lists, what to have as arrays, how much copying to do, compacting, data movement, the impact of virtual memory or the need to swap data in non-virtual memory implementations (e.g. the CRAY), this can all get rather hairy, and you have to connsider the low-level representations in detail. (Consider the 5-way memory interleave on the CRAY-1). I'm a proponent of keeping the initial lisp part of the program as small and simple as possible, and to allow the lisp/c subroutine interface be as NATURAL as possible. My studies indicate that SIOD is better than XLISP, XSCHEME, or ELK inn these matters. Anyone who wants to can consider for themselves: Anonymous FTP to BU.EDU, cd to users/gjc and get siod-v2.3-shar. -gjc  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 10 Mar 90 12:58:48 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa27968; 10 Mar 90 12:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA27467; Sat, 10 Mar 90 12:06:24 EST 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: 10 Mar 90 16:32:50 GMT From: Robert Steven Glickstein Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA Subject: Re: call/cc Message-Id: References: <1990Mar8.064319.28399@brutus.cs.uiuc.edu>, Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu When I was first trying to grok continuations as a Scheme novitiate, I found the sequence below very enlightening. Try to understand what's going on here; I'll post a detailed description in a day or two. > (define (identity-fn x) x) > (define (current-continuation) (call/cc identity-fn)) > (define foo (current-continuation)) > foo #[Continuation] > (foo 10) > foo 10 ______________ Bob Glickstein | Internet: bobg@andrew.cmu.edu Information Technology Center | Bitnet: bobg%andrew@cmuccvma.bitnet Carnegie Mellon University | UUCP: ...!harvard!andrew.cmu.edu!bobg Pittsburgh, PA 15213-3890 | (412) 268-6743 | Sinners can repent, but stupid is forever  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 10 Mar 90 11:57:34 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa25603; 10 Mar 90 11:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA25986; Sat, 10 Mar 90 11:33:46 EST 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: 9 Mar 90 13:58:07 GMT From: Eric Pepke Organization: Florida State University, but I don't speak for them Subject: Re: in defense of C Message-Id: <546@fsu.scri.fsu.edu> References: <1942@skye.ed.ac.uk>, <542@fsu.scri.fsu.edu>, <113917@ti-csl.csc.ti.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Sorry; I misunderstood the controversy. I feel like Emily Latella. "Never mind!" Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 10 Mar 90 06:59:16 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa17203; 10 Mar 90 6:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA13364; Sat, 10 Mar 90 06:09:37 EST 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: 10 Mar 90 02:39:35 GMT From: Pete Harlan Subject: Re: call/cc Message-Id: <38402@iuvax.cs.indiana.edu> References: <1990Mar8.064319.28399@brutus.cs.uiuc.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu sane@cs.uiuc.edu (Aamod Sane) writes: | I tried to understand the operation of call/cc from Dybvigs text |and the R3.99 without success. Can someone give a good explanation here or |a reference? It is said that the interepreter uses continuations which are |not visible normally etc. but I dont quite get this. Chapters 16 and 17 of _Scheme and the Art of Programming_, by Springer/Friedman, McGraw-Hill/MIT Press, gives a thorough introduction to understanding call/cc. It includes many examples of its use, and many exercises for practicing. I highly recommend it. --- Pete Harlan harlan@silver.ucs.indiana.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Mar 90 23:11:07 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03874; 9 Mar 90 23:06 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AB25033; Fri, 9 Mar 90 22:10:38 EST 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: 8 Mar 90 20:36:00 GMT From: snorkelwacker!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uicbert.eecs.uic.edu!lam@bloom-beacon.mit.edu Subject: Re: in defense of C Message-Id: <82000007@uicbert.eecs.uic.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu /* Written 1:35 pm Mar 1, 1990 by gjc@mitech.COM in uicbert.eecs.uic.edu:comp.lang.scheme */ /* ---------- "in defense of C" ---------- */ In defense of C? (Or an apology for small extensible languages with minimal overhead and minimal required runtime libraries). The key here is the phrase "equivalent program in Pascal" coupled with the extremely important suggestion I made, which is that C could be used like you use lisp. You say C has no array bounds checking. (In a way, big deal, certainly the Lispmachines had extremely good low-level checking of that nature, but it didn't keep the software or user from being able to "... let machines crash or behave strangely" as Steele puts it). It is so easy to build up error-checking routines from non-error-checking primitives. Is that not what we do in lisp? (Maybe we only *used* to do it, a lost art?) Here are some declarations from some code I use every day: struct bitarray {long width; long height; char *data;}; int bitaref(struct bitarray *,int,int); void bitaset(struct bitarray *,int,int,int); struct bitarray *cons_bitarray(long,long); Now, with prototype-enforcement there is absolutely no way my program is going to crash or behave badly if I use these three guys, cons_bitarray, bitaref and bitaset. The prototype-enforcement makes sure I'm not calling these on data that are not bit arrays and integers. My C-compiler can inline these and remove redundant error checking in many case. I claim: A good engineer can generate a much richer and more useful set of subroutines of this nature than found in ANY LANGUAGE DESIGNED BY COMMITTEE. ... especially compared to those those languages who's references manuals start overflowing into multiple volumes! On the subject of I/O primitives. "Gets" is one of those line-at-a-time (what I called mainframe-style) procedures. Not what I had in mind (also, not really what you should be calling primitive). Better to think in terms of getc and putc, or read and write, or XGetNextEvent. -gjc p.s. "... let machines crash or behave strangely", personally *no* I don't use the Macintosh and try to avoid writing Unix kernel code. /* End of text from uicbert.eecs.uic.edu:comp.lang.scheme */  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Mar 90 23:10:42 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03807; 9 Mar 90 23:04 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA25070; Fri, 9 Mar 90 22:12:14 EST 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: 9 Mar 90 10:40:06 GMT From: cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uicbert.eecs.uic.edu!lam@yale-zoo.arpa Subject: small pgms using big data? Message-Id: <82000008@uicbert.eecs.uic.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I'm looking for scheme programs to test different aspects of garbage collectors. For now, I'm looking for *small* programs that operate on *large* amounts of data. Programs that have some sort of size parameter, to scale the problem size and data usage, would be ideal. One such program (which we already have) is an n queens program, where we can scale the problem size by setting n to different values. (Don't offer us that one, though -- we've already got it.) Other good programs would be things like chess programs with alpha- beta pruning, which we could scale by setting the number of lookahead moves. Branch-and-bound and transitive closure kinds of things would be interesting, especially if the inputs are in a fairly simple format. (E.g., the dataflow phase of a compiler would be good, if it wouldn't be hard to isolate and port to a very vanilla Scheme, and we could just read representative inputs from a file or something.) Our main desiderata are: 1) that the programs be fairly easily ported (in particular, to a Scheme with very few extensions, and in which #F and '() are two distinct objects.) 2) scalability via either a simple parameter or choice of input problem 3) representativeness of some important class of algorithms -- e.g., things that explore state spaces in something like a depth-first way, where only the representations on the current path are live, and those that keep around representations of things already reached, like branch- and-bound. (I don't mean to overstress AI-type algorithms -- these are just examples. We just want small programs whose overall processing patterns resemble those of more serious programs, and which scale.) Ultimately, we want to put together a set of benchmark programs that can be used to stress different aspects of a garbage collector over a range of problem sizes. Please reply via email. If there's interest, I'll summarize to the net. -- Mike Lam Software Systems Laboratory lam@bert.eecs.uic.edu EECS Dept. (m/c 154) University of Illinois at Chicago Box 4348 Chicago IL 60680  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Mar 90 20:23:56 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa28639; 9 Mar 90 20:19 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA18604; Fri, 9 Mar 90 19:40:58 EST 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: 8 Mar 90 15:49:57 GMT From: "lawrence.g.mayka" Organization: AT&T Bell Laboratories Subject: Re: in defense of C Message-Id: <14236@cbnewsc.ATT.COM> References: <1942@skye.ed.ac.uk> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <1942@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes: >In article <14112@cbnewsc.ATT.COM> lgm@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) writes: > >One of the most important quality measures of a Common Lisp > >compiler is the level of safety it supports without an undue > >sacrifice in execution speed. The better CL implementations score > >quite highly on this scale, especially on newer processor > >architectures such as SPARC. For example, the better compilers > >indeed ensure that CAR and CDR are only applied to lists, without > >a loss of execution speed and even though a CL implementation must > >permit one to apply CAR and CDR to the symbol NIL. > >You say this as if it were typical of better compilers on machines >other than SPARCs, such as, maybe, 68020s. Can they really have safe >CARs and CDRs, without loss of speed, on a 68020? If so, I would >expect that safety to remain even if I set saftey=0, but that doesn't >seem to be what happens. Moreover, how many of the SPARC compilers >can do this? I suspect it's only one or two of them. You may be right. The particular compilation "trick" I've seen relies on the processor hardware to trap a fullword-size reference to a machine address not aligned on a fullword boundary. But if, as I think is true, the 68020 silently satisfies unaligned pointer references, this particular technique will indeed be ineffective on that architecture. All the more reason to upgrade to a RISC-based computer... Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Standard disclaimer.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Mar 90 20:23:35 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa28472; 9 Mar 90 20:13 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA18205; Fri, 9 Mar 90 19:27:30 EST 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: 9 Mar 90 01:08:43 GMT From: "Jacob L. Cybulski" Organization: Comp Sci, La Trobe Uni, Australia Subject: Re: (atom? '()) => #t Message-Id: <7385@latcs1.oz.au> References: <1990Mar7.194937.1421@sun.soe.clarkson.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <1990Mar7.194937.1421@sun.soe.clarkson.edu>, jk0@sun.soe.clarkson.edu (Jason Coughlin) writes: > Can someone explain the rationale behind treating '() as an atom? It > seems to me that it should be a pair: it's the empty *list* not the > empty *atom*. > When you look at lists from a purely functional point of view then any list is the result of CONS, whereas () is a primitive object, thus an atom. A good example of this approach was given in Abelson, Sussman and Sussman's book, where CONS, CAR and CDR are implemented functionally as follows :- (define (cons x y) (define (dispatch m) (cond ((= m 0) x) ((= m 1) y) (else (error "Arg not 0 nor 1 -- CONS" m)))) dispatch) (define (car z)(z 0)) (define (cdr z)(z 1)) As you can see () does not even appear anywhere in this definition, it may be viewed as a constant which customarily appears at the end of the sequencs of pairs (which we call a list). Jacob o | o \_/  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Mar 90 20:18:23 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa28495; 9 Mar 90 20:13 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA18329; Fri, 9 Mar 90 19:32:25 EST 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: 8 Mar 90 23:41:23 GMT From: John Gateley Organization: TI Computer Science Center, Dallas Subject: Re: in defense of C Message-Id: <113917@ti-csl.csc.ti.com> References: <14112@cbnewsc.ATT.COM>, <1942@skye.ed.ac.uk>, <542@fsu.scri.fsu.edu> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu In article <542@fsu.scri.fsu.edu> pepke@gw.scri.fsu.edu (Eric Pepke) writes: |In the one I am now writing for the 680x0, one can have |safe CARs and CDRs without loss of speed. |So, one just makes that a test for |(1) a valid list, or (2) anything else. In my system, that's testing a |single bit. In case 1, do the job. In case 2, return NIL. |Eric Pepke INTERNET: pepke@gw.scri.fsu.edu But this is NOT safe: consider the following code: (defun foo () (if (car 3) (tear-down-the-berlin-wall) (bomb-the-soviets))) Your implementation will bomb the soviets! I understand that your implementation will not crash due to garbage pointers, but I don't think "safe" is a good term to apply here. John gateley@m2.csc.ti.com  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Mar 90 14:59:36 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa15952; 9 Mar 90 14:56 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA06931; Fri, 9 Mar 90 14:19:27 EST 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: 8 Mar 90 18:53:08 GMT From: Tim Moore Organization: University of Utah CS Dept Subject: Re: in defense of C Message-Id: <1990Mar8.115308.6180@hellgate.utah.edu> References: <14112@cbnewsc.ATT.COM>, <1942@skye.ed.ac.uk>, <542@fsu.scri.fsu.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <542@fsu.scri.fsu.edu> pepke@gw.scri.fsu.edu (Eric Pepke) writes: >In article <1942@skye.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes: >> You say this as if it were typical of better compilers on machines >> other than SPARCs, such as, maybe, 68020s. Can they really have safe >> CARs and CDRs, without loss of speed, on a 68020? > >I don't know about the internals of any LISP system other than the ones I >have written. In the one I am now writing for the 680x0, one can have >safe CARs and CDRs without loss of speed. One has to test to see if it is >(1) a valid list, or (2) NIL, anyway. So, one just makes that a test for >(1) a valid list, or (2) anything else. In my system, that's testing a >single bit. In case 1, do the job. In case 2, return NIL. > That's the loss of speed that Jeff is talking about. If you assume that the argument to CAR or CDR is a cons cell or NIL and you have a low-tags type scheme, then those operations are 1 instruction long on a 680x0 (or even less: a base-displacement addressing mode). The NIL case can be handled with a bit of symbol table trickery. A "safe" C{A,D}R that checks its argument is going to be slower. >Eric Pepke INTERNET: pepke@gw.scri.fsu.edu >Supercomputer Computations Research Institute MFENET: pepke@fsu >Florida State University SPAN: scri::pepke >Tallahassee, FL 32306-4052 BITNET: pepke@fsu > Tim Moore moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore "Ah, youth. Ah, statute of limitations." -John Waters  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Mar 90 12:03:01 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07610; 9 Mar 90 11:56 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA28756; Fri, 9 Mar 90 11:20:33 EST 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: 8 Mar 90 15:32:50 GMT From: Eric Pepke Organization: Florida State University, but I don't speak for them Subject: Re: in defense of C Message-Id: <542@fsu.scri.fsu.edu> References: <14112@cbnewsc.ATT.COM>, <1942@skye.ed.ac.uk> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <1942@skye.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes: > You say this as if it were typical of better compilers on machines > other than SPARCs, such as, maybe, 68020s. Can they really have safe > CARs and CDRs, without loss of speed, on a 68020? I don't know about the internals of any LISP system other than the ones I have written. In the one I am now writing for the 680x0, one can have safe CARs and CDRs without loss of speed. One has to test to see if it is (1) a valid list, or (2) NIL, anyway. So, one just makes that a test for (1) a valid list, or (2) anything else. In my system, that's testing a single bit. In case 1, do the job. In case 2, return NIL. Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Mar 90 11:57:49 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07539; 9 Mar 90 11:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA28188; Fri, 9 Mar 90 11:02:27 EST 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: 8 Mar 90 15:33:08 GMT From: "Andrew L. M. Shalit" Organization: Apple Computer Inc, Cambridge, MA Subject: Re: (atom? '()) => #t Message-Id: References: <1990Mar7.194937.1421@sun.soe.clarkson.edu>, <7079@ubc-cs.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <7079@ubc-cs.UUCP> manis@cs.ubc.ca (Vincent Manis) writes: In article <1990Mar7.194937.1421@sun.soe.clarkson.edu> jk0@sun.soe.clarkson.edu (Jason Coughlin) writes: >Can someone explain the rationale behind treating '() as an atom? It >seems to me that it should be a pair: it's the empty *list* not the >empty *atom*. But remember, a list isn't a pair. It's zero or more pairs connected together via a cdr chain. In fact, a pair is an object to which the car and cdr procedures may be applied; it has been considered unkosher for many years to allow (car '()) and (cdr '()). Only unkosher in Scheme, not in Common Lisp. Perhaps more crucially, you have to be able to SET-CAR! and SET-CDR! a pair. This is something you certainly can't do to the empty list. -andrew  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Mar 90 10:10:58 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02130; 9 Mar 90 10:03 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA25116; Fri, 9 Mar 90 09:44:53 EST 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: 24 Feb 90 00:13:50 GMT From: Mark Brader Organization: SoftQuad Inc., Toronto Subject: Re: problems/risks due to programming language, stories requested Message-Id: <1990Feb24.001350.2617@sq.sq.com> References: <9790@medusa.cs.purdue.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Gerald Baumgartner (gb@cs.purdue.EDU) writes in many groups: > There is the famous story that a Mariner probe got lost > because of the Fortran statement `DO 3 I = 1.3' (1.3 instead > of 1,3) ... It is a nice story but, as far as I know, NASA used > Jovial at that time and not Fortran. Just for the record, the above was definitively shown to be fictional according to authoritative references given in comp.risks (= Risks Digest), issue 9.75 (I hear), not too many months ago. There is at least one textbook that states it as truth; this is wrong. The actual reason for the loss of Mariner I was an error in code used in recovering from a hardware failure; the code had been based on handwritten equations, and in transcribing one of these, an overbar was deleted from one letter. A story which may have been the true origin of the "DO statement myth" was posted fairly recently in alt.folklore.computers; the article cited a program at NASA that did enter production use with a dot-for-comma bug in a DO statement, but it wasn't a spacecraft flight control program. (I didn't save the details and would be happy to see them again.) Followups directed to alt.folklore.computers. -- Mark Brader "I'm not going to post a revision: even USENET utzoo!sq!msb, msb@sq.com readers can divide by 100." -- Brian Reid This article is in the public domain.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Mar 90 10:04:45 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02054; 9 Mar 90 10:01 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA24737; Fri, 9 Mar 90 09:34:02 EST 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: 23 Feb 90 23:08:29 GMT From: Joel Bartlett Organization: DEC Western Software Laboratory Subject: Scheme->C compiler available via FTP Message-Id: <2886@bacchus.dec.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu The Scheme-to-C compiler, Scheme->C, done at Digital Equipment Corporation's Western Research Laboratory is now available for public ftp. The compiler compiles Revised**3 Scheme to C that is then compiled by the native C compiler for the target machine. This design results in a portable system that allows either stand-alone Scheme programs or programs written in both compiled and interpreted Scheme and other languages. The Scheme->C system supports the essentials of Revised**3 and many of the optionals. Extensions include "expansion passing style" macros, a foreign function call capability, and interfaces to X11's Xlib. The system does provide call-with-current-continuation. Numbers are represented internally as 29-bit integers, or 64-bit floating point values. The compiler is written in Scheme. Most of the runtime system (including an interpreter) is written in Scheme. The generational compacting garbage collector and a few other things are written in C. There is a small (< 100 lines) amount of assembly code. The system is known to run on VAX's and DECstation 3100's running Ultrix. Other ports should be straightforward. The system is available for anonymous ftp from 'gatekeeper.dec.com' [16.1.0.2]. The Scheme->C files are in '/pub/DEC/Scheme-to-C'. Those files include: README - overview and copyright notice. 23feb90.tar.Z - compressed tar file containing all source and documentation. Joel Bartlett bartlett@decwrl.dec.com  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Mar 90 10:04:37 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02013; 9 Mar 90 10:00 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA24413; Fri, 9 Mar 90 09:25:42 EST 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: 24 Feb 90 02:56:56 GMT From: Vincent Manis Organization: Bucky Bits Cereal Keyboards, Ltd. Subject: Re: first programming languages, and second ones too Message-Id: <6914@ubc-cs.UUCP> References: <9002221434.AA03515@schizo.samsung.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I don't want to get too far away from the purpose of this newsgroup, but I wouldn't recommend C as an immediate successor to Scheme in a SICP-based course. The major reasons are the convoluted syntax and the lack of reasonable response to run-time errors. I've taught courses using C at the second and third year levels for years, and I know for a fact that students find both of these almost insuperable. I am, however, in agreement with gjc that the right way to teach these languages is by having the students work on a Scheme evaluator. That's certainly what we had in mind. As for going directly to assembler: in our course, we won't be using the approach SICP uses to assembly language. We're going to introduce a fairly conventional hypothetical machine, and then explain its behaviour on the register transfer level. This seems more appropriate than the SIPC one in a course which is aimed at non-electrical engineers. -- \ Vincent Manis "There is no law that vulgarity and \ Department of Computer Science literary excellence cannot coexist." /\ University of British Columbia -- A. Trevor Hodge / \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Mar 90 03:35:14 EST Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17709; 9 Mar 90 3:24 EST Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.0/AI-4.10) id AA06533; Fri, 9 Mar 90 03:25:11 EST Received: from localhost by zurich.ai.mit.edu; Fri, 9 Mar 90 03:24:36 est Date: Fri, 9 Mar 90 03:24:36 est From: Chris Hanson Message-Id: <9003090824.AA00467@zurich.ai.mit.edu> To: net%TUB.BITNET@mitvma.mit.edu Cc: scheme@mc.lcs.mit.edu In-Reply-To: Oliver Laumann's message of Thu, 8 Mar 90 17:35:30 +0100 <9003081635.AA14269@tub.UUCP> Subject: constants in Scheme Date: Thu, 8 Mar 90 17:35:30 +0100 From: Oliver Laumann I still don't quite understand which objects are considered immutable in Scheme. The standard says "The constants and the strings returned by symbol->string are then the immutable objects, while all objects created by the other procedures in this Standard are mutable". The basic rule is that any object that appears in your program is immutable. Thus quoted lists, quoted vectors, and any strings that appear in the text of your program are immutable. In addition, the strings returned by symbol->string are also immutable. The standard does not define any other immutable objects. Does this mean that objects returned by, say, "read" are mutable? Yes. Is the expression (string-set! (read) 0 #\a)) legal, when the call to (read) returns a non-empty string? Yes. And what about the elements of a vector constant? Is (set-car! (vector-ref '#((a b) c) 0) 'd) legal? This is not legal. Both the vector, and its elements (just like the elements of a quoted list) are objects that textually appear in your program, and thus are immutable. By the way, why must vector constants be quoted? Does the evaluation of a vector constant ever return a result? Unquoted vectors are not defined as expressions; a program containing an unquoted vector in its text is what the standard calls a "non-conforming program". I don't know any good reason why these are illegal.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Mar 90 14:00:30 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa25602; 8 Mar 90 13:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA26514; Thu, 8 Mar 90 13:08:20 EST 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: 8 Mar 90 06:43:19 GMT From: Aamod Sane Organization: U of Illinois, CS Dept., Systems Research Group Subject: call/cc Message-Id: <1990Mar8.064319.28399@brutus.cs.uiuc.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Beginners question: I tried to understand the operation of call/cc from Dybvigs text and the R3.99 without success. Can someone give a good explanation here or a reference? It is said that the interepreter uses continuations which are not visible normally etc. but I dont quite get this. I would also like examples/references on the Continuation Passing style (just building of lambdas, not the call/cc variety). I know of examples such as gcd of a list where you can escape if a 1 is encountered without doing any computation, by building lambdas and using them only if 1 is not found. Thanks , Aamod Sane sane@cs.uiuc.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Mar 90 12:51:36 EST Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa22864; 8 Mar 90 12:47 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 0441; Thu, 08 Mar 90 12:46:47 EST Received: from DB0TUI6.BITNET (NET) by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 0680; Thu, 08 Mar 90 12:46:46 EST Received: by tub.UUCP; Thu, 8 Mar 90 17:35:30 +0100; AA14269 Date: Thu, 8 Mar 90 17:35:30 +0100 From: Oliver Laumann Message-Id: <9003081635.AA14269@tub.UUCP> To: scheme@mc.lcs.mit.edu Subject: constants in Scheme I still don't quite understand which objects are considered immutable in Scheme. The standard says "The constants and the strings returned by symbol->string are then the immutable objects, while all objects created by the other procedures in this Standard are mutable". Does this mean that objects returned by, say, "read" are mutable? Is the expression (string-set! (read) 0 #\a)) legal, when the call to (read) returns a non-empty string? And what about the elements of a vector constant? Is (set-car! (vector-ref '#((a b) c) 0) 'd) legal? By the way, why must vector constants be quoted? Does the evaluation of a vector constant ever return a result? Thanks, -- Oliver Laumann net@TUB.BITNET net@tub.cs.tu-berlin.de net@tub.UUCP  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Mar 90 12:01:41 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20708; 8 Mar 90 11:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA23087; Thu, 8 Mar 90 11:25:33 EST 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: 8 Mar 90 03:20:13 GMT From: Vincent Manis Organization: Bucky Bits Cereal Keyboards, Ltd. Subject: Re: (atom? '()) => #t Message-Id: <7079@ubc-cs.UUCP> References: <1990Mar7.194937.1421@sun.soe.clarkson.edu> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu In article <1990Mar7.194937.1421@sun.soe.clarkson.edu> jk0@sun.soe.clarkson.edu (Jason Coughlin) writes: >Can someone explain the rationale behind treating '() as an atom? It >seems to me that it should be a pair: it's the empty *list* not the >empty *atom*. But remember, a list isn't a pair. It's zero or more pairs connected together via a cdr chain. In fact, a pair is an object to which the car and cdr procedures may be applied; it has been considered unkosher for many years to allow (car '()) and (cdr '()). -- \ Vincent Manis "There is no law that vulgarity and \ Department of Computer Science literary excellence cannot coexist." /\ University of British Columbia -- A. Trevor Hodge / \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Mar 90 11:02:33 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18288; 8 Mar 90 10:56 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA20430; Thu, 8 Mar 90 10:00:50 EST 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: 6 Mar 90 15:28:55 GMT From: Michael Borza Organization: Antel Optronics Inc., Burlington, Ontario, Canada Subject: Looking for Lisp techniques and tools Message-Id: <1990Mar6.152855.7731@antel.uucp> References: <9003020249.AA10901@LUBEC.MIT.EDU> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu Sorry to interject Lisp/Scheme questions into this otherwise well-placed discussion on C/Pascal/Ada/... but... In article <9003020249.AA10901@LUBEC.MIT.EDU> mory@ATHENA.MIT.EDU writes: > >I would like a public domain c callable scheme interpreter for use as >an extension language. Any recommendations? > > Mory I'm just embarking on a similar trek. I've got a substantial amount of experience with other programming languages, but I'm starting into Lisp as a serious undertaking for the first time. I've got some specific questions and some general ones; I'll start with the general ones so people uninterested in the specifics can bail out early. I'm interested to hear what tools and techniques people use for Lisp program development. Post if you believe it's of general interest, e-mail to me will garner a summary to the net (names will not be included in the summary). Most of these questions probably seem simplistic; please let me know if they are inappropriate to the level of these groups. My purpose is to find out about what people who've done substantial program development in Lisp use for tools and methods. At this point, I've got Elk 1.0 up and running (pretty much), so these questions are slanted towards Elk and Scheme; however, it's not too late to change my mind about choice of tools, so feel free to make any suggestions you like. PD or freely-distributed tools are preferred, but descriptions about any tools and/or systems will be appreciated. 1. What types of tools are available for Lisp program and project development? Presumably there are Lisp-callable editors for Lisp programs that know about Lisp syntax. What about source-code and project management tools? What about simple things like pagers, directory listing tools, shell escapes, and the like? Any pointers to where these can be found? 2. My intention is to develop an easily extended modelling language, suitable for both interactive use for small jobs, but recognizing a need for `batch' processing of larger ones. The processes being simulated involve potentially huge amounts of floating-point computation. A suitable simulation engine is already written in C. My gut reaction is that the user interface for input to the simulator and display of the results are probably best handled in Lisp, with a system call invoking the simulation engine. I propose to handle the interface between the two with intermediate files. For `batch' or command-line driven mode, the model compiler/interpreter may optionally need to be invoked, followed by the simulation engine; I feel that this can be handled adequately by a suitable combination of command scripts and possibly a C wrapper. Any comments on this approach? Does it make more sense for the C program to invoke Lisp (which seems to be a more commonly used technique)? 3. I've implemented a subset of the functionality I want in C, using lex and yacc as required. I find this approach cumbersome when dealing with an extensible language and nested layers of encapsulation. Am I barking up the wrong tree taking a multilingual approach? What about using Lisp in this application? It seems idealy suited to the task, but not having tackled anything substantial in it, I may be missing something obvious. So end the general questions. 4. I currently have Elk 1.0 running under UNIX System V r 3.2 on an 80386. The xlib interface works, xt won't compile, but it looks like a quick fix. The only really tricky point (for me, at least) was an apparent change in the format of externals in COFF files between the release of Elk and release of SysVr3.2. I still experience occassional core dumps with segmentation violations and bus errors, esp. during autoloading and garbage collection. At this point, I'm a little suspicious of the alloca implementation. Before I start trying to track this down, are there any official or unofficial patches known to fix this? 5. What's the current release level of Elk? Are there any known bugs I should be aware of? Is it reasonable to consider increasing the amount of memory allocated to the heap? 6. What are people's opinions of Elk? Is it in wide distribution and being used to implement substantial projects? If not, why not? Are there more suitable systems for the kind of project described above? Are there Elk-specific tool kits, or Scheme tool kits known to be useful with Elk? 7. I have strived to make the existing source code for the simulation engine portable between a number of systems, both UNIX and non-UNIX. While not a pressing issue now, I would like to make the Lisp part of the project similarly portable. It seems that a common approach in a number of Lisp implementations I've seen is to provide compatibility functions for other popular Lisp dialects. What are the issues I should be aware of when trying to accomplish portability in Lisp, or is this best not discussed in polite company? That's it. Any and all responses will be greatly appreciated, especially from you Lisp afficionados out there. If you've got other comments to make, feel free. I'll summarize any e-mail reponses I receive in the next, oh say, 3 weeks to the net. I promise to summarize, and I promise not to name names. cheers, mike borza. -- Michael Borza Antel Optronics Inc. (416)335-5507 3325B Mainway, Burlington, Ont., Canada L7M 1A6 work: mike@antel.UUCP or uunet!utai!utgpu!maccs!antel!mike home: mike@boopsy.UUCP or uunet!utai!utgpu!maccs!boopsy!mike  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Mar 90 11:01:59 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18234; 8 Mar 90 10:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA21302; Thu, 8 Mar 90 10:35:19 EST 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: 8 Mar 90 00:30:49 GMT From: Rich Alderson Organization: Stanford University Academic Information Resources Subject: Re: IEEE CS membership cost (correction) Message-Id: <9894@portia.Stanford.EDU> References: <9003060844.aa02089@mintaka.lcs.mit.edu> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu In article <9003060844.aa02089@mintaka.lcs.mit.edu>, chaynes@IUVAX (Chris Haynes) writes: >In a previous note on balloting for the draft IEEE Scheme standard, I >stated that ACM members could join the IEEE Computer Society for $13. >I was misinformed. The cost for 6 months of Computer Society >membership is $23.50. They don't take 12 month membership >applications at this time of year, and ACM members only get a break if >they join the IEEE proper, which is considerably more expensive. >Once more, you should be an IEEE or Computer Society member if you >wish to ballot on the Scheme standard. I have been an ACM member for years. Recently, when I joined the IEEE Computer Society, I got a $5.00 break because I was a member of the ACM. I didn't have to join the IEEE itself. Hey, $5.00 is $5.00! Rich Alderson alderson@jessica.stanford.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Mar 90 05:59:48 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa06856; 8 Mar 90 5:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA11817; Thu, 8 Mar 90 05:19:42 EST 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: 7 Mar 90 19:49:37 GMT From: Jason Coughlin Organization: Clarkson University, Potsdam, NY Subject: (atom? '()) => #t Message-Id: <1990Mar7.194937.1421@sun.soe.clarkson.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu This one just burnt me, *badly*. Can someone explain the rationale behind treating '() as an atom? It seems to me that it should be a pair: it's the empty *list* not the empty *atom*. Given this defn of a cons node: struct C_node { struct CONS_NODE *car; struct CONS_NODE *cdr; } ; struct CONS_NODE { int type; union { struct C_node cdata; int idata; double fdata; ...etc.. } data; } ; #define CC 1 /* car is a PAIR, cdr is a pair */ #define CA 2 /* car is a PAIR, cdr is an atom */ #define AC 3 /* car is an ATOM, cdr is PAIR */ #define AA 4 /* car is an ATOM, cdr is an ATOM */ #define INT 5 #define FLOAT 6 ...etc... (note: the C means CONS, probably should be a P for PAIR) seem to me, that the list (a b c) should be this: AC -> AC -> AC -> NIL a b c but since '() is an atom, it is in actuality this: AC -> AC -> A A a b c NIL -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Mar 90 05:15:00 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa04872; 8 Mar 90 5:00 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA10422; Thu, 8 Mar 90 04:40:54 EST 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: 6 Mar 90 19:36:27 GMT From: Jeff Dalton Organization: AIAI, University of Edinburgh, Scotland Subject: Re: in defense of C Message-Id: <1942@skye.ed.ac.uk> References: <1903@skye.ed.ac.uk>, <14112@cbnewsc.ATT.COM> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <14112@cbnewsc.ATT.COM> lgm@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) writes: >One of the most important quality measures of a Common Lisp >compiler is the level of safety it supports without an undue >sacrifice in execution speed. The better CL implementations score >quite highly on this scale, especially on newer processor >architectures such as SPARC. For example, the better compilers >indeed ensure that CAR and CDR are only applied to lists, without >a loss of execution speed and even though a CL implementation must >permit one to apply CAR and CDR to the symbol NIL. You say this as if it were typical of better compilers on machines other than SPARCs, such as, maybe, 68020s. Can they really have safe CARs and CDRs, without loss of speed, on a 68020? If so, I would expect that safety to remain even if I set saftey=0, but that doesn't seem to be what happens. Moreover, how many of the SPARC compilers can do this? I suspect it's only one or two of them. -- Jeff  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 6 Mar 90 08:49:34 EST Received: from iuvax.cs.indiana.edu by mintaka.lcs.mit.edu id aa02089; 6 Mar 90 8:44 EST Received: by iuvax.cs.indiana.edu Date: Tue, 6 Mar 90 08:44:23 -0500 From: Chris Haynes To: rrrs-authors@mc.lcs.mit.edu, scheme-standard@wheaties.ai.mit.edu, scheme@mc.lcs.mit.edu Subject: IEEE CS membership cost (correction) Message-ID: <9003060844.aa02089@mintaka.lcs.mit.edu> In a previous note on balloting for the draft IEEE Scheme standard, I stated that ACM members could join the IEEE Computer Society for $13. I was misinformed. The cost for 6 months of Computer Society membership is $23.50. They don't take 12 month membership applications at this time of year, and ACM members only get a break if they join the IEEE proper, which is considerably more expensive. Once more, you should be an IEEE or Computer Society member if you wish to ballot on the Scheme standard. -- Chris Haynes  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Mar 90 22:58:22 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa00141; 5 Mar 90 22:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA17802; Mon, 5 Mar 90 22:47:58 EST 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: 6 Mar 90 03:37:30 GMT From: Dirk Grunwald Organization: University of Colorado at Boulder Subject: TeX Manual for xscheme? Message-Id: <17812@boulder.Colorado.EDU> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu Does anyone have the xscheme manual converted to TeX or TeXinfo format? I want to smash it down to something other than 40 pages. Please mail me or tell me where I can FTP it. thanx  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Mar 90 17:04:28 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa12663; 5 Mar 90 16:59 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA24104; Mon, 5 Mar 90 16:24:29 EST 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: 5 Mar 90 15:19:48 GMT From: "lawrence.g.mayka" Organization: AT&T Bell Laboratories Subject: Re: in defense of C Message-Id: <14112@cbnewsc.ATT.COM> References: <1903@skye.ed.ac.uk> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu [I have added comp.lang.lisp to the newsgroup list.] In article <1903@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes: >Besides, since when does Lisp make such checks. Sure, most Lisps >probably check array bounds, but most do not check whether CAR and >CDR are really being applied to conses (just for example). On Lisp-directed processor architectures, dynamic type checks are (typically) uniformly applied, often in parallel with the computation of the most-common-case result. On conventional (C- and Fortran-directed) architectures, Common Lisp vendors typically offer a range of safety/efficiency tradeoffs. One can then choose a tradeoff according to the needs, or the stage of development, of one's application. One of the most important quality measures of a Common Lisp compiler is the level of safety it supports without an undue sacrifice in execution speed. The better CL implementations score quite highly on this scale, especially on newer processor architectures such as SPARC. For example, the better compilers indeed ensure that CAR and CDR are only applied to lists, without a loss of execution speed and even though a CL implementation must permit one to apply CAR and CDR to the symbol NIL. >As GJC notes, Lisp programmers have developed ways to deal with >this, as have C programmers. I venture to say that generally, Common Lisp programmers compile unsafe code only when they have to (e.g., when the absolute maximum execution speed is called for, or when forced by circumstances to use an inferior CL compiler), not because they like it. Unsafe code is not an integral part of the culture or a badge of pride as, one might say, it seems to be for C. Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Standard disclaimer.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Mar 90 01:58:27 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa04628; 5 Mar 90 1:54 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA09606; Mon, 5 Mar 90 00:57:24 EST 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: 2 Mar 90 14:59:35 GMT From: Jeff Dalton Organization: AIAI, University of Edinburgh, Scotland Subject: Re: in defense of C Message-Id: <1903@skye.ed.ac.uk> References: <9003012059.AA11786@schizo.samsung.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <9003012059.AA11786@schizo.samsung.com> gjc@mitech.com writes: >The key here is the phrase "equivalent program in Pascal" coupled >with the extremely important suggestion I made, which is that C >could be used like you use lisp. Not only that, who says C can't have array bounds checking. As far as I can tell, the lack of them is just an implementation tradition. Pointers would have to be more complex, but fi you want bounds checking enough you'd presumably be willing to pay. Besides, since when does Lisp make such checks. Sure, most Lisps probably check array bounds, but most do not check whether CAR and CDR are really being applied to conses (just for example). As GJC notes, Lisp programmers have developed ways to deal with this, as have C programmers. >You say C has no array bounds checking. (In a way, big deal, >certainly the Lispmachines had extremely good low-level checking >of that nature, but it didn't keep the software or user from >being able to "... let machines crash or behave strangely" as Steele puts it). That too.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 3 Mar 90 23:57:30 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa06825; 3 Mar 90 23:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA27926; Sat, 3 Mar 90 23:40:39 EST 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: 1 Mar 90 15:33:23 GMT From: Jeff Dalton Organization: AIAI, University of Edinburgh, Scotland Subject: Re: problems/risks due to programming language, stories requested Message-Id: <1883@skye.ed.ac.uk> References: <9790@medusa.cs.purdue.edu>, , <6960@internal.Apple.COM> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <6960@internal.Apple.COM> chewy@apple.com (Paul Snively) writes: >machismo is thus huffed and puffed up (another of my personal opinions is >that the per capita arrogance of C programmers far outweighs the per >capita arrogance of any other language-aficionado group). Except for Pascal programmers. Even Wirth has moved on by now.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 3 Mar 90 23:57:24 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa06752; 3 Mar 90 23:54 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA26736; Sat, 3 Mar 90 23:08:57 EST 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: 28 Feb 90 15:31:01 GMT From: William Mcneill Organization: U. of Calgary, Calgary, Alberta, Canada Subject: xscheme request Message-Id: <2556@cs-spool.calgary.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Could someone please inform me as to where I can get a copy of the source for the latest version of xscheme. I beleive that xscheme is now up to version 2.2? Please note that I do not have ftp access from this site. Thanks in Advance Blake McNeill  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU; 3 Mar 90 22:24:14 EST Date: Sat, 3 Mar 90 22:24:10 EST From: Alan Bawden Subject: problems/risks due to programming language, stories requested To: Scheme@MC.LCS.MIT.EDU In-reply-to: Msg of 2 Mar 90 19:19:01 GMT from David F. Carlson Message-ID: <707179.900303.ALAN@AI.AI.MIT.EDU> Date: 2 Mar 90 19:19:01 GMT From: David F. Carlson ... What break does is *very* well defined Of course there is more to designing a good programming language than making sure that it is "well defined". and is no more prone to misinterpretation that any other non-linear control flow statement in any other PL.... I beg to differ. You would be much less likely to make the kind of error that started this discussion if you could give -names- to switch, while, do and for statements, and if break and continue allowed you to name the particular statement that was to be broken or continued. Common Lisp has the RETURN-FROM special form because we learned this lesson from the original MacLisp RETURN special form.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 3 Mar 90 04:25:23 EST Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa26521; 3 Mar 90 4:21 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 5446; Sat, 03 Mar 90 04:20:31 EST Received: from NUSDISCS.BITNET (WONGWF) by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 0154; Sat, 03 Mar 90 04:20:30 EST Date: Sat, 3 Mar 90 17:19 H From: WONGWF%NUSDISCS.BITNET@mitvma.mit.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Subject: subscribe To: scheme@mc.lcs.mit.edu X-Original-To: scheme@mc.lcs.mit.edu, WONGWF Message-ID: <9003030421.aa26521@mintaka.lcs.mit.edu> wongwf@nusdiscs.bitnet  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 3 Mar 90 00:56:55 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18959; 3 Mar 90 0:54 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA24201; Sat, 3 Mar 90 00:19:59 EST 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: 2 Mar 90 14:59:35 GMT From: Jeff Dalton Organization: AIAI, University of Edinburgh, Scotland Subject: Re: in defense of C Message-Id: <1903@skye.ed.ac.uk> References: <9003012059.AA11786@schizo.samsung.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <9003012059.AA11786@schizo.samsung.com> gjc@mitech.com writes: >The key here is the phrase "equivalent program in Pascal" coupled >with the extremely important suggestion I made, which is that C >could be used like you use lisp. Not only that, who says C can't have array bounds checking. As far as I can tell, the lack of them is just an implementation tradition. Pointers would have to be more complex, but fi you want bounds checking enough you'd presumably be willing to pay. Besides, since when does Lisp make such checks. Sure, most Lisps probably check array bounds, but most do not check whether CAR and CDR are really being applied to conses (just for example). As GJC notes, Lisp programmers have developed ways to deal with this, as have C programmers. >You say C has no array bounds checking. (In a way, big deal, >certainly the Lispmachines had extremely good low-level checking >of that nature, but it didn't keep the software or user from >being able to "... let machines crash or behave strangely" as Steele puts it). That too.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 2 Mar 90 23:17:57 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa14875; 2 Mar 90 22:54 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA16574; Fri, 2 Mar 90 21:55:39 EST 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: 3 Mar 90 02:10:47 GMT From: Karl Heuer Organization: Interactive Systems, Cambridge, MA 02138-5302 Subject: Re: problems/risks due to programming language Message-Id: <16078@haddock.ima.isc.com> References: <6960@internal.Apple.COM>, <1004@micropen> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <1004@micropen> dave@micropen (David F. Carlson) writes: >What break does is *very* well defined and is no more prone to >misinterpretation that any other non-linear control flow statement ... Yes, it's well defined, but what it's defined to do is bad. For a formal treatment of the above statement, I refer you to my article <16039@haddock.ima.isc.com>, posted to comp.lang.misc (also .c and .ada) with this same title. I haven't seen any rebuttals yet. >A multi-case switch is very handy in many situations ... Yeah. I wish C had this feature, instead of simulating it with fallthrough. >That you ask the question of the usefulness of break-per-case/multiple-cases >implies that you haven't sufficient experience with the construct to judge >its merits/weaknesses. I don't know about the person you were addressing, but I think I've had sufficient experience with it. I certainly question its usefulness in comparison to something reasonable, like the language I described in my other article. In fact, even if you insist that the comparison must be between C and plain-C-without-break-switch, I think I'd still go for the latter. I believe the benefit of not requiring an overloaded keyword to do a break-switch exceeds the cost of having to use a goto to merge related cases. Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 2 Mar 90 21:58:40 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa12253; 2 Mar 90 21:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA15233; Fri, 2 Mar 90 21:33:49 EST 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: 3 Mar 90 02:23:33 GMT From: Vincent Manis Organization: Bucky Bits Cereal Keyboards, Ltd. Subject: Re: problems/risks due to programming language, stories requested Message-Id: <6984@ubc-cs.UUCP> References: <1004@micropen>, <14258@lambda.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I might note that B's syntax, and hence C's syntax, was a definite *dis*improvement [sic] over that of its predecessor, BCPL. I would in fact post an article saying exactly that, except for the fact that this entire thread most certainly belongs somewhere, but not in comp.lang.scheme. Would you please edit the Newsgroups: line in further articles on this subject? -- \ Vincent Manis "There is no law that vulgarity and \ Department of Computer Science literary excellence cannot coexist." /\ University of British Columbia -- A. Trevor Hodge / \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 2 Mar 90 20:59:56 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07532; 2 Mar 90 20:54 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA10854; Fri, 2 Mar 90 19:56:54 EST 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: 2 Mar 90 23:27:22 GMT From: Jim Giles Subject: Re: problems/risks due to programming language, stories requested Message-Id: <14258@lambda.UUCP> References: <1004@micropen> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu From article <1004@micropen>, by dave@micropen (David F. Carlson): > [... explicit breaks in the C switch construct ...] > Dijkstra notes that no programming language can prevent a poor programmer from > creating bad programs. He also notes that the choice of programming language can have a strong effect on the quality of the resulting code. (His indictment of PL/I as being similar to flying a widebodied jet with all the windows taped over and no labels on the thousands of controls was quite apropos.) This effect of the language choice is mainly psychological - and it CAN be overcome (which is the main thrust of many of Dijkstra's works). But, be honest, how many programmers do you know who _really_ construct their programs abstractly _before_ even selecting their implementation language? This is the proper way (a' la Dijkstra) to make sure the you aren't negatively impacted by the language - you select the proper language for the job at hand - you don't mangle the job to fit the language. Dijkstra's statement, while true, should not be used to excuse poorly designed language features (as you are trying to do). A better design for C would have been _not_ to require breaks after each case and to provide some other syntax for the representation of multiple choices on the same case. It's easy to see these kinds of design errors in retrospect (C _is_ nearly 20 years old you know). J. Giles  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 2 Mar 90 19:56:35 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa04957; 2 Mar 90 19:54 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA08548; Fri, 2 Mar 90 18:58:31 EST 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: 2 Mar 90 23:01:08 GMT From: "William J. Bouma" Organization: Department of Computer Science, Purdue University Subject: Re: problems/risks due to programming language, stories requested Message-Id: <9897@medusa.cs.purdue.edu> References: <6960@internal.Apple.COM> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <6960@internal.Apple.COM> chewy@apple.com (Paul Snively) writes: >We all know C programmers whose >machismo is thus huffed and puffed up (another of my personal opinions is >that the per capita arrogance of C programmers far outweighs the per >capita arrogance of any other language-aficionado group). Oh, really! I can tell you have never met any FORTH programmers. >Well, I hate to say it, but it's extremely unlikely that such an error >would have been made in Pascal, since Pascal doesn't require you to >explicitly break from case...of constructs. Well isn't that special! The way I see it, C gives you the flexibility to not break if you don't want to, where PASCAL restricts you to break. >Before the flames start, Too late! > let me just add: no, I don't necessarily prefer Pascal over C for all tasks. The only place I can see to prefer PASCAL over C is a beginner programming class. Isn't PASCAL usually thrown out along with the diapers? -- Bill | And don't forget my dog... "Astronomy" -- BOC  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 2 Mar 90 18:59:21 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02370; 2 Mar 90 18:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA07743; Fri, 2 Mar 90 18:37:02 EST 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: 2 Mar 90 22:15:22 GMT From: "William Thomas Wolfe, 2847 " Subject: Re: problems/risks due to programming language, stories requested Message-Id: <8218@hubcap.clemson.edu> References: <1004@micropen> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu From dave@micropen (David F. Carlson): >> For what it's worth, my personal opinion is that C lends itself to >> precisely the kinds of errors noted above--when does break work and when >> doesn't it, and why in God's name do you need it in switch statements in >> the first place, etc. > > A multi-case switch is very handy in many situations to reduce identical > treatments for similar cases. So is a multi-alternative case, as provided by Ada: case Foo is when 1 | 3 | 5 => statement1; when 2 | 4 | 6 => statement2; when others => statement3; end case; The difference is that Ada takes care of exiting the case statement for you, whereas C requires (unsafely) that you use a break to avoid being sucked into the code associated with subsequent cases. Bill Wolfe, wtwolfe@hubcap.clemson.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 2 Mar 90 18:02:25 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa29408; 2 Mar 90 17:59 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA05557; Fri, 2 Mar 90 17:53:26 EST 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: 2 Mar 90 19:19:01 GMT From: "David F. Carlson" Organization: Micropen Direct Writing Systems, Pittsford, NY Subject: Re: problems/risks due to programming language, stories requested Message-Id: <1004@micropen> References: <6960@internal.Apple.COM> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu In article <6960@internal.Apple.COM>, chewy@apple.com (Paul Snively) writes: > > > For what it's worth, my personal opinion is that C lends itself to > precisely the kinds of errors noted above--when does break work and when > doesn't it, and why in God's name do you need it in switch statements in > the first place, etc. What break does is *very* well defined and is no more prone to misinterpretation that any other non-linear control flow statement in any other PL. From K&R2 p 244: A9.5: iteration statement is (for, while, do)... A break statement may appear only in an iteration statement or a switch statement; control passes to the statement following the terminated statement. A multi-case switch is very handy in many situations to reduce identical treatments for similar cases. That you ask the question of the usefulness of break-per-case/multiple-cases implies that you haven't sufficient experience with the construct to judge its merits/weaknesses. Dijkstra notes that no programming language can prevent a poor programmer from creating bad programs. -- David F. Carlson, Micropen, Inc. micropen!dave@ee.rochester.edu "The faster I go, the behinder I get." --Lewis Carroll  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 2 Mar 90 11:23:21 EST Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09874; 2 Mar 90 11:17 EST Received: from zurich.ai.mit.edu ([18.43.0.165]) by life.ai.mit.edu (4.0/AI-4.10) id AA13154; Fri, 2 Mar 90 11:17:45 EST Received: from localhost by zurich.ai.mit.edu; Fri, 2 Mar 90 11:17:09 est Date: Fri, 2 Mar 90 11:17:09 est From: Franklyn Turbak Message-Id: <9003021617.AA16492@zurich.ai.mit.edu> To: Scheme@lcs.mit.edu In-Reply-To: Automatic Scheme Digestifier's message of 2 Mar 90 02:18:51 EST Subject: Re: in defense of C In article <5799@udccvax1.acs.udel.EDU>, mccalpin@vax1.acs.udel.edu writes: > >I claim: A good engineer can generate a much richer and more useful set of > >subroutines of this nature than found in ANY LANGUAGE DESIGNED BY COMMITTEE. > > But should every engineer *have*to* generate all of those subroutines? > Certainly it is possible to write your own error-checking code and > such, but many of us were hired to get work done, not to individually > re-created safe programming languages/environments. Indeed, the expressiveness of a language depends not only on what the language allows you to say but also on what it doesn't force you to say. Given any language with reasonable enough abstraction facilities (chiefly procedures and macros) it is *possible* to write clean and safe code, but not necessarily *easy* to do so. The hallmark of a language is the extent to which it abstracts over common programming patterns. If Scheme didn't support SET! or CALL-WITH-CURRENT-CONTINUATION it would be possible to simulate them by passing an explicit store and continuation to every procedure (in the denotational semantics "style"), but programs would become cumbersome to write and impenetrable to read. SET! and CALL-WITH-CURRENT-CONTINUATION are useful language features exactly because they embed into the language patterns which otherwise would have to created again and again by hand. A similar argument can be made for a variety of other language features: types, data abstraction facilities, error-handling facilities, etc. Sure, it's always possible to simulate these in some explicit fashion; but do we want to *have* to? - Lyn -  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 1 Mar 90 21:54:33 EST Received: from ATHENA.MIT.EDU by mintaka.lcs.mit.edu id aa07136; 1 Mar 90 21:51 EST Received: from LUBEC.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA24631; Thu, 1 Mar 90 21:51:50 EST From: mory@athena.mit.edu Received: by LUBEC.MIT.EDU (5.61/4.7) id AA10901; Thu, 1 Mar 90 21:49:50 -0500 Date: Thu, 1 Mar 90 21:49:50 -0500 Message-Id: <9003020249.AA10901@LUBEC.MIT.EDU> To: scheme@mc.lcs.mit.edu Subject: C callable scheme interpreter Cc: mory@athena.mit.edu, lasdev@athena.mit.edu I would like a public domain c callable scheme interpreter for use as an extension language. Any recommendations? Mory  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 1 Mar 90 21:45:34 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03255; 1 Mar 90 20:32 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA08046; Thu, 1 Mar 90 20:15:39 EST 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: 1 Mar 90 22:50:35 GMT From: John D Mccalpin Organization: College of Marine Studies, Univ. of Delaware Subject: Re: in defense of C Message-Id: <5799@udccvax1.acs.udel.EDU> References: <9003012059.AA11786@schizo.samsung.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <9003012059.AA11786@schizo.samsung.com> gjc@mitech.com writes: >In defense of C? >(Or an apology for small extensible languages with minimal overhead > and minimal required runtime libraries). >It is so easy to build up error-checking routines from >non-error-checking primitives. >Here are some declarations from some code I use every day: [...example deleted...] >Now, with prototype-enforcement there is absolutely no way my program is >going to crash or behave badly if I use these three guys, cons_bitarray, >bitaref and bitaset. Maybe a step farther is the TYPES package by Saul Youssef at Florida State which provides an object-oriented programming environment within a FORTRAN implementation. By making careful use of arrays pretending to be structures, it is possible to write fairly robust code even though the language semantics provide very little protection on type-checking on such. The TYPES package provides queues, ordered sets, lists, etc., all accessible and operated on by FORTRAN subroutines. Inquiries to youssef@scri1.scri.fsu.edu >I claim: A good engineer can generate a much richer and more useful set of >subroutines of this nature than found in ANY LANGUAGE DESIGNED BY COMMITTEE. But should every engineer *have*to* generate all of those subroutines? Certainly it is possible to write your own error-checking code and such, but many of us were hired to get work done, not to individually re-created safe programming languages/environments. >... especially compared to those those languages who's references manuals >start overflowing into multiple volumes! -gjc But it is certainly possible to write a fairly simple language which provides a good degree of reliability and which does not allow many of the most common forms of errors that C and FORTRAN are full of. A good example is Turing-Plus, which combines a fairly restrictive and safe language with the ability to do all those nasty things that C and FORTRAN programmers love so.... You just have be be very specific about telling the machine that you are doing something tricky. Ditto for Modula-3, as far as I can tell. (I have not yet gotten it operational on my SparcStation.) Not all strongly-typed and checked languages need to be Ada.... -- John D. McCalpin - mccalpin@vax1.acs.udel.edu mccalpin@delocn.udel.edu mccalpin@scri1.scri.fsu.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 1 Mar 90 18:33:19 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa27656; 1 Mar 90 18:29 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA01043; Thu, 1 Mar 90 17:39:57 EST 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: 1 Mar 90 21:42:21 GMT From: Chuck Lins Organization: Apple Computer Inc, Cupertino, CA Subject: Re: problems/risks due to programming language, stories requested Message-Id: <39109@apple.Apple.COM> References: , <6960@internal.Apple.COM>, <1883@skye.ed.ac.uk> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <1883@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes: >In article <6960@internal.Apple.COM> chewy@apple.com (Paul Snively) writes: > >machismo is thus huffed and puffed up (another of my personal opinions is > >that the per capita arrogance of C programmers far outweighs the per > >capita arrogance of any other language-aficionado group). > >Except for Pascal programmers. Even Wirth has moved on by now. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Yup. Even beyond Modula-2 to Oberon. And several colleagues at ETHZ have enhance Oberon with object-oriented extensions. -- Chuck Lins | "Exit left to funway." Apple Computer, Inc. | Internet: lins@apple.com 20525 Mariani Avenue | AppleLink: LINS Mail Stop 41-K | Cupertino, CA 95014 | "Self-proclaimed Object Oberon Evangelist" The intersection of Apple's ideas and my ideas yields the empty set.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 1 Mar 90 16:07:05 EST Received: from schizo.samsung.com by mintaka.lcs.mit.edu id aa20645; 1 Mar 90 16:00 EST Received: by schizo.samsung.com from mitech.UUCP via UUCP (vers 5.61+) for scheme@mc.lcs.mit.edu (from gjc@mitech.com) id ; Thu, 1 Mar 90 15:59:33 -0500 Message-Id: <9003012059.AA11786@schizo.samsung.com> Reply-To: gjc@mitech.com MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Received: by mitech.com (DECUS UUCP w/Smail); Thu, 1 Mar 90 15:35:23 EDT Date: Thu, 1 Mar 90 15:35:23 EDT From: gjc@mitech.com MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu To: scheme@mc.lcs.mit.edu Subject: in defense of C X-Vms-Mail-To: UUCP%"scheme@mc.lcs.mit.edu" In defense of C? (Or an apology for small extensible languages with minimal overhead and minimal required runtime libraries). The key here is the phrase "equivalent program in Pascal" coupled with the extremely important suggestion I made, which is that C could be used like you use lisp. You say C has no array bounds checking. (In a way, big deal, certainly the Lispmachines had extremely good low-level checking of that nature, but it didn't keep the software or user from being able to "... let machines crash or behave strangely" as Steele puts it). It is so easy to build up error-checking routines from non-error-checking primitives. Is that not what we do in lisp? (Maybe we only *used* to do it, a lost art?) Here are some declarations from some code I use every day: struct bitarray {long width; long height; char *data;}; int bitaref(struct bitarray *,int,int); void bitaset(struct bitarray *,int,int,int); struct bitarray *cons_bitarray(long,long); Now, with prototype-enforcement there is absolutely no way my program is going to crash or behave badly if I use these three guys, cons_bitarray, bitaref and bitaset. The prototype-enforcement makes sure I'm not calling these on data that are not bit arrays and integers. My C-compiler can inline these and remove redundant error checking in many case. I claim: A good engineer can generate a much richer and more useful set of subroutines of this nature than found in ANY LANGUAGE DESIGNED BY COMMITTEE. ... especially compared to those those languages who's references manuals start overflowing into multiple volumes! On the subject of I/O primitives. "Gets" is one of those line-at-a-time (what I called mainframe-style) procedures. Not what I had in mind (also, not really what you should be calling primitive). Better to think in terms of getc and putc, or read and write, or XGetNextEvent. -gjc p.s. "... let machines crash or behave strangely", personally *no* I don't use the Macintosh and try to avoid writing Unix kernel code.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 1 Mar 90 14:33:40 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa16145; 1 Mar 90 14:30 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA23361; Thu, 1 Mar 90 14:28:07 EST 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: 1 Mar 90 15:33:23 GMT From: Jeff Dalton Organization: AIAI, University of Edinburgh, Scotland Subject: Re: problems/risks due to programming language, stories requested Message-Id: <1883@skye.ed.ac.uk> References: <9790@medusa.cs.purdue.edu>, , <6960@internal.Apple.COM> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <6960@internal.Apple.COM> chewy@apple.com (Paul Snively) writes: >machismo is thus huffed and puffed up (another of my personal opinions is >that the per capita arrogance of C programmers far outweighs the per >capita arrogance of any other language-aficionado group). Except for Pascal programmers. Even Wirth has moved on by now.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 1 Mar 90 14:33:34 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa16102; 1 Mar 90 14:30 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA22393; Thu, 1 Mar 90 14:06:10 EST 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: 1 Mar 90 19:00:10 GMT From: Barry Margolin Organization: Thinking Machines Corporation, Cambridge MA, USA Subject: Re: problems/risks due to programming language, stories requested Message-Id: <34416@news.Think.COM> References: <6960@internal.Apple.COM>, <1990Feb28.213543.21748@sun.soe.clarkson.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <1990Feb28.213543.21748@sun.soe.clarkson.edu> jk0@image.soe.clarkson.edu (Jason Coughlin) writes: > Gee, if you read the language defn you'd know exactly when break >applies and when break doesn't. It seems to me that it is the >programmer's responsibility to know the language in which he is going to >implement said project -- it's not necessarily the language's responsibility >to know the programmer didn't read the defn. What would you say if a car designer used a similar excuse: Gee, if you'd read the owner's manual for the 6000SUX you'd know that you have to turn the radio off before stepping on the brake pedal. It seems to me that it is the driver's responsibility to know the car he's driving -- it's not necessarily the manufacturer's responsibility to know that the driver didn't read the manual. Yes, it's the resposibility of the programmer to know the language. But it's the responsibility of language designers to design languages reasonably. If programmer-friendliness weren't an issue we'd still be programming in machine language. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 1 Mar 90 13:32:03 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa13073; 1 Mar 90 13:28 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA18166; Thu, 1 Mar 90 12:43:52 EST 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: 1 Mar 90 17:39:51 GMT From: zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!cs325ec@think.com Subject: Need letrec Message-Id: <7900001@ux1.cso.uiuc.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu If anyone has some time, could you take the time to mail me a letrec funtion definition (or macro) that will work on the simplest of scheme implementations... i.e. only +,- etc., null? car, cons etc. Thanks -Greg  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 1 Mar 90 06:32:38 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa24679; 1 Mar 90 6:28 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA26286; Thu, 1 Mar 90 05:54:32 EST 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: 28 Feb 90 15:31:01 GMT From: William Mcneill Organization: U. of Calgary, Calgary, Alberta, Canada Subject: xscheme request Message-Id: <2556@cs-spool.calgary.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Could someone please inform me as to where I can get a copy of the source for the latest version of xscheme. I beleive that xscheme is now up to version 2.2? Please note that I do not have ftp access from this site. Thanks in Advance Blake McNeill  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 1 Mar 90 02:42:46 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa14993; 1 Mar 90 2:29 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA14345; Thu, 1 Mar 90 02:10:16 EST 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: 1 Mar 90 06:59:40 GMT From: Walter Maner Organization: Bowling Green State University B.G., Oh. Subject: Stepper for XSCHEME Wanted Message-Id: <5485@bgsuvax.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu There exists an excellent single-stepper for XLISP. Does similar software exist for XSCHEME? -- InterNet maner@andy.bgsu.edu (129.1.1.2) | BGSU, Comp Science Dept UUCP ... ! osu-cis ! bgsuvax ! maner | Bowling Green, OH 43403 BITNet MANER@BGSUOPIE | 419/372-2337 Secretary Relays @relay.cs.net, @nsfnet-relay.ac.uk | FAX is available - call  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 28 Feb 90 18:37:17 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21328; 28 Feb 90 17:59 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA15857; Wed, 28 Feb 90 16:54:44 EST 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: 28 Feb 90 21:35:43 GMT From: Jason Coughlin Organization: Clarkson University, Potsdam, NY Subject: Re: problems/risks due to programming language, stories requested Message-Id: <1990Feb28.213543.21748@sun.soe.clarkson.edu> References: <6960@internal.Apple.COM> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu From article <6960@internal.Apple.COM>, by chewy@apple.com (Paul Snively): > For what it's worth, my personal opinion is that C lends itself to > precisely the kinds of errors noted above--when does break work and when > doesn't it, and why in God's name do you need it in switch statements in > the first place, etc. Gee, if you read the language defn you'd know exactly when break applies and when break doesn't. It seems to me that it is the programmer's responsibility to know the language in which he is going to implement said project -- it's not necessarily the language's responsibility to know the programmer didn't read the defn. > Well, I hate to say it, but it's extremely unlikely that such an error > would have been made in Pascal, since Pascal doesn't require you to > explicitly break from case...of constructs. And without knowing the project, you have no business making the assertion that Pascal was better than C [especially on a Unix box] or that C was better than Pascal [especially on a VMS box]. -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 28 Feb 90 18:32:32 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa14714; 28 Feb 90 16:03 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA06934; Wed, 28 Feb 90 14:11:31 EST 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: 28 Feb 90 18:57:58 GMT From: Paul Snively Organization: Apple Computer, Inc. Subject: Re: problems/risks due to programming language, stories requested Message-Id: <6960@internal.Apple.COM> References: Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu In article bill@ssd.harris.com (Bill Leonard) writes: > In article <9790@medusa.cs.purdue.edu> gb@cs.purdue.EDU (Gerald Baumgartner) writes: > Again it looks like this bug wouldn't have occurred in another > programming language. > > I can't resist saying that this last statement seems to me to be utter > nonsense. What programming language (read, compiler) can read the > programmer's mind and tell what he meant? The use of the "break" statement > was a logic error (actually, it sounds like it was a lack of knowledge of > the language, since "break" does not apply to "if"). I can't imagine a > programming language that could discern this type of error. [If I use > WHILE instead of IF, for instance, I can expect some things to work and > some not. Yet I seriously doubt any compiler could possibly detect this > error.] > > I certainly think programmers often choose an inappropriate language, but I > shy away from anecdotal stories like these because they seem (to me) to > spread a lot of misinformation. Unless you implement a project in multiple > languages, it is nothing more than a guess to say what would have happened > if the project had been implemented in some other language. Perhaps you > would have discovered an even more serious flaw in that language, or you > might simply find it was no better or worse than the one you chose, just > different. > > Most of the stories I have heard along these lines all struck me as missing > the point: how well was the program tested? Were there code reviews? > Design reviews? All of these techniques are proven to reduce errors. Most > of the errors in these stories (e.g., the infamous dot-versus-comma one) > should have been found with even rudimentary testing. > > Use of an inappropriate language is no excuse for abandoning other techniques > of good software engineering. I don't think that anyone's claiming that it is an excuse; I believe the point was that some languages applied to some tasks lend themselves to error more than another language applied to the same task. If you wish to interpret the above story as a rather pointed jab at the C programming language, and object to C being treated that way, that's fine, but please just say so. For what it's worth, my personal opinion is that C lends itself to precisely the kinds of errors noted above--when does break work and when doesn't it, and why in God's name do you need it in switch statements in the first place, etc. I believe that it's C's historical looseness that is simultaneously its greatest weakness, when it leads to errors like this, and its greatest strength--C doesn't restrict you; C is mean and lean; C is close to the hardware; real programmers use C; even, God help us, C is the only language you need! We all know C programmers whose machismo is thus huffed and puffed up (another of my personal opinions is that the per capita arrogance of C programmers far outweighs the per capita arrogance of any other language-aficionado group). Now to get back to the important point: what language would have been better for the task in question? Well, I hate to say it, but it's extremely unlikely that such an error would have been made in Pascal, since Pascal doesn't require you to explicitly break from case...of constructs. Before the flames start, let me just add: no, I don't necessarily prefer Pascal over C for all tasks. I generally attempt to choose the right tool for the job, rather than falling into the "when all you have is a hammer, everything looks like a nail" trap. Standard Disclaimer.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 28 Feb 90 18:30:19 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa08696; 28 Feb 90 13:32 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA26158; Tue, 27 Feb 90 12:59:45 EST 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: 27 Feb 90 14:56:17 GMT From: Jeff Dalton Organization: AIAI, University of Edinburgh, Scotland Subject: Re: A Franz Lisp question. Message-Id: <1851@skye.ed.ac.uk> References: <660@shuldig.Huji.Ac.IL> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu In article <660@shuldig.Huji.Ac.IL> misha@boojum.huji.ac.il writes: >As you all might well know, Franz Lisp is a dynamic binding langauge, while >Scheme is not. Therefore, the following code is unwriteable in Franz Lisp: > >(define (func param) > (lambda (x) (param x))) > >[This function accepts a parameter which is also a function, and returns yet >another function which 'apply's param on x.] In Opus 38.92, you would write this: (declare (special param)) (defun func (param) (fclosure '(param) #'(lambda (x) (funcall param x)))) "funcall" is used to call a functional object. "fclosure" is used to make a closure over dynamic (ie, special) variables. Hence "param" must be declared special if you want your code to compile correctly. The problem with compilation occurs because Franz is not a totally dynamic binding language. It is for interpreted code, but in compiled code variables have lexical scope (but only dynamic extent) by default. -- Jeff  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 28 Feb 90 18:26:35 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa05815; 28 Feb 90 11:48 EST Received: from daystar.aca.mcc.com by MCC.COM with TCP/SMTP; Wed 28 Feb 90 10:49:02-CST Date: Wed, 28 Feb 90 10:48:51 CST From: "David D. Loeffler" Posted-Date: Wed, 28 Feb 90 10:48:51 CST Message-Id: <9002281648.AA01350@daystar.aca.mcc.com> Received: by daystar.aca.mcc.com (4.0/ACAv4.1i) id AA01350; Wed, 28 Feb 90 10:48:51 CST To: eru!luth!sunic!dkuug!iesd!normark@bloom-beacon.mit.edu Cc: scheme@mc.lcs.mit.edu In-Reply-To: Kurt Normark's message of 23 Feb 90 09:55:48 GMT <1990Feb23.095548.2764@iesd.auc.dk> Subject: A Report on Object-oriented Programming in Scheme. Reply-To: "David D. Loeffler" I would like a copy of the report please. Dave  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 28 Feb 90 15:59:42 EST Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa13170; 28 Feb 90 15:28 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 6613; Wed, 28 Feb 90 15:27:34 EST Received: from IRUCCIBM.BITNET by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 2864; Wed, 28 Feb 90 15:27:34 EST Received: from IRUCCVAX.UCC.IE (STCS8004) by IRUCCIBM.BITNET (Mailer R2.05) with BSMTP id 0745; Wed, 28 Feb 90 10:42:59 IST Date: Wed, 28 Feb 90 10:43 GMT From: STCS8004%IRUCCVAX.UCC.IE@mitvma.mit.edu Subject: Scheme as 1st language To: SCHEME@mc.lcs.mit.edu X-VMS-To: SCHEME Message-ID: <9002281528.aa13170@mintaka.lcs.mit.edu> My thanks to everyone who responded to my request for views on using Scheme as the first programming language. I have tried to acknowledge each individual response but I have had several 'undeliverable mail' messages as a result. If you did not get an acknowledgement from me direct please accept my thanks now! G. Oulsnam  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 28 Feb 90 15:52:28 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa08650; 28 Feb 90 13:31 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA05479; Tue, 27 Feb 90 16:22:38 EST 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: 27 Feb 90 19:32:14 GMT From: Keith Morgan Organization: GE Advanced Technology Labs, Moorestown, NJ Subject: Re: Scheme->C compiler available via FTP Message-Id: <211@puma.ge.com> References: <2886@bacchus.dec.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <2886@bacchus.dec.com> bartlett@decwrl.dec.com (Joel Bartlett) writes: >The Scheme-to-C compiler, Scheme->C, done at Digital Equipment >Corporation's Western Research Laboratory is now available for public >ftp. [...} >There is a small (< 100 lines) amount of assembly code. The system >is known to run on VAX's and DECstation 3100's running Ultrix. Other >ports should be straightforward. My installation on the Vax went very smoothly. This is a nice system. However, I really need it for the SPARC. The assembly portion doesn't look too bad, but the heap manager might be hairy due to the new and exciting alignment restrictions of the SPARC. Has anyone done this port or planning to? Keith Morgan Domain: kmorgan@atl.ge.com Path: !mcnc!ge-rtp!atl.ge.com!kmorgan  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 28 Feb 90 15:52:20 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa08585; 28 Feb 90 13:30 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA01375; Wed, 28 Feb 90 12:31:13 EST 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: 27 Feb 90 19:30:04 GMT From: Bill Leonard Organization: Harris Computer Systems Division Subject: Re: problems/risks due to programming language, stories requested Message-Id: References: <9790@medusa.cs.purdue.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <9790@medusa.cs.purdue.edu> gb@cs.purdue.EDU (Gerald Baumgartner) writes: I received the following on AT&T's famous bug (and have deleted multiple forwarding headers): | | Subject: AT&T Bug | | Date: Fri Jan 19 12:18:33 1990 | | | | This is the bug that cause the AT&T breakdown | | the other day (no, it wasn't an MCI virus): | | | | In the switching software (written in C), there was a long | | "do . . . while" construct, which contained | | a "switch" statement, which contained | | an "if" clause, which contained a | | "break," which was intended for | | the "if" clause, but instead broke from | | the "switch" statement. | | Again it looks like this bug wouldn't have occurred in another programming language. I can't resist saying that this last statement seems to me to be utter nonsense. What programming language (read, compiler) can read the programmer's mind and tell what he meant? The use of the "break" statement was a logic error (actually, it sounds like it was a lack of knowledge of the language, since "break" does not apply to "if"). I can't imagine a programming language that could discern this type of error. [If I use WHILE instead of IF, for instance, I can expect some things to work and some not. Yet I seriously doubt any compiler could possibly detect this error.] I certainly think programmers often choose an inappropriate language, but I shy away from anecdotal stories like these because they seem (to me) to spread a lot of misinformation. Unless you implement a project in multiple languages, it is nothing more than a guess to say what would have happened if the project had been implemented in some other language. Perhaps you would have discovered an even more serious flaw in that language, or you might simply find it was no better or worse than the one you chose, just different. Most of the stories I have heard along these lines all struck me as missing the point: how well was the program tested? Were there code reviews? Design reviews? All of these techniques are proven to reduce errors. Most of the errors in these stories (e.g., the infamous dot-versus-comma one) should have been found with even rudimentary testing. Use of an inappropriate language is no excuse for abandoning other techniques of good software engineering. -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.csd.harris.com or hcx1!bill@uunet.uu.net  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 26 Feb 90 16:37:37 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18350; 26 Feb 90 16:31 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA22586; Mon, 26 Feb 90 15:41:01 EST 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 Feb 90 17:42:53 GMT From: Jeff Dalton Organization: AIAI, University of Edinburgh, Scotland Subject: Re: Scheme and the Art of Programming Message-Id: <1844@skye.ed.ac.uk> References: <36655@iuvax.cs.indiana.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <36655@iuvax.cs.indiana.edu> harlan@silver.ucs.indiana.edu (Pete Harlan) writes: >concludes with a lovely set of exercises that has the student >implement Turing machines as a controller driven by an external >state-transition table. One could hardly imagine a more fitting >conclusion for a chapter on mutation! Humm. Turing machines are pretty boring, IMHO.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 26 Feb 90 14:11:37 EST Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa11037; 26 Feb 90 14:02 EST Received: from Fafnir.Think.COM by Think.COM; Mon, 26 Feb 90 14:02:48 -0500 Return-Path: Received: from verdi.think.com by fafnir.think.com; Mon, 26 Feb 90 14:01:37 EST Received: from joplin.think.com by verdi.think.com; Mon, 26 Feb 90 14:02:43 EST From: Guy Steele Received: by joplin.think.com; Mon, 26 Feb 90 14:02:14 EST Date: Mon, 26 Feb 90 14:02:14 EST Message-Id: <9002261902.AA01811@joplin.think.com> To: Scheme@lcs.mit.edu In-Reply-To: <9002221434.AA03515@schizo.samsung.com> Subject: first programming languages, and second ones too Date: Wed, 21 Feb 90 09:39:47 EDT >From: gjc@mitech.com There are more obvious practical and commercial advantages to knowing the language C rather than Pascal, so I would think students would be better served learning and using that language as a second language after Scheme. * with a reasonable ANSI compiler supporting prototypes, and especially one that supports a "require-prototypes" compilation flag, it seems you get about as much strict type checking out of a C program as out of an equivalent program in Pascal. Hm. And none of that nasty array-bounds checking that costs so many cycles. Much better to let machines crash or behave strangely. See, for example, the mailer buffer overflow bug recently discoverec at Stanford (ACM SIGSOFT Software Engineering Notes 15, 5, January 1990, page 7, item "Risks of Mail"). * C has more modern/natural I/O primitives, not the funny ancient mainframe O/S oriented stuff in standard Pascal. Double hm. You mean like "gets", which made possible parts of the Morris worm? ... --Guy :-)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 26 Feb 90 11:21:53 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02643; 26 Feb 90 11:12 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA01993; Mon, 26 Feb 90 10:09:51 EST 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 Feb 90 14:00:49 GMT From: Lennart Augustsson Organization: Dept. of CS, Chalmers, Sweden Subject: Re: Functional / algebraic languages for DS3100 Message-Id: <3417@undis.cs.chalmers.se> References: <90045.114639CMH117@psuvm.psu.edu>, <1990Feb14.190515.4402@ncsuvx.ncsu.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <1990Feb14.190515.4402@ncsuvx.ncsu.edu> jwb@cepmax.ncsu.edu writes: >Apparently NJML is soon to be released for the pmax. My >question is `Are there any (currently available) alternatives?' >By alternatives I mean a `modern' functional language with >disjoint union data constructors, pattern matching, etc. > Yes, there are alternativers (at leaast one). LML is available for pmax. You can get lml by (anonymous) ftp from skutt.cs.chalmers.se. It's in the file pub/lml-0.95a.tar.Z. Below is a short blurb on LML. There will be a new release of LML available in a few weeks, but only with minor differences. -- Lennart Augustsson New LML release (0.95) ====================== There is now a new version of the LML compiler available. It is, naturally, free of charge. The best way (both for us and for you) to get a copy is via anonumous ftp to skutt.cs.chalmers.se (129.16.2.7) where it is stored in pub/lml-0.95a.tar.Z. Uncompress, untar, install, and enjoy. If you don't have access to the Internet and you don't know anyone who has a copy of LML you can send us a tape or cartridge and we'll put LML on. This process takes time, since it involves tedious work for us. If you ftp a copy or get it from someone else, please send us (electronic) mail message and tell us so! It's nice to know who has it. The distribution take a lot of space. Around 15 Mbytes in the uncompressed version. This is because it includes binary files for a lot of machines, so most of this can be thrown way once you have unpacked it. This may very well be the last LML version ever! We hope that Haskell will take over soon. For those of you who have not heard of LML, here's a short introduction: LML is a strongly typed, lazy, purely functional language. The LML system consist of a compiler in the traditional batch-oriented sense. You give the compiler a file which it compiles and gives you an executable file. The compiler produces code that is reasonable enough to write "real" programs, such as the compiler itself. There are also some primitives for I/O that allows you to write simple real time programs. The compiler runs on a number of machines, but only under UNIX (so far). The machines and OS on which LML runs today are: SUN3 SunOS 3.5 SUN3 SunOS 4.0 Sequent Symmetry Dynix 3.0.12 Sequent Balance (this version has not been used for a while, but probably works) VAX BSD 4.3 IBM RT/PC BSD 4.3 CRAY XMP Unicos DECstation 3100 Ultrix SUN4 SunOs 4.0 The distribution contains binaries and source (in LML) for the compiler and some contributed programs, as well as some documentation. If you have any problems send us a mail. Lennart Augustsson Thomas Johnsson augustss@cs.chalmers.se johnsson@cs.chalmers.se Department of Computer Sciences Chalmers University of Technology S-412 96 Gothenburg Sweden -- -- Lennart Augustsson Email: augustss@cs.chalmers.se  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 26 Feb 90 03:41:22 EST Received: from [18.70.0.223] by mintaka.lcs.mit.edu id aa14852; 26 Feb 90 3:28 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA09198; Mon, 26 Feb 90 01:34:46 EST 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: 25 Feb 90 16:01:07 GMT From: shum.huji.ac.il!misha@ucbvax.berkeley.edu Organization: Hebrew University of Jerusalem, ISRAEL Subject: A Franz Lisp question. Message-Id: <660@shuldig.Huji.Ac.IL> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu As a novice to Franz Lisp, I have the following question: As you all might well know, Franz Lisp is a dynamic binding langauge, while Scheme is not. Therefore, the following code is unwriteable in Franz Lisp: (Scheme): (define (func param) (lambda (x) (param x))) [This function accepts a parameter which is also a function, and returns yet another function which 'apply's param on x.] Am I right? And if I am not, how is it done then? Thanks, Misha.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 25 Feb 90 16:39:17 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18008; 25 Feb 90 16:28 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA08161; Sun, 25 Feb 90 15:31:05 EST 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: 25 Feb 90 20:28:19 GMT From: Duke Briscoe Organization: Yale University Computer Science Dept, New Haven CT 06520-2158 Subject: Re: parallel multilisp? Message-Id: <17047@cs.yale.edu> References: <11300001@altair> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I posted this information just about a week ago, but here it is again. From masala.lcs.mit.edu (18.27.0.200) in the pub directory you can get a T dialect extended for parallelism (uses the future construct) called Mul-T; it runs on the Encore Multimax. In case you don't know, T is pretty similar to Scheme, and in fact T supports an environment which conforms to the Scheme standard.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 25 Feb 90 13:36:38 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa10137; 25 Feb 90 13:28 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA28871; Sun, 25 Feb 90 12:36:40 EST 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: 23 Feb 90 21:35:00 GMT From: deimos!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!auriga!altair!boyle@rutgers.edu Subject: parallel multilisp? Message-Id: <11300001@altair> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I'm not sure this is the best place to ask, but I'll do so anyway. Is there a parallel implementation of Multilisp available for the Encore, Sequent, or Alliant? If so, could someone please tell me how to obtain it? Jim Boyle boyle@mcs.anl.gov  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 24 Feb 90 03:52:54 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa01882; 24 Feb 90 3:46 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA07236; Sat, 24 Feb 90 02:55:45 EST 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: 24 Feb 90 07:46:56 GMT From: Jonathan Lee Organization: UC Berkeley Experimental Computing Facility (XCF) Subject: free Scheme interpreter Message-Id: <22377@pasteur.Berkeley.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Fools' lisp is a Scheme interpreter that follows all the RRRRS essentials and is reasonably small. It is written in C and Scheme. The design allows easy inclusion of new datatypes and primitives. It is available from scam.berkeley.edu (128.32.138.1) via anonymous ftp in src/local/fools.tar.Z (a compressed tar file, so remember to turn on binary mode). The interpreter runs on the following systems (it will probably run on any 4.3BSD based UNIX with little trouble): DECstation 3100 Ultrix 3.1 Sun3 and Sun4 SunOS 4.0.3 VAX Ultrix 3.1 and 4.3BSD Sequent Symmetry DYNIX(R) V3.0.12 Apollo DN3500 DomainOS Release 10.1 (bsd4.3) Let me know if you pick up a copy, and feel free to send me any comments. Thanks, Jonathan Lee (jonathan@scam.berkeley.edu)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 24 Feb 90 02:13:24 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa26768; 24 Feb 90 2:02 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA01286; Sat, 24 Feb 90 00:50:12 EST 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: 24 Feb 90 00:13:50 GMT From: Mark Brader Organization: SoftQuad Inc., Toronto Subject: Re: problems/risks due to programming language, stories requested Message-Id: <1990Feb24.001350.2617@sq.sq.com> References: <9790@medusa.cs.purdue.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Gerald Baumgartner (gb@cs.purdue.EDU) writes in many groups: > There is the famous story that a Mariner probe got lost > because of the Fortran statement `DO 3 I = 1.3' (1.3 instead > of 1,3) ... It is a nice story but, as far as I know, NASA used > Jovial at that time and not Fortran. Just for the record, the above was definitively shown to be fictional according to authoritative references given in comp.risks (= Risks Digest), issue 9.75 (I hear), not too many months ago. There is at least one textbook that states it as truth; this is wrong. The actual reason for the loss of Mariner I was an error in code used in recovering from a hardware failure; the code had been based on handwritten equations, and in transcribing one of these, an overbar was deleted from one letter. A story which may have been the true origin of the "DO statement myth" was posted fairly recently in alt.folklore.computers; the article cited a program at NASA that did enter production use with a dot-for-comma bug in a DO statement, but it wasn't a spacecraft flight control program. (I didn't save the details and would be happy to see them again.) Followups directed to alt.folklore.computers. -- Mark Brader "I'm not going to post a revision: even USENET utzoo!sq!msb, msb@sq.com readers can divide by 100." -- Brian Reid This article is in the public domain.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 24 Feb 90 00:47:38 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa22023; 24 Feb 90 0:37 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA26753; Fri, 23 Feb 90 23:24:30 EST 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: 23 Feb 90 23:08:29 GMT From: Joel Bartlett Organization: DEC Western Software Laboratory Subject: Scheme->C compiler available via FTP Message-Id: <2886@bacchus.dec.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu The Scheme-to-C compiler, Scheme->C, done at Digital Equipment Corporation's Western Research Laboratory is now available for public ftp. The compiler compiles Revised**3 Scheme to C that is then compiled by the native C compiler for the target machine. This design results in a portable system that allows either stand-alone Scheme programs or programs written in both compiled and interpreted Scheme and other languages. The Scheme->C system supports the essentials of Revised**3 and many of the optionals. Extensions include "expansion passing style" macros, a foreign function call capability, and interfaces to X11's Xlib. The system does provide call-with-current-continuation. Numbers are represented internally as 29-bit integers, or 64-bit floating point values. The compiler is written in Scheme. Most of the runtime system (including an interpreter) is written in Scheme. The generational compacting garbage collector and a few other things are written in C. There is a small (< 100 lines) amount of assembly code. The system is known to run on VAX's and DECstation 3100's running Ultrix. Other ports should be straightforward. The system is available for anonymous ftp from 'gatekeeper.dec.com' [16.1.0.2]. The Scheme->C files are in '/pub/DEC/Scheme-to-C'. Those files include: README - overview and copyright notice. 23feb90.tar.Z - compressed tar file containing all source and documentation. Joel Bartlett bartlett@decwrl.dec.com  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 24 Feb 90 00:11:44 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20248; 24 Feb 90 0:05 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA23585; Fri, 23 Feb 90 22:10:40 EST 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: 24 Feb 90 02:56:56 GMT From: Vincent Manis Organization: Bucky Bits Cereal Keyboards, Ltd. Subject: Re: first programming languages, and second ones too Message-Id: <6914@ubc-cs.UUCP> References: <9002221434.AA03515@schizo.samsung.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I don't want to get too far away from the purpose of this newsgroup, but I wouldn't recommend C as an immediate successor to Scheme in a SICP-based course. The major reasons are the convoluted syntax and the lack of reasonable response to run-time errors. I've taught courses using C at the second and third year levels for years, and I know for a fact that students find both of these almost insuperable. I am, however, in agreement with gjc that the right way to teach these languages is by having the students work on a Scheme evaluator. That's certainly what we had in mind. As for going directly to assembler: in our course, we won't be using the approach SICP uses to assembly language. We're going to introduce a fairly conventional hypothetical machine, and then explain its behaviour on the register transfer level. This seems more appropriate than the SIPC one in a course which is aimed at non-electrical engineers. -- \ Vincent Manis "There is no law that vulgarity and \ Department of Computer Science literary excellence cannot coexist." /\ University of British Columbia -- A. Trevor Hodge / \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 23 Feb 90 23:49:37 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18596; 23 Feb 90 23:41 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA21331; Fri, 23 Feb 90 21:12:39 EST 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: 23 Feb 90 09:55:48 GMT From: Kurt Normark Organization: Mathematics & Computer Science, University of Aalborg Subject: A Report on Object-oriented Programming in Scheme. Message-Id: <1990Feb23.095548.2764@iesd.auc.dk> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I use Abelson and Sussman's book "Structure and Interpretation of Computer Programs" in a course on Scheme and programming paradigms. One of the things I find particular interesting is the possibilities of simulating object-oriented mechanisms in Scheme. Unfortunately, the Abelson and Sussman book is relatively weak in the object-oriented area. I have written a report which introduces object-oriented programming in Scheme. It starts with the basics (in order to be pedagogical), but it also describes some more advanced topics such as multiple super classes, metaclasses, and procedural activation of methods. Some of the topics are inspired of existing literature (in particular Adams and Rees' paper "Object-oriented programming in Scheme", Lisp & Functional programming 88); other material is new (as far as I know). Seriously interested people can obtain a copy of the report (send me a message). The title and the table of contents of the report is listed below. Kurt Normark normark@iesd.auc.dk Kurt Normark: "SIMULATION OF OBJECT-ORIENTED CONCEPTS AND MECHANISMS IN SCHEME", R-90-1, Department of Mathematics and Computer Science, Institute of Electronic Systems, Aalborg University, Denmark. 1. Introduction 1.1 Scheme 1.2 Simulation 1.3 Related Work 1.4 Outline of this Report 2. Classes, Instances, and Message Passing 2.1 Classes and Instances 2.2 Message Passing 2.3 Procedural Activation of Methods 3. Class Hierarchies and Single Inheritance 3.1 The Introduction of super 3.2 Object Precedence Lists 3.3 Another Interpretation of self 4. Multiple Inheritance 4.1 A Simple Approach 4.2 Shared Object Parts 4.3 The Object Precedence List Representation 4.4 Method Combination 4.5 Caching of Effective Methods 5. Metaclasses 5.1 The pattern of Metaclasses 5.2 The most General Parts of the Class Hierarchy 5.3 Instantiation of Classes via Message Passing 5.4 Support of Metaprogramming 6. Conclusions  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 22 Feb 90 09:38:09 EST Received: from schizo.samsung.com by mintaka.lcs.mit.edu id aa04752; 22 Feb 90 9:34 EST Received: by schizo.samsung.com from mitech.UUCP via UUCP (vers 5.61+) for scheme@mc.lcs.mit.edu (from gjc@mitech.com) id ; Thu, 22 Feb 90 09:34:55 -0500 Message-Id: <9002221434.AA03515@schizo.samsung.com> Reply-To: gjc@mitech.com MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Received: by mitech.com (DECUS UUCP w/Smail); Wed, 21 Feb 90 09:39:47 EDT Date: Wed, 21 Feb 90 09:39:47 EDT From: gjc@mitech.com MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu To: scheme@mc.lcs.mit.edu Subject: first programming languages, and second ones too X-Vms-Mail-To: UUCP%"scheme@mc.lcs.mit.edu" There are more obvious practical and commercial advantages to knowing the language C rather than Pascal, so I would think students would be better served learning and using that language as a second language after Scheme. * with a reasonable ANSI compiler supporting prototypes, and especially one that supports a "require-prototypes" compilation flag, it seems you get about as much strict type checking out of a C program as out of an equivalent program in Pascal. * C has more modern/natural I/O primitives, not the funny ancient mainframe O/S oriented stuff in standard Pascal. * you can build up complex programs and datastructures from "the bits" and abstract upwards in the same way you learn in lisp programming. Obviously just about any language lets you do this; I'm just arguing that it is rather natural and similar in lisp and C. * one could introduce/motivate C near the end of a course (e.g. Chapter 5, SICP) with a small C program that implements Scheme, such as SIOD. On the other hand, after SICP, especially chapter 5, one could argue more strongly that it would be more natural to cover a reasonable assembly language programming machine environment in more detail rather than go for something artificial like a so-called high-level language. I had one student at Boston University that got into CADR microcode after his lisp course. -gjc  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 21 Feb 90 23:32:23 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa06962; 21 Feb 90 23:25 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA09114; Wed, 21 Feb 90 22:21:58 EST 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: 22 Feb 90 02:51:38 GMT From: Pete Harlan Organization: Indiana University, Bloomington Subject: Scheme and the Art of Programming Message-Id: <36655@iuvax.cs.indiana.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu manis@cs.ubc.ca (Vincent Manis) writes: >The classical way to introduce computer science via Scheme is Abelson >and Sussman's `Structure and Interpretation of Computer Programs', >published by MIT Press/McGraw-Hill. Paradoxically, this book is not >about Scheme, and hardly mentions it. Instead, the book concentrates >upon fundamental principles of computer science, paradigms of program >design, and the structures of various evaluators, including interpreters >and compilers for Scheme. The goal isn't so much to have the student be >a good Scheme programmer, as to be able to understand the principles >behind programming and computers. And now of course there is also Springer and Friedman's _Scheme and the Art of Programming_, also published by MIT Press/McGraw-Hill. The difference between these two excellent books is best summed up I think in the difference between their titles. For a study of programming language issues I would prefer Abelson and Sussman, and for learning the elements of programming I would prefer Springer and Friedman. The early sections of the book provide a beautiful development of recursion/iteration and data abstraction. This is followed by an amazing two chapters on higher-order procedures that completes the development of "how to write programs". In this way the first ~250 pages of the book prepare the student for the topics in the final ~350 pages. Part 3, Managing State, begins with a functional view of vectors, and then introduces the reader to mutation by showing the efficiency gained through mutable vectors vs. functional ones. The two views of vectors are then compared throughout the discussion of sorting techniques. The following section on mutation presents not only the use of mutation the way it is typically used in Scheme (eg, memoization), but also includes a section on imperative-style programming. The chapter concludes with a lovely set of exercises that has the student implement Turing machines as a controller driven by an external state-transition table. One could hardly imagine a more fitting conclusion for a chapter on mutation! Having given the reader the ability to mutate data, the book then presents a controllable use for such ability with object-oriented programming. Objects are then used to introduce the basic abstract data structures (accumulators, stacks, queues, buckets and hash tables) while showing how they incorporate elements of each other. This is followed by an extended OOP example, a gas-station simulation that finishes the section on managing state. To be fair, I must say I thought this simulation got a little bogged down -- spread over so many pages, it requires a diligent reader to follow the discussion. A section on syntactic extension comes next, catering to both the traditional "macro" declaration and extend-syntax. Having gained the power to declare special forms, the book defines streams, developing recursive data, and ends with an extended example for reformatting a text file using filters. "Control" is the title of Part 5, the last section of the book. This is a thorough development of the nature of run-time control, and the capturing of run-time control through the use of call/cc. The first chapter develops call/cc, and the second chapter uses it to implement coroutines. While the development is careful and the examples lucid, some of the exercises here are treacherous indeed! Overall, the book is an excellent introduction to computer programming and computer science, with excursions into specific areas to provide applications of what is being learned. Having read it cover-to-cover, I couldn't recommend it more highly as a first computer-science text. Pete Harlan Indiana University harlan@silver.ucs.indiana.edu Disclaimer: I am being as objective as I can about a book I fell in love with while reading. The authors of the book are on faculty here, but should you doubt my review of the book, _read_ it! I learned Scheme from _Structure and Interpretation of Computer Programs_, and have similar accolades for it as a book about interpretation models. Where the two books overlap, it is a tossup -- Abelson/Sussman favors the advanced programmer, while Springer/Friedman favors the development of technique.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 21 Feb 90 22:32:40 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa04624; 21 Feb 90 22:27 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA06534; Wed, 21 Feb 90 21:33:59 EST 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: 21 Feb 90 23:39:00 GMT From: CARLETON.EDU!RKIRCHNE@bloom-beacon.mit.edu Organization: The Internet Subject: RE: Scheme Digest #307 Message-Id: <9002211840.aa24798@mintaka.lcs.mit.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Can I unsubscribe from the Digest and resubscribe to get the original messages? Thanks. Roger Kirchner  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU; 21 Feb 90 21:04:52 EST Date: Wed, 21 Feb 90 21:04:55 EST From: Devon Sean McCullough Subject: Sun4 Scheme To: comp.lang.scheme@EDDIE.MIT.EDU, scheme@MC.LCS.MIT.EDU cc: DEVON%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU reply-to: devon@ai.ai.mit.edu Message-ID: <703508.900221.DEVON@AI.AI.MIT.EDU> Do you know of a commercial Scheme with a good compiler for Sun's sparc? I told <> to imbed Scheme in their <> but they want commercial support.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 21 Feb 90 18:58:31 EST Received: from tirith.carleton.edu by mintaka.lcs.mit.edu id aa24798; 21 Feb 90 18:40 EST Date: Wed, 21 Feb 90 17:39 CST From: RKIRCHNE@carleton.edu Subject: RE: Scheme Digest #307 To: Scheme@MINTAKA.LCS.MIT.EDU X-VMS-To: IN%"Scheme@XX.LCS.MIT.EDU" Message-ID: <9002211840.aa24798@mintaka.lcs.mit.edu> Can I unsubscribe from the Digest and resubscribe to get the original messages? Thanks. Roger Kirchner  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 21 Feb 90 10:46:35 EST Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa02376; 21 Feb 90 10:35 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 5742; Wed, 21 Feb 90 10:35:23 EST Received: from DB0TUI6.BITNET (NET) by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 3979; Wed, 21 Feb 90 10:35:22 EST Received: by tub.UUCP; Wed, 21 Feb 90 13:12:38 +0100; AA08829 Date: Wed, 21 Feb 90 13:12:38 +0100 From: Oliver Laumann Message-Id: <9002211212.AA08829@tub.UUCP> To: scheme@mc.lcs.mit.edu Subject: syntax question [Warning: this message is not about #f and '()] I would like to know how something like foo'bar or foo`bar should be tokenized by a Scheme parser. That is, is it parsed as a single token, or are quote and backquote regarded as delimiters? I think the formal syntax description in the R^3.99RS is not particularly clear on this point. It says "[identifiers] may be terminated by any , but not necessarily by anything else". However, quote and backquote are not listed in the rule for . Regards, -- Oliver Laumann net@TUB.BITNET net@tub.cs.tu-berlin.de net@tub.UUCP  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Feb 90 22:32:34 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa12732; 20 Feb 90 22:28 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA04906; Tue, 20 Feb 90 21:01:43 EST 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: 20 Feb 90 23:54:56 GMT From: Dorai Sitaram Organization: Rice University, Houston Subject: Re: comp.lang.functional Message-Id: <5144@brazos.Rice.edu> References: <1619@husc6.harvard.edu>, <1797@skye.ed.ac.uk> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu In article <1797@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes: >In article <1619@husc6.harvard.edu> carlton@husc4.harvard.edu (david carlton) writes: >> >>What do people think about creating a comp.lang.functional news groups, for >>the discussion of functional programming languages? > >I'm in favor. Indeed, I was surprised that there wasn't such a group >already. The only problem would be if we later wanted a ML group, >say. Should it have to be comp.lang.functional.ml? I'm tentatively in favor too; however, "functional" is about the most ambivalent, and consequently useless, term in programming languages. The two common (often incompatible) views seem to be i) A language which has higher-order functions; ii) Ditto, but which very definitely eschews "assignment." In apparent contrast, "imperative" languages support "assignment," and are perceived oftentimes, why, I don't know, as definitely having no higher-order functions (procedures). Thus we have the paradox of Scheme and ML being both "imperative" ("non-functional," taking definition ii)) as well as "functional" (taking definition i)). It may be we should choose another name. --dorai -- ------------------------------------------------------------------------------- It may be that the gulfs will wash us down; It may be we shall touch the Happy Isles. -------------------------------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Feb 90 21:03:04 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa09613; 20 Feb 90 20:53 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA01094; Tue, 20 Feb 90 19:41:42 EST 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: 20 Feb 90 22:28:57 GMT From: Gerald Baumgartner Organization: Department of Computer Science, Purdue University Subject: problems/risks due to programming language, stories requested Message-Id: <9790@medusa.cs.purdue.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu For a research project I am collecting information about the risk of choosing the wrong programming language. In particular I am looking for problems that could have been avoided if another (a better) programming language would have been used. I know of these three such stories: 1. There is the famous story that a Mariner probe got lost because of the Fortran statement `DO 3 I = 1.3' (1.3 instead of 1,3) (see Peter Neumann: A Few Old War Stories Reappear. ACM SIGSOFT 11(5), Oct. 1986, pp. 16-18). It is a nice story but, as far as I know, NASA used Jovial at that time and not Fortran. 2. One of the security holes the Internet Worm took advantage of was in fingerd (the finger deamon). The deamon uses the gets routine for input. This routine, written in C, reads input without checking for bounds on the buffer involved. By overrunning the buffer, the worm rewrote the stack frame (see Eugene H. Spafford: Crisis and Aftermath. Communications of the ACM 32(6), June 1989). There would be no security hole in the finger daemon if a programming language would have been used for the I/O routines, where the compiler takes care of boundary checks for arrays. Pascal doesn't work since variable length strings are needed, but Ada would be fine. A language a la ML, where these checks are done at compile time, would be even better. 3. The AT&T breakdown a month ago was caused by a break statement in C. See the following mail (multiple forwarding headers deleted): Subject: AT&T software problem Subject: Cautionary note on C programming...AT&T learns from experience >From: kent@wsl.dec.com Subj: I've always thought C looked like line noise. Subj: the bug Subj: AT&T's bug, for you C users out there... Subj: I C what they mean! Subj: "c" considered dangerous to telephones Subj: Be careful from where you break! (else no long distance calls will make it thru...) Subj: C switch breaks AT&T switches! Subj: your "c users" list might appreciate this.... I received the following on AT&T's famous bug (and have deleted multiple forwarding headers): | | Subject: AT&T Bug | | Date: Fri Jan 19 12:18:33 1990 | | | | This is the bug that cause the AT&T breakdown | | the other day (no, it wasn't an MCI virus): | | | | In the switching software (written in C), there was a long | | "do . . . while" construct, which contained | | a "switch" statement, which contained | | an "if" clause, which contained a | | "break," which was intended for | | the "if" clause, but instead broke from | | the "switch" statement. | | Again it looks like this bug wouldn't have occurred in another programming language. You C what I mean? Do you know other stories like these, if possible with references? I don't want to praise Ada or pick at C and Fortran; I am looking for any story where a proveably inappropriate/insecure programming language has been used. Gerald Baumgartner gb@cs.purdue.edu ...!{decwrl,gatech,ucbvax}!purdue!gb  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Feb 90 17:25:33 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa01803; 20 Feb 90 17:21 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA24583; Tue, 20 Feb 90 14:55:37 EST 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: 20 Feb 90 19:20:31 GMT From: Vincent Manis Organization: Bucky Bits Cereal Keyboards, Ltd. Subject: Re: Scheme as 1st language Message-Id: <6835@ubc-cs.UUCP> References: <9002200317.aa29279@mintaka.lcs.mit.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu The classical way to introduce computer science via Scheme is Abelson and Sussman's `Structure and Interpretation of Computer Programs', published by MIT Press/McGraw-Hill. Paradoxically, this book is not about Scheme, and hardly mentions it. Instead, the book concentrates upon fundamental principles of computer science, paradigms of program design, and the structures of various evaluators, including interpreters and compilers for Scheme. The goal isn't so much to have the student be a good Scheme programmer, as to be able to understand the principles behind programming and computers. About 2 years ago, I posted a similar query to this newsgroup. I received responses from, among others, MIT, UCLA, UC Berkeley, Brandeis, the University of Delaware, and Indiana. As a result of these highly positive responses, we at the University of British Columbia decided to move our first year computer science courses to this curriculum. We've been teaching a prototype section this year, and it has gone quite well (we've learned lots of things *not* to do, too!). We propose to do what is done in one term at MIT in two terms here (our students are good, but not as good as MIT students). We will, however, add a final unit, which introduces Pascal. We are doing this for pragmatic reasons (a knowledge of Pascal is useful in further computer science), and for intellectual ones (Pascal takes a rather different--I would say ``inferior''--view of types from that which Scheme takes, as the Instructor's Guide to Abelson & Sussman points out). Naturally, the laboratory project for that part of the course will be to write a Scheme evaluator in Pascal. In answer to the question which was posed, I don't support using Scheme as a replacement for Pascal in an introductory programming course. What is needed instead is to replace introductory programming by introductory computer science; Scheme is an excellent vehicle for that. -- \ Vincent Manis "There is no law that vulgarity and \ Department of Computer Science literary excellence cannot coexist." /\ University of British Columbia -- A. Trevor Hodge / \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Feb 90 03:46:58 EST Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa29279; 20 Feb 90 3:17 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 1633; Tue, 20 Feb 90 03:16:51 EST Received: from IRUCCIBM.BITNET by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 4673; Tue, 20 Feb 90 03:16:50 EST Received: from IRUCCVAX.UCC.IE (STCS8004) by IRUCCIBM.BITNET (Mailer R2.05) with BSMTP id 6094; Fri, 16 Feb 90 09:45:17 IST Date: Thu, 15 Feb 90 14:52 GMT From: STCS8004%IRUCCVAX.UCC.IE@mitvma.mit.edu Subject: Scheme as 1st language To: SCHEME@MC.lcs.mit.edu X-VMS-To: SCHEME Message-ID: <9002200317.aa29279@mintaka.lcs.mit.edu> I am soliciting the community's views regarding the choice of Scheme as the first programming language to be taught to students majoring in Computer Science. The Department of Computer Science at University College Cork, Ireland is undertaking a major restructuring of its Honours Degree program in the Faculties of Arts and of Science and the question has arisen whether or not the time given to Pascal would be better utilized in some other way, such as algorithm design and analysis, for instance. We presently teach the full standard Pascal to our first-year students in a course of 52 lectures over 26 weeks, plus the usual tutorial/practical sessions. There is also a 1 hour per week course of lectures on non-Pascal intro- ductory Computer Science topics. I would be interested to receive views on the what the first programming language should be, and to learn of the experiences---good or bad---of those who have switched away from Pascal to something else. We presently use Scheme extensively in our 'Data Structures' and 'Compiler Theory and Practice' courses with great success, the students being largely self-taught Scheme through Friedman and Felleisen's 'The Little LISPer'. It is seeing how much quicker students can understand, analyze, and undertake proofs of correctness of the relevant algorithms expressed in Scheme that prompts the consideration of using some form of small non-trivial functional programming language at an earlier stage in their education. I consider that the fundamentals of algorithm design and programming style should be taught with the minimum of syntactic baggage, and only then should a study of alternative programming languages and styles be undertaken---but what are your views, please? G. Oulsnam.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Feb 90 03:35:00 EST Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa29302; 20 Feb 90 3:17 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 1634; Tue, 20 Feb 90 03:17:10 EST Received: from IRUCCIBM.BITNET by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 4675; Tue, 20 Feb 90 03:17:09 EST Received: from IRUCCVAX.UCC.IE (STCS8004) by IRUCCIBM.BITNET (Mailer R2.05) with BSMTP id 6789; Mon, 19 Feb 90 09:38:34 IST Date: Mon, 19 Feb 90 09:40 GMT From: STCS8004%IRUCCVAX.UCC.IE@mitvma.mit.edu Subject: Scheme as 1st language To: SCHEME@MC.lcs.mit.edu X-VMS-To: SCHEME Message-ID: <9002200317.aa29302@mintaka.lcs.mit.edu> I am soliciting the community's views regarding the choice of Scheme as the first programming language to be taught to students majoring in Computer Science. The Department of Computer Science at University College Cork, Ireland is undertaking a major restructuring of its Honours Degree program in the Faculties of Arts and of Science and the question has arisen whether or not the time given to Pascal would be better utilized in some other way, such as algorithm design and analysis, for instance. We presently teach the full standard Pascal to our first-year students in a course of 52 lectures over 26 weeks, plus the usual tutorial/practical sessions. There is also a 1 hour per week course of lectures on non-Pascal intro- ductory Computer Science topics. I would be interested to receive views on the what the first programming language should be, and to learn of the experiences---good or bad---of those who have switched away from Pascal to something else. We presently use Scheme extensively in our 'Data Structures' and 'Compiler Theory and Practice' courses with great success, the students being largely self-taught Scheme through Friedman and Felleisen's 'The Little LISPer'. It is seeing how much quicker students can understand, analyze, and undertake proofs of correctness of the relevant algorithms expressed in Scheme that prompts the consideration of using some form of small non-trivial functional programming language at an earlier stage in their education. I consider that the fundamentals of algorithm design and programming style should be taught with the minimum of syntactic baggage, and only then should a study of alternative programming languages and styles be undertaken---but what are your views, please? G. Oulsnam.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 19 Feb 90 23:25:38 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21315; 19 Feb 90 23:20 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA07677; Mon, 19 Feb 90 21:45:32 EST 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: 20 Feb 90 00:55:37 GMT From: Jason Coughlin Organization: Clarkson University, Potsdam, NY Subject: Boxes -- what exactly are these? Message-Id: <1990Feb20.005537.25572@sun.soe.clarkson.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I saw an implementation of boxes that looks like this: (define box (lambda (x) (cons x #f))) (define unbox (lambda (x) (car x))) (define set-box! (lambda (x v) (set-car! x v))) Is the point akin to a pointer in C? ie, so you could have args that "changed" (call by variable)? Is this an OK defn of boxes? -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 19 Feb 90 06:46:31 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa14039; 19 Feb 90 6:34 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA25568; Mon, 19 Feb 90 05:46:39 EST 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: 19 Feb 90 03:28:24 GMT From: "Mohd Hanafiah b. Abdullah" Organization: MIMOS, Malaysia Subject: Public domain SCHEME. Message-Id: <233@rangkom.MY> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Could anyone please inform me of how to get source code for the SCHEME programming language. I prefer to have the source, but binaries for the VAX, Convex, Apollo, or Sun III is fine. Thank you very much. Mohd Hanafiah Abdullah.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 19 Feb 90 05:22:31 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa12146; 19 Feb 90 5:21 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA24691; Mon, 19 Feb 90 05:18:18 EST 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: 14 Feb 90 15:30:27 GMT From: Douglas K Pierce Organization: Michigan State University, Computer Science Department Subject: Need brief documentation of extend-syntax Message-Id: <6451@cps3xx.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I am interested in developing macros and special forms in PC Scheme that will simplify the porting of source code between Scheme and Common Lisp. I have already had some success with this, using the extend-syntax source file bundled with TI PC Scheme. However, the documentation for this is practically nil. I know there is a book, I believe by Dybvig (sp?), that covers this topic, and hope to purchase it someday. For now, though, I am looking for some brief documentation on extend-syntax that will take me farther than I have been able to get on my own. For example, I know there is a 'with' form, but have no idea what it can be used for. Anything at all would be more than I have now. Thanks much for anything! Also, if there are others working on this type of project, I would be interested in corresponding. And a big *thank you* to whoever started this Scheme newsgroup! Doug Pierce AI/KBS Lab Michigan State  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 17 Feb 90 08:39:08 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20911; 17 Feb 90 8:33 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA09283; Sat, 17 Feb 90 07:22:18 EST 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: 16 Feb 90 22:22:54 GMT From: Mac Michaels Organization: MCC CAD Program, Austin, Texas Subject: Will macros be defined in r4rs? Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I have been comparing Scheme (thanks again to all who helped me find r3rs) and Common Lisp. On page 37 I discovered that macros were not defined in Scheme yet. Is it likely that macros will be defined in r4rs? -- USPS: Mac Michaels, 3500 West Balcones Center Dr., Austin,TX 78759 ARPA: mac@mcc.com UUCP: {uunet,harvard,gatech,pyramid}!cs.utexas.edu!milano!cadillac!mac :-)))))))) She had so many chins, she looked like a piece of Lisp code!  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 16 Feb 90 13:44:21 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20487; 16 Feb 90 5:57 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA14416; Fri, 16 Feb 90 03:51:06 EST 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: 15 Feb 90 12:26:08 GMT From: Gilles Kahn Organization: INRIA, Sophia-Antipolis (Fr) Subject: Lisp and Functional Programming Conference '90 (very long) Message-Id: <540@mirsa.inria.fr> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu 1990 Lisp and Functional Programming Conference Advance Program Nice, France, June 27--29, 1990 A conference jointly sponsored by the ACM Special Interest Groups SIGPLAN, SIGACT and SIGART, in cooperation with SIGSAM. The conference is organized in France in cooperation with INRIA. Tuesday, June 26th 05:00--06:30 pm Conference Registration 05:00--06:30 pm Reception Wednesday, June 27th 09:00--10:30 Session 1: Chaired by Christopher T. Haynes, Indiana University Andrew P. Tolmach and Andrew W. Appel, Princeton University Debugging Standard ML Without Reverse Engineering Pavel Curtis, Xerox PARC, and James Rauen, MIT A Module System for Scheme Mark A. Sheldon and David K. Gifford, MIT Static Dependent Types for First Class Modules 11:00--12:30 Session 2: Chaired by Pierre-Louis Curien, ENS Paris Luca Cardelli, DEC SRC, and Giuseppe Longo, University of Pisa and LIENS A Semantic Basis for Quest V. Breazu-Tannen, C. A. Gunter, A. Scedrov, University of Pennsylvania Computing with Coercions Philip Wadler, University of Glasgow Comprehending Monads 02:00--03:30 Session 3: Chaired by Robert Kessler, University of Utah Douglas Johnson, Texas Instruments Trap Architectures for Lisp Systems Benjamin Zorn, Berkeley Comparing Mark-and-Sweep and Stop-and-Copy Garbage Collection Gregor Kiczales, Xerox PARC, and Luis Rodriguez, MIT Efficient Method Dispatch in PCL 04:00--06:00 Session 4: Chaired by Hal Abelson, MIT Chris Hanson, MIT Efficient Stack Allocation for Tail-Recursive Languages Marc Feeley and James S. Miller, Brandeis University A Parallel Virtual Machine for Efficient Scheme Compilation Clifford Walinsky and Deb Banerjee, Dartmouth College A Functional Programming Language Compiler for Massively Parallel Computers Andrew Berlin, MIT Partial Evaluation Applied to Numerical Computation Thursday, June 28th 09:00--10:30 Session 5: Chaired by Hans-J. Boehm, Xerox PARC Olivier Danvy, Indiana University, and Andrzej Filinski, Carnegie-Mellon Abstracting Control Dorai Sitaram and Matthias Felleisen, Rice University Reasoning with Continuations II: How to Get Full Abstraction for Models of Control Morry Katz and Daniel Weise, Stanford University Continuing Into the Future: On the Interaction of Futures and First-Class Continuations 11:00--12:30 Session 6: Chaired by John Foderaro, Franz, Inc. E. Mohr, Yale University, D. A. Kranz, MIT, and R. H. Halstead Jr., DEC CRL Lazy Task Creation: A Technique for Increasing the Granularity of Parallel Programs Randy B. Osborne, DEC CRL Speculative Computation in Multilisp J.F. Giorgi and D. Le M\'etayer, IRISA/INRIA Continuation-Based Parallel Implementation of Functional Programming Languages 02:00--03:30 Session 7: Chaired by Paul Hudak, Yale University Henry G. Baker, Nimble Computer Corporation Unify and Conquer (Garbage, Updating, Aliasing, ...) in Functional Languages G.L. Burn, Imperial College Using Projection Analysis in Compiling Lazy Functional Programs M. Draghicescu and S. Purushothaman, Pennsylvania State University A Compositional Analysis of Evaluation-order and Its Application 04:00--05:30 Session 8: Chaired by Simon Peyton-Jones, University of Glasgow Hanne Riis Nielson and Flemming Nielson, Aarhus University Context Information for Lazy Code Generation Charles Consel, Yale University Binding Time Analysis for Higher Order Untyped Functional Languages Laurence Puel, LIENS and DEC PRL, and Ascander Suarez, DEC PRL Compiling Pattern Matching by Term Decomposition Friday, June 29th 08:30--10:00 Session 9: Chaired by Mitchell Wand, Northeastern University Carsten K. Gomard, University of Copenhagen Partial Type Inference for Untyped Functional Programs Daniel Leivant, Carnegie Mellon University Discrete Polymorphism Brian T. Howard and John C. Mitchell, Stanford University Operational and Axiomatic Semantics of PCF 10:30--12:30 Session 10: Chaired by Ken McAloon, Brooklyn College John Field and Tim Teitelbaum, Cornell University Incremental Reduction in the Lambda Calculus John Hannan and Dale Miller, University of Pennsylvania From Operational Semantics to Abstract Machines: Preliminary Results P. Cregut, LIENS-CNRS An Abstract Machine for Lambda-Terms Normalization Gopalan Nadathur and Debra Sue Wilson, Duke University A Representation of Lambda Terms Suitable for Operations on their Intensions CONFERENCE INFORMATION The 1990 ACM Lisp and Functional Programming Conference will be held in the Acropolis Convention Center, in Nice, France. Palais des Congres 1, Esplanade Kennedy 06012 NICE Tel. (33) 93.92.80.80 Nice has a major international airport located less than two miles from the downtown area, with frequent buses. It is possible to fly direct to Nice from North America and from most capitals in Europe. Advance registration for the Conference is highly recommended. If you wish to receive a latex copy of the conference leaflet, with Registration Form and Hotel Reservation Form, send a request to kahn@mirsa.inria.fr.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 16 Feb 90 13:28:27 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20485; 16 Feb 90 5:57 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA16504; Fri, 16 Feb 90 04:45:50 EST 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: 15 Feb 90 20:41:39 GMT From: Mac Michaels Organization: MCC CAD Program, Austin, Texas Subject: Need Scheme R3RS Spec. Message-Id: Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu I have been watching this group for a couple of weeks now hoping to see a hint to answer a question that is probably common knowledge. I am analyzing Scheme and Common Lisp to try to determine which will best suit the needs of the Computer Aided Engineering (CAE) community. I need to get a copy of the Scheme R3RS specification. Where is a location that has it available for anonymous ftp or someone who can email it to me? Please contact me before emailing as I don't want to waste internet bandwidth getting many copies. I am also interested in the R4RS draft if it is available. -- USPS: Mac Michaels, 3500 West Balcones Center Dr., Austin,TX 78759 ARPA: mac@mcc.com UUCP: {uunet,harvard,gatech,pyramid}!cs.utexas.edu!milano!cadillac!mac :-)))))))) She had so many chins, she looked like a piece of Lisp code!  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Feb 90 14:39:24 EST Received: from SUN3-GW.CS.YALE.EDU by mintaka.lcs.mit.edu id aa13771; 15 Feb 90 14:38 EST Received: by NEBULA.SUN3.CS.YALE.EDU; Thu, 15 Feb 90 14:24:38 EST From: Duke Briscoe Full-Name: Duke Briscoe Message-Id: <9002151924.AA28390@NEBULA.SUN3.CS.YALE.EDU> Received: by yale-sun3-nebula (pullback) via WIMP-MAIL (Version 1.3/1.6) ; Thu Feb 15 14:33:15 Date: Thu, 15 Feb 90 14:33:14 EST Subject: re: address for ftping T To: scheme@mc.lcs.mit.edu It has come to my attention that some people have trouble with the hostname TRIX.AI.MIT.EDU. That is where my earlier note said the T files are available for anonymous ftp. The numeric Internet address for trix is 128.52.32.6. You could also try wheaties.ai.mit.edu which also has the files. I think peoples host tables are more likely to have wheaties than trix, so wheaties may work for you while trix wouldn't. In fact, this was true for my own workstation. Duke -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Feb 90 10:23:09 EST Received: from SUN3-GW.CS.YALE.EDU by mintaka.lcs.mit.edu id aa01564; 15 Feb 90 10:20 EST Received: by NEBULA.SUN3.CS.YALE.EDU; Thu, 15 Feb 90 10:10:03 EST From: Duke Briscoe Full-Name: Duke Briscoe Message-Id: <9002151510.AA26799@NEBULA.SUN3.CS.YALE.EDU> Received: by yale-sun3-nebula (pullback) via WIMP-MAIL (Version 1.3/1.6) ; Thu Feb 15 10:18:38 Date: Thu, 15 Feb 90 10:18:37 EST Subject: re: Functional / algebraic languages for DS3100 To: scheme@mc.lcs.mit.edu John Baugh writes: >Apparently NJML is soon to be released for the pmax. My >question is `Are there any (currently available) alternatives?' >By alternatives I mean a `modern' functional language with >disjoint union data constructors, pattern matching, etc. >I heard that a scheme-based interpreter exists for Haskell--is >that true? If so, would it run on T (using the scheme mode)? The Yale Haskell system is planned to be released in a few weeks. It compiles Haskell to T, which then can be compiled by the T Orbit compiler. The Yale Haskell system is not an interpreter, but we are working on a user interface which will allow something similar to a read-eval-print loop. Actually, it will be more of a read-(compile Haskell to T)-run-print loop. T's scheme-mode has nothing to do with Haskell, although you could interface T code or T scheme-mode code to Haskell code. You could even make use of the T Unix/C foreign function interface. I think someone at Yale has recently linked some of the X window system into T, although I haven't seen it running. We'll announce the Haskell release to this list when it is ready in a few weeks. It will be available by anonymous ftp. Duke -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Feb 90 10:12:02 EST Received: from SUN3-GW.CS.YALE.EDU by mintaka.lcs.mit.edu id aa00770; 15 Feb 90 10:01 EST Received: by NEBULA.SUN3.CS.YALE.EDU; Thu, 15 Feb 90 09:49:55 EST From: Duke Briscoe Full-Name: Duke Briscoe Message-Id: <9002151449.AA26625@NEBULA.SUN3.CS.YALE.EDU> Received: by yale-sun3-nebula (pullback) via WIMP-MAIL (Version 1.3/1.6) ; Thu Feb 15 09:58:30 Date: Thu, 15 Feb 90 09:58:28 EST Subject: Re: Fast Scheme for Suns? To: scheme@mc.lcs.mit.edu The T language includes an environment for Scheme, and from my experience I judge it to be at least 99% conformant to the Scheme standard, and there isn't any performance penalty for using T to run Scheme since the Scheme environment just allows a different set of names to be used for the underlying T functions. T also provides some useful extensions to Scheme. T has an optimizing compiler, and best of all it is available by anonymous ftp from trix.ai.mit.edu in the pub/t3.1 directory. That directory contains binaries and sources for T3.1. Currently available versions are for Dec3100(pmax), Sun4(sparc),Sun3, Vax/Unix, Encore, Hp workstation, Apollo and Mac/Aux. The online version of the T manual is also there as well as release notes for T3.0 and T3.1. For Sun and Vax there is a C/Unix interface to T. From masala.lcs.mit.edu you can get a T dialect extended for parallelism (uses the future construct) called Mul-T; it runs on the Encore Multimax. -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Feb 90 03:25:53 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18433; 15 Feb 90 3:22 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA25868; Thu, 15 Feb 90 02:44:48 EST 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: 14 Feb 90 21:03:21 GMT From: Steve Ritacco Organization: Hewlett Packard - Boise, ID Subject: Scheme docs in PostScript? Message-Id: <17020001@hpdml93.HP.COM> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu Hi, I have built the 7.0 Scheme system for my machine, but I'm having trouble creating the documentation. Does anyone have a PostScript version I could just print out? This would save me a major headache. Thanks  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Feb 90 03:25:29 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18385; 15 Feb 90 3:20 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA23042; Thu, 15 Feb 90 01:39:45 EST 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: 15 Feb 90 06:12:11 GMT From: Hurley Braden Organization: University of California, Berkeley Subject: I need a Scheme Message-Id: <1990Feb15.061211.6113@agate.berkeley.edu> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu < eat me > Howdy, I was wondering if anyone out there knows if there is a Scheme for the Amiga (brand tm, copyright etc ...). Oh, and since I am a lowly student (read poor (strike that very poor)) I was wondering if there is a PD version hanging around somewhere. thanks in advance. Hurley. "Me against the Universe," I said. "With those odds, even a loser can look good."  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Feb 90 03:08:32 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa17756; 15 Feb 90 3:04 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA21948; Thu, 15 Feb 90 01:09:02 EST 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: 14 Feb 90 23:05:36 GMT From: Jordan Bortz Subject: XSCHEME Status? Message-Id: <16174@well.sf.ca.us> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Can someone please fill me in on the status of XSCHEME? Is it available for the Mac? What about for those of us without anon FTP? Thanks, Jordan -- *********************************************************************** * Jordan A. Bortz, Higher Level Software, Santa Cruz, CA * * well!frobozz frobozz@well.sf.ca.us 408 - 476 - 8464 * ***********************************************************************  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Feb 90 01:38:34 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa14822; 15 Feb 90 1:33 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA16635; Wed, 14 Feb 90 23:13:22 EST 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: 15 Feb 90 02:49:13 GMT From: Vincent Manis Organization: Bucky Bits Cereal Keyboards, Ltd. Subject: Re: Fast Scheme for Suns? Message-Id: <6784@ubc-cs.UUCP> References: <2399@randvax.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <2399@randvax.UUCP> leverich@rand.org (Brian Leverich) writes: >Anybody have any experience with a Scheme that will run on Sun UNIX >boxes? Ideally I'd like a Scheme that is public domain, high optimized, >and compatible with PC-Scheme, but I'll take whatever is available. We have been using Chez Scheme, a commercial product which runs on Apollo DN3000/3500's, Sun-3's (I don't remember if it runs on Sun-4's), and VAXen. It is an outstanding system, comprising a very high-performance compiler and a complete language implementation. It isn't very expensive (I don't have the price list at hand, but it runs about US$1K per copy, with site licencing at about $10K, and educational discounts of 50%), but it's an excellent value. The publisher is Cadence Research, in Bloomington, Indiana. Sorry, but I also don't have Cadence's address at hand, but you can email to Kent Dybvig for more information. -- \ Vincent Manis "There is no law that vulgarity and \ Department of Computer Science literary excellence cannot coexist." /\ University of British Columbia -- A. Trevor Hodge / \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Feb 90 19:26:36 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa01958; 14 Feb 90 19:21 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA13048; Wed, 14 Feb 90 09:43:05 EST 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: 14 Feb 90 09:21:13 GMT From: Eric Ho Organization: Cognitive Science Lab. Princeton University. Subject: David Betz's email address ? Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Has anyone got David Betz's email address handy ? Any pointers appreciated. -- Eric Ho Princeton University eho@clarity.princeton.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Feb 90 17:53:01 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa28386; 14 Feb 90 17:51 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA27100; Wed, 14 Feb 90 14:58:52 EST 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: 14 Feb 90 19:05:15 GMT From: "John W. Baugh Jr." Organization: North Carolina State University Subject: Functional / algebraic languages for DS3100 Message-Id: <1990Feb14.190515.4402@ncsuvx.ncsu.edu> References: <90045.114639CMH117@psuvm.psu.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Apparently NJML is soon to be released for the pmax. My question is `Are there any (currently available) alternatives?' By alternatives I mean a `modern' functional language with disjoint union data constructors, pattern matching, etc. I heard that a scheme-based interpreter exists for Haskell--is that true? If so, would it run on T (using the scheme mode)? Finally, are interpreters for algebraic languages like obj3 readily available? John Baugh  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Feb 90 13:33:34 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa14515; 14 Feb 90 12:20 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA15394; Wed, 14 Feb 90 10:27:07 EST 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: 13 Feb 90 23:44:03 GMT From: Brian Leverich Organization: The RAND Corporation, Santa Monica, CA Subject: Fast Scheme for Suns? Message-Id: <2399@randvax.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I've been doing knowledge-based simulation modeling of the Army's wartime theater ammunition distribution system using ROSS built on top of Texas Instruments' PC-Scheme, but things have grown to the point (as they usually do in simulation modeling...) where I need more processing horsepower. Anybody have any experience with a Scheme that will run on Sun UNIX boxes? Ideally I'd like a Scheme that is public domain, high optimized, and compatible with PC-Scheme, but I'll take whatever is available. Thanks for suggestions! -B -- "Simulate it in ROSS" Brian Leverich | U.S. Snail: 1700 Main St. ARPAnet: leverich@rand.org | Santa Monica, CA 90406 UUCP: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Feb 90 13:32:56 EST Received: from schizo.samsung.com by mintaka.lcs.mit.edu id aa12002; 14 Feb 90 11:11 EST Received: by schizo.samsung.com from mitech.UUCP via UUCP (vers 5.61+) for scheme@mc.lcs.mit.edu (from gjc@mitech.com) id ; Wed, 14 Feb 90 10:32:37 -0500 Message-Id: <9002141532.AA28905@schizo.samsung.com> Reply-To: gjc@mitech.com MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Received: by mitech.com (DECUS UUCP w/Smail); Wed, 14 Feb 90 09:35:36 EDT Date: Wed, 14 Feb 90 09:35:36 EDT From: gjc@mitech.com MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu To: scheme@mc.lcs.mit.edu Subject: CSCHEME under VMS X-Vms-Mail-To: UUCP%"scheme@mc.lcs.mit.edu" For CSCHEME under VMS one might want to look at the code distributed by DECUS. In particular CD-ROM collection 4 or 5 has a languages-and-tools collection which includes CSCHEME, GNU CC, TEX, and megabytes of other code.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Feb 90 02:37:22 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa26246; 14 Feb 90 2:30 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA18869; Wed, 14 Feb 90 00:53:23 EST 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: 14 Feb 90 05:16:53 GMT From: Scott Fritchie Organization: St. Olaf College, Northfield, MN Subject: Scheme macros for TeX Message-Id: <11278@thor.acc.stolaf.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I've been typesetting Scheme for Computer Science course examinations and handouts using TeX, but I don't have any nice macros packages to deal with the dirty-work of aligning parentheses, etc. and would be interested in a macro package to get rid of kludgy \kern's :-( I heard a rumor that such a package was available via anon. FTP from linus.mitre.org, but it has been unreachable for the past week. Are there any other FTP sites/places/people I might find such a beast? -Scott --- Scott Fritchie, Systems Programmer and Postmaster St. Olaf College, Northfield, MN 55057 USA Domain: fritchie@acc.stolaf.edu UUCP: ..!umn-cs!stolaf!fritchie "Yeah, boss, I'll be in late today. UNIX refuses to boot on my Ford."  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Feb 90 00:54:51 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa23361; 14 Feb 90 0:49 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA14483; Tue, 13 Feb 90 23:06:19 EST 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: 14 Feb 90 01:35:11 GMT From: Johan Ihren Organization: Royal Institute Of Technology, Stockholm, Sweden Subject: Re: X bindings in Scheme? Message-Id: <2940@draken.nada.kth.se> References: <2891@draken.nada.kth.se>, <4803@hplabsz.HPL.HP.COM> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu We apologize for not replying earlier. We are in the middle of a period of exams right now... In article <4803@hplabsz.HPL.HP.COM>, mayer@hplabsz.HPL.HP.COM (Niels Mayer) writes: > > should be written in C. I may prototype low level routines in XLISP, > but the ones that matter end up in C. IMHO, hybrid programming is the > way to go. Of course it has to be hybrid programming, as Scheme does not have any primitives for interprocess communication ;-) The question is on which level the conversion between C and Scheme structures should occur, provided that one wants to be able to manipulate the data as standard Scheme objects. In our system it is done at a very low level. This enables us to have an environment much more suited for Scheme. We are not saying that our approach is the right one, but rather that there is use for both the WINTERP and the SCIX solutions to the problem. > So H}kan, are saying that the compiling scheme system is fast enough? > I guess I need to read Bartlett's paper... Yes, it is fast enough to be useful. The speed of SCIX is roughly equivalent to that of CLX (a well known binding to Common Lisp). We haven't done any formal benchmarks, this is based on elementary comparision of a few example applications. The main difference between CLX and SCIX is that CLX is an imperative interface on which object oriented layers (CLUE) can be/has been added. SCIX is thoroughly object oriented from the inside and out. A SCIX application runs between four and six times slower than the C equivalent. This can be disastrous for an application that mostly consists of a speedy user interface, but is not unusable in other situations. We also have ideas that will hopefully speed up the eventhandling considerably in the future ;-) The big problem with the C binding to X is that C isn't really suited to the task of modelling a window system. The result is a very large system that is used in different ways on different levels (Xlib vs the toolkit layer). This makes it cumbersome to write X code in C. Much of the elegance of the underlying X protocol has been lost among the deficiencies of a particular language. When using a more powerful language, like Scheme, it was interesting to try to redo it all, with the X protocol as a starting point. The result is much cleaner and much easier to understand as the SCIX environment is consistent on all levels. Yes, SCIX is definitely slower than an application written entirely in C, but if speed is crucial then maybe the entire application should be written in C. For applications that need to be written in Scheme, however, I think that the power of the SCIX model of X can outweigh the speed gains that would come from using the C bindings from within Scheme. Yes, we do widgets in Scheme as well. They are typically quite easy to write. A set of buttons (generic-, text- and pixmap-buttons) that we wrote currently consists of 70, 35 and 20 lines of Scheme code each. The latter two inherit the former... -- Johan Ihren Dept. of Computer Science, Royal Institute of Technology, Stockholm, Sweden Email: johani@nada.kth.se -or- !sunic!nada!johani  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 13 Feb 90 03:23:36 EST Received: from mcsun.eu.net by mintaka.lcs.mit.edu id aa09277; 13 Feb 90 3:18 EST Received: by mcsun.EU.net via EUnet; Tue, 13 Feb 90 09:18:11 +0100 (MET) Received: by goya.dit.upm.es (EUnet) (3.2/6.3) Tue, 13 Feb 90 09:13:10 +0100 Date: 13 Feb 90 9:12 +0100 From: Javier Bejar Alonso To: scheme@lcs.mit.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Message-Id: <168*FIBCLS05@CLRS.LSI.UPC.ES> Subject: Compiling CSCHEME in VMS We have the sources of CSCHEME 7.0 (MIT-scheme), but we don't have the '.COM' files to build the 'VMS' version. Could anyone send us these files via e-mail? (Specially MAKE.COM & SCHEME.COM). My net address is FIBCLS05@CLRS.LSI.UPC.ES A question more, are there any troubles to install CSCHEME 7.0 on VAX VMS 5.1? Thanks in advance. JAVIER P.S. Forgive my bad english.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 13 Feb 90 01:39:58 EST Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa05454; 13 Feb 90 1:32 EST Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA07701; Tue, 13 Feb 90 01:32:31 EST Received: from ucsd.edu (ucsd.edu) by zurich.ai.mit.edu; Tue, 13 Feb 90 01:29:07 est Received: from vis.UUCP by ucsd.edu; id AA11297 sendmail 5.61/UCSD-2.0-sun via UUCP Mon, 12 Feb 90 22:29:26 -0800 for scheme@zurich.ai.mit.edu From: vis!greg@ucsd.edu Received: by vis. (4.0/SMI-4.0) id AA16090; Mon, 12 Feb 90 21:36:58 PST Message-Id: <9002130536.AA16090@vis.> To: scheme@zurich.ai.mit.edu Subject: Need monochrome PC SCHEME graphics Date: Mon, 12 Feb 90 21:36:56 -0800 Dear schemers, I recommended PC scheme from TI to a friend for her PC. She really likes it, but can't use it for graphics since it only supports color graphics. Do you know of any packages for PC scheme, or any other scheme for the PC which will support monochrome graphics? Any leads would be much appreciated. Thanks, _Greg J. Greg Davidson Virtual Infinity Systems +1 (619) 452-8059 6231 Branting St; San Diego, CA 92122 USA greg@vis.com ucbvax--| telesoft--| vis!greg@nosc.mil decvax--+---ucsd----+--vis vis!greg@ucsd.edu ihnp4--| nosc----|  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 13 Feb 90 01:34:44 EST Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa05433; 13 Feb 90 1:32 EST Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA07702; Tue, 13 Feb 90 01:32:32 EST Received: from ucsd.edu (ucsd.edu) by zurich.ai.mit.edu; Tue, 13 Feb 90 01:28:53 est Received: from vis.UUCP by ucsd.edu; id AA11288 sendmail 5.61/UCSD-2.0-sun via UUCP Mon, 12 Feb 90 22:29:24 -0800 for scheme@zurich.ai.mit.edu From: vis!greg@ucsd.edu Received: by vis. (4.0/SMI-4.0) id AA16082; Mon, 12 Feb 90 21:33:44 PST Message-Id: <9002130533.AA16082@vis.> To: scheme@zurich.ai.mit.edu Subject: NEED: Old SCHEME for 512K Macintosh Date: Mon, 12 Feb 90 21:33:41 -0800 Dear schemers, I have recommended SCHEME to a friend and student. She has an old 512K Mac. Unfortunately, the current versions of scheme are too large for her Mac. She can't afford to upgrade right now, so I'm looking for an old version of MacSCHEME or SCHEME Express or something else that is lean enough to fit. I understand that older versions of the products I've mentioned will work just fine. She would be happy to buy someone's old version. Please send me any information you have that might be helpful. Thanks, _Greg J. Greg Davidson Virtual Infinity Systems +1 (619) 452-8059 6231 Branting St; San Diego, CA 92122 USA greg@vis.com ucbvax--| telesoft--| vis!greg@nosc.mil decvax--+---ucsd----+--vis vis!greg@ucsd.edu ihnp4--| nosc----|  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 12 Feb 90 18:04:23 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18690; 12 Feb 90 17:46 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA24717; Mon, 12 Feb 90 15:00:37 EST 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: 12 Feb 90 19:33:58 GMT From: Jason Coughlin Organization: Clarkson University, Potsdam, NY Subject: quasiquote Message-Id: <1990Feb12.193358.29510@sun.soe.clarkson.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Can quasiquote be implemented as an extend-syntax form? If so, does someone have a definition of it as an extend-syntax form? I'm not looking for a full blown implementation with recursive quasiquotation (unless you've got it :-) -- just something that handles cases similar to these: `(a b (,(+ 2 3) c) d) `(a b ,(reverse '(c d e)) f g) `(a b ,@(reverse '(c d e)) f g) -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 12 Feb 90 07:57:35 EST Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa26955; 12 Feb 90 7:53 EST Received: from mcsun.EU.net by life.ai.mit.edu (4.0/AI-4.10) id AA03006; Mon, 12 Feb 90 04:22:45 EST Received: by mcsun.EU.net via EUnet; Mon, 12 Feb 90 10:22:20 +0100 (MET) Received: by goya.dit.upm.es (EUnet) (3.2/6.3) Mon, 12 Feb 90 09:37:43 +0100 Date: 12 Feb 90 9:38 +0100 From: Javier Bejar Alonso To: info-cscheme@zurich.ai.mit.edu, scheme@ai.mit.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Message-Id: <163*FIBCLS05@CLRS.LSI.UPC.ES> Subject: Compiling CSCHEME in VMS We have the sources of CSCHEME 7.0 (MIT-scheme), but we don't have the '.COM' files to build the 'VMS' version. Could anyone send us these files via e-mail? (Specially MAKE.COM & SCHEME.COM). My net address is FIBCLS05@CLRS.LSI.FIB.ES A question more, are there any troubles to install CSCHEME 7.0 on VAX VMS 5.1? Thanks in advance. JAVIER P.S. Forgive my bad english.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 11 Feb 90 00:48:37 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03377; 11 Feb 90 0:46 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA18339; Sun, 11 Feb 90 00:01:57 EST 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: 10 Feb 90 10:14:55 GMT From: Aaron Sloman Organization: School of Cognitive & Computing Sciences, Sussex Univ. UK Subject: optimising factorial Message-Id: <2155@syma.sussex.ac.uk> References: <9002051741.AA03862@heike.informatik.uni-dortmund.de>, , <4782@brazos.Rice.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu dorai@titan.rice.edu (Dorai Sitaram) writes: (about optimising a recursive defintion of factorial) > > ....I wouldn't want the compiler to perform this > optimization, for if you unwind the *-calls, you'll find the > non-tail-rec version does (* n (* n-1 (* n-2 ... 1))), while the > tail-rec one does (* 1 (* 2 (* 3 ... (* n 1)))). The optimization > hinges too much on the commutativity of * for my comfort. > This can be surprisingly important if at some point "big" integers are created (e.g. factorial 1000). If you start the multiplication from the top down i.e. (* 1 (* 2 (* 3 ... (* n 1)))) then more big integers are created than if it is done the other way, (* n (* n-1 (* n-2 ... 1))) Unless your compiler is clever about re-using temporary results of mutiplications etc, the former can spend significantly more time in garbage collection. Aaron Sloman, School of Cognitive and Computing Sciences, Univ of Sussex, Brighton, BN1 9QH, England EMAIL aarons@cogs.sussex.ac.uk aarons%uk.ac.sussex.cogs@nsfnet-relay.ac.uk  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Feb 90 18:43:23 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07948; 9 Feb 90 18:30 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA01348; Fri, 9 Feb 90 16:21:20 EST 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: 9 Feb 90 18:56:47 GMT From: John Gateley Organization: TI Computer Science Center, Dallas Subject: Re: (none) Message-Id: <109911@ti-csl.csc.ti.com> References: <9002051741.AA03862@heike.informatik.uni-dortmund.de>, , <4782@brazos.Rice.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <4782@brazos.Rice.edu> dorai@titan.rice.edu (Dorai Sitaram) writes: simon@opal.tu-berlin.de (Simon Leinen) writes: <$[Transforms fact into tail recursive form] <$Unfortunately, most existing compilers don't perform this optimization <$themselves. < <"Unfortunately"? I wouldn't want the compiler to perform this Message-Id: <9002091653.AA27665@zurich.ai.mit.edu> To: shelby!vera%fanaraaken.Stanford.EDU@decwrl.dec.com Cc: scheme@mc.lcs.mit.edu In-Reply-To: "James S. Vera"'s message of 9 Feb 90 05:16:59 GMT <16@fanaraaken.stanford.edu> Subject: MIT-Scheme documentaion question Date: 9 Feb 90 05:16:59 GMT From: "James S. Vera" I just pulled MIT-Scheme Release 7 off of gatekeeper and was disappointed to discover that the accompanied manual has several large gaps, namely large(?) chunks of sections 8 (OS Features), 9 (Syntax Transducers), 10 (User Interface) and all of section 11 (Debugging Tools). My question is basicly "What's Up?", to which I see a number of possible answers: 4) "These sections aren't written yet, but will be Real Soon Now" This is the correct answer, for some value of RSN. I created those sections of the manual when I was working on it as an outline for what remained to be done, but then I ran out of steam long before the thing was finished. I don't expect to resume writing that manual any time soon.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Feb 90 00:53:37 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02247; 9 Feb 90 0:46 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA18585; Fri, 9 Feb 90 00:40:25 EST 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: 9 Feb 90 05:16:59 GMT From: "James S. Vera" Organization: Stanford University Subject: MIT-Scheme documentaion question Message-Id: <16@fanaraaken.stanford.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I just pulled MIT-Scheme Release 7 off of gatekeeper and was disappointed to discover that the accompanied manual has several large gaps, namely large(?) chunks of sections 8 (OS Features), 9 (Syntax Transducers), 10 (User Interface) and all of section 11 (Debugging Tools). My question is basicly "What's Up?", to which I see a number of possible answers: 1) "Its public domain software and you shuld be grateful for any manual at all." (and I am, don't get me wrong) 2) "You obvious don't know TeX from a hole in the Sendmail, try printing it the _right_ way." (hints?) 3) "These sections weren't written a first but are now available from blah." and 4) "These sections aren't written yet, but will be Real Soon Now" Call now! [$2.00 plus toll if any] James S. Vera | Internet |Standard Disclaimers Stanford University|vera@fanaraaken.stanford.edu|Blah Blah Blah Blah Bellcore |vera2@rigel.cc.bellcore.com |vvv My Cutesy Quote vvv "When I was young it seemed that life was so wonderful..." - Supertramp  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Feb 90 00:53:30 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02225; 9 Feb 90 0:46 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA15800; Thu, 8 Feb 90 23:46:37 EST 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: 9 Feb 90 03:07:10 GMT From: Niels Mayer Organization: Hewlett-Packard Labs, Software Technology Lab, Palo Alto, CA. Subject: Re: X bindings in Scheme? Message-Id: <4803@hplabsz.HPL.HP.COM> References: <2891@draken.nada.kth.se> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <2891@draken.nada.kth.se> huss@nada.kth.se (H}kan Huss) writes: >rather easy. Some systems also provide interfaces to the toolkit >layers of X. In our opinion, however, the main question is not >the feasibility, but rather the desirability of this approach. We >believe that the C interface is not suited for direct use from Scheme. I agree that the xlib layer is too low-level for lisp programming ... that's why I like my UI components implemented in C. I've found WINTERP to be plenty fast -- As long as I'm not forcing XLISP to perform lots of grinding and garbage generating operations. THose should be written in C. I may prototype low level routines in XLISP, but the ones that matter end up in C. IMHO, hybrid programming is the way to go. So H}kan, are saying that the compiling scheme system is fast enough? I guess I need to read Bartlett's paper... ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Feb 90 17:53:28 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa15029; 8 Feb 90 17:49 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA25981; Thu, 8 Feb 90 17:17:45 EST 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: 7 Feb 90 21:36:48 GMT From: Joe Keane Organization: Object Sciences Corp., Menlo Park, CA Subject: Re: (none) Message-Id: <2008@osc.COM> References: <9002051741.AA03862@heike.informatik.uni-dortmund.de> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <9002051741.AA03862@heike.informatik.uni-dortmund.de> muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes: >At first, it is possible to implement scheme that tail recursions (means >recursions of iterative nature, needing only a constant amount of memory) >really work without allocating new memory during every recursive application. >In Abelson + Sussman it is said it is possible and I think in MIT-Scheme it >is done. Wait, isn't this _required_ of an implementation?  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Feb 90 15:06:51 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07142; 8 Feb 90 15:01 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA17802; Thu, 8 Feb 90 14:33:17 EST 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: 8 Feb 90 18:33:06 GMT From: H}kan Huss Organization: Royal Institute of Technology, Stockholm, Sweden Subject: Re: X bindings in Scheme? Message-Id: <2892@draken.nada.kth.se> References: <2891@draken.nada.kth.se> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Sorry, the first line of the previous post got mangled. It should have read: To interface Scheme to Xlib is, as several people have reported, rather easy...  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Feb 90 15:06:46 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07137; 8 Feb 90 15:01 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA16928; Thu, 8 Feb 90 14:14:07 EST 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: 8 Feb 90 18:26:41 GMT From: H}kan Huss Organization: Royal Institute Of Technology, Stockholm, Sweden Subject: Re: X bindings in Scheme? Message-Id: <2891@draken.nada.kth.se> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu rather easy. Some systems also provide interfaces to the toolkit layers of X. In our opinion, however, the main question is not the feasibility, but rather the desirability of this approach. We believe that the C interface is not suited for direct use from Scheme. To support this notion we have designed an interface between Scheme and X called SCIX, written entirely in Scheme. What we wanted to achieve with this system was a model of the X window system that more closely matched the means of abstraction available in Scheme. I.e, a model that is object-oriented from the bottom and up. We have found that this approach makes widget construction simple and elegant. The price of elegance is, as always, performance. Run interactively the system is rather inefficient. Thus, in order for it to be interesting one needs a compiling Scheme system. Our implementation is based on the WRL Scheme->C system. SCIX has been developed for Digital Equipment, but it is meant to be made freely available. It is scheduled to be released in March. Regards, Hakan Huss Johan Ihren  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Feb 90 10:58:20 EST Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa26918; 8 Feb 90 10:49 EST Received: from Fafnir.Think.COM by Think.COM; Thu, 8 Feb 90 10:49:40 -0500 Return-Path: Received: from verdi.think.com by fafnir.think.com; Thu, 8 Feb 90 10:48:39 EST Received: from ungar.think.com by verdi.think.com; Thu, 8 Feb 90 10:48:57 EST From: Guy Steele Received: by ungar.think.com; Thu, 8 Feb 90 10:48:56 EST Date: Thu, 8 Feb 90 10:48:56 EST Message-Id: <9002081548.AA10809@ungar.think.com> To: Scheme@lcs.mit.edu In-Reply-To: Automatic Scheme Digestifier's message of 8 Feb 90 02:45:42 EST Subject: Scheme Digest #295 Date: 7 Feb 90 23:00:08 GMT From: Dorai Sitaram ... simon@opal.tu-berlin.de (Simon Leinen) writes: $... muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes: $This is why Lisp (or Scheme) programmers change a definition like $ $ (define fac (lambda (n) $ (if (= n 0) $ 1 $ (* n (fac (- n 1)))))) ; tail-call to *, but not to fac $ $into the less obvious, but more efficient $ $ (define fac (lambda (n) $ (letrec ((fac-aux (lambda (n acc) $ (if (= n 0) $ acc $ (fac-aux (- n 1) (* n acc)))))) ; tail-call to fac-aux $ (fac-aux n 1)))) $ $Unfortunately, most existing compilers don't perform this optimization $themselves. "Unfortunately"? I wouldn't want the compiler to perform this optimization, for if you unwind the *-calls, you'll find the non-tail-rec version does (* n (* n-1 (* n-2 ... 1))), while the tail-rec one does (* 1 (* 2 (* 3 ... (* n 1)))). The optimization hinges too much on the commutativity of * for my comfort. Indeed, you do need to know that * is associative (commutativity is not required). See Darlington and Burstall. "A Transformation System for Developing Recursive Programs", Journal of the ACM, January 1977, and a pile of other papers that it inspired. --Guy Steele  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Feb 90 10:44:48 EST Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa26515; 8 Feb 90 10:40 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 1701; Thu, 08 Feb 90 10:40:59 EST Received: from DB0TUI6.BITNET (NET) by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 8557; Thu, 08 Feb 90 10:40:58 EST Received: by tub.UUCP; Thu, 8 Feb 90 16:22:57 +0100; AA24765 Date: Thu, 8 Feb 90 16:22:57 +0100 From: Oliver Laumann Message-Id: <9002081522.AA24765@tub.UUCP> To: Scheme@lcs.mit.edu Subject: Re: (none) > $Don't expect any professor in this country to be able to help you. > > I thought Elk was Made in Germany. So schlimm kann es doch nicht sein. I wrote Elk without any professor's help; in fact, the only useful help I was able to get was from the participants of the Scheme mailing list! Regards, -- Oliver Laumann net@TUB.BITNET net@tub.cs.tu-berlin.de net@tub.UUCP  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Feb 90 09:04:16 EST Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22520; 8 Feb 90 9:00 EST Received: from zurich.ai.mit.edu ([18.43.0.171]) by life.ai.mit.edu (4.0/AI-4.10) id AA00943; Thu, 8 Feb 90 09:00:54 EST Received: from localhost by zurich.ai.mit.edu; Thu, 8 Feb 90 09:00:43 est Date: Thu, 8 Feb 90 09:00:43 est From: "Guillermo J. Rozas" Message-Id: <9002081400.AA15746@zurich.ai.mit.edu> To: titan!dorai@rice.edu Cc: scheme@mc.lcs.mit.edu In-Reply-To: Dorai Sitaram's message of 7 Feb 90 23:00:08 GMT <4782@brazos.Rice.edu> Subject: (none) Reply-To: jinx@zurich.ai.mit.edu "Unfortunately"? I wouldn't want the compiler to perform this optimization, for if you unwind the *-calls, you'll find the non-tail-rec version does (* n (* n-1 (* n-2 ... 1))), while the tail-rec one does (* 1 (* 2 (* 3 ... (* n 1)))). The optimization hinges too much on the commutativity of * for my comfort. Commutativity should not be a problem as long as the compiler can determine that * is really *. A worse problem is associativity, which doesn't generally hold for computer arithmetic, although it typically holds in Lisp systems when restricted to integers. (I guess you mean Scheme rather than Lisp, since none of the (other) Lisps bother even about tail-call optimization, not to speak of the optimizations that Holger and you speak of.) If I'm not mistaken, the MacLisp compiler handled some purely local cases of tail-call optimization, and the Lucid compiler handles even more. The difference is that Scheme requires that the language be properly tail recursive, that is, calls in tail position (whether to a procedure visible at "compile" time or not) should generate no net growth of storage. For example, the following contrived program should be an infinite loop (no net growth of storage) when given a list with a single element as an argument, yet it is an infinite recursion when given a longer list. (define (tst l) (define (flat-apply f original) (define (flatten-1 l add-to-what) (if (pair? l) (flatten-1 (car l) (flatten-2 (cdr l) add-to-what)) (f l add-to-what))) (define (flatten-2 l add-to-what) (cond ((pair? l) (flatten-1 (car l) (flatten-2 (cdr l) add-to-what))) ((null? l) add-to-what) (else (error "Flatten: Bad list" original)))) (flatten-2 original '())) (define (test-f element ignore) (newline) (write element) (flat-apply test-f l)) (flat-apply test-f l))  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 7 Feb 90 19:21:19 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa23377; 7 Feb 90 19:13 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA23349; Wed, 7 Feb 90 18:13:15 EST 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: 7 Feb 90 23:00:08 GMT From: Dorai Sitaram Organization: Rice University, Houston Subject: Re: (none) Message-Id: <4782@brazos.Rice.edu> References: <9002051741.AA03862@heike.informatik.uni-dortmund.de>, Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article simon@opal.tu-berlin.de (Simon Leinen) writes: $In article <9002051741.AA03862@heike.informatik.uni-dortmund.de> muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes: $This is why Lisp (or Scheme) programmers change a definition like $ $ (define fac (lambda (n) $ (if (= n 0) $ 1 $ (* n (fac (- n 1)))))) ; tail-call to *, but not to fac $ $into the less obvious, but more efficient $ $ (define fac (lambda (n) $ (letrec ((fac-aux (lambda (n acc) $ (if (= n 0) $ acc $ (fac-aux (- n 1) (* n acc)))))) ; tail-call to fac-aux $ (fac-aux n 1)))) $ $Unfortunately, most existing compilers don't perform this optimization $themselves. "Unfortunately"? I wouldn't want the compiler to perform this optimization, for if you unwind the *-calls, you'll find the non-tail-rec version does (* n (* n-1 (* n-2 ... 1))), while the tail-rec one does (* 1 (* 2 (* 3 ... (* n 1)))). The optimization hinges too much on the commutativity of * for my comfort. $ Today I asked a professsor and a doctor here at UniDo but both $ couldn't help me. $ $Don't expect any professor in this country to be able to help you. $Lisp wird in Deutschland einfach nicht ernstgenommen. (I guess you mean Scheme rather than Lisp, since none of the (other) Lisps bother even about tail-call optimization, not to speak of the optimizations that Holger and you speak of.) I thought Elk was Made in Germany. So schlimm kann es doch nicht sein. $Viele Gruesse und happy LISPing, --dorai -- ------------------------------------------------------------------------------- It may be that the gulfs will wash us down; It may be we shall touch the Happy Isles. -------------------------------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 7 Feb 90 18:49:08 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa22404; 7 Feb 90 18:45 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA20813; Wed, 7 Feb 90 17:04:11 EST 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: 7 Feb 90 11:04:54 GMT From: Simon Leinen Organization: TU Berlin, Fachbereich 20 (Informatik) Subject: Re: (none) Message-Id: References: <9002051741.AA03862@heike.informatik.uni-dortmund.de> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <9002051741.AA03862@heike.informatik.uni-dortmund.de> muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes: (define (dummy x) (if (< x 10) (dummy (1+ x)) 'DONE)) Here you cannot immediately see if (dummy ...) is the last evaluated expression. In some way you have to analyze the meaning of the procedure. What you have is almost THE CLASSICAL EXAMPLE of tail recursion. A function call is a tail call if it occurs last *in an execution path* of the calling function, and this is the case for the call to `dummy'. In the example, the if form is known to be the last form in the function body. Either the `then' or the `else' branch is taken. The else branch just returns a constant, which cannot be optimized very much. The then part calls a function and returns the result of this call. Call and return can be transformed into a jump, and the jump can be transformed into a branch, since the called function is the same as the calling function. Thus the tail-recursive call can be eliminated, and this is what you can expect from any decent Lisp or Scheme compiler. To my opinion it is not enough to test additional in special forms like 'if' or 'cond' if the application is the last evaluated expression in this form because after the 'if' or 'cond' clause there can be other expressions to be evaluated. If there were other forms after the if, you could only optimize tail-recursion in those forms. Tail calls only occur at the end of a sequence (hence the word `tail'). This is why Lisp (or Scheme) programmers change a definition like (define fac (lambda (n) (if (= n 0) 1 (* n (fac (- n 1)))))) ; tail-call to *, but not to fac into the less obvious, but more efficient (define fac (lambda (n) (letrec ((fac-aux (lambda (n acc) (if (= n 0) acc (fac-aux (- n 1) (* n acc)))))) ; tail-call to fac-aux (fac-aux n 1)))) Unfortunately, most existing compilers don't perform this optimization themselves. Today I asked a professsor and a doctor here at UniDo but both couldn't help me. Don't expect any professor in this country to be able to help you. Lisp wird in Deutschland einfach nicht ernstgenommen. Viele Gruesse und happy LISPing, -- Simon Leinen.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 6 Feb 90 23:50:17 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa06385; 6 Feb 90 23:45 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA02086; Tue, 6 Feb 90 23:19:39 EST 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: 6 Feb 90 23:07:01 GMT From: Speed Organization: The Johns Hopkins University - HCF Subject: Pc scheme where? Message-Id: <4148@jhunix.HCF.JHU.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Hi! I've just started reading this group (obviously), and have seen several people mention PC scheme. Where could I get a copy? I have ftp, and the like. Secondly is this compatable with scheme 7.0? I currently have a class on scheme and we need 7.0.0 beta. I have tried to work with the original code, but it was a quite large task. Please respond by E-mail. Thanx in advance, -- Justin ins_ajdc@jhunix.hcf.jhu.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 6 Feb 90 22:24:42 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02174; 6 Feb 90 22:19 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA14287; Tue, 6 Feb 90 17:46:08 EST 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: 6 Feb 90 20:51:58 GMT From: Rusty Haddock Organization: 1/entropy Subject: XScheme 0.20 for the Amiga available on UUNET Message-Id: <307@fe2o3.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu This morning (2/6) I put a Zoo file containing the sources, two binaries, and documentation for David Betz's XScheme 0.20 (yes, not even 1.0 yet) with my Amiga/Manx modifications onto UUNET.UU.NET (192.48.96.2) for anonymous ftp. The file was amiga-sources/xscheme.20.zoo The two binaries included, xscheme and xscheme.881, were compiled for using the IEEE math libraries and 68881/2 inline code, respectfully. Two things to remember: 1) Use binary mode for ftp'ing. 2) I simply ftp'ed this onto UUNET's disks without any specific permission to do so. As such, my file may disappear without warning. If this happens I'll find another way to keep this ftp'able. Enjoy! -Rusty- -- Rusty Haddock o {uunet,att,rutgers}!mimsy.umd.edu!fe2o3!rusty Laurel, Maryland o "IBM sucks silicon!" -- PC Banana Jr, "Bloom County"  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 6 Feb 90 15:50:08 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21605; 6 Feb 90 15:45 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA06255; Tue, 6 Feb 90 15:04:53 EST 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: 5 Feb 90 16:16:36 GMT From: Jean-Michel ROSSET Organization: Hewlett-Packard, GND Subject: Scheme compiler in scheme ? Message-Id: <2530001@hpgnd.HP.COM> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu I have xscheme on a 68000 based machine (namely an atari) and I would like to be able to generate efficient code. I guess a scheme compiler in scheme could do it. Is there anything available and compatible with the memory limitations of this kind of machine (a couple of Mbytes and no virtual memory)? If my quest was infortunate, what is the bibliography startup for implementing one? Thanks Jean-Michel ROSSET jm@hpgnd.hp.com ...My opinions are shared  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 6 Feb 90 13:22:03 EST Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa14334; 6 Feb 90 13:10 EST Received: from Fafnir.Think.COM by Think.COM; Tue, 6 Feb 90 13:11:03 -0500 Return-Path: Received: from verdi.think.com by fafnir.think.com; Tue, 6 Feb 90 13:10:07 EST Received: from ungar.think.com by verdi.think.com; Tue, 6 Feb 90 13:10:54 EST From: Guy Steele Received: by ungar.think.com; Tue, 6 Feb 90 13:10:51 EST Date: Tue, 6 Feb 90 13:10:51 EST Message-Id: <9002061810.AA03161@ungar.think.com> To: muenx@heike.informatik.uni-dortmund.de Cc: Scheme@lcs.mit.edu In-Reply-To: Automatic Scheme Digestifier's message of 6 Feb 90 02:00:37 EST Subject: Scheme Digest #293 But HOW can it be done? I think the problem is to determine in every application of a compound procedure if it is the last command which is evaluated in a procedure. Another point of view is that the problem is to construct a framework in which application does not require conditional treatment. This can be done. The idea is that a procedure call *never* adds anything to the stack; *all* calls, as such, are tail-recursive. However, not all *evaluations* are tail-recursive. A frame must be added to the stack whenever one is about to evaluate a function argument, or the predicate part of a conditional, or any form except the last in a block, or in general whenever one is about to evaluate a subform but must regain control again. For a more extensive treatment of this topic, see my paper "Procedure Call Implementations Considered Harmful" in the Proceedings of the 1977 ACM National Conference. Happy hacking! --Guy Steele  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 6 Feb 90 09:45:11 EST Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa04200; 6 Feb 90 9:35 EST Received: from unido.Informatik.Uni-Dortmund.DE by uunet.uu.net (5.61/1.14) with SMTP id AA02550; Tue, 6 Feb 90 09:35:11 -0500 Received: from gmdzi.UUCP (gmdzi) (1778) by unido.informatik.uni-dortmund.de for uunet id AP02306; Tue, 6 Feb 90 15:33:39 +0100 Received: by gmdzi.UUCP id AA17563; Tue, 6 Feb 90 15:37:53 -0100 Date: Tue, 6 Feb 90 15:37:53 -0100 From: Harry Bretthauer Message-Id: <9002061437.AA17563@gmdzi.UUCP> To: Scheme@mc.lcs.mit.edu Subject: OOP with Scheme? Cc: gmdzi!?@uunet.uu.net I'm currently working on a conversion of an object oriented extension for Common Lisp (MetaClassSystem by Harry Bretthauer and Juergen Kopp at the "Gesellschaft fuer Mathematik und Datenverarbeitung", GMD) to Scheme (particularly MacScheme and PCScheme). Now I would like to know which OOP-Extensions for Scheme exist until now or are under development. If anybody has experiences with OOP in Scheme or has a good overview in this area, I would be happy for an answer in this mailing group. Andreas Lange  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Feb 90 16:06:31 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20800; 5 Feb 90 15:59 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA26722; Mon, 5 Feb 90 14:56:44 EST 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: 5 Feb 90 19:47:39 GMT From: Jason Coughlin Organization: Clarkson University, Potsdam, NY Subject: Re: (none) Message-Id: <1990Feb5.194739.3018@sun.soe.clarkson.edu> References: <9002051741.AA03862@heike.informatik.uni-dortmund.de> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu muenx@heike.informatik.uni-dortmund.de (Holger Muenx): > Although there are some implementations for the Amiga or at least simple > to port to the Amiga I decided to write my own scheme. > I could give you source to a beginning of scheme so that you wouldn't have to implement the WHOLE thing. I am writing a scheme -- and the interpreter is almost completely finished (I'm acutally working onthe compiler right now). The source is not public domain but it is freely distributable -- of course, I'd like your improvements to be freely distributable too [your problem in the first case!], but we could work this out. > At first, it is possible to implement scheme that tail recursions (means > recursions of iterative nature, needing only a constant amount of memory) > really work without allocating new memory during every recursive application. > In Abelson + Sussman it is said it is possible and I think in MIT-Scheme it > is done. > Correct, the stack doesn't grow by 1 cons node. I have a compile time option that lets you see this (the stack really doesn't grow at all). > Here you cannot immedeatly see if (dummy ...) is the last evaluated > expression. In some way you have to analyze the meaning of the procedure. > To my opinion it is not enough to test additional in special forms like 'if' > or 'cond' if the application is the last evaluated expression in this form > because after the 'if' or 'cond' clause there can be other expressions to be > evaluated. > You're thinking on too high a level -- human level. it isn't implemented this way. > But HOW can it be done? I think the problem is to determine in every > application of a compound procedure if it is the last command which is evaluated > in a procedure. For example, the following is obviously tail recursive: > > (define (dummy x) > (print x) > (dummy (1+ x))) > first of all, this is equivalent to (and the interp probably sees it like this): (define dummy (lambda (x) (print x) (dummy (+ 1 x)) ) ) lambda is a special form that returns a closure. a closure is code and it's associated env (remember static scope -- things are evaled in the env in which they're defined). it probably looks like this: (*CLOSURE* parms body env) where *CLOSURE* is just a symbol and env is the CURRENT env. Ok, the interpreter is a stack based machine. To evaluate the closure (NOT LAMBDA, you've got to separate the eval of LAMBDA and what it returns [a closure]). On entering the closure (that's what dummy is) Since it's static scope, you: (1) push the current env on the stack (so you can return to it when you're done with the closure) (2) restore the env from the closure (static scope, evaluate something in the environment in which it is DEFINED ) (3) bind args to parms over this new environment (4) evaluate code in closure (by pushing the body of the closure on the stack) (5) restore environment that you pushed on the stack that handles one evaluation. if your language doesn't handle tail recursion, then it does this ad nauseum. at each invokation of the closure, it pushes the current environment so your stack has ALL of these environments on it -- the tail recurision comes in because when you're done, you have to step back through ALL of those environments. to handle tail recursion, change step 1. (1) if there is an environemnt on the stack, skip to step 2. if not, push the current env this way, there is only 1 env on the stack during any directly recursive call. viola, no tail recursion (you immediately pop back to the original environment because that's the only one on the stack). -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Feb 90 14:36:01 EST Received: from [134.228.1.2] by mintaka.lcs.mit.edu id aa16541; 5 Feb 90 14:25 EST Received: by schizo.samsung.com from mitech.UUCP via UUCP (vers 5.61+) for scheme@lcs.mit.edu (from gjc@mitech.com) id ; Mon, 5 Feb 90 14:25:42 -0500 Message-Id: <9002051925.AA11173@schizo.samsung.com> Reply-To: gjc@mitech.com MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Received: by mitech.com (DECUS UUCP w/Smail); Mon, 5 Feb 90 13:04:55 EDT Date: Mon, 5 Feb 90 13:04:55 EDT From: gjc@mitech.com MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu To: scheme@lcs.mit.edu Subject: CGOL revisited: A Pratt parser for SIOD (scheme in one defun) X-Vms-Mail-To: UUCP%"scheme@lcs.mit.edu" From time to time people ask me for CGOL, so I've decided to make the technology more available by consing up something that will run in SIOD version 2.3 directly, without the need to bootstrap the thing as with the original CGOL implementation. Please forgive me if the code looks like Maclisp. The values for the binding powers are a tricky area, and these are somewhat like what is documented for Macsyma. ---- START OF PRATT.SCM ---- ;; -*-mode:lisp-*- ;; ;; A simple Pratt-Parser for SIOD: 2-FEB-90, George Carrette, GJC@PARADIGM.COM ;; ;; COPYRIGHT (c) 1990 BY ;; PARADIGM ASSOCIATES INCORPORATED, CAMBRIDGE, MASSACHUSETTS. ;; See the source file SLIB.C for more information. ;; ;; ;; Based on a theory of parsing presented in: ;; ;; Pratt, Vaughan R., ``Top Down Operator Precedence,'' ;; ACM Symposium on Principles of Programming Languages ;; Boston, MA; October, 1973. ;; ;; The following terms may be useful in deciphering this code: ;; NUD -- NUll left Denotation (op has nothing to its left (prefix)) ;; LED -- LEft Denotation (op has something to left (postfix or infix)) ;; LBP -- Left Binding Power (the stickiness to the left) ;; RBP -- Right Binding Power (the stickiness to the right) ;; ;; ;; Example calls ;; ;; (pl '(f [ a ] = a + b / c)) => (= (f a) (+ a (/ b c))) ;; ;; (pl '(if g [ a COMMA b ] then a > b else k * c + a * b)) ;; => (if (g a b) (> a b) (+ (* k c) (* a b))) ;; ;; Notes: ;; ;; This code must be used with siod.scm loaded, in siod version 2.3 ;; ;; For practical use you will want to write some code to ;; break up input into tokens. (defvar *eof* (list '*eof*)) ;; (defun pl (l) ;; parse a list of tokens (setq l (append l '($))) (toplevel-parse (lambda (op arg) (cond ((eq op 'peek) (if l (car l) *eof*)) ((eq op 'get) (if l (pop l) *eof*)) ((eq op 'unget) (push arg l)))))) (defun peek-token (stream) (stream 'peek nil)) (defun read-token (stream) (stream 'get nil)) (defun unread-token (x stream) (stream 'unget x)) (defun toplevel-parse (stream) (if (eq *eof* (peek-token stream)) (read-token stream) (parse -1 stream))) (defun get (sym key) ;; symbolconc takes the place of an explicit hash-table (setq sym (symbolconc sym '+INTERNAL-PLIST)) (and (symbol-bound? sym) (cdr (assq key (symbol-value sym))))) (defun putprop (sym val key) (set-cdr! (let ((cell (symbolconc sym '+INTERNAL-PLIST))) (or (assq key (if (symbol-bound? cell) (symbol-value cell) (set-symbol-value! cell nil))) (car (set-symbol-value! cell (cons (list key) (symbol-value cell)))))) val)) (defun plist (sym) (setq sym (symbolconc sym '+INTERNAL-PLIST)) (and (symbol-bound? sym) (symbol-value sym))) (defun value-if-symbol (x) (if (symbol? x) (symbol-value x) x)) (defun nudcall (token stream) (if (symbol? token) (if (get token 'nud) ((value-if-symbol (get token 'nud)) token stream) (if (get token 'led) (error 'not-a-prefix-operator token) token) token) token)) (defun ledcall (token left stream) ((value-if-symbol (or (and (symbol? token) (get token 'led)) (error 'not-an-infix-operator token))) token left stream)) (defun lbp (token) (or (and (symbol? token) (get token 'lbp)) 200)) (defun rbp (token) (or (and (symbol? token) (get token 'rbp)) 200)) (defvar *parse-debug* nil) (defun parse (rbp-level stream) (if *parse-debug* (print `(parse ,rbp-level))) (defun parse-loop (translation) (if (< rbp-level (lbp (peek-token stream))) (parse-loop (ledcall (read-token stream) translation stream)) (begin (if *parse-debug* (print translation)) translation))) (parse-loop (nudcall (read-token stream) stream))) (defun header (token) (or (get token 'header) token)) (defun parse-prefix (token stream) (list (header token) (parse (rbp token) stream))) (defun parse-infix (token left stream) (list (header token) left (parse (rbp token) stream))) (defun parse-nary (token left stream) (cons (header token) (cons left (prsnary token stream)))) (defun parse-matchfix (token left stream) (cons (header token) (prsmatch (or (get token 'match) token) stream))) (defun prsnary (token stream) (defun loop (l) (if (eq? token (peek-token stream)) (begin (read-token stream) (loop (cons (parse (rbp token) stream) l))) (reverse l))) (loop (list (parse (rbp token) stream)))) (defun prsmatch (token stream) (if (eq? token (peek-token stream)) (begin (read-token stream) nil) (begin (defun loop (l) (if (eq? token (peek-token stream)) (begin (read-token stream) (reverse l)) (if (eq? 'COMMA (peek-token stream)) (begin (read-token stream) (loop (cons (parse 10 stream) l))) (error 'comma-or-match-not-found (read-token stream))))) (loop (list (parse 10 stream)))))) (defun delim-err (token stream) (error 'illegal-use-of-delimiter token)) (defun erb-error (token left stream) (error 'too-many token)) (defun premterm-err (token stream) (error 'premature-termination-of-input token)) (defmac (defprops form) (defun loop (l result) (if (null? l) `(begin ,@result) (loop (cddr l) `((putprop ',(cadr form) ',(cadr l) ',(car l)) ,@result)))) (loop (cddr form) nil)) (defprops $ lbp -1 nud premterm-err) (defprops COMMA lbp 10 nud delim-err) (defprops ] nud delim-err led erb-err lbp 5) (defprops [ nud open-paren-nud led open-paren-led lbp 200) (defprops if nud if-nud rbp 45) (defprops then nud delim-err lbp 5 rbp 25) (defprops else nud delim-err lbp 5 rbp 25) (defprops - nud parse-prefix led parse-nary lbp 100 rbp 100) (defprops + nud parse-prefix led parse-nary lbp 100 rbp 100) (defprops * led parse-nary lbp 120) (defprops = led parse-infix lbp 80 rbp 80) (defprops ** lbp 140 rbp 139 led parse-infix) (defprops := led parse-infix lbp 80 rbp 80) (defprops / led parse-infix lbp 120 rbp 120) (defprops > led parse-infix lbp 80 rbp 80) (defprops < led parse-infix lbp 80 rbp 80) (defprops >= led parse-infix lbp 80 rbp 80) (defprops <= led parse-infix lbp 80 rbp 80) (defprops not nud parse-prefix lbp 70 rbp 70) (defprops and led parse-nary lbp 65) (defprops or led parse-nary lbp 60) (defun open-paren-nud (token stream) (if (eq (peek-token stream) ']) nil (let ((right (prsmatch '] stream))) (if (cdr right) (cons 'sequence right) (car right))))) (defun open-paren-led (token left stream) (cons (header left) (prsmatch '] stream))) (defun if-nud (token stream) (define pred (parse (rbp token) stream)) (define then (if (eq? (peek-token stream) 'then) (parse (rbp (read-token stream)) stream) (error 'missing-then))) (if (eq? (peek-token stream) 'else) `(if ,pred ,then ,(parse (rbp (read-token stream)) stream)) `(if ,pred ,then))) ---- END OF PRATT.SCM ----  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Feb 90 13:53:38 EST Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12679; 5 Feb 90 13:05 EST Received: from uunet.uu.net by life.ai.mit.edu (4.0/AI-4.10) id AA10081; Mon, 5 Feb 90 12:43:03 EST Received: from unido.Informatik.Uni-Dortmund.DE by uunet.uu.net (5.61/1.14) with SMTP id AA20635; Mon, 5 Feb 90 12:42:04 -0500 Received: from heike.informatik.uni-dortmun (heike-fbi) (3238) by unido.informatik.uni-dortmund.de for uunet id AS08684; Mon, 5 Feb 90 18:40:20 +0100 From: Holger Muenx Date: Mon, 5 Feb 90 18:41:57 +0100 Message-Id: <9002051741.AA03862@heike.informatik.uni-dortmund.de> To: scheme@ai.mit.edu Hi! Thanks to all who answered to my request for scheme on the Amiga. Although there are some implementations for the Amiga or at least simple to port to the Amiga I decided to write my own scheme. Now there is the next problem. No question of minor programming difficulties but a severe implementation decision. It's about tail recursion. I think there were some discussions about that. At first, it is possible to implement scheme that tail recursions (means recursions of iterative nature, needing only a constant amount of memory) really work without allocating new memory during every recursive application. In Abelson + Sussman it is said it is possible and I think in MIT-Scheme it is done. But HOW can it be done? I think the problem is to determine in every application of a compound procedure if it is the last command which is evaluated in a procedure. For example, the following is obviously tail recursive: (define (dummy x) (print x) (dummy (1+ x))) There it is simple to test if (dummy ...) is the last evaluated expression. But this example is senseless and in real programming it would never occur. (define (dummy x) (if (< x 10) (dummy (1+ x)) 'DONE)) Here you cannot immedeatly see if (dummy ...) is the last evaluated expression. In some way you have to analyze the meaning of the procedure. To my opinion it is not enough to test additional in special forms like 'if' or 'cond' if the application is the last evaluated expression in this form because after the 'if' or 'cond' clause there can be other expressions to be evaluated. Don't know if you see my problem and if there is a simple solution for it. Today I asked a professsor and a doctor here at UniDo but both couldn't help me. Thank you for your interest. Ciao, -Holger ------------------------------------------------------------------------------ Holger Muenx muenx@heike.informatik.uni-dortmund.de IRB, UniDo 4600 Dortmund West-Germany  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Feb 90 03:34:17 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa17090; 5 Feb 90 2:14 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA19672; Mon, 5 Feb 90 01:19:15 EST 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: 5 Feb 90 05:26:27 GMT From: Rusty Haddock Organization: 1/entropy Subject: Re: Scheme for the Amiga Message-Id: <305@fe2o3.UUCP> References: <9002021501.AA24590@heike.informatik.uni-dortmund.de>, <304@fe2o3.UUCP> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu In article <304@fe2o3.UUCP> rusty%fe2o3@mimsy.umd.edu (Rusty Haddock) writes: >... The source is about 700K >(uncompressed) and the Amiga executable is about 90K. Oops. That 700K figured in the .o (object files). The sources alone come to about 450K bytes. Sorry about that. -Rusty- -- Rusty Haddock o {uunet,att,rutgers}!mimsy.umd.edu!fe2o3!rusty Laurel, Maryland o "IBM sucks silicon!" -- PC Banana Jr, "Bloom County"  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Feb 90 01:21:54 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa14876; 5 Feb 90 1:14 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA16996; Mon, 5 Feb 90 00:22:45 EST 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: 5 Feb 90 04:52:42 GMT From: Rusty Haddock Organization: 1/entropy Subject: Scheme for the Amiga Message-Id: <304@fe2o3.UUCP> References: <9002021501.AA24590@heike.informatik.uni-dortmund.de> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes: > Hi! Hello! > So my question: Is there any smaller version of MIT-Scheme. If yes: where > can I get it? Or do you know anyone who tried to port Scheme to an Amiga? Well, there's XScheme but it has nothing to do with MIT-Scheme. XScheme is in C and was written by the same person (David Betz) that wrote XLisp. The XScheme that I've gotten to compile on the Amiga is version 0.20 and runs fairly well with my '020. I downloaded the sources from the MIPS Magazine's BBS*. The source is about 700K (uncompressed) and the Amiga executable is about 90K. The original source was intended for the Lattice C compiler but I have added some small changes so that it would compile with Manx 3.6 (sorry, no 5.0 yet). I could make everything ftp-able if you (or anyone else) want. -Rusty- * David Betz _may_ be reached at the MIPS Magazine BBS +1 (603) 882-1599, 2400BAUD, 8-N-1 This BBS also carries the latest versions of XLisp and XScheme. -- Rusty Haddock o {uunet,att,rutgers}!mimsy.umd.edu!fe2o3!rusty Laurel, Maryland o "IBM sucks silicon!" -- PC Banana Jr, "Bloom County"  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 3 Feb 90 19:03:46 EST Received: from att-in.att.com by mintaka.lcs.mit.edu id aa13845; 3 Feb 90 19:01 EST From: listen@ihlpn.att.com Date: Sat, 3 Feb 90 03:14 CST To: Scheme@lcs.mit.edu Message-ID: <9002031901.aa13845@mintaka.lcs.mit.edu> remote execution [uucp job ihlpnA0539 (2/3-3:14:41)] rmail command exited with status 1 - denied by unix  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 2 Feb 90 20:15:27 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa01069; 2 Feb 90 20:09 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA05032; Fri, 2 Feb 90 18:51:17 EST 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: 2 Feb 90 09:46:37 GMT From: Niels Mayer Organization: Hewlett-Packard Labs, Software Technology Lab, Palo Alto, CA. Subject: Re: X bindings in Scheme [long] Message-Id: <4761@hplabsz.HPL.HP.COM> References: <9002011531.AA14140@tub.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu >> Actually, what I'd like is Xt (or, even better, Motif) from Scheme. It >> would be even better to be able to write widgets in Scheme! The problem >> is that the architecture of Xt involves a lot of callbacks, and, >> generally (unless you're using the DECWRL compiler) you can't call >> Scheme from C. Well it's not quite scheme, but.... WINTERP is similar to Elk, but is based on XLISP. It features XLISP OOP interface to the Motif widgets; a serverized lisp listener that handles lisp events and X events simultanously; allows fully interactive language-based or direct manipulation of widgets. WINTERP is designed to provide a gnuemacs-like rapid prototyping environment, and XLISP makes it easy to call LISP-->C or C-->LISP. The OOP style of widget programming enabled by winterp is quite nifty as it lets you subclass widgets in Lisp, override methods, or add new methods. For an example, I've included a simple file-search browser that is built off of the unix grep(1) and a subclassed Motif list widget... other other examples include a bitmap browser that sets your rootmap, a mh-based mail browser, menus, etc. Get winterp from contrib/clients/winterp on the X11r4 tape-2 (be sure to get contrib/R4fixes/winterp/patch-0), or get it via anonymous ftp from expo.lcs.mit.edu directory contrib/winterp; files winterp.tar.Z, winterp.README. contrib/winterp/winterp.binaries contains binaries for HP machines. ; -*-Lisp-*- ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; File: grep-br.lsp ; RCS: $Header: grep-br.lsp,v 1.1 89/11/25 04:00:19 mayer Exp $ ; Description: A transformation of mail-br.lsp into a search browser using the ; unix grep command. Evaluate the form '(grep-browser)' to bring ; up the application. ; Author: Niels Mayer, HPLabs ; Created: Mon Nov 20 18:13:23 1989 ; Modified: Sat Nov 25 01:04:49 1989 (Niels Mayer) mayer@hplnpm ; Language: Lisp ; Package: N/A ; Status: X11r4 contrib tape release ; ; (c) Copyright 1989, Hewlett-Packard Company. ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; Make a subclass of XM_LIST_WIDGET_CLASS which holds an additional ;; instance variable 'items'. 'items' is an array of arbitrary objects ;; (BROWSER_OBJECT) to be displayed in a browser made from the list widget. ;; ;; BROWSER-OBJECT can be any arbitrary xlisp object that responds to ;; the message :display_string. ;; ;; Message :display_string must return a string which is used as the ;; textual representation of the object in the browser display. ;; (setq List_Browser (send Class :new '(items) ;new instance vars '() ;no class vars XM_LIST_WIDGET_CLASS)) ;superclass ;; ;; We add a method to set the items browsed by the list browser ;; and set the 'items' instance variable. ;; ;; (send List_Browser :set_browser_items ) ;; is a list of BROWSER_OBJECTs as described above. ;; (send List_Browser :answer :SET_BROWSER_ITEMS '(items_list) '( (let* ( (items_end_idx (length items_list)) (display_items (make-array items_end_idx))) ;; initialize the 'items' instance variable so that it ;; holds all the BROWSER_OBJECTs passed in (setq items (make-array items_end_idx)) ;create the array (do ( ;copy elts from list to array (i 0 (1+ i)) (elts items_list (cdr elts))) ;; loop till no more elts ((null elts)) ;; loop body (setf (aref items i) (car elts)) (setf (aref display_items i) (send (car elts) :display_string)) ) ;; initialize the widget, passing in the browser items. (send self :set_values :xmn_items display_items :xmn_item_count items_end_idx ) ) ) ) ;; ;; Given a List Widget position, this returns the object associated ;; with that position. Note that the first item is at position 1. ;; (send List_Browser :answer :GET_ITEM_AT_POSITION '(position) '( (aref items (1- position)) )) ;; ;; override methods on XM_LIST_WIDGET_CLASS so that they work properly ;; with the list browser. Note that all other list methods work fine ;; on the list browser ;; (send List_Browser :answer :ADD_ITEM '(item position) '( (setq items (array-insert-pos items (1- position) item)) (send-super :add_item (send item :display_string) position) ) ) (send List_Browser :answer :ADD_ITEM_UNSELECTED '(item position) '( (setq items (array-insert-pos items (1- position) item)) (send-super :add_item_unselected (send item :display_string) position) ) ) (send List_Browser :answer :DELETE_ITEM '(item) '( ;; this is too lame to implement... requires that we compare ;; item with the result of :display_string done on every element ;; of ivar 'items' (error "Message :DELETE_ITEM not supported in List_Browser") ) ) (send List_Browser :answer :DELETE_POS '(position) '( (setq items (array-delete-pos items (1- position))) (send-super :delete_pos position) ) ) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Define a BROWSER_OBJECT ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; Each BROWSER_OBJECT holds the information summarizing one mail message. ;; the information is split up into individual fields because we may want ;; to be able to sort on one field, or search for mathes on one field. ;; (setq Grep_Item_Class (send Class :new '(file-name line-num match-line) )) ;; this method will read a single line of grep output. ;; and sets the instance variables in the ;; BROWSER_OBJECT to the individual fields of the grep output (send Grep_Item_Class :answer :read-grep-info '(pipe) '( (if (and (setq file-name (fscanf-string pipe "%[^:]:")) (setq line-num (fscanf-fixnum pipe "%d:")) (setq match-line (fscanf-string pipe "%[^\n]\n")) ) self ;return self if succesful NIL ;return NIL if hit EOF ) ) ) (send Grep_Item_Class :answer :display_string '() '( (format nil "~A: ~A" file-name match-line) )) (send Grep_Item_Class :answer :file-name '() '( file-name )) (send Grep_Item_Class :answer :line-num '() '( line-num )) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; This returns a list of Grep_Item_Class instances corresponding ;; to the items matching the search pattern and file list given ;; in argument ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (defun grep (grep-arg-string) (do* (;; loop variables, initializers, and increments. (fp (popen (strcat "grep -n " grep-arg-string " /dev/null") :direction :input)) (line (send (send Grep_Item_Class :new) :read-grep-info fp) (send (send Grep_Item_Class :new) :read-grep-info fp)) (result '()) ;init to an empty list ) ;; loop test and return ((null line) ; :read-grep-info returns NIL on EOF (pclose fp) result ;return list of grep objects. ) ;; loop body (setq result (nconc result (cons line NIL))) ;append grep-obj to list ) ) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; The Main program -- note that this doesn't use any global variables, so ;; you can have many grep browsers up all at once without having them ;; interact. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (defun grep-browser() (let ( top_w paned_w controlpanel_w doit_button_w search_label_w search_editor_w files_label_w files_editor_w list_w filename_label_w viewtext_w ) (setq top_w (send TOP_LEVEL_SHELL_WIDGET_CLASS :new :XMN_TITLE "Grep Browser" :XMN_ICON_NAME "Grep Browser" )) (setq paned_w (send XM_PANED_WINDOW_WIDGET_CLASS :new :managed top_w )) (setq controlpanel_w (send XM_ROW_COLUMN_WIDGET_CLASS :new :managed paned_w :XMN_ADJUST_LAST t :XMN_ORIENTATION :HORIZONTAL :XMN_PACKING :PACK_TIGHT :XMN_NUM_COLUMNS 1 )) (setq doit_button_w (send XM_PUSH_BUTTON_WIDGET_CLASS :new :managed controlpanel_w :XMN_LABEL_STRING "DO SEARCH" )) (setq search_label_w (send XM_LABEL_WIDGET_CLASS :new :managed controlpanel_w :XMN_LABEL_STRING "Search for string:" )) (setq search_editor_w (send XM_TEXT_WIDGET_CLASS :new :managed controlpanel_w :XMN_EDIT_MODE :SINGLE_LINE_EDIT)) (setq files_label_w (send XM_LABEL_WIDGET_CLASS :new :managed controlpanel_w :XMN_LABEL_STRING "From Files:" )) (setq files_editor_w (send XM_TEXT_WIDGET_CLASS :new :managed controlpanel_w :XMN_EDIT_MODE :SINGLE_LINE_EDIT)) (setq list_w (send List_Browser :new :managed :scrolled "browser" paned_w :xmn_visible_item_count 20 )) (setq filename_label_w (send XM_LABEL_WIDGET_CLASS :new :managed "label" paned_w :xmn_label_string "None" )) (setq viewtext_w (send XM_TEXT_WIDGET_CLASS :new :managed :scrolled "view" paned_w :XMN_EDIT_MODE :MULTI_LINE_EDIT :XMN_HEIGHT 400 :XMN_EDITABLE nil ;don't allow user to change text. )) (send top_w :realize) ;; ;; set contraint resources on controlpanel so that paned window ;; doesn't give it resize sashes. ;; (let (height) (send controlpanel_w :get_values :xmn_height 'height) (send controlpanel_w :set_values :xmn_maximum height :xmn_minimum height ) ) ;; ;; set contraint resources on label widget so that paned window ;; doesn't give it resize sashes. ;; (let (height) (send filename_label_w :get_values :xmn_height 'height) (send filename_label_w :set_values :xmn_maximum height :xmn_minimum height ) ) ;; ;; The doit_button initiates a grep search. ;; (send doit_button_w :add_callback :XMN_ARM_CALLBACK '() `( (send list_w :set_browser_items (grep (strcat "'" ;quotify string to protect from shell (send ,search_editor_w :get_string) ;string to search for "' " (send ,files_editor_w :get_string)) ;wildcarded files )) )) ;; ;; set up a callback on the list widget initialized above such that ;; a double click on the browser-item will browse the object. ;; (send list_w :add_callback :xmn_default_action_callback '(callback_item_position) `( (let* ((browsed-object (send ,list_w :get_item_at_position callback_item_position)) (filename (send browsed-object :file-name)) (linenum (send browsed-object :line-num)) ) (send ,filename_label_w :set_values :xmn_label_string filename) (send ,filename_label_w :update_display) ;incase reading file takes long time (send ,viewtext_w :find_file filename linenum) )) ) )) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Add a :FIND_FILE method to the Motif Text widget. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (send XM_TEXT_WIDGET_CLASS :answer :FIND_FILE '(filename linenum) '( (let* (;; loc vars (fp (open filename :direction :input) ) inspos text_line ) (if (null fp) (error "Can't open file." filename)) (send self :set_string "") ;clear out old text (send self :disable_redisplay NIL) ;don't show changes till done (loop (if (null (setq text_line (read-line fp))) (return)) (setq inspos (send self :get_insertion_position)) (send self :replace inspos inspos (strcat text_line "\n")) ) (send self :scroll linenum) ;make be the top of screen (send self :enable_redisplay) ;now show changes... (close fp) ) ) ) ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 2 Feb 90 17:25:38 EST Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24424; 2 Feb 90 17:18 EST Received: from zurich.ai.mit.edu ([18.43.0.251]) by life.ai.mit.edu (4.0/AI-4.10) id AA23963; Fri, 2 Feb 90 17:18:56 EST Received: from localhost by zurich.ai.mit.edu; Fri, 2 Feb 90 17:18:38 est Date: Fri, 2 Feb 90 17:18:38 est From: "Sameer E. Shalaby" Message-Id: <9002022218.AA03417@zurich.ai.mit.edu> To: scheme@zurich.ai.mit.edu Subject: YACC Is there a YACC version written in Scheme or Lisp? Thank you. - Sameer -  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 2 Feb 90 14:42:23 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa11937; 2 Feb 90 12:02 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA18262; Fri, 2 Feb 90 11:12:23 EST 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: 2 Feb 90 16:09:31 GMT From: Sho-Huan Simon Tung Organization: Indiana University, Bloomington Subject: Re: X bindings in Scheme? Message-Id: <34721@iuvax.cs.indiana.edu> References: <9001311838.AA02827@jove.pa.dec.com>, <6599@ubc-cs.UUCP> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu In article <6599@ubc-cs.UUCP> manis@cs.ubc.ca (Vincent Manis) writes: >Actually, what I'd like is Xt (or, even better, Motif) from Scheme. It >would be even better to be able to write widgets in Scheme! The problem >is that the architecture of Xt involves a lot of callbacks, and, >generally (unless you're using the DECWRL compiler) you can't call >Scheme from C. I have found a way to get around the problem. The trick is: - use a vector to store the Scheme callback functions and client_data. - use the index to the vector to communicate between Scheme and C. - use a "standard_callback" function (written in C). standard_callback's client data will always be the index to the vector. If this callback is called by Xt it simply set a few flags which indicates information about widget-id, client_data (the index), and call_data. - XtMainloop need to be written in Scheme which simply polls the flags while looping. (if callback occured, use the index to find the Schems callback function and call it with the desired data.) Simon Tung Department of Computer Science Indiana University  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 2 Feb 90 14:35:08 EST Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa08752; 2 Feb 90 10:34 EST Received: from uunet.uu.net by life.ai.mit.edu (4.0/AI-4.10) id AA16185; Fri, 2 Feb 90 10:02:41 EST Received: from unido.Informatik.Uni-Dortmund.DE by uunet.uu.net (5.61/1.14) with SMTP id AA15440; Fri, 2 Feb 90 10:02:07 -0500 Received: from heike.informatik.uni-dortmun (heike-fbi) (2636) by unido.informatik.uni-dortmund.de for uunet id AP14129; Fri, 2 Feb 90 15:59:29 +0100 From: Holger Muenx Date: Fri, 2 Feb 90 16:01:19 +0100 Message-Id: <9002021501.AA24590@heike.informatik.uni-dortmund.de> To: scheme@ai.mit.edu Hi! I just looked at the sources of MIT-Scheme because I thought of porting it to an Amiga. (Yes, yes, I know, you are only working on REAL computers. But I think there are many students who have an Amiga and want to have a scheme for it. At least in Dortmund there is a demand for scheme on an Amiga as the beginner's course is about scheme.) The problem is that your scheme is very big (maybe huge is the better word) so there is no possibility to transfer it to my Amiga. I must copy it via kermit to an ST and after that it can be copied to my Amiga - for all sources this would take hours. So my question: Is there any smaller version of MIT-Scheme. If yes: where can I get it? Or do you know anyone who tried to port Scheme to an Amiga? Sorry for my horrible English, thank you for your interest, ciao -Holger ----------------------------------------------------------------------------- Holger Muenx muenx@heike.informatik.uni-dortmund.de IRB Universitaet Dortmund 4600 Dortmund West-Germany  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 2 Feb 90 14:34:26 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa08576; 2 Feb 90 10:28 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA14248; Fri, 2 Feb 90 10:05:24 EST 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: 2 Feb 90 13:15:39 GMT From: Richard Kennaway CMP RA Organization: University of East Anglia, Norwich Subject: Re: Combinators & Compilation Message-Id: <1282@sys.uea.ac.uk> References: <387CZXC@cs.swarthmore.edu> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu In message <387CZXC@cs.swarthmore.edu>, taylor@cs.swarthmore.edu (Brian Taylor) writes: > I'd also appreciate references to any particularly valuable articles in the > literature providing a theoretical justification for the use of graph > reduction in the interpretation of combinatory logic and lambda calculus. I wont attempt to rank the following references by value, but here are those I know of, besides the two cited by Taylor. For graph reduction of the lambda calculus, the original reference is %A Wadsworth, C. %T Semantics and pragmatics of the lambda calculus %R D.Phil. thesis %I Programming Research Group, Oxford University %D 1971 %X address of PRG is 8-11 Keble Road, Oxford OX1 3QD, U.K. This describes a graph rewriting implementation of lambda calculus and proves it correct. It does not achieve "optimal" sharing in Levy's sense (see Barendregt's book on the lambda calculus for what this means); this has recently been done by: %A Lamping, John %T An algorithm for optimal lambda calculus reduction %B POPL 90 conference %D 1990 January %A Lamping, John %T An algorithm for optimal lambda calculus reduction %R unpublished %I Xerox PARC %D 1989 %X A longer version of the POPL paper, with more proofs. The question of whether the bookkeeping overhead with Lamping's method outweighs the improvement in sharing it gains is not yet settled. For graph rewriting implementation of functional languages, see: %A Peyton-Jones, S.L. %T The Implementation of Functional Languages %I Prentice-Hall %D 1987 For the optimality properties of combinator graph reduction, there is a series of three papers by Staples (which actually prove it for regular term graph rewrite systems, of which combinatory logic is an example). %A Staples, John %T Computation on graph-like expressions %J Th.Comp.Sci. %V 10 %P 171-185 %D 1980 %A Staples, John %T Optimal evaluations of graph-like expressions %J Th.Comp.Sci. %V 10 %P 297-316 %D 1980 %A Staples, John %T Speeding up subtree replacement systems %J Th.Comp.Sci. %V 11 %P 39-47 %D 1980 Other references for the correctness of combinator graph reduction: %A Lester, David %T Combinator graph reduction: a congruence and its applications %R D.Phil thesis, Technical Monograph PRG-73 %D 1989 %I Programming Research Group, Oxford University %X (from the abstract) "This thesis may be read as a formal mathematical proof that the G-machine is correct with respect to a denotational semantic specification of a simple language. ... The G-machine is shown to be a representation of the combinator graph reduction operational model." %A Farmer, William M. %A Ramsdell, John D. %A Watro, Ronald J. %T A correctness proof for combinator reduction with cycles %R Report M88-53 %I MITRE %D 1988 November %A Farmer, William M. %A Watro, Ronald J. %T Redex capturing in term graph rewriting %R unpublished %I MITRE %D 1989 June 16 The address of MITRE is: The MITRE Corporation Bedford Massachusetts U.S.A. There are two papers using category theory to prove the same result: %A Raoult, J.C. %T On graph rewritings %J Th.Comp.Sci. %V 32 %P 1-24 %D 1984 %A Kennaway, J.R. %T On 'On graph rewritings' %J Th.Comp.Sci. %V 52 %P 37-58 %D 1987 %X See also the minor corrigendum in v.61, pp.317-320 (but only if you really need to study the proofs in detail). The paper Taylor cited by van den Broek and van der Hoeven is based on a different category-theoretic approach to general graph rewriting, developed by the 'Berlin school' - see various papers in the following volumes: Proc. (1st, 2nd, 3rd) Int. Workshop on Graph Grammars and their application to computer science, eds. H.Ehrig et al (different als for the three volumes) 1978, 1982, 1986 Springer-Verlag LNCS 73, 153, 291 There will be a 4th conference in this series in Bremen, March 5-9 this year. Proc. Int. Workshop WG80 on Graph Theoretic Concepts in Computer Science ed. H. Noltemeier Springer-Verlag LNCS 100, 1980. These conferences are concerned with graph rewriting in general, not just the particular application to functional language implementation. For the latter, see Proc. Workshop on Graph Reduction eds. J.H. Fasel and R.M.Keller Springer-Verlag LNCS 279, 1986. There is also a paper either by v.d.Broek and v.d.Hoeven or their colleagues at Twente on the relationship between the two different category-theoretic definitions, but I can't find the exact reference at the moment. The subject is also discussed in Revesz's book "Lambda-calculus, Combinators, and Functional Programming". It's some time since I last saw someone ask what LNCS means, but just in case, it stands for "Lecture Notes in Computer Science". -- Richard Kennaway SYS, University of East Anglia, Norwich, U.K. Internet: jrk@sys.uea.ac.uk uucp: ...mcvax!ukc!uea-sys!jrk  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 2 Feb 90 00:33:40 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20513; 2 Feb 90 0:28 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA14518; Thu, 1 Feb 90 23:17:20 EST 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: 1 Feb 90 20:44:29 GMT From: Cris Perdue Organization: Sun Microsystems, Mountain View Subject: Re: Scheme as a standard extension language Message-Id: <131091@sun.Eng.Sun.COM> References: <1486@viewlog.UUCP>, <1990Jan27.222837.3997@odi.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Dan, It is possible in principle to make small Common Lisp applications by using just part of the language, but there is a problem. Common Lisp defines no layers, so it is impossible to decide which parts of the language can be avoided to reduce the size of an application. I believe that most implementations are rather intertwined: support for one language feature tends to rely on more of the rest of the language than one might imagine. Many of these dependencies can be eliminated if need be, and if we know which ones to eliminate. One big advantage of Scheme is that the base language is such a layer. Also, when one uses a language plus a set of libraries, it is usually possible to find out the dependencies among the libraries and to find out what features require large amounts of runtime support. This is in addition to the benefits Scheme provides by not carrying around a lot of features for backward compatibility. The implementations become smaller and the language becomes intellectually simpler and cleaner.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 1 Feb 90 15:23:38 EST Received: from iuvax.cs.indiana.edu by mintaka.lcs.mit.edu id aa01983; 1 Feb 90 15:17 EST Received: by iuvax.cs.indiana.edu Date: Thu, 1 Feb 90 15:16:59 -0500 From: Chris Haynes To: rrrs-authors@mc.lcs.mit.edu, scheme-standard@wheaties.ai.mit.edu, scheme@mc.lcs.mit.edu Subject: Scheme standard balloting Message-ID: <9002011517.aa01983@mintaka.lcs.mit.edu> This note is for those who are interested in balloting on the IEEE draft standard for Scheme. As noted in the recently posted minutes, there was consensus at the 4th Scheme standardization meeting that the draft (with minor revision) is ready for public comment and balloting. If things proceed on schedule, the IEEE Microprocessor Standards Committee (MSC) will approve the draft for balloting at their March 12th meeting and ballots will be mailed about April 1st. At least 75% of the ballots must be returned within 30 days for the ballot to be valid, and at least 75% of the non-abstention ballots must be affirmative for the draft to become a standard. (If all goes smoothly, the draft could then be approved as an IEEE standard on September 28th.) Membership in the balloting group may be requested by emailing the form at the end of this note to camp@csc.ti.com. That's Clyde Camp, the MSC chair. If necessary, his mail address is: Texas Instruments, Inc., 2313 Merrimac Dr., Plano, TX 75075. Comments on draft standards are welcome from anyone, whether they participate in balloting or not. On the request form for balloting group membership, if you are significantly involved in developing or maintaining a Scheme implementation, interest category P1178-p is appropriate. If you do a great deal of programming in Scheme, P1178-u is appropriate. Otherwise, P1178-gi is appropriate---this should include most academics (such as myself) who use Scheme for teaching and research. If more than one category is appropriate, you may pick any one that is. However, in choosing a category, you may wish to keep in mind the following IEEE (and ANSI) rule: for balloting to be valid, not more than 50% of the ballots may be from individuals in the same interest category, except for the general interest category, on which there is no limit. Thus, when in doubt, it may be best to choose P1178-gi. With few exceptions, balloting body members must be IEEE or IEEE Computer Society (CS) members. You do not have to be a member at the time you request membership on the balloting body, but you have to be a member before your ballot is returned, and it takes 3 to 6 weeks for membership applications to be processed. Thus if you want to be in the balloting body and you are not already an IEEE or CS member, YOU MUST APPLY FOR MEMBERSHIP SOON. Membership information and applications may be obtained by calling 800-678-IEEE or 201-562-5528. IEEE membership is $77, but ACM members can join the CS for only $13. If you can locate an officer of a local chapter of the IEEE or CS, they should have applications. You may also email Clyde Camp (camp@csc.ti.com) a request and he will FAX you a CS application. CS membership applications may be FAXed (both sides, with credit card information) to David Barber at 714-821-4010. Alternatively, CS applications with check/cash/money order/plastic number can be mailed, for rapid processing, in to: IEEE Computer Society 10662 Los Vaqueros Circle Los Alamitos, CA 90720-2578 Attn: David Barber Applications must be signed by an existing IEEE or CS member (as a "recommender"). If you can't find such a person locally, you may send your application to me and I will provide the signature. Christopher Haynes, Scheme Working Group Chair Computer Science Department Indiana University Bloomington, IN 47405 Phone: 812-855-33767 Fax: 812-855-4829 Internet: chaynes@iuvax.cs.indiana.edu ======================== CUT HERE =================================== ================================================================= = Sponsor Application Form = = for = = Microcomputer and Microprocessor Standards Subcommittee = ================================================================= Instructions/notes: 1) The fields marked * are optional, but they help us locate you if there is a problem. 2) If you have applied but not yet received a membership number from the IEEE or Computer Society, please enter the application date in that field. 3) There is no additional fee for Sponsor Membership 4) Under interest, put P1178-gi for general interest/academic P1178-u for user P1178-p for producer P1178-0 for other (and specify other) Name: Title: Company: Street Address: City,State: Zip-code: Country: USA Business Phone: *Home Phone: *FAX Phone: IEEE/CS Membership Number: *E-mail address: Interests: P1178 YES___ NO___ Please add me to the MSC mailing list YES___ NO___ I am interested in other language related standards. YES___ NO___ I am interested in other bus related standards. YES___ NO___ I am interested in other microprocessor related standards.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 1 Feb 90 10:40:01 EST Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa22567; 1 Feb 90 10:36 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 1130; Thu, 01 Feb 90 10:37:22 EST Received: from DB0TUI6.BITNET (NET) by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 0975; Thu, 01 Feb 90 10:37:21 EST Received: by tub.UUCP; Thu, 1 Feb 90 16:31:13 +0100; AA14140 Date: Thu, 1 Feb 90 16:31:13 +0100 From: Oliver Laumann Message-Id: <9002011531.AA14140@tub.UUCP> To: Scheme@lcs.mit.edu Subject: Re: X bindings in Scheme [long] Cc: manis@cs.ubc.ca > Actually, what I'd like is Xt (or, even better, Motif) from Scheme. It > would be even better to be able to write widgets in Scheme! The problem > is that the architecture of Xt involves a lot of callbacks, and, > generally (unless you're using the DECWRL compiler) you can't call > Scheme from C. The `Elk' Scheme interpreter provides an interface to the Motif widget set. It allows you to interactively `explore' the Motif widgets. Here is a small example program that allows you to set up and use Motif pulldown, popup, and option menus: ----------------------------------------------------------------- ;;; -*-Scheme-*- (define (create-menu type parent args) (define grand-parent (widget-parent parent)) (if (and (not (eq? grand-parent 'none)) (eq? (widget-class grand-parent) (find-class 'menu-shell))) (set! parent grand-parent)) (let ((shell (create-popup-shell (find-class 'menu-shell) parent 'width 100 'height 100))) (apply create-widget (find-class 'row-column) shell 'row-column-type type args))) (define (create-popup-menu parent . args) (create-menu 'menu-popup parent args)) (define (create-pulldown-menu parent . args) (create-menu 'menu-pulldown parent args)) (define (create-option-menu parent . args) (apply create-managed-widget (find-class 'row-column) parent 'row-column-type 'menu-option args)) (define (create-cascade-pulldown parent pulldown . args) (let ((button (create-managed-widget (find-class 'cascade-button) parent))) (set-values! button 'sub-menu-id pulldown) (apply set-values! button args) button)) (define (menu-add-item! type menu args) (let ((item (create-managed-widget (find-class type) menu))) (apply set-values! item args) item)) (define (menu-add-label! menu . args) (menu-add-item! 'label menu args)) (define (menu-add-separator! menu . args) (menu-add-item! 'separator menu args)) (define (menu-add-button! menu . args) (menu-add-item! 'push-button menu args)) ----------------------------------------------------------------- The following is a small example how you would use the above module to create a popup menu: ----------------------------------------------------------------- (require 'motif) (load-widgets shell row-column cascade-button push-button label separator drawing-area) (load 'menu-stuff) (define con (create-context)) (define dpy (initialize-display con #f 'popup 'demo)) (define top (create-shell 'popup 'demo (find-class 'application-shell) dpy)) (define w (create-managed-widget (find-class 'drawing-area) top)) (set-values! w 'width 350 'height 100) (define menu (create-popup-menu w 'which-button 1)) (menu-add-label! menu 'label-string "Popup menu" 'font-list "9x15") (menu-add-separator! menu) (menu-add-button! menu 'label-string "item 1") (menu-add-button! menu 'label-string "item 2") (menu-add-button! menu 'label-string "item 3") (menu-add-separator! menu) (define quit-button (menu-add-button! menu 'label-string "quit")) (add-callback quit-button 'activate-callback (lambda args (exit))) (popup-menu-attach-to! menu w) (realize-widget top) (context-main-loop con) ----------------------------------------------------------------- If you have any questions about Elk drop me a letter. Regards, -- Oliver Laumann net@TUB.BITNET net@tub.cs.tu-berlin.de net@tub.UUCP  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 31 Jan 90 17:22:00 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa17352; 31 Jan 90 17:14 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA28239; Wed, 31 Jan 90 16:58:42 EST 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: 31 Jan 90 21:53:28 GMT From: Vincent Manis Organization: Bucky Bits Cereal Keyboards, Ltd. Subject: Re: X bindings in Scheme? Message-Id: <6599@ubc-cs.UUCP> References: <9001311838.AA02827@jove.pa.dec.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Xlib is pretty easy to call from your favourite Scheme. I'm desultorily working on a simple Xlib interface from Chez Scheme; and MIT CScheme has (almost?) full Xlib support as well, as I recollect. Any Scheme which allows you to call C procedures will support Xlib ok. Actually, what I'd like is Xt (or, even better, Motif) from Scheme. It would be even better to be able to write widgets in Scheme! The problem is that the architecture of Xt involves a lot of callbacks, and, generally (unless you're using the DECWRL compiler) you can't call Scheme from C. Has anybody had any thoughts on this? -- \ Vincent Manis "There is no law that vulgarity and \ Department of Computer Science literary excellence cannot coexist." /\ University of British Columbia -- A. Trevor Hodge / \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 31 Jan 90 16:24:43 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa14818; 31 Jan 90 16:15 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA24901; Wed, 31 Jan 90 15:51:58 EST 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: 31 Jan 90 17:40:21 GMT From: Richard Kennaway CMP RA Organization: University of East Anglia, Norwich Subject: Re: Combinators & Compilation Message-Id: <1277@sys.uea.ac.uk> References: <387CZXC@cs.swarthmore.edu>, <4232@brahma.cs.hw.ac.uk> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <4232@brahma.cs.hw.ac.uk> greg@cs.hw.ac.uk (Greg Michaelson) writes: >Indeed, is there any evidence that graph reduction will ever be as time/space >efficient as traditional compilation techniques for functional languages >on Von Neumann architectures? Surely graph reduction *is* the traditional technique. What did you have in mind? -- Richard Kennaway SYS, University of East Anglia, Norwich, U.K. Internet: jrk@sys.uea.ac.uk uucp: ...mcvax!ukc!uea-sys!jrk  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 31 Jan 90 16:18:33 EST Received: from iuvax.cs.indiana.edu by mintaka.lcs.mit.edu id aa14751; 31 Jan 90 16:13 EST Received: by iuvax.cs.indiana.edu Date: Wed, 31 Jan 90 16:11:55 -0500 From: Chris Haynes To: scheme-standard@wheaties.ai.mit.edu, rrrs-authors@MC.lcs.mit.edu, scheme@MC.lcs.mit.edu Subject: Minutes of the 4th Scheme standarization meeting Message-ID: <9001311613.aa14751@mintaka.lcs.mit.edu> IEEE/MCS/P1178 Working Group on Scheme Unapproved Minutes of the Fourth Meeting January 19, 1990, San Francisco, CA The meeting was called to order by Christopher Haynes at about 1:45PM. The attendees were: Norman Adams Xerox PARC Scott Burson Blue Space Foundation William Clinger University of Oregon Pavel Curtis Xerox PARC Ken Dickey Tektronix, Inc. Kent Dybvig Indiana University Marc Feeley Brandeis University Dan Friedman Indiana University Dick Gabriel Stanford University John Gateley Texas Instruments Jed Harris Apple Computer Christopher Haynes Indiana University Robert Hieb Indiana University Roger Kirchner Carleton College William Maddox U. of California at Berkeley Sidney Marshal Xerox James Miller Brandeis University John D. Ramsdell The MITRE Corporation Benjamin Schreiber Brandeis University Guy L. Steele, Jr Thinking Machines Inc 1. The agenda was amended; the changes are reflected by the minutes. 2. John D. Ramsdell was elected secretary. 3. Minutes of the third meeting were accepted with no changes. 4. Reports on R4RS, macros, and ISO. A. Report on R4RS. (Will Clinger) R4RS is complete except for the appendix describing macros and the bibliography. B. Report on the status of the macro committee. (Will Clinger) 1. Syntactic closures are out of favor. Chris Hanson attempted to implement EXTEND-SYNTAX using syntactic closures. The attempt was not entirely successful because of a previously unrecognized technical problem: in some cases an EXTEND-SYNTAX based on syntactic closures must know the syntactic role of an identifier before macro expansion has made that role apparent. 2. A proposal based on a descendent of hygienic macro expansion has some members of the macro committee confident that a resolution to the macro impasse is at hand. The current proposal is due to Jonathan Rees, who modified a proposal by Will Clinger, who based his proposal on Eugene Kohlbecker's Ph.D thesis work. C. Report on the International Standards Organization WG-16. (Dick Gabriel) WG-16 is not currently interested in Scheme as a basis for an international standard. 5. Quick review of IEEE standardization procedures. (Chris Haynes) Resolved: The chair will post instructions to the Scheme notesfiles on how to request membership in the balloting group for the Scheme standard. 6. Discuss draft P1178/D3. Many of the agenda items were entered by Sidney Marshall. A. Consensus: The editors should fix the introduction so that the definitions of "confirming implementation" and "conforming program" constrain the implementation to meet the standard. B. Consensus: No change is needed in the description on pg. 11 of the "evaluates to" symbol. C. Consensus: An editorial change shall be made to the section on disjoint types with "No object satisfies more than one ..." changed to "Every object satisfies at most one ...". D. Consensus: The restriction on duplicate entries in CASE key sets should be removed and the text updated to be consistent with the derived semantics. That is (case x ((3.14 3.14159) 'pi) (else '())) is fine on machines on which (eqv? 3.14 3.14159) => #t, and key lists are examined inorder to find the first match. E. Consensus: Add to the text a statement of the form "Assigning a new value to a variable defined in the initial environment does not affect the behavior of any procedure defined in the report." F. Consensus: Change reference 20 to the second edition of CLtL. G. Consensus: Change the description of remainder to correctly deal with the sign of negative zero. H. Consensus: References to unpublished works should be changed into references to published works. Ref 5 --> "The Theory of Numbers," by G H Hardy & E W Wright, Refs 17 --> William Clinger and Jonathan Rees (editors), The revised^4 report on the algorithmic language Scheme, University of Oregon Technical Report CIS-TR-90-02. Ref 22 --> Thinking Machines Technical Report by Guy Steele, Jr. Section 1.1 should refer to Steele's master's thesis (MIT AI-TR-474) for a definition of "properly tail recursive". The bracketed sentence at the end of Appendix C.3 should removed and the sentence preceding it changed to refer to William Clinger, How to read floating point numbers accurately, University of Oregon Technical Report CIS-TR-90-01. I. Withdrawn: The word "should" should be eliminated from text. J. Withdrawn: Definitions should be treated syntactically as expressions. K. Moved and rejected: Eliminate CALL-WITH-CURRENT-CONTINUATION from text. It was argued that elimination would encourage more people to use IEEE Scheme as their extension language, but others felt Scheme without CALL-WITH-CURRENT-CONTINUATION is simply not Scheme. The vote was three for and eleven against. L. Withdrawn: Change text so that "(BEGIN)" is a legal expression. M. Moved and rejected: A key set of a CASE form may not be empty. N. Moved and rejected: Remove named LET from the text. O. Discussed and rejected: All parts of lists generated by a quasiquote expression should be mutable. P. Moved and accepted: Change the text in the section on symbols to qualify some of the examples with the phrase "symbols as defined in this report". Q. Withdrawn: All conforming implementations must support a minimum number range. 6. Moved and unanimously accepted: After amendment to conform with the consensus of this meeting, and other changes deemed non-controversial by the editors, draft D3 should be submitted to the MSC for public comment and balloting. 7. Consensus: An ad hoc subcommittee of this working group will respond to public comments and negative ballots. The members of this committee will be Chris Hanson, James S. Miller, and John D. Ramsdell. Another meeting of the working group will be called if it is felt that the responses recommended by this subcommittee may be controversial. 8. Moved and accepted: This working group will terminate its activity when the draft is accepted as a standard, and will reform when necessary to revise the standard. 9. Moved and unanimously accepted: The committee thanks Christopher Haynes, the IEEE editors, David H. Bartley, Chris Hanson, and James S. Miller, and the RnRS editors, Will Clinger and Jonathan Rees. 10. Moved and accepted: Identify the standard draft editors in the text. The meeting adjourned at 5:45PM. -- Minutes by John D. Ramsdell, edited by Christopher Haynes.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 31 Jan 90 15:42:27 EST Received: from decpa.pa.dec.com by mintaka.lcs.mit.edu id aa13311; 31 Jan 90 15:36 EST Received: by decpa.pa.dec.com; id AA01026; Wed, 31 Jan 90 10:38:50 -0800 Received: by jove.pa.dec.com; id AA02827; Wed, 31 Jan 90 10:38:13 -0800 Message-Id: <9001311838.AA02827@jove.pa.dec.com> To: Scheme@lcs.mit.edu Cc: bartlett@wrl.dec.com Subject: Re: X bindings in Scheme? Date: Wed, 31 Jan 90 10:38:12 PST From: bartlett@wrl.dec.com The Scheme->C compiler and interpreter done at DECWRL provides Scheme interfaces to the C library for X11R3. If it's in "X Window System C Library and Protocol Reference", Scheifler, Gettys & Newman, then it's available. Using the interfaces, the "Hello World" program from Oliver Jone's book "Introduction to the X Window System" can be written: (define (HELLO-WORLD) (let* ((hello "Hello, World") (hi "Hi!") (dpy (let ((x (xopendisplay ""))) (if (null-pointer? x) (error 'hello-world "DISPLAY is not defined")) x)) (screen (xdefaultscreen dpy)) (background (xwhitepixel dpy screen)) (foreground (xblackpixel dpy screen)) (window (xcreatesimplewindow dpy (xdefaultrootwindow dpy) 200 300 350 250 5 foreground background)) (gc (xcreategc dpy window 0 (make-xgcvalues))) (event (make-xevent))) (xstorename dpy window "Hello, World in Scheme->C using X11's Xlib") (xseticonname dpy window "hello") (xsetbackground dpy gc background) (xsetforeground dpy gc foreground) (xselectinput dpy window (bit-or buttonpressmask keypressmask exposuremask)) (xmapraised dpy window) (let loop () (ynextevent dpy event) (cond ((eq? (xevent-type event) expose) (xdrawimagestring (xevent-xexpose-display event) (xevent-xexpose-window event) gc 50 50 hello (string-length hello)) (loop)) ((eq? (xevent-type event) mappingnotify) (xrefreshkeyboardmapping event) (loop)) ((eq? (xevent-type event) buttonpress) (xdrawimagestring (xevent-xbutton-display event) (xevent-xbutton-window event) gc (xevent-xbutton-x event) (xevent-xbutton-y event) hi (string-length hi)) (loop)) ((and (eq? (xevent-type event) keypress) (equal? (ylookupstring event) "q")) (xfreegc dpy gc) (xdestroywindow dpy window) (xclosedisplay dpy)) (else (loop))))))  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 31 Jan 90 11:27:30 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02568; 31 Jan 90 11:17 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA09060; Wed, 31 Jan 90 10:56:43 EST 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: 31 Jan 90 15:51:51 GMT From: Bruce Duba Organization: Rice University, Houston Subject: Re: Extend-syntax sources Message-Id: <4445@brazos.Rice.edu> References: <1990Jan30.015944.11884@sun.soe.clarkson.edu>, <1990Jan30.142352.17622@sun.soe.clarkson.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <1990Jan30.142352.17622@sun.soe.clarkson.edu> jk0@image.soe.clarkson.edu (Jason Coughlin) writes: >Does anyone have sources for extend-syntax? > ... >(The problem is that I'm going to build extend-syntax into my interpreter >and want to do with C code. Trying to re-write that Scheme code is >turning into a major ordeal). The best source to understand a (simple) extend-syntax processor and how to build it is Eugene Kohlbecker's original publciation: Kohlbecker, E. and M. Wand. Macro-by-example: deriving syntactic transformations from their specifications. In Proc. 14th ACM Symposium on Principles of Programming Languages, 1987, 77--85. The most complete description of extend-syntax todate is Kohlbecker's dissertation: Kohlbecker, E. Syntactic Extensions in the Programming Language Lisp. Ph.D. dissertation, Indiana University, 1986. -- Bruce Duba & Matthias Felleisen  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 30 Jan 90 22:51:33 EST Received: from helios.northeastern.edu by mintaka.lcs.mit.edu id aa07727; 30 Jan 90 22:44 EST Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu id aa24630; 31 Jan 90 3:40 EST Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.6) id AA10361; Tue, 30 Jan 90 22:39:26 EST Date: Tue, 30 Jan 90 22:39:26 EST From: Mitchell Wand Message-Id: <9001310339.AA10361@corwin.CCS.Northeastern.EDU> To: scheme@mc.lcs.mit.edu Subject: X bindings in Scheme? Cc: wand@corwin.ccs.northeastern.edu Has anyone attempted to build Scheme bindings for any of the X resource sets, so I can play with X windows from inside Scheme? Mitch Wand wand@corwin.ccs.northeastern.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 30 Jan 90 16:34:03 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa24662; 30 Jan 90 16:18 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA26126; Tue, 30 Jan 90 15:38:50 EST 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: 30 Jan 90 20:33:24 GMT From: "R. Kent Dybvig" Organization: Indiana University, Bloomington Subject: Re: Extend-syntax sources Message-Id: <34354@iuvax.cs.indiana.edu> References: <1990Jan30.015944.11884@sun.soe.clarkson.edu>, <1990Jan30.142352.17622@sun.soe.clarkson.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu >Does anyone have sources for extend-syntax? I have 2 copies: one >bundled with PC-Scheme and one bundled with MIT-Scheme. However, >the code in them (originally written by R. Kent Dyvbig [sp]) is >REAL dense. I'm looking for either the original (not twisted to fit >on PC-Scheme or MIT-Scheme) from Dyvbig [sorry about that] or a >version no quite so dense. Any ideas? I have made three implementations of extend-syntax available on iuvax.cs.indiana.edu for anonymous ftp. The files are: pub/extend-syntax.ss: Chez Scheme source code for extend-syntax pub/mitscheme-extend-syntax.ss: MITScheme compatible version pub/simple-extend.ss: simpler version The first two are certainly dense. The third is much simpler, though the file I found it in was three years old so it may be somewhat out of date. The mitscheme version is a port of a slightly older version of the Chez Scheme source code that didn't handle quasiquote within "with" clauses properly. If someone will send me current versions for MacScheme or PCScheme, I will be happy to make them available for ftp access as well. Kent Dybvig R. Kent Dybvig | Computer Science Department dyb@iuvax.cs.indiana.edu | Indiana University 812/855-6486 | Bloomington, IN 47405  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 30 Jan 90 15:18:38 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa22349; 30 Jan 90 15:14 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA22344; Tue, 30 Jan 90 14:28:32 EST 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: 30 Jan 90 19:12:00 GMT From: GEMINI.ARC.NASA.GOV!/C=CANADA/ADMD=TELECOM.CANADA/ID=ICS.TEST/S=TESTGROUP/@ucbvax.berkeley.edu Subject: Scheme in Forth? Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I was casually browsing comp.lang.forth a few days ago, and I think that it was then that I caught an article asking for information about Scheme in Forth. Does anyone know of such a magic device, and from where it can be snarfed (preferably by FTP)? I am curious to see how such a thing would implement the garbage-collection (or other memory-management) in a Forth virtual machine, especially on a host-machine like an 8088 Incredibly Bad Machine Xtra-Terrible clone. --- Sean Doran pp ICS TEST GROUP RFC-822: /C=CANADA/ADMD=TELECOM.CANADA/ID=ICS.TEST/S=TESTGROUP/@gemini.arc.nasa.gov sdoran%utzbee@zoo.utoronto.ca UUCP: {uunet,utgpu,utzoo,ucbvax,decuac}!att!attmail!mhs!envoy!ICS.TEST utzoo!utzbee!sdoran  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 30 Jan 90 13:23:54 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18247; 30 Jan 90 13:15 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA16889; Tue, 30 Jan 90 12:43:42 EST 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: 30 Jan 90 11:30:36 GMT From: Greg Michaelson Organization: Computer Science, Heriot-Watt U., Scotland Subject: Re: Combinators & Compilation Message-Id: <4232@brahma.cs.hw.ac.uk> References: <387CZXC@cs.swarthmore.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu From article <387CZXC@cs.swarthmore.edu>, by taylor@cs.swarthmore.edu (Brian Taylor): > I'd also appreciate references to any particularly valuable articles in the > literature providing a theoretical justification for the use of graph > reduction in the interpretation of combinatory logic and lambda calculus. Indeed, is there any evidence that graph reduction will ever be as time/space efficient as traditional compilation techniques for functional languages on Von Neumann architectures?  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 30 Jan 90 10:20:01 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa11625; 30 Jan 90 10:14 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA07051; Tue, 30 Jan 90 09:41:25 EST 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: 30 Jan 90 14:23:52 GMT From: Jason Coughlin Organization: Clarkson University, Potsdam, NY Subject: Extend-syntax sources Message-Id: <1990Jan30.142352.17622@sun.soe.clarkson.edu> References: <1990Jan30.015944.11884@sun.soe.clarkson.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anyone have sources for extend-syntax? I have 2 copies: one bundled with PC-Scheme and one bundled with MIT-Scheme. However, the code in them (originally written by R. Kent Dyvbig [sp]) is REAL dense. I'm looking for either the original (not twisted to fit on PC-Scheme or MIT-Scheme) from Dyvbig [sorry about that] or a version no quite so dense. Any ideas? (The problem is that I'm going to build extend-syntax into my interpreter and want to do with C code. Trying to re-write that Scheme code is turning into a major ordeal). -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 29 Jan 90 21:26:32 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa16487; 29 Jan 90 21:20 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA11618; Mon, 29 Jan 90 21:09:28 EST 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: 30 Jan 90 01:59:44 GMT From: Jason Coughlin Organization: Clarkson University, Potsdam, NY Subject: Re: Questions about PC-Scheme Message-Id: <1990Jan30.015944.11884@sun.soe.clarkson.edu> References: <7774@sdcsvax.UCSD.Edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu From article <7774@sdcsvax.UCSD.Edu>, by sudbeck@beowulf.ucsd.edu (David Sudbeck): > Can any in the Scheme community answer a few questions about PC-Scheme > for me? > > 1) Is there a command in the EDWIN editor to do global replaces of > text? I can't comment on EDWIN because I don't use it. However, I use EMACS *A LOT*, and you might want to get a real Emacs for the PC. Since you asked about ftp, ftp to sun.soe.clarkson.edu and grab a copy of freemacs. Freemacs is a pretty good implementation of Emacs for the PC (and it's FreeWare :-). -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 29 Jan 90 21:19:07 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa16257; 29 Jan 90 21:14 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA09448; Mon, 29 Jan 90 20:17:43 EST 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: 30 Jan 90 01:06:13 GMT From: David Sudbeck Organization: EE/CS Dept. U.C. San Diego Subject: Questions about PC-Scheme Message-Id: <7774@sdcsvax.UCSD.Edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Can any in the Scheme community answer a few questions about PC-Scheme for me? 1) Is there a command in the EDWIN editor to do global replaces of text? 2) How do you use the UNBIND call? It is a procedure but I can't find it in the documentation? 3) Is it true there is a 4.0 version of PC-SCHEME bundled with another of TI's products? What are the differences with this version from the usual 3.03 version? 4) Is there a library of Common-Lisp macros (making PC-SCHEME look like Common Lisp) available for ftp? Thanks for any help. Dave Sudbeck  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 28 Jan 90 20:31:55 EST Received: from cunyvm.cuny.edu by mintaka.lcs.mit.edu id aa23813; 28 Jan 90 20:25 EST Received: from att-in.att.com by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with TCP; Sun, 28 Jan 90 20:16:31 EST From: postmaster@att-in.att.com Date: Sun, 28 Jan 90 19:19:13 EST To: Scheme%lcs.mit.edu@cunyvm.cuny.edu Message-ID: <9001282025.aa23813@mintaka.lcs.mit.edu> Mail to `att.att.com!attmail!mhs!envoy!ics.test/pn=_test_group' alias `att!attmail!mhs!envoy!ics.test/pn=_test_group' from 'CUNYVM.CUNY.EDU!Scheme%lcs.mit.edu' failed. The error message was: destination unknown or forwarding disallowed The message began: Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7392; Sun, 28 Jan 90 15:00:31 EST Received: by BNANDP11 (Mailer R2.02A) id 7080; Sun, 28 Jan 90 18:50:30 +0100 Date: Sun, 28 Jan 90 02:12:33 EST Reply-To: Scheme%lcs.mit.edu@CUNYVM.CUNY.EDU Sender: Scheme Programming Language From: Automatic Scheme Digestifier Subject: Scheme Digest #284 Comments: To: Scheme@lcs.mit.edu To: ICSUG TEST GROUP Scheme Digest #284 28 Jan 90 02:12:33 EST Today's Topics: Scheme as a standard extension language Combinators & Compilation ---------------------------------------------------------------------- Message-ID: <1990Jan27.222837.3997@odi.com> Date: 27 Jan 90 22:28:37 GMT From: Dan Weinreb To: scheme@mc.lcs.mit.edu Subject: Re: Scheme as a standard extension language It sounds like you're saying that you prefer Scheme to Common Lisp because Scheme is "smaller", but Scheme is missing things that you need, so you'll have to extend it. Well, if you think about it, this shows why Common Lisp is the size that it is: it contains a whole lot of stuff that people have needed from time to time. Once you put in all the extensions to Scheme that you'll find you want to have, the difference in size will not be as great. When people talk about the "size of Common Lisp", whether they be measuring the size of executable files or the reference manual, they are really talking about the language plus a huge library of functions that are useful to some people some of the time. It is possible to construct a Common Lisp implementation in which an executable doesn't pay for the parts of the library that it doesn't use. I have heard that various Lisp implementors, such as Lucid and Franz and possibly others, have done work in this area, but I don't know any of the details. The decision of a standard extension language for the CFI is important. If you really want to find out the lowdown on this whole topic, I strongly recommend you talk to the experienced, professional Lisp implementors at such companies, and see what they can tell you. Of course, there are also experienced Scheme implementors around, too, who you might want to talk to. Of course, if you're considering an extended Scheme, you could equally well consider a subset of Common Lisp. Despite my role in defining Common Lisp, I do agree that Scheme has advantages. Its main advantage is that it's more internally clean and simple; Common Lisp was required to maintain all kinds of compatibility with older Lisp dialects, whereas the Scheme designers started from a tabula rasa and worked hard on elegance and simplicity. The only counterbalancing argument might be that Common Lisp is becoming more of a "standard", although Scheme is also something of a standard in its own right; I'm not sure how much this matters in the CFI decision. ------------------------------ Message-ID: <387CZXC@cs.swarthmore.edu> Date: 26 Jan 90 19:32:51 GMT From: Brian Taylor To: scheme@mc.lcs.mit.edu Subject: Combinators & Compilation Does anyone out there have machine readable copies of either of the following two papers? H.P. Barendregt, M.C.J.D. can Eekelen, J.R.W. Glauert, J.R. Kennaway, M.J. Plasmeijer and M.R. Sleep. [1986] Term graph rewriting, Report 87, Department of Computer Science, University of Nijmegen, and Report SYS-C87-01, School of Information Systems, University of East Anglia. P.M. van den Broek, and G.G. van der Hoeven [1986] Combinatorgraph reduction and the Church-Rosser theorem, preprint INF-86-15, Department of Informatics, Twente University of Technology. A condensed version of the first paper has been published, but I would like access to the full proofs contained in the original. If anyone could send me a copy of either of these, or suggest some way of finding paper copies in the States, I'd greatly appreciate it. I'd also appreciate references to any particularly valuable articles in the literature providing a theoretical justification for the use of graph reduction in the interpretation of combinatory logic and lambda calculus. Thanks in advance, Brian ----------------------------------------------------------------------- | Brian Taylor |internet: taylor@cs.swarthmore.edu | | Swarthmore College |bitnet: bdt90@swarthmr.bitnet | | Swarthmore, PA 19081 |uucp: ...rutgers!bpa!swatsun!taylor | | USA | | ---------------------------------------------------------------------- -- ---------------------------------------------------------------------- | Brian Taylor |internet: taylor@cs.swarthmore.edu | | Swarthmore College |bitnet: bdt90@swarthmr.bitnet | | Swarthmore, PA 19081 |uucp: ...rutgers!bpa!swatsun!taylor | ------------------------------ End of Scheme Digest ********************  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 28 Jan 90 20:31:36 EST Received: from cunyvm.cuny.edu by mintaka.lcs.mit.edu id aa23812; 28 Jan 90 20:25 EST Received: from att-in.att.com by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with TCP; Sun, 28 Jan 90 20:14:24 EST From: postmaster@att-in.att.com Date: Sun, 28 Jan 90 19:15:47 EST To: Scheme%lcs.mit.edu@cunyvm.cuny.edu Message-ID: <9001282025.aa23812@mintaka.lcs.mit.edu> Mail to `att.att.com!attmail!mhs!envoy!ics.test/pn=_test_group' alias `att!attmail!mhs!envoy!ics.test/pn=_test_group' from 'CUNYVM.CUNY.EDU!Scheme%lcs.mit.edu' failed. The error message was: destination unknown or forwarding disallowed The message began: Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 4525; Fri, 26 Jan 90 12:59:37 EST Received: by BNANDP11 (Mailer R2.02A) id 5839; Fri, 26 Jan 90 16:38:36 +0100 Date: Fri, 26 Jan 90 02:42:30 EST Reply-To: Scheme%lcs.mit.edu@CUNYVM.CUNY.EDU Sender: Scheme Programming Language From: Automatic Scheme Digestifier Subject: Scheme Digest #282 Comments: To: Scheme@lcs.mit.edu To: ICSUG TEST GROUP Scheme Digest #282 26 Jan 90 02:42:30 EST Today's Topics: Scheme as a standard extension language ---------------------------------------------------------------------- Message-ID: <1486@viewlog.UUCP> Date: 24 Jan 90 23:13:30 GMT From: Josh Marantz To: scheme@mc.lcs.mit.edu Subject: Scheme as a standard extension language I'm on a subcommittee of the CAD Framework Initiative (CFI), and we're working to standardize on a specific standard extension language for Electrical CAD/CAE applications. The mission of CFI is "To develop world-wide industry acceptable guidelines for design automation frameworks which will enable the coexistence and cooperation of a variety of tools." The goal of the working group on extension languages is to provide integrators and users of multi-vendor systems a single extension language that will work with all their applications. The obvious analogy is that different flavors of Emacs have compatible user interfaces and philosophies, but totally incompatible extension languages (EEL, Mocklisp, Elisp, Teco...). Wouldn't it be nice if they standardized? Whether or not you agree with this premise, we are trying to come up with a standard language (for some definition of "standard") that meets various criteria. The criteria include: High Productivity (implies high level language) Good development environment Automatic memory management (garbage collection) Specific runtime call to reclaim memory (collect garbage) Easy construction of complex data structures Easy manipulation of strings, lists, and complex data structures Quick turn around of code changes Rapid prototyping Built in debugging capability Public domain source and commercial products available Easy to parse EDIF using extension language Late binding Dynamic binding Able to express rules and constraints Able to construct module generator (to generate cells) Sequential model of execution (stream i/o) Standard language with a large user base Multiple namespaces (packages) Access to all other parts of framework from extension language We could try to invent our own language that meets these requirements, but leveraging off an existing standard is a high priority for us. The two languages that we've come up with that come closest to meeting these requirements are Common Lisp and Scheme. Common Lisp is feature-rich and requires the fewest extensions to provide the features we need. But it is huge and thereby dictates certain architectural considerations and platform requirements where it would be nice to remain more flexible. In particular, it may be desirable to have several applications running on a workstation, each of which has its own extension language processor linked in. Correct me if I'm wrong, but if the extension language is 2 Meg worth of Common Lisp, then this would not be a design option. My understanding is that shared libraries might ease the problem, but would not eliminate it. However, standard Common Lisp (with CLOS and the Pittman error handler) provide us a nearly complete package that we wouldn't have to augment. The useful features it provides that Scheme doesn't include: structure definition (defstruct), error handling, an object/class system, hash tables, optional strong typing, looping constructs, and efficient compilation. Scheme is more elegant and streamlined, but would require a large number of extensions to supply all the features we need. I couldn't find many of the required features in R3RS, but I've seen them in various implementations of Scheme. For example: Packages MIT-Scheme Debugging Support MIT-Scheme Object Oriented Programming XScheme Simple integration with C Code SIOD I personally support Scheme as the basis for an extension language, primarily because it can be implemented without a big memory hit (as was done with SIOD). It seems to me that even with the extensions we need, Scheme would still be leaner than Common Lisp. For example, packages and an object/class system can be trivially implemented with environments. But what I need to present my case better is some sort of "common" extension package that can provide the features we require. Is there an effort out there to define extensions and enhancements that I could present along with R3RS to the committee? Or should I try to come up with a "Scheme's greatest hits" collection and suggest that we standardize on those extensions as well as R3RS? Any comments from the Scheme and Lisp communities are welcome. If Common Lisp is not as expensive as I assume, then I'm sure someone will correct me! -- Joshua Marantz Viewlogic Systems, Inc. cloud9!viewlog!josh@bu-cs.bu.edu ------------------------------ End of Scheme Digest ********************  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 27 Jan 90 22:18:50 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa13647; 27 Jan 90 22:13 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA10621; Sat, 27 Jan 90 21:48:59 EST 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 Jan 90 19:32:51 GMT From: Brian Taylor Organization: Swarthmore College CS Dept., PA Subject: Combinators & Compilation Message-Id: <387CZXC@cs.swarthmore.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anyone out there have machine readable copies of either of the following two papers? H.P. Barendregt, M.C.J.D. can Eekelen, J.R.W. Glauert, J.R. Kennaway, M.J. Plasmeijer and M.R. Sleep. [1986] Term graph rewriting, Report 87, Department of Computer Science, University of Nijmegen, and Report SYS-C87-01, School of Information Systems, University of East Anglia. P.M. van den Broek, and G.G. van der Hoeven [1986] Combinatorgraph reduction and the Church-Rosser theorem, preprint INF-86-15, Department of Informatics, Twente University of Technology. A condensed version of the first paper has been published, but I would like access to the full proofs contained in the original. If anyone could send me a copy of either of these, or suggest some way of finding paper copies in the States, I'd greatly appreciate it. I'd also appreciate references to any particularly valuable articles in the literature providing a theoretical justification for the use of graph reduction in the interpretation of combinatory logic and lambda calculus. Thanks in advance, Brian ----------------------------------------------------------------------- | Brian Taylor |internet: taylor@cs.swarthmore.edu | | Swarthmore College |bitnet: bdt90@swarthmr.bitnet | | Swarthmore, PA 19081 |uucp: ...rutgers!bpa!swatsun!taylor | | USA | | ----------------------------------------------------------------------- -- ----------------------------------------------------------------------- | Brian Taylor |internet: taylor@cs.swarthmore.edu | | Swarthmore College |bitnet: bdt90@swarthmr.bitnet | | Swarthmore, PA 19081 |uucp: ...rutgers!bpa!swatsun!taylor |  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 27 Jan 90 18:22:33 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07394; 27 Jan 90 18:18 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA29562; Sat, 27 Jan 90 17:53:52 EST 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: 27 Jan 90 22:28:37 GMT From: Dan Weinreb Organization: Object Design, Inc. Subject: Re: Scheme as a standard extension language Message-Id: <1990Jan27.222837.3997@odi.com> References: <1486@viewlog.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu It sounds like you're saying that you prefer Scheme to Common Lisp because Scheme is "smaller", but Scheme is missing things that you need, so you'll have to extend it. Well, if you think about it, this shows why Common Lisp is the size that it is: it contains a whole lot of stuff that people have needed from time to time. Once you put in all the extensions to Scheme that you'll find you want to have, the difference in size will not be as great. When people talk about the "size of Common Lisp", whether they be measuring the size of executable files or the reference manual, they are really talking about the language plus a huge library of functions that are useful to some people some of the time. It is possible to construct a Common Lisp implementation in which an executable doesn't pay for the parts of the library that it doesn't use. I have heard that various Lisp implementors, such as Lucid and Franz and possibly others, have done work in this area, but I don't know any of the details. The decision of a standard extension language for the CFI is important. If you really want to find out the lowdown on this whole topic, I strongly recommend you talk to the experienced, professional Lisp implementors at such companies, and see what they can tell you. Of course, there are also experienced Scheme implementors around, too, who you might want to talk to. Of course, if you're considering an extended Scheme, you could equally well consider a subset of Common Lisp. Despite my role in defining Common Lisp, I do agree that Scheme has advantages. Its main advantage is that it's more internally clean and simple; Common Lisp was required to maintain all kinds of compatibility with older Lisp dialects, whereas the Scheme designers started from a tabula rasa and worked hard on elegance and simplicity. The only counterbalancing argument might be that Common Lisp is becoming more of a "standard", although Scheme is also something of a standard in its own right; I'm not sure how much this matters in the CFI decision.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 26 Jan 90 09:28:54 EST Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa09163; 26 Jan 90 9:21 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 5750; Fri, 26 Jan 90 09:21:26 EST Received: from DB0TUI6.BITNET (NET) by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 2654; Fri, 26 Jan 90 09:21:25 EST Received: by tub.UUCP; Fri, 26 Jan 90 10:53:00 +0100; AA29337 Date: Fri, 26 Jan 90 10:53:00 +0100 From: Oliver Laumann Message-Id: <9001260953.AA29337@tub.UUCP> To: Scheme@lcs.mit.edu Subject: Re: Scheme as a standard extension language Cc: josh@think.com If you are interested in using Scheme as a standard extension language, you might want to look into the recently posted implementation of Scheme named `Elk' (Extension Language Kit). One purpose of the Elk project was to end the recent proliferation of (often mutually incompatible) Lisp-like extension languages. Instead of inventing and implementing yet another extension language, we expect application programmers to link the Scheme interpreter into their application in order to make it extensible and customizable. We feel that Scheme is better suited as a general extension language than other Lisp dialects: it is sufficiently small to not dwarf the application it serves and to be fully understood with acceptable effort; it is orthogonal and well-defined. In addition, Scheme has been recognized to be mature enough for national and international standardization (IEEE P1178, ISO/IEC JTC1/SC22/WG16). The `Elk' Scheme interpreter can easily be extended by application-specific new data types and primitive procedures. Such extensions are typically written in C or C++ and dynamically loaded into the running interpreter. Regards, -- Oliver Laumann net@TUB.BITNET net@tub.UUCP  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 26 Jan 90 08:08:22 EST Received: from BRONTO.SOAR.CS.CMU.EDU by mintaka.lcs.mit.edu id aa07172; 26 Jan 90 8:04 EST Received: by bronto.soar.cs.cmu.edu (3.2CMU/5.17) id AA23617; Fri, 26 Jan 90 08:01:21 EST Date: Fri, 26 Jan 90 08:01:21 EST From: Olin Shivers Message-Id: <9001261301.AA23617@bronto.soar.cs.cmu.edu> To: cloud9!viewlog!josh@cs.bu.edu Cc: Scheme@MINTAKA.LCS.MIT.EDU Subject: Scheme and CAD You are missing one or two good bets. Joel Bartlett at DECWRL has done an implementation of R3RS that compiles to C called Scheme->C. There is a paper on this implementation available from WRL. Scheme->C was designed with an eye to using it as an embedded command processor, writing standalone executables, and linking Scheme code together with C code, so it sounds like just the thing for what you have in mind. You can get Bartlett's paper from the slick WRL mail server. To find out how, send a message with subject line "help" to wrl-techreports@decwrl.dec.com or {someplace}!decwrl!wrl-techreports T has a very nice packages system, called locales, an object-oriented extension, which is directly supported by the native-code optimizing compiler. Calling C from T is not too hard; calling T from C is hard. You can get T for most 68K, Vax, R2000, and Sparc systems -- it can be ftp'd from MIT. If you want to know more, contact kranz@wheaties.ai.mit.edu. -Olin  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 25 Jan 90 03:22:15 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa04392; 25 Jan 90 3:16 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA05109; Thu, 25 Jan 90 02:52:20 EST 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: 24 Jan 90 23:13:30 GMT From: Josh Marantz Organization: Viewlogic Systems Inc., Marlboro, MA Subject: Scheme as a standard extension language Message-Id: <1486@viewlog.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I'm on a subcommittee of the CAD Framework Initiative (CFI), and we're working to standardize on a specific standard extension language for Electrical CAD/CAE applications. The mission of CFI is "To develop world-wide industry acceptable guidelines for design automation frameworks which will enable the coexistence and cooperation of a variety of tools." The goal of the working group on extension languages is to provide integrators and users of multi-vendor systems a single extension language that will work with all their applications. The obvious analogy is that different flavors of Emacs have compatible user interfaces and philosophies, but totally incompatible extension languages (EEL, Mocklisp, Elisp, Teco...). Wouldn't it be nice if they standardized? Whether or not you agree with this premise, we are trying to come up with a standard language (for some definition of "standard") that meets various criteria. The criteria include: High Productivity (implies high level language) Good development environment Automatic memory management (garbage collection) Specific runtime call to reclaim memory (collect garbage) Easy construction of complex data structures Easy manipulation of strings, lists, and complex data structures Quick turn around of code changes Rapid prototyping Built in debugging capability Public domain source and commercial products available Easy to parse EDIF using extension language Late binding Dynamic binding Able to express rules and constraints Able to construct module generator (to generate cells) Sequential model of execution (stream i/o) Standard language with a large user base Multiple namespaces (packages) Access to all other parts of framework from extension language We could try to invent our own language that meets these requirements, but leveraging off an existing standard is a high priority for us. The two languages that we've come up with that come closest to meeting these requirements are Common Lisp and Scheme. Common Lisp is feature-rich and requires the fewest extensions to provide the features we need. But it is huge and thereby dictates certain architectural considerations and platform requirements where it would be nice to remain more flexible. In particular, it may be desirable to have several applications running on a workstation, each of which has its own extension language processor linked in. Correct me if I'm wrong, but if the extension language is 2 Meg worth of Common Lisp, then this would not be a design option. My understanding is that shared libraries might ease the problem, but would not eliminate it. However, standard Common Lisp (with CLOS and the Pittman error handler) provide us a nearly complete package that we wouldn't have to augment. The useful features it provides that Scheme doesn't include: structure definition (defstruct), error handling, an object/class system, hash tables, optional strong typing, looping constructs, and efficient compilation. Scheme is more elegant and streamlined, but would require a large number of extensions to supply all the features we need. I couldn't find many of the required features in R3RS, but I've seen them in various implementations of Scheme. For example: Packages MIT-Scheme Debugging Support MIT-Scheme Object Oriented Programming XScheme Simple integration with C Code SIOD I personally support Scheme as the basis for an extension language, primarily because it can be implemented without a big memory hit (as was done with SIOD). It seems to me that even with the extensions we need, Scheme would still be leaner than Common Lisp. For example, packages and an object/class system can be trivially implemented with environments. But what I need to present my case better is some sort of "common" extension package that can provide the features we require. Is there an effort out there to define extensions and enhancements that I could present along with R3RS to the committee? Or should I try to come up with a "Scheme's greatest hits" collection and suggest that we standardize on those extensions as well as R3RS? Any comments from the Scheme and Lisp communities are welcome. If Common Lisp is not as expensive as I assume, then I'm sure someone will correct me! -- Joshua Marantz Viewlogic Systems, Inc. cloud9!viewlog!josh@bu-cs.bu.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 24 Jan 90 17:07:58 EST Received: from cunyvm.cuny.edu by mintaka.lcs.mit.edu id aa08530; 24 Jan 90 17:01 EST Received: from att-in.att.com by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with TCP; Wed, 24 Jan 90 17:00:33 EST From: postmaster@att-in.att.com Date: Wed, 24 Jan 90 16:56:45 EST To: Scheme%lcs.mit.edu@cunyvm.cuny.edu Message-ID: <9001241701.aa08530@mintaka.lcs.mit.edu> Mail to `att.att.com!attmail!mhs!envoy!ics.test/pn=_test_group' alias `att!attmail!mhs!envoy!ics.test/pn=_test_group' from 'CUNYVM.CUNY.EDU!Scheme%lcs.mit.edu' failed. The error message was: destination unknown or forwarding disallowed The message began: Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 5831; Wed, 24 Jan 90 16:57:21 EST Received: by BNANDP11 (Mailer R2.02A) id 9431; Wed, 24 Jan 90 18:36:28 +0100 Date: Wed, 24 Jan 90 02:15:06 EST Reply-To: Scheme%lcs.mit.edu@CUNYVM.CUNY.EDU Sender: Scheme Programming Language From: Automatic Scheme Digestifier Subject: Scheme Digest #280 Comments: To: Scheme@lcs.mit.edu To: ICSUG TEST GROUP Scheme Digest #280 24 Jan 90 02:15:06 EST Today's Topics: () as an expression ---------------------------------------------------------------------- Message-ID: <1990Jan23.203035.148@vicom.com> Date: 23 Jan 90 20:30:35 GMT From: Roderic Taylor To: scheme@mc.lcs.mit.edu Subject: Re: () as an expression In a recent article Jason Coughlin (jk0@sun.soe.clarkson.edu) writes: = =Why is () an invalid expression? It seems to me that it is a constant. = () is not a constant. '() is a constant (at least in the sense you're thinking). This is the way Lisp works with all lists, not just the empty one. --Roderic T ------------------------------ End of Scheme Digest ********************  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 24 Jan 90 11:25:27 EST Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa23021; 24 Jan 90 11:21 EST Received: from Fafnir.Think.COM by Think.COM; Wed, 24 Jan 90 11:20:58 -0500 Return-Path: Received: from verdi.think.com by fafnir.think.com; Wed, 24 Jan 90 11:20:42 EST Received: from ungar.think.com by verdi.think.com; Wed, 24 Jan 90 11:20:50 EST From: Guy Steele Received: by ungar.think.com; Wed, 24 Jan 90 11:20:48 EST Date: Wed, 24 Jan 90 11:20:48 EST Message-Id: <9001241620.AA04533@ungar.think.com> To: Scheme@lcs.mit.edu Cc: gls@think.com In-Reply-To: Automatic Scheme Digestifier's message of 24 Jan 90 02:15:06 EST Subject: () as an expression Message-ID: <1990Jan23.203035.148@vicom.com> Date: 23 Jan 90 20:30:35 GMT >From: Roderic Taylor To: scheme@mc.lcs.mit.edu In a recent article Jason Coughlin (jk0@sun.soe.clarkson.edu) writes: Why is () an invalid expression? It seems to me that it is a constant. () is not a constant. '() is a constant (at least in the sense you're thinking). This is the way Lisp works with all lists, not just the empty one. Begging your pardon, but this is the way *Scheme* works with all lists. As dearly as we may love Scheme, we must recognize that there are other dialects of Lisp, some of greater seniority. --Guy  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 23 Jan 90 17:54:28 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa13968; 23 Jan 90 17:50 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA29699; Tue, 23 Jan 90 17:45:45 EST 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: 23 Jan 90 20:30:35 GMT From: Roderic Taylor Organization: Vicom Systems Inc., San Jose, CA Subject: Re: () as an expression Message-Id: <1990Jan23.203035.148@vicom.com> References: <1990Jan16.193134.10491@sun.soe.clarkson.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In a recent article Jason Coughlin (jk0@sun.soe.clarkson.edu) writes: = =Why is () an invalid expression? It seems to me that it is a constant. = () is not a constant. '() is a constant (at least in the sense you're thinking). This is the way Lisp works with all lists, not just the empty one. --Roderic T  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 22 Jan 90 21:45:12 EST Received: from cunyvm.cuny.edu by mintaka.lcs.mit.edu id aa00684; 22 Jan 90 21:39 EST Received: from att-in.att.com by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with TCP; Mon, 22 Jan 90 21:27:13 EST From: postmaster@att-in.att.com Date: Mon, 22 Jan 90 21:24:32 EST To: Scheme%lcs.mit.edu@cunyvm.cuny.edu Message-ID: <9001222139.aa00684@mintaka.lcs.mit.edu> Mail to `att.att.com!attmail!mhs!envoy!ics.test/pn=_test_group' alias `att!attmail!mhs!envoy!ics.test/pn=_test_group' from 'CUNYVM.CUNY.EDU!Scheme%lcs.mit.edu' failed. The error message was: destination unknown or forwarding disallowed The message began: Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2397; Mon, 22 Jan 90 21:25:13 EST Received: by BNANDP11 (Mailer R2.02A) id 4855; Tue, 23 Jan 90 03:25:07 +0100 Date: Mon, 22 Jan 90 02:37:51 EST Reply-To: Scheme%lcs.mit.edu@CUNYVM.CUNY.EDU Sender: Scheme Programming Language From: Automatic Scheme Digestifier Subject: Scheme Digest #278 Comments: To: Scheme@lcs.mit.edu To: ICSUG TEST GROUP Scheme Digest #278 22 Jan 90 02:37:51 EST Today's Topics: scheme manual ---------------------------------------------------------------------- Message-ID: <9001211521.AA29490@cmvax.nrl.navy.mil> Date: Sun, 21 Jan 90 10:21:58 EST From: Eric Hoffman To: scheme@ai.mit.edu Subject: scheme manual Is there a manual which deals with scheme contructs and concepts availiable through a publisher or over the network, aside from the release notes? -Eric Hoffman Connection Machine Facility Naval Research Laboratory ------------------------------ End of Scheme Digest ********************  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 22 Jan 90 20:58:59 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa29014; 22 Jan 90 20:52 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA05101; Mon, 22 Jan 90 19:59:44 EST 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: 22 Jan 90 16:06:43 GMT From: Jonathan Shapiro Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: (none) Message-Id: <3055@odin.SGI.COM> References: <9001211910.aa06333@mintaka.lcs.mit.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Can we arrange for archives to get a proper subject line? It's pretty irritating to see identical content in the digest and the newsgroup, and I would like to be able to kill one or the other in my kill file. Killing all things from postmaster@att... doesn't seem like the ideal solution. Jon Shapiro  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 22 Jan 90 10:24:36 EST Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa05664; 22 Jan 90 10:19 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 3529; Mon, 22 Jan 90 10:18:38 EST Received: from OWUCOMCN.BITNET (JJLACEY) by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 1449; Mon, 22 Jan 90 10:18:38 EST Date: Mon, 22 Jan 90 10:11 EST From: JJLACEY%OWUCOMCN.BITNET@mitvma.mit.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Subject: Multiple copies of Digest #276 To: scheme@lcs.mit.edu X-Original-To: scheme@lcs.mit.edu Message-ID: <9001221019.aa05664@mintaka.lcs.mit.edu> To date (22 Jan 1990, 10:00am), I have received 3 copies of this beast. Now, mind you, I *like* these digests, but I feel that this is a problem, and not a treat. Thanks for your consideration. John Lacey jjlacey@owucomcn.bitnet  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 21 Jan 90 23:05:58 EST Received: from cunyvm.cuny.edu by mintaka.lcs.mit.edu id aa14170; 21 Jan 90 23:02 EST Received: from att-in.att.com by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with TCP; Sun, 21 Jan 90 23:01:56 EST From: postmaster@att-in.att.com Date: Sun, 21 Jan 90 22:54:07 EST To: Scheme%lcs.mit.edu@cunyvm.cuny.edu Message-ID: <9001212302.aa14170@mintaka.lcs.mit.edu> Mail to `att.att.com!attmail!mhs!envoy!ics.test/pn=_test_group' alias `att!attmail!mhs!envoy!ics.test/pn=_test_group' from 'CUNYVM.CUNY.EDU!Scheme%lcs.mit.edu' failed. The error message was: destination unknown or forwarding disallowed The message began: Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8686; Sun, 21 Jan 90 23:01:39 EST Received: by BNANDP11 (Mailer R2.02A) id 2663; Mon, 22 Jan 90 04:51:45 +0100 Date: Wed, 17 Jan 90 02:32:34 EST Reply-To: Scheme%lcs.mit.edu@CUNYVM.CUNY.EDU Sender: Scheme Programming Language From: Automatic Scheme Digestifier Subject: Scheme Digest #276 Comments: To: Scheme@lcs.mit.edu To: ICSUG TEST GROUP Scheme Digest #276 17 Jan 90 02:32:34 EST Today's Topics: (none) () as an expression (3 messages) Administrivia: The Scheme Digest is now being produced by a new automatic digestifier. If you notice any problems caused by this change, please report them to us. (Note that this change is unrelated to the recent problems where an errant mailer is sending entire digests back to us as submissions.) Scheme-Request@LCS.MIT.EDU ---------------------------------------------------------------------- Message-ID: <502@qusunitb.queensu.CA> Date: 15 Jan 90 16:11:36 GMT From: Prakash Panangaden To: scheme@mc.lcs.mit.edu Subject: Re: (none) Is there anyone who knows where to get PC schemes in Canada? Thanks ------------------------------ Message-ID: <1990Jan16.193134.10491@sun.soe.clarkson.edu> Date: 16 Jan 90 19:31:34 GMT From: Jason Coughlin To: scheme@mc.lcs.mit.edu Subject: () as an expression The Revised^3 Report says that () is an illegal expression. It must be quoted. However, MIT-Scheme and PC-Scheme both allow it, ie: MIT-SCHEME => () () MIT-SCHEME => Why is () an invalid expression? It seems to me that it is a constant. (eq? #t #t) => #t (eq? #f #f) => #t (eq? '() '()) => #t now why isn't () considered a constant, when it really IS a constant? -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants ------------------------------ Message-ID: <5413@tekcrl.LABS.TEK.COM> Date: 16 Jan 90 20:55:13 GMT From: Ken Dickey To: scheme@MC.lcs.mit.edu Subject: Re: () as an expression In article <1990Jan16.193134.10491@sun.soe.clarkson.edu> jk0@sun.soe.clarkson.edu (Jason Coughlin) writes: >The Revised^3 Report says that () is an illegal expression. It must >be quoted. However, MIT-Scheme and PC-Scheme both allow it, ie: .. >Why is () an invalid expression? It seems to me that it is a constant. > >(eq? #t #t) => #t >(eq? #f #f) => #t >(eq? '() '()) => #t > >now why isn't () considered a constant, when it really IS a constant? The syntax () is considered a combination (a.k.a. procedure call) and as such must have at lease one subexpression. So, the empty list is valid, but the empty combination is an error. Note also that #f and '() may be distinct in newer Scheme implementations [the value of (eq? '() #f) is currently unspecified]. There are other non-R^3RS behaviors allowed by various versions of Scheme implementations, particularly those implementations done before R^3RS was issued. -Ken Dickey ------------------------------ Message-ID: <1990Jan16.231311.18316@sun.soe.clarkson.edu> Date: 16 Jan 90 23:13:11 GMT From: Jason Coughlin To: scheme@mc.lcs.mit.edu Subject: Re: () as an expression From article <5413@tekcrl.LABS.TEK.COM>, by kend@tekchips.LABS.TEK.COM (Ken Dickey): > Note also that #f and '() may be distinct in newer Scheme > implementations [the value of (eq? '() #f) is currently unspecified]. This leads to another point: I think we need a definitive answer on whether #f == (). In my Scheme, #f and () are two different entities. I like this because in my mind, #f != (). #f is boolean, () is an empty list. So what say you about: (BOOLEAN? '()) (NULL? '()) (EQ? '() #f) -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants ------------------------------ End of Scheme Digest ********************  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 21 Jan 90 22:58:13 EST Received: from cunyvm.cuny.edu by mintaka.lcs.mit.edu id aa13936; 21 Jan 90 22:53 EST Received: from att-in.att.com by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with TCP; Sun, 21 Jan 90 22:53:28 EST From: postmaster@att-in.att.com Date: Sun, 21 Jan 90 22:43:21 EST To: Scheme%lcs.mit.edu@cunyvm.cuny.edu Message-ID: <9001212253.aa13936@mintaka.lcs.mit.edu> Mail to `att.att.com!attmail!mhs!envoy!ics.test/pn=_test_group' alias `att!attmail!mhs!envoy!ics.test/pn=_test_group' from 'CUNYVM.CUNY.EDU!Scheme%lcs.mit.edu' failed. The error message was: destination unknown or forwarding disallowed The message began: Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8628; Sun, 21 Jan 90 22:51:48 EST Received: by BNANDP11 (Mailer R2.02A) id 2563; Mon, 22 Jan 90 04:50:44 +0100 Date: Wed, 17 Jan 90 02:32:34 EST Reply-To: Scheme%lcs.mit.edu@CUNYVM.CUNY.EDU Sender: Scheme Programming Language From: Automatic Scheme Digestifier Subject: Scheme Digest #276 Comments: To: Scheme@lcs.mit.edu To: ICSUG TEST GROUP Scheme Digest #276 17 Jan 90 02:32:34 EST Today's Topics: (none) () as an expression (3 messages) Administrivia: The Scheme Digest is now being produced by a new automatic digestifier. If you notice any problems caused by this change, please report them to us. (Note that this change is unrelated to the recent problems where an errant mailer is sending entire digests back to us as submissions.) Scheme-Request@LCS.MIT.EDU ---------------------------------------------------------------------- Message-ID: <502@qusunitb.queensu.CA> Date: 15 Jan 90 16:11:36 GMT From: Prakash Panangaden To: scheme@mc.lcs.mit.edu Subject: Re: (none) Is there anyone who knows where to get PC schemes in Canada? Thanks ------------------------------ Message-ID: <1990Jan16.193134.10491@sun.soe.clarkson.edu> Date: 16 Jan 90 19:31:34 GMT From: Jason Coughlin To: scheme@mc.lcs.mit.edu Subject: () as an expression The Revised^3 Report says that () is an illegal expression. It must be quoted. However, MIT-Scheme and PC-Scheme both allow it, ie: MIT-SCHEME => () () MIT-SCHEME => Why is () an invalid expression? It seems to me that it is a constant. (eq? #t #t) => #t (eq? #f #f) => #t (eq? '() '()) => #t now why isn't () considered a constant, when it really IS a constant? -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants ------------------------------ Message-ID: <5413@tekcrl.LABS.TEK.COM> Date: 16 Jan 90 20:55:13 GMT From: Ken Dickey To: scheme@MC.lcs.mit.edu Subject: Re: () as an expression In article <1990Jan16.193134.10491@sun.soe.clarkson.edu> jk0@sun.soe.clarkson.edu (Jason Coughlin) writes: >The Revised^3 Report says that () is an illegal expression. It must >be quoted. However, MIT-Scheme and PC-Scheme both allow it, ie: .. >Why is () an invalid expression? It seems to me that it is a constant. > >(eq? #t #t) => #t >(eq? #f #f) => #t >(eq? '() '()) => #t > >now why isn't () considered a constant, when it really IS a constant? The syntax () is considered a combination (a.k.a. procedure call) and as such must have at lease one subexpression. So, the empty list is valid, but the empty combination is an error. Note also that #f and '() may be distinct in newer Scheme implementations [the value of (eq? '() #f) is currently unspecified]. There are other non-R^3RS behaviors allowed by various versions of Scheme implementations, particularly those implementations done before R^3RS was issued. -Ken Dickey ------------------------------ Message-ID: <1990Jan16.231311.18316@sun.soe.clarkson.edu> Date: 16 Jan 90 23:13:11 GMT From: Jason Coughlin To: scheme@mc.lcs.mit.edu Subject: Re: () as an expression From article <5413@tekcrl.LABS.TEK.COM>, by kend@tekchips.LABS.TEK.COM (Ken Dickey): > Note also that #f and '() may be distinct in newer Scheme > implementations [the value of (eq? '() #f) is currently unspecified]. This leads to another point: I think we need a definitive answer on whether #f == (). In my Scheme, #f and () are two different entities. I like this because in my mind, #f != (). #f is boolean, () is an empty list. So what say you about: (BOOLEAN? '()) (NULL? '()) (EQ? '() #f) -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants ------------------------------ End of Scheme Digest ********************  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 21 Jan 90 19:13:45 EST Received: from cunyvm.cuny.edu by mintaka.lcs.mit.edu id aa06333; 21 Jan 90 19:10 EST Received: from att-in.att.com by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with TCP; Sun, 21 Jan 90 19:10:19 EST From: postmaster@att-in.att.com Date: Sun, 21 Jan 90 19:04:55 EST To: Scheme%lcs.mit.edu@cunyvm.cuny.edu Message-ID: <9001211910.aa06333@mintaka.lcs.mit.edu> Mail to `att.att.com!attmail!mhs!envoy!ics.test/pn=_test_group' alias `att!attmail!mhs!envoy!ics.test/pn=_test_group' from 'CUNYVM.CUNY.EDU!Scheme%lcs.mit.edu' failed. The error message was: destination unknown or forwarding disallowed The message began: Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7441; Sun, 21 Jan 90 19:09:58 EST Received: by BNANDP11 (Mailer R2.02A) id 2056; Mon, 22 Jan 90 01:09:06 +0100 Date: Thu, 18 Jan 90 02:33:02 EST Reply-To: Scheme%lcs.mit.edu@CUNYVM.CUNY.EDU Sender: Scheme Programming Language From: Automatic Scheme Digestifier Subject: Scheme Digest #277 Comments: To: Scheme@lcs.mit.edu To: ICSUG TEST GROUP Scheme Digest #277 18 Jan 90 02:33:02 EST Today's Topics: Another compiling Scheme reference ---------------------------------------------------------------------- Message-ID: <9001130114.AA17216@jove.pa.dec.com> Date: Fri, 12 Jan 90 17:14:30 PST From: bartlett@decwrl.dec.com To: Scheme%mc.lcs.mit.edu@MINTAKA.lcs.mit.edu CC: bartlett@lcs.mit.edu Subject: Another compiling Scheme reference Joel F. Bartlett, Scheme->C a Portable Scheme-to-C Compiler, WRL Research Report 89/1, Digital Equipment Corporation Western Research Laboratory, January 1989. ------------------------------ End of Scheme Digest ********************  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 21 Jan 90 15:41:03 EST Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa28249; 21 Jan 90 15:38 EST Received: from cmvax.nrl.navy.mil ([134.207.7.12]) by life.ai.mit.edu (4.0/AI-4.10) id AA11441; Sun, 21 Jan 90 15:38:11 EST Received: by cmvax.nrl.navy.mil (5.57/Ultrix2.4-C) id AA29490; Sun, 21 Jan 90 10:21:58 EST Date: Sun, 21 Jan 90 10:21:58 EST From: Eric Hoffman Message-Id: <9001211521.AA29490@cmvax.nrl.navy.mil> To: scheme@ai.mit.edu Subject: scheme manual Is there a manual which deals with scheme contructs and concepts availiable through a publisher or over the network, aside from the release notes? -Eric Hoffman Connection Machine Facility Naval Research Laboratory  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 17 Jan 90 19:43:01 EST Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa12752; 17 Jan 90 19:40 EST Received: by decwrl.dec.com; id AA01956; Sun, 14 Jan 90 20:26:17 -0800 Received: by jove.pa.dec.com; id AA17216; Fri, 12 Jan 90 17:14:32 -0800 Message-Id: <9001130114.AA17216@jove.pa.dec.com> To: Scheme%mc.lcs.mit.edu@MINTAKA.lcs.mit.edu Cc: bartlett@lcs.mit.edu Subject: Another compiling Scheme reference Date: Fri, 12 Jan 90 17:14:30 PST From: bartlett@decwrl.dec.com Joel F. Bartlett, Scheme->C a Portable Scheme-to-C Compiler, WRL Research Report 89/1, Digital Equipment Corporation Western Research Laboratory, January 1989.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 17 Jan 90 09:03:57 EST Received: from cunyvm.cuny.edu by mintaka.lcs.mit.edu id aa16593; 17 Jan 90 9:01 EST Received: from att-in.att.com by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with TCP; Wed, 17 Jan 90 09:00:55 EST From: postmaster@att-in.att.com Date: Wed, 17 Jan 90 09:00:08 EST To: Scheme%lcs.mit.edu@cunyvm.cuny.edu Message-ID: <9001170901.aa16593@mintaka.lcs.mit.edu> Mail to `att.att.com!attmail!mhs!envoy!ics.test/pn=_test_group' alias `att!attmail!mhs!envoy!ics.test/pn=_test_group' from 'CUNYVM.CUNY.EDU!Scheme%lcs.mit.edu' failed. The error message was: destination unknown or forwarding disallowed The message began: Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0545; Wed, 17 Jan 90 09:00:08 EST Received: by BNANDP11 (Mailer R2.02A) id 2852; Wed, 17 Jan 90 14:19:39 +0100 Date: Wed, 17 Jan 90 02:32:34 EST Reply-To: Scheme%lcs.mit.edu@CUNYVM.CUNY.EDU Sender: Scheme Programming Language From: Automatic Scheme Digestifier Subject: Scheme Digest #276 Comments: To: Scheme@lcs.mit.edu To: ICSUG TEST GROUP Scheme Digest #276 17 Jan 90 02:32:34 EST Today's Topics: (none) () as an expression (3 messages) Administrivia: The Scheme Digest is now being produced by a new automatic digestifier. If you notice any problems caused by this change, please report them to us. (Note that this change is unrelated to the recent problems where an errant mailer is sending entire digests back to us as submissions.) Scheme-Request@LCS.MIT.EDU ---------------------------------------------------------------------- Message-ID: <502@qusunitb.queensu.CA> Date: 15 Jan 90 16:11:36 GMT From: Prakash Panangaden To: scheme@mc.lcs.mit.edu Subject: Re: (none) Is there anyone who knows where to get PC schemes in Canada? Thanks ------------------------------ Message-ID: <1990Jan16.193134.10491@sun.soe.clarkson.edu> Date: 16 Jan 90 19:31:34 GMT From: Jason Coughlin To: scheme@mc.lcs.mit.edu Subject: () as an expression The Revised^3 Report says that () is an illegal expression. It must be quoted. However, MIT-Scheme and PC-Scheme both allow it, ie: MIT-SCHEME => () () MIT-SCHEME => Why is () an invalid expression? It seems to me that it is a constant. (eq? #t #t) => #t (eq? #f #f) => #t (eq? '() '()) => #t now why isn't () considered a constant, when it really IS a constant? -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants ------------------------------ Message-ID: <5413@tekcrl.LABS.TEK.COM> Date: 16 Jan 90 20:55:13 GMT From: Ken Dickey To: scheme@MC.lcs.mit.edu Subject: Re: () as an expression In article <1990Jan16.193134.10491@sun.soe.clarkson.edu> jk0@sun.soe.clarkson.edu (Jason Coughlin) writes: >The Revised^3 Report says that () is an illegal expression. It must >be quoted. However, MIT-Scheme and PC-Scheme both allow it, ie: .. >Why is () an invalid expression? It seems to me that it is a constant. > >(eq? #t #t) => #t >(eq? #f #f) => #t >(eq? '() '()) => #t > >now why isn't () considered a constant, when it really IS a constant? The syntax () is considered a combination (a.k.a. procedure call) and as such must have at lease one subexpression. So, the empty list is valid, but the empty combination is an error. Note also that #f and '() may be distinct in newer Scheme implementations [the value of (eq? '() #f) is currently unspecified]. There are other non-R^3RS behaviors allowed by various versions of Scheme implementations, particularly those implementations done before R^3RS was issued. -Ken Dickey ------------------------------ Message-ID: <1990Jan16.231311.18316@sun.soe.clarkson.edu> Date: 16 Jan 90 23:13:11 GMT From: Jason Coughlin To: scheme@mc.lcs.mit.edu Subject: Re: () as an expression From article <5413@tekcrl.LABS.TEK.COM>, by kend@tekchips.LABS.TEK.COM (Ken Dickey): > Note also that #f and '() may be distinct in newer Scheme > implementations [the value of (eq? '() #f) is currently unspecified]. This leads to another point: I think we need a definitive answer on whether #f == (). In my Scheme, #f and () are two different entities. I like this because in my mind, #f != (). #f is boolean, () is an empty list. So what say you about: (BOOLEAN? '()) (NULL? '()) (EQ? '() #f) -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants ------------------------------ End of Scheme Digest ********************  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 16 Jan 90 19:09:35 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18219; 16 Jan 90 19:07 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA24050; Tue, 16 Jan 90 18:26:50 EST 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: 16 Jan 90 23:13:11 GMT From: Jason Coughlin Organization: Clarkson University, Potsdam, NY Subject: Re: () as an expression Message-Id: <1990Jan16.231311.18316@sun.soe.clarkson.edu> References: <5413@tekcrl.LABS.TEK.COM> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu From article <5413@tekcrl.LABS.TEK.COM>, by kend@tekchips.LABS.TEK.COM (Ken Dickey): > Note also that #f and '() may be distinct in newer Scheme > implementations [the value of (eq? '() #f) is currently unspecified]. This leads to another point: I think we need a definitive answer on whether #f == (). In my Scheme, #f and () are two different entities. I like this because in my mind, #f != (). #f is boolean, () is an empty list. So what say you about: (BOOLEAN? '()) (NULL? '()) (EQ? '() #f) -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 16 Jan 90 17:09:17 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa13174; 16 Jan 90 17:07 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA18041; Tue, 16 Jan 90 16:34:03 EST 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: 16 Jan 90 20:55:13 GMT From: Ken Dickey Organization: Tektronix, Inc., Beaverton, OR. Subject: Re: () as an expression Message-Id: <5413@tekcrl.LABS.TEK.COM> References: <1990Jan16.193134.10491@sun.soe.clarkson.edu> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu In article <1990Jan16.193134.10491@sun.soe.clarkson.edu> jk0@sun.soe.clarkson.edu (Jason Coughlin) writes: >The Revised^3 Report says that () is an illegal expression. It must >be quoted. However, MIT-Scheme and PC-Scheme both allow it, ie: ... >Why is () an invalid expression? It seems to me that it is a constant. > >(eq? #t #t) => #t >(eq? #f #f) => #t >(eq? '() '()) => #t > >now why isn't () considered a constant, when it really IS a constant? The syntax () is considered a combination (a.k.a. procedure call) and as such must have at lease one subexpression. So, the empty list is valid, but the empty combination is an error. Note also that #f and '() may be distinct in newer Scheme implementations [the value of (eq? '() #f) is currently unspecified]. There are other non-R^3RS behaviors allowed by various versions of Scheme implementations, particularly those implementations done before R^3RS was issued. -Ken Dickey  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 16 Jan 90 15:14:34 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa08566; 16 Jan 90 15:07 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA12436; Tue, 16 Jan 90 14:37:50 EST 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: 16 Jan 90 19:31:34 GMT From: Jason Coughlin Organization: Clarkson University, Potsdam, NY Subject: () as an expression Message-Id: <1990Jan16.193134.10491@sun.soe.clarkson.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu The Revised^3 Report says that () is an illegal expression. It must be quoted. However, MIT-Scheme and PC-Scheme both allow it, ie: MIT-SCHEME => () () MIT-SCHEME => Why is () an invalid expression? It seems to me that it is a constant. (eq? #t #t) => #t (eq? #f #f) => #t (eq? '() '()) => #t now why isn't () considered a constant, when it really IS a constant? -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 16 Jan 90 05:12:36 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa15345; 16 Jan 90 5:06 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA11028; Tue, 16 Jan 90 04:33:32 EST 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: 15 Jan 90 16:11:36 GMT From: Prakash Panangaden Organization: Queen's University, Kingston Ontario Subject: Re: (none) Message-Id: <502@qusunitb.queensu.CA> References: <9001050058.aa04151@mintaka.lcs.mit.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Is there anyone who knows where to get PC schemes in Canada? Thanks  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Jan 90 16:19:00 EST Received: from cunyvm.cuny.edu by mintaka.lcs.mit.edu id aa22174; 15 Jan 90 16:07 EST Received: from arpa.att.com by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with TCP; Mon, 15 Jan 90 15:57:09 EDT From: attmail!uucp@att.att.com To: Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu@cunyvm.cuny.edu Report-Version: 2 >To: attbl!arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu (Automatic Scheme Digestifier ) Date: Sun Jan 14 14:39:56 EST 1990 MTS-Message-ID: <1992911010698690141939560> Original-Date: Sun Jan 14 00:02:05 EST 1990 Not-Delivered-To: !anybody due to 10 Invalid Parameters Message header has unacceptable format End-of-Header: Content-Type: message Content-Length: 2024 Message-ID: <9001151607.aa22174@mintaka.lcs.mit.edu> Received: from attbl by attmail; Sun Jan 14 19:39 GMT 1990 >From arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu Sun Jan 14 00:02:05 EST 1990 remote from attbl Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7238; Sun, 14 Jan 90 05:17:49 EDT Received: by BNANDP11 (Mailer R2.02A) id 4771; Sun, 14 Jan 90 11:17:27 +0100 Date: Sun, 14 Jan 90 00:02:05 EST Reply-To: Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu@CUNYVM.CUNY.EDU Sender: Scheme Programming Language From: attbl!arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu (Automatic Scheme Digestifier) Subject: Scheme Digest #274 Comments: To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu To: ICSUG TEST GROUP Scheme Digest #274 14 JAN 90 00:02:05 EST Today's Topics: location of SIOD Revised^4 Definition ---------------------------------------------------------------------- Message-Id: <9001131533.AA20984@bu-it.bu.edu> Date: Sat, 13 Jan 90 10:34 EST From: GJC@buenga.bu.edu Subject: location of SIOD Clarification of the location of SIOD: Scheme in One Defun. BU.EDU is 128.197.2.6, users/gjc/siod-v2.3-shar ------------------------------ Date: 13 Jan 90 20:02:34 GMT From: Jason Coughlin Subject: Revised^4 Definition Message-Id: <1990Jan13.200234.18252@sun.soe.clarkson.edu> Have I heard correctly that there is now a Revised^4 Report on Scheme? If so, where can I get the LaTeX source for it? -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants ------------------------------ End of Scheme Digest ********************  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 13 Jan 90 16:07:50 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa08976; 13 Jan 90 16:06 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA28141; Sat, 13 Jan 90 15:16:27 EST 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: 13 Jan 90 20:02:34 GMT From: Jason Coughlin Organization: Clarkson University, Potsdam, NY Subject: Revised^4 Definition Message-Id: <1990Jan13.200234.18252@sun.soe.clarkson.edu> References: <9001131533.AA20984@bu-it.bu.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Have I heard correctly that there is now a Revised^4 Report on Scheme? If so, where can I get the LaTeX source for it? -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 13 Jan 90 10:36:31 EST Received: from BU.EDU by mintaka.lcs.mit.edu id aa27523; 13 Jan 90 10:33 EST Received: from BU-IT.BU.EDU by BU.EDU (1.97) Sat, 13 Jan 90 10:33:32 EST Received: from buenga.bu.edu by bu-it.bu.edu (12/20/89); Sat, 13 Jan 90 10:33:30 EST Message-Id: <9001131533.AA20984@bu-it.bu.edu> Date: Sat, 13 Jan 90 10:34 EST From: GJC@buenga.bu.edu Subject: location of SIOD To: scheme@mc.lcs.mit.edu X-Vms-To: IN%"scheme@mc.lcs.mit.edu" Clarification of the location of SIOD: Scheme in One Defun. BU.EDU is 128.197.2.6, users/gjc/siod-v2.3-shar  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 12 Jan 90 22:06:10 EST Received: from relay.cs.net by mintaka.lcs.mit.edu id ab03990; 12 Jan 90 22:01 EST Received: from relay2.cs.net by RELAY.CS.NET id ak01375; 12 Jan 90 18:59 EST Received: from zix.gmd.dbp.de by RELAY.CS.NET id az20931; 12 Jan 90 19:58 EST Received: from zix.gmd.dbp.de by .zix.gmd.dbp.de id a005059; 12 Jan 90 18:54 MET Date: 12 Jan 90 07:47 PST From: Peter Schindler To: SCHEME@mc.lcs.mit.edu Message-ID: <4:schindler@vax1.informatik.fh-regensburg.dbp.de> Subject: HELP HELP  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 12 Jan 90 18:19:57 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa29368; 12 Jan 90 18:18 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA29707; Fri, 12 Jan 90 17:55:22 EST 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: 12 Jan 90 22:48:39 GMT From: Dirk Grunwald Organization: University of Colorado at Boulder Subject: Re: Compiling Scheme (Summary) Message-Id: <15594@boulder.Colorado.EDU> References: <1990Jan10.024859.28865@sun.soe.clarkson.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu sadly, you all missed one of the more interesting papers, by luddy harrison at the Univ. of Illinois Center for Supercomputing Res. and Dev. (CSRD). ``compiling lisp for evaluation on a tightly coupled multiprocessor'' CSRD tech report #565 by W. Ludwell Harrison, III luddy wrote a scheme compiler that allegedly out-gabriales everything. It runs on an alliant FX-8. It concurrentizes & vectorizes, if I recall correctly. Dirk Grunwald -- Univ. of Colorado at Boulder (grunwald@foobar.colorado.edu) (grunwald@boulder.colorado.edu)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 12 Jan 90 01:33:06 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa23009; 12 Jan 90 0:54 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA07408; Fri, 12 Jan 90 00:38:59 EST 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: 12 Jan 90 03:58:58 GMT From: Ken Dickey Organization: Tektronix, Inc., Beaverton, OR. Subject: Re: Compiling Scheme Message-Id: <5375@tekcrl.LABS.TEK.COM> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Upon reading my posting I see that I forgot Kent Dybvig's Thesis: "Three Implementation Models for Scheme", U of North Carolina at Chappel Hill, 1987. (Sorry, Kent!) -Ken Dickey  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 11 Jan 90 16:40:15 EST Received: from ucbeh.san.uc.edu by mintaka.lcs.mit.edu id aa04135; 11 Jan 90 15:37 EST Date: Thu, 11 Jan 90 14:13 EST From: Amin Shafie - Univ of Cincinnati Comp Ctr Subject: SIGUCCS CALL for PARTICIPATION To: 386USERS@twg.com, 9370-L%HEARN.BITNET@mitvma.mit.edu, AAI@st-louis-emh2.army.mil, ADA-SW@wsmr-simtel20.army.mil, ADVISE-L%CANADA01.BITNET@cunyvm.cuny.edu, ADVSYS@eddie.mit.edu, AG-EXP-L%NDSUVM1.BITNET@cunyvm.cuny.edu, AI-ED@sumex-aim.stanford.edu, AIDSNEWS%RUTVM1.BITNET@cunyvm.cuny.edu, AIList@ai.ai.mit.edu, AIX-L%BUACCA.BITNET@mitvma.mit.edu, ALLIN1-L@ccvm.sunysb.edu, AMETHYST-USERS@wsmr-simtel20.army.mil, AMIGA-RELAY@udel.edu, ANDREW-DEMOS@andrew.cmu.edu, ANTHRO-L%UBVM.BITNET@cunyvm.cuny.edu, apollo@umix.cc.umich.edu, ARMS-D@xx.lcs.mit.edu, ARPANET-BBOARDS@mc.lcs.mit.edu, ASM370%UCF1VM.BITNET@cunyvm.cuny.edu, AVIATION@mc.lcs.mit.edu, AVIATION-THEORY@mc.lcs.mit.edu, bicycles@bbn.com, BIG-LAN@suvm.acs.syr.edu, BIG-LAN@suvm.bitnet, BIOTECH%UMDC.BITNET@cunyvm.cuny.edu, BIOTECH@umdc.umd.edu, BITNEWS%BITNIC.BITNET@cunyvm.cuny.edu, BMDP-L%MCGILL1.BITNET@cornellc.ccs.cornell.edu, bug-1100@sumex-aim.stanford.edu, CA@think.com, CADinterest^.es@xerox.com, CAN-INET@mc.lcs.mit.edu, cisco@spot.colorado.edu Message-id: X-Envelope-to: V2LNI-PEOPLE@MC.LCS.MIT.EDU, SCHEME@MC.LCS.MIT.EDU, NIHONGO@MC.LCS.MIT.EDU, INFO-JAPAN@MC.LCS.MIT.EDU, Heath-People@MC.LCS.MIT.EDU, HEADER-PEOPLE@MC.LCS.MIT.EDU, Dead-Flames@MC.LCS.MIT.EDU, CAN-INET@MC.LCS.MIT.EDU, AVIATION-THEORY@MC.LCS.MIT.EDU, AVIATION@MC.LCS.MIT.EDU, ARPANET-BBOARDS@MC.LCS.MIT.EDU X-VMS-To: @LISTS.DIS X-VMS-Cc: SHAFIE <-------------------------------------------------------------------- < < SIGUCCS User Services Conference XVIII < Call For Participation < < New Centerings in Computing Services < < September 30 through October 3, 1990 < < Westin Hotel < Cincinnati, Ohio < < <<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << < Organization: floenz1, Public Access UNIX Munich/W.-Germany Subject: Re: Texas Instruments PC Scheme Message-Id: <1158@doitcr.UUCP> References: <17909@super.ORG> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <17909@super.ORG> pcolsen@super.UUCP (Peter C Olsen) writes: } I found this out only by accident --- I used another computer with V3.03. } I've written TI twice about upgrades, and they have yet to answer. Are they } still in business???!!? Well, they even developed a version 4.0. It is bundled with one of their expert system shells. But it wasn't developed only by TI. There was another company working on the code. Perhaps this prevents TI from distributing version 4.0. My software dealer here in the Federal Republic of Germany sells version 3.03 for 330 DM. I can give his address to you. flo@floenz1.doit.sub.org or via Bitnet: doitcr!floenz1!flo@tmpmbx.uucp  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 10 Jan 90 15:57:41 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa12310; 10 Jan 90 15:56 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA02398; Wed, 10 Jan 90 15:48:52 EST 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: 10 Jan 90 20:23:20 GMT From: Ken Dickey Organization: Tektronix, Inc., Beaverton, OR. Subject: Re: Compiling Scheme (Summary) Message-Id: <5365@tekcrl.LABS.TEK.COM> References: <1990Jan10.024859.28865@sun.soe.clarkson.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <1990Jan10.024859.28865@sun.soe.clarkson.edu> jk0@sun.soe.clarkson.edu (Jason Coughlin) writes: >This is quite a hot issue so I thought I'd post a summary of what I >received. Thanks to everyone who gave me a lead! > I guess I missed your request. Here are the references I have to published works on Scheme compilation: Sussman, Gerald Jay: "LISP, Programming and Implementation", in "Functional Programming and its Applications" Eds: Darlington, Henderson, & Turner Cambridge U Press, 1982 Abelson & Sussman: "Structure and Interpretation of Computer Programs" MIT Press, 1985 Steele: "RABBIT: A Compiler for SCHEME (A Study in Compiler Optimization)" MIT AI-TR-474, May 1978 Rosas, Guillermo: "Liar, an Algol-like Compiler for Scheme" MIT Bachelor's thesis, January 24, 1987 Clinger, Will:"The Scheme 311 Compiler, An Excercise in Denotational Semantics" 1984 Symposium on Lisp and Functional Programming Bartley & Jensen: "The Implementation of PC Scheme" Proceedings of the 1986 ACM Conference on Lisp and Functional Programming Kranz, ... Adams , et al: "Orbit, an Optimizing Compiler for Scheme" SigPlan Notices V21, #7, July 1986 Wand: "From Interpreter to Compiler: A Representational Derivation" in "Programs as Data Objects", Springer-Verlag lecture notes 217, 1986. Feeley & Lapine: "Using Closures for Code Generation" Computer Languages: V12, #1 1987 Vegdahl & Pleban: "The Runtime Environment for Screme, a Scheme implementation on the 88000", SIGPLAN Notices, Vol 24 Special Issue, May 1989. Also, the latest issue of LISP AND SYMBOLIC COMPUTATION which contains a loooong article on compiling Scheme for parallel machines. -Ken Dickey  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 10 Jan 90 06:13:15 EST Received: from cunyvm.cuny.edu by mintaka.lcs.mit.edu id aa19149; 10 Jan 90 6:05 EST Received: from arpa.att.com by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with TCP; Wed, 10 Jan 90 06:05:04 EDT From: attmail!uucp@att.att.com To: Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu@cunyvm.cuny.edu Report-Version: 2 >To: attbl!arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu (Automatic Scheme Digestifier ) Date: Wed Jan 10 05:39:37 EST 1990 MTS-Message-ID: <597911010698690101039370> Original-Date: Wed Jan 10 00:00:38 EST 1990 Not-Delivered-To: !anybody due to 10 Invalid Parameters Message header has unacceptable format End-of-Header: Content-Type: message Content-Length: 7319 Message-ID: <9001100605.aa19149@mintaka.lcs.mit.edu> Received: from attbl by attmail; Wed Jan 10 10:39 GMT 1990 >From arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu Wed Jan 10 00:00:38 EST 1990 remote from attbl Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 9145; Wed, 10 Jan 90 03:38:55 EDT Received: by BNANDP11 (Mailer R2.02A) id 5272; Wed, 10 Jan 90 09:26:28 +0100 Date: Wed, 10 Jan 90 00:00:38 EST Reply-To: Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu@CUNYVM.CUNY.EDU Sender: Scheme Programming Language From: attbl!arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu (Automatic Scheme Digestifier) Subject: Scheme Digest #270 Comments: To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu To: ICSUG TEST GROUP Scheme Digest #270 10 JAN 90 00:00:38 EST Today's Topics: t3.1 on Apollo SR10 Pretty Printer Source Code Compiling Scheme (Summary) ---------------------------------------------------------------------- Date: 8 Jan 90 19:02:12 GMT From: Patrick Logan Subject: t3.1 on Apollo SR10 Message-Id: <1990Jan8.190212.354@mentor.com> I have ftp'd t3.1 from MIT and am trying to get it running on Apollo SR10. My current problem is this: % bl st.image error loading t: seeking for data section - bad length (process manager/mapped segment manager) Has anyone run into this? Have you fixed it? More information: -rwxr-xr-x+ 1 plogan sim 8530 Feb 24 1989 bl -rwxr-xr-x+ 1 plogan sim 4456 Feb 24 1989 float.bin -rwxr-xr-x+ 1 plogan sim 2428 Feb 27 1989 float.pas -rwxr-xr-x+ 1 plogan sim 2886648 Feb 24 1989 st.image This is curiously not COFF: % file bl bl: obj apollo type obj executable (OBJ) This is curious too. What is this supposed to be? % file ../apollo_sr10_bl ../apollo_sr10_bl: unstruct data % ll ../apollo_sr10_bl -rwxr-xr-x+ 1 plogan sim 8530 Jan 7 14:19 ../apollo_sr10_bl If anyone can offer any help, I'd appreciate it. Until then, I'll be debugging... -- Patrick Logan | ...!{decwrl,sequent,tessi}!mntgfx!plogan Mentor Graphics Corporation | plogan@pdx.MENTOR.COM Beaverton, Oregon | ------------------------------ Date: 10 Jan 90 02:50:49 GMT From: Jason Coughlin Subject: Pretty Printer Source Code Message-Id: <1990Jan10.025049.28982@sun.soe.clarkson.edu> Does anyone have source code to a pretty printer for LISP or Scheme? LISP or Scheme code would be nice, but beggars can't be choosers :-)! Either email or post. Thank you! -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants ------------------------------ Date: 10 Jan 90 02:48:59 GMT From: Jason Coughlin Subject: Compiling Scheme (Summary) Message-Id: <1990Jan10.024859.28865@sun.soe.clarkson.edu> This is quite a hot issue so I thought I'd post a summary of what I received. Thanks to everyone who gave me a lead! The best I've found so far is in _Structure and Interpretation and Computer Programs_ by Harold Abelson, Gerald Jay Sussman, and Julie Sussman. This is a GREAT book that IMHO should be used to teach undergrad Programming Languages courses. Anyway, enjoy! From: Ozan Yigit * The best reference on compiling scheme appears to be SIofCP of Abelson & Sussman. * Also check out xscheme * Allen's "Anatomy Of Lisp" also has a From: Matthias Felleisen * You may want to look at a paper by Will Clinger in the proceedings of Lisp & Functional Programming 1984. His paper on deriving a byte-code compiler for Scheme has some title like "An exercise in denotational semantics." The resulting system, Scheme 311, was used at Indiana for a few years. * If you want the code of a byte-code compiler for unix machines and you have FRANZ LISP, write to nlg@indiana.iuvax.cs.edu and ask whether they still distribute Scheme84. I have a revision of Scheme84, called Scheme88, that is pretty much the same thing (a bit cleaner inside, but not much) except that it uses Common Lisp for the interpretation of byte-code. From: Denys Duchier * Check Guy Steele's thesis (RABBIT a compiler for scheme) (MIT) * also David Krantz's thesis (ORBIT, an optimizing compiler for scheme) (YALE). From: Simon Leinen here comes a list of references to books and articles about the problem of compiling Scheme or Lisp. I don't know whether it is correct `refer' syntax. I distributed the following keywords of my own creation: scheme - concerned with scheme rather than lisp lisp - concerned with lisp rather than scheme commonlisp - maclisp/common lisp (more like scheme) standardlisp - psl/cambridge etc. (less like scheme, e.g. no closures) compiler - all articles deal with compilation (more or less) %A R. R. Kessler %A J. C. Peterson %A H. Carr %A G.P. Duggan %A J. Knell %A J.J. Krohnfeldt %T EPIC - a retargetable, highly optimizing Lisp compiler %J Proc. Sigplan 1986 Sym. on Compiler Construction %D June 1986 %C New York %P 118-130 %K lisp standardlisp compiler %A D. Kranz %A R. Kelsey %A J. Rees %A P. Hudak %A J. Philbin %A N. Adams %T ORBIT: an optimizing compiler for Scheme %J Proc. Sigplan '86 Sym. on Compiler Construction %D June 1986 %C New York %P 219-233 %K scheme compiler %A G. L. Steele Jr. %T RABBIT: a compiler for Scheme %R AI Memo 474 %C Massachusetts Institute of Technology %D May 1978 %K scheme compiler %A R. A. Brooks %A R. P. Gabriel %A G. L. Steele Jr. %T An optimizing compiler for lexicaly scoped LISP %J Proc. 1982 Sym. on Compiler Construction %D June 1982 %V 17 %N 4 %K lisp commonlisp compiler %A R. A. Brooks %A R. P. Gabriel %A G. L. Steele Jr. %T S-1 Common Lisp implementation %J Proc. 1982 Sym. on Lisp and Functional Programming %D August 1982 %C New York %K lisp commonlisp compiler %A O. Shivers %T Control flow analysis in Scheme %J Proc. Sigplan 1988 Conf. on Programming Language Design and Implementation %D 1988 %C New York %K scheme compiler %A R. A. Brooks %A D. B. Posner %A J. L. McDonald %A J. L. White %A E. Benson %A R. P. Gabriel %T Design of an optimizing, dynamically retargetable compiler for Common Lisp %K lisp commonlisp compiler %A R. P. Gabriel %T Performance and evaluation of Lisp systems %I MIT Press %C Cambridge, Mass. %D 1985 %K lisp compiler %A M. L. Griss %A A. C. Hearn %T A portable LISP compiler %J Software Practice and Experience %N 11 %D 1981 %P 541-605 %K lisp standardlisp compiler -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants ------------------------------ End of Scheme Digest ********************  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Jan 90 23:00:55 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03705; 9 Jan 90 22:54 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA06916; Tue, 9 Jan 90 21:58:53 EST 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: 10 Jan 90 02:48:59 GMT From: Jason Coughlin Organization: Clarkson University, Potsdam, NY Subject: Compiling Scheme (Summary) Message-Id: <1990Jan10.024859.28865@sun.soe.clarkson.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu This is quite a hot issue so I thought I'd post a summary of what I received. Thanks to everyone who gave me a lead! The best I've found so far is in _Structure and Interpretation and Computer Programs_ by Harold Abelson, Gerald Jay Sussman, and Julie Sussman. This is a GREAT book that IMHO should be used to teach undergrad Programming Languages courses. Anyway, enjoy! From: Ozan Yigit * The best reference on compiling scheme appears to be SIofCP of Abelson & Sussman. * Also check out xscheme * Allen's "Anatomy Of Lisp" also has a From: Matthias Felleisen * You may want to look at a paper by Will Clinger in the proceedings of Lisp & Functional Programming 1984. His paper on deriving a byte-code compiler for Scheme has some title like "An exercise in denotational semantics." The resulting system, Scheme 311, was used at Indiana for a few years. * If you want the code of a byte-code compiler for unix machines and you have FRANZ LISP, write to nlg@indiana.iuvax.cs.edu and ask whether they still distribute Scheme84. I have a revision of Scheme84, called Scheme88, that is pretty much the same thing (a bit cleaner inside, but not much) except that it uses Common Lisp for the interpretation of byte-code. From: Denys Duchier * Check Guy Steele's thesis (RABBIT a compiler for scheme) (MIT) * also David Krantz's thesis (ORBIT, an optimizing compiler for scheme) (YALE). From: Simon Leinen here comes a list of references to books and articles about the problem of compiling Scheme or Lisp. I don't know whether it is correct `refer' syntax. I distributed the following keywords of my own creation: scheme - concerned with scheme rather than lisp lisp - concerned with lisp rather than scheme commonlisp - maclisp/common lisp (more like scheme) standardlisp - psl/cambridge etc. (less like scheme, e.g. no closures) compiler - all articles deal with compilation (more or less) %A R. R. Kessler %A J. C. Peterson %A H. Carr %A G.P. Duggan %A J. Knell %A J.J. Krohnfeldt %T EPIC - a retargetable, highly optimizing Lisp compiler %J Proc. Sigplan 1986 Sym. on Compiler Construction %D June 1986 %C New York %P 118-130 %K lisp standardlisp compiler %A D. Kranz %A R. Kelsey %A J. Rees %A P. Hudak %A J. Philbin %A N. Adams %T ORBIT: an optimizing compiler for Scheme %J Proc. Sigplan '86 Sym. on Compiler Construction %D June 1986 %C New York %P 219-233 %K scheme compiler %A G. L. Steele Jr. %T RABBIT: a compiler for Scheme %R AI Memo 474 %C Massachusetts Institute of Technology %D May 1978 %K scheme compiler %A R. A. Brooks %A R. P. Gabriel %A G. L. Steele Jr. %T An optimizing compiler for lexicaly scoped LISP %J Proc. 1982 Sym. on Compiler Construction %D June 1982 %V 17 %N 4 %K lisp commonlisp compiler %A R. A. Brooks %A R. P. Gabriel %A G. L. Steele Jr. %T S-1 Common Lisp implementation %J Proc. 1982 Sym. on Lisp and Functional Programming %D August 1982 %C New York %K lisp commonlisp compiler %A O. Shivers %T Control flow analysis in Scheme %J Proc. Sigplan 1988 Conf. on Programming Language Design and Implementation %D 1988 %C New York %K scheme compiler %A R. A. Brooks %A D. B. Posner %A J. L. McDonald %A J. L. White %A E. Benson %A R. P. Gabriel %T Design of an optimizing, dynamically retargetable compiler for Common Lisp %K lisp commonlisp compiler %A R. P. Gabriel %T Performance and evaluation of Lisp systems %I MIT Press %C Cambridge, Mass. %D 1985 %K lisp compiler %A M. L. Griss %A A. C. Hearn %T A portable LISP compiler %J Software Practice and Experience %N 11 %D 1981 %P 541-605 %K lisp standardlisp compiler -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Jan 90 22:54:31 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03646; 9 Jan 90 22:52 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA06931; Tue, 9 Jan 90 21:59:24 EST 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: 10 Jan 90 02:50:49 GMT From: Jason Coughlin Organization: Clarkson University, Potsdam, NY Subject: Pretty Printer Source Code Message-Id: <1990Jan10.025049.28982@sun.soe.clarkson.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anyone have source code to a pretty printer for LISP or Scheme? LISP or Scheme code would be nice, but beggars can't be choosers :-)! Either email or post. Thank you! -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Jan 90 03:31:26 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa08818; 8 Jan 90 22:53 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA00757; Mon, 8 Jan 90 22:19:23 EST 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: 8 Jan 90 19:02:12 GMT From: Patrick Logan Organization: engr Subject: t3.1 on Apollo SR10 Message-Id: <1990Jan8.190212.354@mentor.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I have ftp'd t3.1 from MIT and am trying to get it running on Apollo SR10. My current problem is this: % bl st.image error loading t: seeking for data section - bad length (process manager/mapped segment manager) Has anyone run into this? Have you fixed it? More information: -rwxr-xr-x+ 1 plogan sim 8530 Feb 24 1989 bl -rwxr-xr-x+ 1 plogan sim 4456 Feb 24 1989 float.bin -rwxr-xr-x+ 1 plogan sim 2428 Feb 27 1989 float.pas -rwxr-xr-x+ 1 plogan sim 2886648 Feb 24 1989 st.image This is curiously not COFF: % file bl bl: obj apollo type obj executable (OBJ) This is curious too. What is this supposed to be? % file ../apollo_sr10_bl ../apollo_sr10_bl: unstruct data % ll ../apollo_sr10_bl -rwxr-xr-x+ 1 plogan sim 8530 Jan 7 14:19 ../apollo_sr10_bl If anyone can offer any help, I'd appreciate it. Until then, I'll be debugging... -- Patrick Logan | ...!{decwrl,sequent,tessi}!mntgfx!plogan Mentor Graphics Corporation | plogan@pdx.MENTOR.COM Beaverton, Oregon |  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Jan 90 22:44:34 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa10527; 5 Jan 90 17:15 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA22378; Fri, 5 Jan 90 16:42:36 EST 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: 5 Jan 90 21:34:11 GMT From: Scott Hankin Subject: Re: mac scheme implementations Message-Id: <2468@paperboy.OSF.ORG> References: <9001051959.AA13175@schizo.samsung.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu gjc@mitech.COM writes: >SIOD will run on the Mac, probably with a little modification for >Lightspeed C. anonymous ftp to bu.edu and cd to src/gjc and get >siod-v2.3-shar Actually, its in users/gjc. ------------------------------ Scott Hankin (hankin@osf.org) Open Software Foundation  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Jan 90 22:41:58 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa08034; 5 Jan 90 16:09 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA17551; Fri, 5 Jan 90 15:25:55 EST 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: 5 Jan 90 16:38:18 GMT From: John Gateley Organization: TI Computer Science Center, Dallas Subject: Re: exit on Schemes for Unix Message-Id: <104546@ti-csl.csc.ti.com> References: <9001041217.AA11268@huxley.mitre.org> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <9001041217.AA11268@huxley.mitre.org> ramsdell@LINUS.MITRE.ORG writes: >When the exit command is called with no >arguments, or when there is nothing more to read from standard input, >the Scheme interpreter process should set the status bits returned to >the parent process to the break level. I agree except for one thing: It should merely set the status bits to a non-zero value (or whatever restriction Unix percieves as an error). This allows the scheme program to return more useful error information: (error 57) where 57 is the error number for directory not found, John gateley@m2.csc.ti.com  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Jan 90 15:06:08 EST Received: from schizo.samsung.com by mintaka.lcs.mit.edu id aa05291; 5 Jan 90 15:01 EST Received: by schizo.samsung.com from mitech.UUCP via UUCP (vers 5.61+) for scheme@mc.lcs.mit.edu (from gjc@mitech.com) id ; Fri, 5 Jan 90 14:59:02 -0500 Message-Id: <9001051959.AA13175@schizo.samsung.com> Reply-To: gjc@mitech.com MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Received: by mitech.com (DECUS UUCP w/Smail); Fri, 5 Jan 90 09:34:13 EDT Date: Fri, 5 Jan 90 09:34:13 EDT From: gjc@mitech.com MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu To: scheme@mc.lcs.mit.edu Subject: mac scheme implementations X-Vms-Mail-To: UUCP%"scheme@mc.lcs.mit.edu" SIOD will run on the Mac, probably with a little modification for Lightspeed C. anonymous ftp to bu.edu and cd to src/gjc and get siod-v2.3-shar Note on interpreters: I tried SABER-C on a SUN-4 with SLIB.C compiled and SIOD.C interpreted. By running (standard-fib 15) vs. (cfib 15) we can then test the scheme interpreter speed vs the SABER-C interpreter speed. Here is the code: (define (standard-fib x) (if (< x 2) x (+ (standard-fib (- x 1)) (standard-fib (- x 2))))) LISP cfib(x) LISP x; {if NNULLP(lessp(x,my_two)) return(x); else return(plus(cfib(difference(x,my_one)), cfib(difference(x,my_two))));} RESULT: The scheme interpreter is more than 10 times faster (takes less than 1/10'th the time to compute fib(15)) than the SABER-C interpreter. -gjc  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Jan 90 14:18:51 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02897; 5 Jan 90 14:13 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA11367; Fri, 5 Jan 90 13:42:03 EST 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: 5 Jan 90 18:20:59 GMT From: "David H. West" Organization: Industrial Technology Institute Subject: Re: TI PC-Scheme (was (none)) Message-Id: <4737@itivax.iti.org> References: <9001050058.aa04151@mintaka.lcs.mit.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <9001050058.aa04151@mintaka.lcs.mit.edu> uucp@attmail.UUCP writes: |From: Peter C Olsen |Subject: Texas Instruments PC Scheme | |Can anyone tell me how to communicate with Texas Instruments about |their PC Scheme? [...] |I've written TI twice about upgrades, and they have yet to answer. Are they |still in business???!!? I just called the local TI sales office, and got my 3.0 upgraded to 3.03 with no trouble at all. They did want the original floppies back, though.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Jan 90 02:20:45 EST Received: from cunyvm.cuny.edu by mintaka.lcs.mit.edu id aa06444; 5 Jan 90 2:16 EST Received: from arpa.att.com by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with TCP; Fri, 05 Jan 90 01:52:50 EDT From: attmail!uucp@att.att.com To: Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu@cunyvm.cuny.edu Report-Version: 2 >To: attbl!arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu (Automatic Scheme Digestifier ) Date: Fri Jan 5 01:04:02 EST 1990 MTS-Message-ID: <1393011010698690050604020> Original-Date: Fri Jan 5 00:11:45 EST 1990 Not-Delivered-To: !anybody due to 10 Invalid Parameters Message header has unacceptable format End-of-Header: Content-Type: message Content-Length: 2862 Message-ID: <9001050216.aa06444@mintaka.lcs.mit.edu> Received: from attbl by attmail; Fri Jan 5 06:03 GMT 1990 >From arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu Fri Jan 5 00:11:45 EST 1990 remote from attbl Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 9863; Fri, 05 Jan 90 00:43:57 EDT Received: by BNANDP11 (Mailer R2.02A) id 7403; Fri, 05 Jan 90 06:35:18 +0100 Date: Fri, 5 Jan 90 00:11:45 EST Reply-To: Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu@CUNYVM.CUNY.EDU Sender: Scheme Programming Language From: attbl!arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu (Automatic Scheme Digestifier) Subject: Scheme Digest #268 Comments: To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu To: ICSUG TEST GROUP Scheme Digest #268 5 JAN 90 00:11:45 EST Today's Topics: Mac implementations exit on Schemes for Unix ---------------------------------------------------------------------- Date: 4 Jan 90 05:52:29 GMT From: Andres Moreno Subject: Mac implementations Message-Id: <18025@umn-cs.CS.UMN.EDU> Does anybody have any experience with MacScheme? Do you recomend to look into another dialect of LISP for this machine? Does anyone know anything about ExperLOGO? I'd appreciate any suggestions regarding LISPs and Schemes for PCs or Macs (or any other small machine costing less than $4,000) since I am in the market for a new computer. Thanks, Andres F. Moreno ------------------------------ From: ramsdell@linus.mitre.org Message-Id: <9001041217.AA11268@huxley.mitre.org> Subject: exit on Schemes for Unix Date: Thu, 04 Jan 90 07:17:56 EST Please remember, Scheme is not always used interactively!!! To: Implementors of Scheme on Unix Subject: Let your Scheme's exit status reflect the current break level. I would like to encourage all Scheme Implementors which target Unix to add a fairly simple feature. When the exit command is called with no arguments, or when there is nothing more to read from standard input, the Scheme interpreter process should set the status bits returned to the parent process to the break level. When there has been no errors, that status should be set to zero, the Unix convention for successful completion. A non-zero break level indicates an error, and that state should be reflected by a non-zero exit status. For just one example of where this might be useful, consider the writing of Makefiles. Suppose we have the rule: .scm.sobj: echo "(compile-file \"$*.sobj\")" | scheme The rule will fail when the compiler detects an error. John ------------------------------ End of Scheme Digest ********************  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Jan 90 01:01:34 EST Received: from cunyvm.cuny.edu by mintaka.lcs.mit.edu id aa04151; 5 Jan 90 0:58 EST Received: from arpa.att.com by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with TCP; Fri, 05 Jan 90 00:57:34 EDT From: attmail!uucp@att.att.com To: Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu@cunyvm.cuny.edu Report-Version: 2 >To: attbl!arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu (Automatic Scheme Digestifier ) Date: Thu Jan 4 21:46:24 EST 1990 MTS-Message-ID: <527711010698690050246240> Original-Date: Thu Dec 28 00:03:49 EST 1989 Not-Delivered-To: !anybody due to 10 Invalid Parameters Message header has unacceptable format End-of-Header: Content-Type: message Content-Length: 1777 Message-ID: <9001050058.aa04151@mintaka.lcs.mit.edu> Received: from attbl by attmail; Fri Jan 5 02:46 GMT 1990 >From arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu Thu Dec 28 00:03:49 EST 1989 remote from attbl Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7538; Thu, 04 Jan 90 17:47:53 EDT Received: by BNANDP11 (Mailer R2.02A) id 6674; Thu, 04 Jan 90 23:46:11 +0100 Date: Thu, 28 Dec 89 00:03:49 EST Reply-To: Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu@CUNYVM.CUNY.EDU Sender: Scheme Programming Language From: attbl!arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu (Automatic Scheme Digestifier) Subject: Scheme Digest #267 Comments: To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu To: ICSUG TEST GROUP Scheme Digest #267 28 DEC 89 00:03:49 EST Today's Topics: Texas Instruments PC Scheme ---------------------------------------------------------------------- Date: 24 Dec 89 03:53:20 GMT From: Peter C Olsen Subject: Texas Instruments PC Scheme Message-Id: <17909@super.ORG> Can anyone tell me how to communicate with Texas Instruments about their PC Scheme? I've had V3.0 for two years, and reported two bugs --- both of which have been corrected in supsequent releases. Unfortunately, I found this out only by accident --- I used another computer with V3.03. I've written TI twice about upgrades, and they have yet to answer. Are they still in business???!!? Peter Olsen pcolsen@super.org ------------------------------ End of Scheme Digest ********************  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 4 Jan 90 10:39:57 EST Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa01670; 4 Jan 90 10:38 EST Received: from linus.mitre.org by life.ai.mit.edu (4.0/AI-4.10) id AA02352; Thu, 4 Jan 90 10:37:17 EST Return-Path: Received: from huxley.mitre.org by linus.mitre.org (5.59/RCF-3S) id AA09889; Thu, 4 Jan 90 07:18:01 EST Posted-Date: Thu, 04 Jan 90 07:17:56 EST Received: by huxley.mitre.org (5.61/RCF-4C) id AA11268; Thu, 4 Jan 90 07:17:58 -0500 From: ramsdell@linus.mitre.org Message-Id: <9001041217.AA11268@huxley.mitre.org> To: scheme@life.ai.mit.edu Cc: ramsdell@linus.mitre.org Subject: exit on Schemes for Unix Date: Thu, 04 Jan 90 07:17:56 EST Please remember, Scheme is not always used interactively!!! To: Implementors of Scheme on Unix Subject: Let your Scheme's exit status reflect the current break level. I would like to encourage all Scheme Implementors which target Unix to add a fairly simple feature. When the exit command is called with no arguments, or when there is nothing more to read from standard input, the Scheme interpreter process should set the status bits returned to the parent process to the break level. When there has been no errors, that status should be set to zero, the Unix convention for successful completion. A non-zero break level indicates an error, and that state should be reflected by a non-zero exit status. For just one example of where this might be useful, consider the writing of Makefiles. Suppose we have the rule: .scm.sobj: echo "(compile-file \"$*.sobj\")" | scheme The rule will fail when the compiler detects an error. John  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 4 Jan 90 02:18:04 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05053; 4 Jan 90 2:11 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA15819; Thu, 4 Jan 90 01:38:01 EST 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: 4 Jan 90 05:52:29 GMT From: Andres Moreno Organization: CSci Dept., University of Minnesota, Mpls. Subject: Mac implementations Message-Id: <18025@umn-cs.CS.UMN.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anybody have any experience with MacScheme? Do you recomend to look into another dialect of LISP for this machine? Does anyone know anything about ExperLOGO? I'd appreciate any suggestions regarding LISPs and Schemes for PCs or Macs (or any other small machine costing less than $4,000) since I am in the market for a new computer. Thanks, Andres F. Moreno  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 27 Dec 89 10:15:02 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa00847; 27 Dec 89 10:09 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA21666; Wed, 27 Dec 89 09:32:18 EST 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: 24 Dec 89 03:53:20 GMT From: Peter C Olsen Organization: Supercomputing Research Center, Bowie, Md. Subject: Texas Instruments PC Scheme Message-Id: <17909@super.ORG> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Can anyone tell me how to communicate with Texas Instruments about their PC Scheme? I've had V3.0 for two years, and reported two bugs --- both of which have been corrected in supsequent releases. Unfortunately, I found this out only by accident --- I used another computer with V3.03. I've written TI twice about upgrades, and they have yet to answer. Are they still in business???!!? Peter Olsen pcolsen@super.org  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 22 Dec 89 13:09:11 EST Received: from cunyvm.cuny.edu by mintaka.lcs.mit.edu id aa17206; 22 Dec 89 13:07 EST Received: from arpa.att.com by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with TCP; Fri, 22 Dec 89 13:06:07 EDT From: attmail!uucp@att.att.com To: Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu@cunyvm.cuny.edu Report-Version: 2 >To: attbl!arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu (Automatic Scheme Digestifier ) Date: Fri Dec 22 12:32:22 EST 1989 MTS-Message-ID: <1413011010698693561732210> Original-Date: Fri Dec 22 00:03:38 EST 1989 Not-Delivered-To: !anybody due to 10 Invalid Parameters Message header has unacceptable format End-of-Header: Content-Type: message Content-Length: 2532 Message-ID: <8912221307.aa17206@mintaka.lcs.mit.edu> Received: from attbl by attmail; Fri Dec 22 17:32 GMT 1989 >From arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu Fri Dec 22 00:03:38 EST 1989 remote from attbl Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 4775; Fri, 22 Dec 89 10:20:29 EDT Received: by BNANDP11 (Mailer R2.02A) id 2981; Fri, 22 Dec 89 12:41:52 +0100 Date: Fri, 22 Dec 89 00:03:38 EST Reply-To: Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu@CUNYVM.CUNY.EDU Sender: Scheme Programming Language From: attbl!arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu (Automatic Scheme Digestifier) Subject: Scheme Digest #265 Comments: To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu To: ICSUG TEST GROUP Scheme Digest #265 22 DEC 89 00:03:38 EST Today's Topics: Prolog interpreter in LISP wanted ---------------------------------------------------------------------- Date: 21 Dec 89 19:47:43 GMT From: Dorai Sitaram Subject: Re: Prolog interpreter in LISP wanted Message-Id: <3932@brazos.Rice.edu> In article <3841@brazos.Rice.edu> dorai@titan.rice.edu (Dorai Sitaram) writes: >convenient to all concerned if I made it ftp'able from Rice, rather >than clog the net. > >Procedure: ftp titan.rice.edu (as anonymous) > get public/slog.sh > >slog.sh is a shar file, and contains two implementation files (slog.ss Drew Adams of Laboratoires de Marcoussis, France, very graciously informs me that the name "slog" is already used and probably copyrighted for a functional/logic language developed by his lab since 1984. To avoid complications, I've changed the name of the Prolog-in-Scheme embedding to "schelog," and hopefully this is a safe name. The file to ftp is now schelog.sh, but I've retained a soft link to it called slog.sh, so my previous instructions still remain valid for would-be ftp'ers. My thanks to Drew for letting me know. By the way, "schelog" is pronounced "Ski Lodge," of course. --dorai -- ------------------------------------------------------------------------------- It may be that the gulfs will wash us down; It may be we shall touch the Happy Isles. ------------------------------------------------------------------------------- ------------------------------ End of Scheme Digest ********************  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 21 Dec 89 15:16:51 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa06664; 21 Dec 89 15:11 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA24776; Thu, 21 Dec 89 14:57:51 EST 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: 21 Dec 89 19:47:43 GMT From: Dorai Sitaram Organization: Rice University, Houston Subject: Re: Prolog interpreter in LISP wanted Message-Id: <3932@brazos.Rice.edu> References: <1690@gannet.cl.cam.ac.uk>, <3833@brazos.Rice.edu>, <3841@brazos.Rice.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <3841@brazos.Rice.edu> dorai@titan.rice.edu (Dorai Sitaram) writes: >convenient to all concerned if I made it ftp'able from Rice, rather >than clog the net. > >Procedure: ftp titan.rice.edu (as anonymous) > get public/slog.sh > >slog.sh is a shar file, and contains two implementation files (slog.ss Drew Adams of Laboratoires de Marcoussis, France, very graciously informs me that the name "slog" is already used and probably copyrighted for a functional/logic language developed by his lab since 1984. To avoid complications, I've changed the name of the Prolog-in-Scheme embedding to "schelog," and hopefully this is a safe name. The file to ftp is now schelog.sh, but I've retained a soft link to it called slog.sh, so my previous instructions still remain valid for would-be ftp'ers. My thanks to Drew for letting me know. By the way, "schelog" is pronounced "Ski Lodge," of course. --dorai -- ------------------------------------------------------------------------------- It may be that the gulfs will wash us down; It may be we shall touch the Happy Isles. -------------------------------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 19 Dec 89 14:20:42 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa27890; 19 Dec 89 14:12 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA07948; Tue, 19 Dec 89 13:17:29 EST 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: 19 Dec 89 18:10:29 GMT From: Dorai Sitaram Organization: Rice University, Houston Subject: Re: Prolog interpreter in LISP wanted Message-Id: <3841@brazos.Rice.edu> References: <1690@gannet.cl.cam.ac.uk>, <3833@brazos.Rice.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <3833@brazos.Rice.edu> dorai@titan.rice.edu (Dorai Sitaram) writes: >[This is also addressed to people other than Clocksin.] > >I have a fairly complete (i.e., it includes bagof and ilk, though I >didn't feel the need to add assert/detract!) and "easily" extensible >Prolog embedding written in Scheme, modeled on the one described in >[...] >want it, send me email, I'll see if I can make it subscribe to RRRS >standards to make it portable (allow time for delivery!), and email >you a copy. If you don't have a Scheme at your place, my code will >[...] I somewhat underestimated the response I would get for the above message. I've emailed the code to some of you, but there's still a backlog, and there are some of you I couldn't reach. There were suggestions that I _post_ the code. I guess, though, it'd be more convenient to all concerned if I made it ftp'able from Rice, rather than clog the net. Procedure: ftp titan.rice.edu (as anonymous) get public/slog.sh slog.sh is a shar file, and contains two implementation files (slog.ss and bagof.ss), two doc (loosely speaking!) files (Readme and Usage), and a bunch of example files (mostly from Sterling&Shapiro) to make it easy to acquire a feel for the possibly unusual syntax. The code is _not_ completely RRRS-compatible, but should be easily fixable for the Scheme of your choice/fate by adding requisite definitions of extend-syntax, boxes and printf (see The Scheme Programming Language by R. Kent Dybvig). If you encounter bugs/problems or get royally chewed by you-don't-know-what, email me, and I'll see if I can fix it. BTW, I would still like to get email from those who will be ftp'ing the stuff, so that I can get back to you if there are changes. (No, the list of names will _not_ be released to junk-mail senders. :-) --dorai ps: The code is completely free, and users can make all the changes and/or extensions to it they want. You might want to tell me about it, if you think it's significant, though. -- ------------------------------------------------------------------------------- It may be that the gulfs will wash us down; It may be we shall touch the Happy Isles. -------------------------------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 19 Dec 89 11:11:43 EST Received: from ATHENA.MIT.EDU by mintaka.lcs.mit.edu id aa20799; 19 Dec 89 11:06 EST Received: from AALTO.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA16485; Tue, 19 Dec 89 11:05:08 EST From: afleishr@athena.mit.edu Received: by AALTO.MIT.EDU (5.61/4.7) id AA05635; Tue, 19 Dec 89 11:04:51 -0500 Message-Id: <8912191604.AA05635@AALTO.MIT.EDU> To: Scheme%mc.lcs.mit.edu@MINTAKA.lcs.mit.edu Subject: Re: Scheme Digest #263 In-Reply-To: Your message of 19 Dec 89 00:04:21 -0500. <8912190025.aa29509@mintaka.lcs.mit.edu> Date: Tue, 19 Dec 89 11:04:47 EST sir: about your prolog in scheme,, i should be very grateful to you for a copy. aaron fleisher afleisher@athena.mit.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 18 Dec 89 17:20:42 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa13256; 18 Dec 89 17:14 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA09568; Mon, 18 Dec 89 16:35:31 EST 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: 18 Dec 89 21:16:27 GMT From: Dorai Sitaram Organization: Rice University, Houston Subject: Re: Prolog interpreter in LISP wanted Message-Id: <3833@brazos.Rice.edu> References: <1690@gannet.cl.cam.ac.uk> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <1690@gannet.cl.cam.ac.uk> wfc@cl.cam.ac.uk (William Clocksin) writes: $Could somebody send me the source code of a Prolog interpreter $written in LISP (or the reference of a paper where one may be found)? $I need this for teaching purposes only, and can't spare the time $just at the moment to write one myself. I already know about $the "smallest one in the world" in John Campbell's book, but I $wonder whether somebody has got a more realistic one to share. $Thank you. [This is also addressed to people other than Clocksin.] I have a fairly complete (i.e., it includes bagof and ilk, though I didn't feel the need to add assert/detract!) and "easily" extensible Prolog embedding written in Scheme, modeled on the one described in Matthias Felleisen's "Transliterating Prolog into Scheme," Tech. Rep. 182, Indiana Univ. Comp. Sci. Dept., 1985. I may have referred to this in my only previous posting on c.l.p. a few weeks ago. It's "better" than an interpreter since it's an embedding, i.e., I can use both languages with something approaching gay abandon. I am not sure if this is what you want, since the language used is Scheme (Ch*z) rather than Lisp. First-class continuations of Scheme, something not available in Lisp, are exploited. If you think you still want it, send me email, I'll see if I can make it subscribe to RRRS standards to make it portable (allow time for delivery!), and email you a copy. If you don't have a Scheme at your place, my code will probably not be a good idea, since a Prolog embedding in a Scheme interpreter written on top of your Lisp would be enough to break your back, efficiency-wise, I should think. --dorai -- ------------------------------------------------------------------------------- It may be that the gulfs will wash us down; It may be we shall touch the Happy Isles. -------------------------------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 17 Dec 89 12:12:31 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa16121; 17 Dec 89 12:07 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA29002; Sun, 17 Dec 89 11:16:13 EST 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: 17 Dec 89 16:08:32 GMT From: Jason Coughlin Organization: Clarkson University, Potsdam, NY Subject: Articles on compiling scheme Message-Id: <1989Dec17.160832.7157@sun.soe.clarkson.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I wrote a Scheme interpreter which I am going to turn into a byte-code compiler. Can anyone please send me references to articles about compiling scheme and/or compiling LISP? Please email as I don't read this group that much. Thanks for your help. -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 16 Dec 89 02:41:21 EST Received: from schizo.samsung.com by mintaka.lcs.mit.edu id aa04686; 16 Dec 89 2:35 EST Received: by schizo.samsung.com from mitech.UUCP via UUCP (vers 5.61+) for scheme@mc.lcs.mit.edu (from gjc@mitech.com) id ; Sat, 16 Dec 89 02:34:00 -0500 Message-Id: <8912160734.AA11135@schizo.samsung.com> Reply-To: gjc@mitech.com MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Received: by mitech.com (DECUS UUCP w/Smail); Fri, 15 Dec 89 16:52:56 EDT Date: Fri, 15 Dec 89 16:52:56 EDT From: gjc@mitech.com MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu To: scheme@mc.lcs.mit.edu Subject: a self-contained lisp environment, siod and micro emacs. X-Vms-Mail-To: UUCP%"scheme@mc.lcs.mit.edu" An "emacs" subr may be defined for siod-v2.3-shar (Scheme In One Day) with trivial modifications to micro-emacs. The resulting behavior is that when you exit emacs and re-enter, your buffers are in the same state as before. How to call micro emacs from siod. (Done with MicroEMACS 3.7) Modify DISPLAY.C - Make sure vscreen is initialized to NULL at top of file. VIDEO **vscreen = NULL; - Then add a line to vtinit before the malloc of vscreen. if (vscreen != NULL) return(1); Modify MAIN.C - rename the function main to main_hacked. - conditionalize the call to edinit to be if (argc > -1) edinit(bname); - before this line: viewflag = FALSE; add this line: sgarbf = TRUE; - conditionalize the call to startup to be if (argc > -1) startup(""); - in the function quit replace exit with exit_hacked. Modify SLIB.C There are name conflicts on functions "eq" and "quit" so I just renamed these to "l_eq" and "l_quit" in slib.c Easier than modifying micro-emacs. Add this new subr to siod.c: #include long uemacs_need_init = 1; jmp_buf uemacs_exit; exit_hacked(value) int value; {longjmp(uemacs_exit,2);} LISP uemacs_call() {long flag,k; flag = no_interrupt(1); k = setjmp(uemacs_exit); if (k == 2) {uemacs_need_init = 0; no_interrupt(flag); return(NIL);} if (uemacs_need_init) {main_hacked(0,0); uemacs_need_init = 0;} else main_hacked(-1,0); no_interrupt(flag); return(NIL);} init_subr("emacs",tc_subr_0,uemacs_call); Here are the diffs. ************ File UTIL$DISK:[UEMACS]MAIN_HACKED.C;5 353 main_hacked(argc, argv) 354 char *argv[]; ****** File UTIL$DISK:[UEMACS]MAIN_HACKED.C;1 353 main(argc, argv) 354 char *argv[]; ************ ************ File UTIL$DISK:[UEMACS]MAIN_HACKED.C;5 380 if (argc > -1) 381 edinit(bname); /* Buffers, windows. */ 382 sgarbf = TRUE; /* new */ 383 viewflag = FALSE; /* view mode defaults off in command line */ ****** File UTIL$DISK:[UEMACS]MAIN_HACKED.C;1 380 edinit(bname); /* Buffers, windows. */ 381 viewflag = FALSE; /* view mode defaults off in command line */ ************ ************ File UTIL$DISK:[UEMACS]MAIN_HACKED.C;5 465 if (argc > -1) startup(""); 466 startf = TRUE; ****** File UTIL$DISK:[UEMACS]MAIN_HACKED.C;1 463 startup(""); 464 startf = TRUE; ************ ************ File UTIL$DISK:[UEMACS]MAIN_HACKED.C;5 753 exit_hacked(GOOD); 754 } ****** File UTIL$DISK:[UEMACS]MAIN_HACKED.C;1 751 exit(GOOD); 752 } ************ ************ File UTIL$DISK:[UEMACS]DISPLAY.C;2 32 VIDEO **vscreen = NULL; /* Virtual screen. */ 33 #if IBMPC == 0 ****** File UTIL$DISK:[UEMACS]DISPLAY.C;1 32 VIDEO **vscreen; /* Virtual screen. */ 33 #if IBMPC == 0 ************ ************ File UTIL$DISK:[UEMACS]DISPLAY.C;2 52 53 if (vscreen != NULL) return(1); 54 55 vscreen = (VIDEO **) malloc(term.t_nrow*sizeof(VIDEO *)); ****** File UTIL$DISK:[UEMACS]DISPLAY.C;1 52 vscreen = (VIDEO **) malloc(term.t_nrow*sizeof(VIDEO *)); ************  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Dec 89 17:18:22 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa17031; 15 Dec 89 17:09 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA04726; Fri, 15 Dec 89 16:52:54 EST 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: 15 Dec 89 20:41:51 GMT From: Vincent Manis Organization: The Invisible City of Kitezh Subject: Re: Scheme book by Eisenberg Message-Id: <5992@ubc-cs.UUCP> References: <8912150029.aa24351@mintaka.lcs.mit.edu>, <8912151354.AA02180@zurich.ai.mit.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu We've been using Eisenberg's text on Scheme as a supplementary in our `SICP section' of our first year course. The students quite like it (and I like it too!). The current edition is keyed to PC-Scheme, but as I understand it, a MacScheme version is in production. -- \ Vincent Manis "There is no law that vulgarity and \ Department of Computer Science literary excellence cannot coexist." /\ University of British Columbia -- A. Trevor Hodge / \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Dec 89 16:21:17 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa15468; 15 Dec 89 16:18 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA01335; Fri, 15 Dec 89 14:51:27 EST 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: 15 Dec 89 17:23:59 GMT From: Paul Snively Organization: Apple Computer, Inc. Subject: Re: Scheme book by Springer and Friedman Message-Id: <5800@internal.Apple.COM> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <19891215071609.2.VANMEULE@PERTA.SCRC.Symbolics.COM> vanMeule@ALLEGHENY.SCRC.SYMBOLICS.COM (Andre van Meulebrouck) writes: [Lots o' stuff about Scheme and the Art of Programming removed] First, a message for Andre': Hey! So THAT'S where you disappeared to! :-) Now, back to the subject at hand: Dan Friedman was kind enough to send me a copy of his (co-authored) new book, and I am very pleased with it. I think it would be perfectly fine for bright high-school students, especially if the students are NOT carrying around a lot of preconceived baggage from BASIC/Pascal/C when they get into this. They'll have less to unlearn that way. I'm with Andre'; I particularly appreciated the in-depth discussion of continuations (two chapters that Dan Friedman called "a labor of love," and it shows). Like many texts, the books is a tad short on example applications of the methodologies, but that is really my only criticism, and it's intended to be a mild one (Structure and Interpretation of Computer Programs has lots of examples of application; I think between these two texts, you've got an EXTREMELY good computer science course with an emphasis on Scheme). __________________________________________________________________________ Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. __________________________________________________________________________ C++ -- The language in which only friends can access your private members. __________________________________________________________________________  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Dec 89 16:21:05 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa15464; 15 Dec 89 16:18 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA02938; Fri, 15 Dec 89 16:00:17 EST 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: 15 Dec 89 17:52:50 GMT From: Kai Zimmermann Organization: Inst. fuer Informatik, TU Muenchen, W. Germany Subject: Errors in the SCOOPS for the Macintosh Message-Id: <970@tuminfo1.lan.informatik.tu-muenchen.dbp.de> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Hello everybody, I have discovered and REMOVED two errors in the implementation of TI's SCOOPS package for the Apple Macintosh that comes with Lightship's MacScheme. 1. You can't work with the special instance variable SELF because it's not bound to the instance itself but to the dispatching procedure for that instance. 2. (describe ) produces an error if you haven't defined any class that uses CLASSVARS yet. Thus, (load "SCOOPS") (define-class foo) (define fie (make-instance foo)) (describe fie) results in an error, but (load "SCOOPS") (define-class foo) (define-class dummy (CLASSVARS WeNeedJustOne)) (define fie (make-instance foo)) (describe fie) works. The following code will remove these errors and documents why they occured. If anyone has discovered more errors I'd like to hear of them. Hope I helped someone with this posting, --Kai ========================================================================= | I started lisp programming with the Xerox Interlisp-D environment, | | moved down (at that time) to the Symbolics programming environment, | | had to work with the Allegro Commonlisp environment? | | and now finally work in MacScheme. | | Tomorrow I will work in lisp bytecode directly | | with nothing but a hardcopy teletype as input device. | | Would be nearly no difference :-( | | | | Kai Zimmermann zimmerma@lan.informatik.tu-muenchen.dbp.de | ========================================================================= ----------Cut Here------------- ; Just replace the definitions of the procedures ; INSTANCE-DESCRIPTION and ; COMPILE-MAKE-FN ; in the source file that comes with MacScheme ; by the following code. (define instance-description (let ((*key* *key*) (inheritance inheritance) (writeln (lambda l (for-each display l) (newline)))) (lambda (inst) (letrec ((class (send inst get-class)) (printvars (lambda (f1 f2) ;f1 is a list of instvars and f2 an environment (let ((n 0)) (while f1 (writeln " " (car f1) " : " (vector-ref f2 n)) (set! n (1+ n)) (set! f1 (cdr f1))))))) (writeln " ") (writeln " INSTANCE DESCRIPTION") (writeln " ====================") (writeln " ") (writeln " Instance of Class " (send (class *key*) name)) (writeln " ") (writeln " Class Variables : ") (printvars (mapcar car (inheritance class 'get-classvars )) ; Kai Zimmermann, 1989 ; Here was an error due to the fact that in ; PC-Scheme (car '()) returns () and in ; MacScheme an error is signalled. (let ((possibly-empty-environment (send (class *key*) get-class-environment))) (if (null? possibly-empty-environment) '() (car possibly-empty-environment)))) (writeln " ") (writeln " Instance Variables :") (printvars (mapcar car (inheritance class 'get-instvars)) (cadr (->pair (car (->pair inst))))) (string->symbol "") )))) ;----------- (define compile-make-fn (lambda (x) (let* ((params (gensym "init-parms")) (instvars (instance-vars x)) (totalvars (append instvars (class-vars x)))) `(lambda ,params (letrec ,(append (format-vars instvars) (list (list 'self `(lambda msg (case (car msg) ,@(format-case (append `((get-class (lambda (),x))) (get-methods (inheritance x 'get-gettable) totalvars) (set-methods (inheritance x 'get-settable) totalvars) (inheritance x 'get-methods) ))))))) ; Kai Zimmermann, 1989 ; Here was an error, because self wasn't changed ; to the constructed symbol, but left as ; the above lambda. This made it impossible to ; work with self. (set! self (->symbol (list self ',(cons 'pname (string-append "#string (send (x *key*) name)) ">"))))) ,(compile-init-code x params) self))))) ;------------End----------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Dec 89 13:48:04 EST Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa11342; 15 Dec 89 13:42 EST Received: from zurich.ai.mit.edu ([18.43.0.174]) by life.ai.mit.edu (4.0/AI-4.10) id AA04213; Fri, 15 Dec 89 13:41:29 EST Received: from localhost by zurich.ai.mit.edu; Fri, 15 Dec 89 13:39:52 est Date: Fri, 15 Dec 89 13:39:52 est From: Julie Sussman Message-Id: <8912151839.AA01268@zurich.ai.mit.edu> To: mss+@andrew.cmu.edu Cc: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu In-Reply-To: Mark Sherman's message of Thu, 14 Dec 89 13:15:43 -0500 (EST) Subject: Scheme book by Springer and Friedman I haven't seen that book yet, but there is a wonderful Scheme book intended especially for bright high-school students. It is "Programming in Scheme" by Michael Eisenberg. Published by the Scientific Press, but MIT Press is (or shortly will be) distributing it too. It is geared for use with TI's PC Scheme (i.e. the machine- dependent examples, such as graphics, are for that Scheme), and a MacIntosh version will be out soon. But it is not critical that the book and your Scheme version match. Julie Sussman (jems@zurich.ai.mit.edu)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Dec 89 09:02:19 EST Received: from [128.52.32.80] by mintaka.lcs.mit.edu id aa04877; 15 Dec 89 8:57 EST Received: from zurich.ai.mit.edu ([18.43.0.165]) by life.ai.mit.edu (4.0/AI-4.10) id AA01013; Fri, 15 Dec 89 08:56:05 EST Received: from localhost by zurich.ai.mit.edu; Fri, 15 Dec 89 08:54:31 est Date: Fri, 15 Dec 89 08:54:31 est From: Franklyn Turbak Message-Id: <8912151354.AA02180@zurich.ai.mit.edu> To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu, mss+@andrew.cmu.edu In-Reply-To: Automatic Scheme Digestifier's message of 15 DEC 89 00:04:15 EST <8912150029.aa24351@mintaka.lcs.mit.edu> Subject: Scheme book by Eisenberg In article , mss+@ANDREW.CMU.EDU (Mark Sherman) writes: > Is anyone familar with the book "Scheme and the Art of Programming" by > Springer & Friedman (MIT Press)? I'm looking for something for bright > high school students. I highly recommend Mike Eisenberg's "Programming in Scheme" (Scientific Press). It was specifically written with high school students in mind, but is an excellect general introduction to Scheme for just about anyone. It's well organized, beautifully written, and chock full of fun and interesting examples (including an Eliza-like program based on Abbot and Costello's "Who's on first" routine).  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Dec 89 02:26:08 EST Received: from [128.81.41.45] by mintaka.lcs.mit.edu id aa26816; 15 Dec 89 2:21 EST Received: from PERTA.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 166629; 15 Dec 89 02:16:24 EST Date: Fri, 15 Dec 89 02:16 EST From: Andre van Meulebrouck Subject: Scheme book by Springer and Friedman To: mss+@andrew.cmu.edu, Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu cc: vanmeule@allegheny.scrc.symbolics.com In-Reply-To: Message-ID: <19891215071609.2.VANMEULE@PERTA.SCRC.Symbolics.COM> Date: Thu, 14 Dec 89 13:15:43 -0500 (EST) From: Mark Sherman Is anyone familar with the book "Scheme and the Art of Programming" by Springer & Friedman (MIT Press)? I'm looking for something for bright high school students. (Please respond to me, I don't normally read this newgroup, thanks.) -Mark I just skimmed it, looking over every page briefly, so take my comments with that in mind. I bought it because it has a nice section on continuations (which I felt I could profit from to become more comfortable with them), and for reference purposes because it does go into some pretty deep and interesting examples that show not just Scheme, but various programming paradigms and how to use them (in a similar manner to "Structure and Interpretation of Computer Programs"'s approach). The latter is especially nice as Scheme, elegant as it is, is ultimately "just" a vehicle by which to express algorithms and concepts, so some discussion of what to "say" once you learn "speak" Scheme is important (as well as the comments here and there as to why it might perhaps be easier to say them in Scheme than in other languages). The book seems to me to be very concise, complete, readable, and text-bookish (in that I believe it has lots of exercises, almost like a math book) so I should think it would suit your purposes well. My *real* intent in replying to this message however was to change the subject , as it reminded me about a book I'm curious about. Specifically, has anyone looked at a copy of the (relatively) recent "Introduction to Functional Programming" by Bird and Wadler of Oxford and Glasgow Universities (Prentice Hall, March 1988)?  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Dec 89 23:09:49 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa22401; 14 Dec 89 23:05 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA28384; Thu, 14 Dec 89 22:35:03 EST 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: 13 Dec 89 14:44:11 GMT From: The Bhagwan Organization: Voodoo Graphics Project Subject: Anyone have CScheme7, T3.1, Elk 1.0 on Apollo SR10.2 Message-Id: <631@voodoo.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Hello, I'm looking for anyone that has: MIT C-Scheme-7 Yale T3.1 or Elk 1.0 compiled and running on Apollo SR10.2 (68xxx). I can ftp source but we have no assembler so cannot build. If anyone has done this perhaps you can let me know and we'll make arrangements to mail binaries. Also, I can ftp. Thanks, -- Al McPherson Member Holstein Aerobatic Team Boeing Computer Services ...uw-beaver!ssc-vax!voodoo!bhagwan P.O. Box 24346 MS: 6M-49 Seattle, WA 98124 (206) 234-7825  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Dec 89 16:41:10 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07993; 14 Dec 89 16:35 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA18514; Thu, 14 Dec 89 16:19:43 EST 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: 14 Dec 89 20:13:49 GMT From: Richard Pattis Organization: U of Washington, Computer Science, Seattle Subject: Re: Scheme book by Springer and Friedman Message-Id: <10189@june.cs.washington.edu> References: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article , mss+@ANDREW.CMU.EDU (Mark Sherman) writes: > Is anyone familar with the book "Scheme and the Art of Programming" by > Springer & Friedman (MIT Press)? I'm looking for something for bright > high school students. (Please respond to me, I don't normally read this > newgroup, thanks.) > -Mark When asking such a question, is it appropriate for the inquirer to also say that he/she will post responses to the net? As a faithful comp.lang.scheme reader, who is interested in the topic, and took the time to read the message, I would like to profit from any responses generated by this newsgroup. Rich Pattis  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Dec 89 14:24:35 EST Received: from PO2.ANDREW.CMU.EDU by mintaka.lcs.mit.edu id aa02059; 14 Dec 89 14:20 EST Received: by po2.andrew.cmu.edu (5.54/3.15) id for scheme@mc.lcs.mit.edu; Thu, 14 Dec 89 13:20:05 EST Received: via switchmail; Thu, 14 Dec 89 13:19:49 -0500 (EST) Received: from mss.andrew.cmu.edu via qmail ID ; Thu, 14 Dec 89 13:16:01 -0500 (EST) Received: from mss.andrew.cmu.edu via qmail ID ; Thu, 14 Dec 89 13:15:43 -0500 (EST) Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.mss.andrew.cmu.edu.rt.r3 via MS.5.6.mss.andrew.cmu.edu.rt_r3; Thu, 14 Dec 89 13:15:43 -0500 (EST) Message-Id: Date: Thu, 14 Dec 89 13:15:43 -0500 (EST) From: Mark Sherman To: scheme@mc.lcs.mit.edu Subject: Scheme book by Springer and Friedman Is anyone familar with the book "Scheme and the Art of Programming" by Springer & Friedman (MIT Press)? I'm looking for something for bright high school students. (Please respond to me, I don't normally read this newgroup, thanks.) -Mark  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 13 Dec 89 21:10:18 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa17837; 13 Dec 89 21:04 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA21828; Wed, 13 Dec 89 20:45:16 EST 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: 14 Dec 89 01:14:40 GMT From: Paul Snively Organization: Apple Computer, Inc. Subject: Re: continuation based error handling Message-Id: <5754@internal.Apple.COM> References: <4169@amelia.nas.nasa.gov> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <4169@amelia.nas.nasa.gov> raible@orville.nas.nasa.gov (Eric Raible) writes: > It seems to me that it ought to be possible to implement a somewhat > portable error handling facility using call/cc. > > I'd appreciate comments and/or code. Well, Common Lisp's CATCH and THROW are certainly trivial when you have full upward continuations; I think Dybvig's book gives examples. __________________________________________________________________________ Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. __________________________________________________________________________ C++ -- The language in which only friends can access your private members. __________________________________________________________________________  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 11 Dec 89 19:43:25 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03514; 11 Dec 89 19:34 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA13338; Mon, 11 Dec 89 19:01:13 EST 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: 11 Dec 89 22:59:24 GMT From: Eric Raible Organization: NASA Ames Research Center, Moffett Field, CA Subject: continuation based error handling Message-Id: <4169@amelia.nas.nasa.gov> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu It seems to me that it ought to be possible to implement a somewhat portable error handling facility using call/cc. I'd appreciate comments and/or code.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Dec 89 19:18:26 EST Received: from F.GP.CS.CMU.EDU by mintaka.lcs.mit.edu id aa09076; 5 Dec 89 19:12 EST Date: Tue, 5 Dec 1989 18:48-EST From: Barak.Pearlmutter@f.gp.cs.cmu.edu To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu Subject: Consing Rest Args Considered Harmful Message-Id: In-Reply-To: Scheme's mail message of 28 NOV 89 00:10:25 EST In Oaklisp, Kevin and I used a somewhat ideosyncratic solution to the rest args problem. A form like (lambda (a b . c) BODY) makes a procedure of at least two arguments, and BODY can refer to the first two, A and B. But the token C is not a variable; it is special syntax indicating that an indeterminite number of rest arguments are being passed. Since it is just syntax, it can't be closed over. It can be used in only one context: in a tail recursive call that gets you out of BODY, you must terminate the call with ". C". And all exits from body must be tail recursive, and must do this. For instance, you could write (define (foo a b . c) (list a 'aye b 'bee . c)) There is a way to find out how many extra arguments were passed, as in the following form. REST-LENGTH is syntax though, not a procedure. I'm still not sure if this was a good idea, although it is simple enough to provide. (define (foo a b . c) (if (> (rest-length c) 5) (list 'lots 'of . c) (list 'little . c))) A number of utility functions are provided for manipulating the rest arguments. For instance, LISTIFY-ARGS takes at least one argument, a procedure, which it calls on a list made up of any additional arguments. So to write a function which takes an arbitrary number of arguments and returns its second, you could write (define (second-arg a x . rest) (listify-args (lambda (l) x) . rest)) Other functions useful for rest argument consumption are also provided. We felt that this mechanism provided the bare minimum of functionality necessary in the base level language to work with rest arguments, without imposing undue implementation constraints. In using it, we found that almost all uses of rest arguments fit naturally into the paradigm, and very rarely is there any reason to listify the rest arguments. In particular, this is true of things like + and * which can basically eat there arguments left to right until they're all gone. [ In passing, I should mention that the compatibility package makes dotted rest args behave in the usual ugly but standard way. ]  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Dec 89 01:53:49 EST Received: from LABS-N.BBN.COM by mintaka.lcs.mit.edu id aa08964; 5 Dec 89 1:50 EST From: Dan Cerys Sender: cerys@bbn.com Organization: Bolt Beranek and Newman Inc. (STC) To: ziggy@hx.lcs.mit.edu CC: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu In-reply-to: ziggy@hx.lcs.mit.edu's message of Mon, 4 Dec 89 21:23:47 EST <2837816627-224788@RTS-13> Subject: LENGTH optimization? Date: Tue, 5 Dec 89 1:43:16 EST Message-ID: <8912050150.aa08964@mintaka.lcs.mit.edu> Are there any LISP implementations that attempt to make LENGTH of a list be a less than linear-time operation. I can imagine especially for immutable lists that this is easily achieved. Only SET-CDR! seems to be a fly in the ointment. The Zetalisps of old (probably still true of Explorers and Genera) used to provide an ART-Q-LIST array type. Such arrays were a cross between a general (ART-Q) array and a list. Application of the wonderfully mnemonic G-L-P function would return the "list" equivalent of the array. Preventing any flies from mucking about, SET-CDR! (RPLACD) on this "list" was an error. Because of these restrictions, it would seem that LENGTH of such "lists" would require constant time, regardless of length (just like determining LENGTH of an array). However, I don't know if this was the case. Dan  Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU; 4 Dec 89 21:26:07 EST Received: from RTS-13.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with SMTP id 316025; 4 Dec 89 21:24:46 EST Message-Id: <2837816627-224788@RTS-13> Sender: QIX@RTS-13 Date: Mon, 4 Dec 89 21:23:47 EST From: ziggy@hx.lcs.mit.edu To: scheme@mc.lcs.mit.edu Subject: LENGTH optimization? Are there any LISP implementations that attempt to make LENGTH of a list be a less than linear-time operation. I can imagine especially for immutable lists that this is easily achieved. Only SET-CDR! seems to be a fly in the ointment. ~Ziggy  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 3 Dec 89 16:11:51 EST Received: from schizo.samsung.com by mintaka.lcs.mit.edu id aa08453; 3 Dec 89 16:04 EST Received: by schizo.samsung.com from mitech.UUCP via UUCP (vers 5.61+) for scheme@mc.lcs.mit.edu (from gjc@mitech.com) id ; Sun, 3 Dec 89 16:03:46 -0500 Message-Id: <8912032103.AA03092@schizo.samsung.com> Reply-To: gjc@mitech.com MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Received: by mitech.com (DECUS UUCP w/Smail); Sun, 3 Dec 89 15:58:37 EDT Date: Sun, 3 Dec 89 15:58:37 EDT From: gjc@mitech.com MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu To: scheme@mc.lcs.mit.edu Subject: SIOD, release 2.0 X-Vms-Mail-To: UUCP%"scheme@mc.lcs.mit.edu" Also available is siod-v2.0-shar, which has call-with-current-continuation.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 3 Dec 89 13:38:24 EST Received: from [129.7.1.19] by mintaka.lcs.mit.edu id aa05160; 3 Dec 89 13:32 EST Received: by lavaca.uh.edu id ; Sun, 3 Dec 89 12:31:28 CST Date: Sun, 3 Dec 89 12:31 CST From: ELEE6L2@uhvax1.uh.edu Subject: SCHEME-MEMBERSHIP To: scheme@mc.lcs.mit.edu X-Vms-To: SCHEME Message-ID: <8912031332.aa05160@mintaka.lcs.mit.edu> I am about to begin my Masters thesis in the area of Neural Networks and I have been using the Rochester Connectionist Simulator for that.But I am not having Scheme which I want ot understand.Could you e-mail it to me please. K.V.Krishna Iyer,Electrical Engg. Dept.,University of Houston,TX 77004.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 2 Dec 89 09:31:07 EST Received: from BU-IT.BU.EDU by mintaka.lcs.mit.edu id aa14471; 2 Dec 89 9:27 EST Received: from BUIT4.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA02964; Sat, 2 Dec 89 09:26:48 EST Return-Path: Received: by buit4.bu.edu (3.2/4.7) id AA11190; Sat, 2 Dec 89 09:26:46 EST Date: Sat, 2 Dec 89 09:26:46 EST From: gjc@bu-it.bu.edu Message-Id: <8912021426.AA11190@buit4.bu.edu> To: scheme@mc.lcs.mit.edu Subject: new version of SIOD, Scheme in One Defun Version 1.5 of SIOD is now available via anonymous ftp to bu-it.bu.edu, CD to "src/gjc" and get "siod-v1.5-shar". New features: * modularized with small main program in one file, scheme runtime and REPL in another. * stop-and-copy or mark-and-sweep GC selectable via command line argument, -g0 for mark-and-sweek, -g1 for stop-and-copy. * On 3 architectures tested, VAX, SUN3, ENCORE, the code in -g0 mode to mark the stack and registers is effective. Therefore GC can happen at any time during EVAL, READ, etc. -gjc  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 28 Nov 89 14:26:55 EST Received: from EDDIE.MIT.EDU by mintaka.lcs.mit.edu id aa09140; 28 Nov 89 14:17 EST Received: from GATECH.EDU by EDDIE.MIT.EDU with SMTP (5.61/25-eef) id AA08624; Tue, 28 Nov 89 14:16:40 EST Received: from kong.UUCP with UUCP by gatech.edu (5.58/GATECH-8.6) id AA25876 for ; Tue, 28 Nov 89 14:13:07 EST Message-Id: <8911281913.AA25876@gatech.edu> Subject: Scheme interface to MS Windows To: scheme@mc.lcs.mit.edu Date: Mon, 27 Nov 89 10:55:57 EST From: Gene Pierce X-Mailer: ELM [version 2.2 PL10] Is There an MS Windows interface for Scheme ? -- Gene Pierce (Gene.Pierce@Dayton.NCR.COM) Software Technology, R&D Division (1 513 445-1079) NCR Corporation 1700 Patterson Blvd., Dayton Ohio 45479  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 27 Nov 89 18:48:25 EST Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa28830; 27 Nov 89 18:34 EST Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA22907; Mon, 27 Nov 89 18:34:18 EST Received: from garlic.Stanford.EDU ([36.22.0.43]) by zurich.ai.mit.edu; Mon, 27 Nov 89 18:33:08 est Received: by garlic.Stanford.EDU (5.57/Ultrix3.0-C) id AA07264; Mon, 27 Nov 89 15:29:55 PST Date: Mon, 27 Nov 89 15:29:55 PST From: Morris Katz Message-Id: <8911272329.AA07264@garlic.Stanford.EDU> To: Pavel.pa@xerox.com Cc: scheme@zurich.ai.mit.edu In-Reply-To: Pavel.pa@Xerox.COM's message of Mon, 27 Nov 89 14:11:47 PST <891127-144857-1155@Xerox> Subject: Request for Comments: A new n-ary function construction Date: Mon, 27 Nov 89 14:11:47 PST From: Pavel.pa@Xerox.COM To what procedure would you apply "arity" to get the answer? In retrospect it is clear that my original message on this subject was so cryptic as to be content free. I would propose having one extra argument which would be bound to a procedure which would return the optional arguments as multiple return values. For symetry reasons, a language which supports multiple return values would require two types of arity functions: call-arity and return-arity. (Please don't flame about the names. I just hate using foo and bar as names when I can think of something semantically more meaningful.) Call-arity is the procedure which is more commonly called arity and returns information about the number of parameters which a function expect. Return-arity is the procedure which returns information about the number of return values to be returned by a function. An application of return-arity to the special function which is bound to optional arguments would return information about the number of optionals which were supplied. I realize that this proposal goes far beyond Pavel's original question; but, I believe that multiple return values should be integrated into Scheme for good symetry reasons. I feel that this can be done in such a way that they will actually solve many more problems than they create. Pavel's application is only one of many examples where the multiple value approach actually leads to a quite elegant solution. ------------------------------------------------------------------------------- Morry Katz katz@cs.stanford.edu -------------------------------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 27 Nov 89 14:55:37 EST Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa25545; 27 Nov 89 14:50 EST Received: from Fafnir.Think.COM by Think.COM; Mon, 27 Nov 89 14:51:43 -0500 Return-Path: Received: from verdi.think.com by fafnir.think.com; Mon, 27 Nov 89 14:47:09 EST Received: from ungar.think.com by verdi.think.com; Mon, 27 Nov 89 14:45:10 EST From: Guy Steele Received: by ungar.think.com; Mon, 27 Nov 89 14:45:08 EST Date: Mon, 27 Nov 89 14:45:08 EST Message-Id: <8911271945.AA01984@ungar.think.com> To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu In-Reply-To: Automatic Scheme Digestifier's message of 23 NOV 89 00:10:13 EST <8911230056.aa23623@mintaka.lcs.mit.edu> Subject: Scheme Digest #249 Date: Wed, 22 Nov 89 11:55:42 PST >From: Pavel.pa@xerox.com Subject: Request for Comments: A new n-ary function construction Message-ID: <891122-121343-4098@Xerox> This note concerns an idea I've been kicking around for some time; I'm probably going to implement the idea in Scheme Xerox and I'd like to get comments on it from the community at large. You can consider yourselves as design consultants... ... [Note: I'll point out right here that nobody I've shown this to has liked having strings in the lambda-list. It just seemed better to me than &arbitrary or #!arbitrary. Suggestions are solicited.] Instead of a string, how about using the number 69 ? :-) --Guy P.S. Otherwise it is an interesting idea. Are you sure that improving the LEXPR mechanism isn't gilding a sow's ear?  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 27 Nov 89 11:59:53 EST Received: from garlic.Stanford.EDU by mintaka.lcs.mit.edu id aa21493; 27 Nov 89 11:53 EST Received: by garlic.Stanford.EDU (5.57/Ultrix3.0-C) id AA04492; Mon, 27 Nov 89 08:49:40 PST Date: Mon, 27 Nov 89 08:49:40 PST From: Morris Katz Message-Id: <8911271649.AA04492@garlic.Stanford.EDU> To: Pavel.pa@xerox.com Cc: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu In-Reply-To: Pavel.pa@xerox.com's message of Wed, 22 Nov 89 11:55:42 PST <891122-121343-4098@Xerox> Subject: Request for Comments: A new n-ary function construction Date: Wed, 22 Nov 89 11:55:42 PST From: Pavel.pa@xerox.com That is, you can now follow the ``required'' parameters by the marker string "arbitrary" and two identifiers. The first of these will, on invocation of the procedure, be bound to the number of ``extra'' arguments, those not accounted for by the required parameters; it is an exact integer. The second new identifier will be bound to a procedure of one argument, an exact non-negative integer less than the extra argument count; it returns the extra argument with that index. I believe that it would be much cleaner to only use the second of the two extra arguments. (i.e., the one which is bound to a procedure) The information about the number of optional arguments which are supplied can be aquired through the use of an arity function of the type previously discussed on the rrrs-authors mailing list during a discussion on multiple values. I support the arity approach because it is more general purpose and can be specified in a manner that is orthoginal to the rest of Scheme. Why put in a special purpose hack, when a more general solution is available. ------------------------------------------------------------------------------- Morry Katz katz@cs.stanford.edu -------------------------------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Nov 89 15:34:58 EST Received: from [13.0.12.232] by mintaka.lcs.mit.edu id aa10871; 22 Nov 89 15:18 EST Received: from Cabernet.ms by ArpaGateway.ms ; 22 NOV 89 12:13:43 PST Date: Wed, 22 Nov 89 11:55:42 PST From: Pavel.pa@xerox.com Subject: Request for Comments: A new n-ary function construction To: Scheme@MC.lcs.mit.edu Message-ID: <891122-121343-4098@Xerox> This note concerns an idea I've been kicking around for some time; I'm probably going to implement the idea in Scheme Xerox and I'd like to get comments on it from the community at large. You can consider yourselves as design consultants... I would like to avoid using ``rest lists'' in my Scheme code, especially at the lowest levels, for a number of reasons: they are usually difficult to optimize and I don't like the language-level preference for the list type over, for example, vectors. To get around the problem, I thought of extending the syntax of lambda-lists to the following: ::= | ( * ) | ( + . ) | ( * "arbitrary" ) | ( * "arbitrary" . ) That is, you can now follow the ``required'' parameters by the marker string "arbitrary" and two identifiers. The first of these will, on invocation of the procedure, be bound to the number of ``extra'' arguments, those not accounted for by the required parameters; it is an exact integer. The second new identifier will be bound to a procedure of one argument, an exact non-negative integer less than the extra argument count; it returns the extra argument with that index. [Note: I'll point out right here that nobody I've shown this to has liked having strings in the lambda-list. It just seemed better to me than &arbitrary or #!arbitrary. Suggestions are solicited.] Thus, for example, one could write Common Lisp's LIST* as follows: (define (list* first "arbitrary" n f) (if (zero? n) first (cons first (let loop ((i (- n 2)) (result (f (- n 1)))) ; last argument (if (negative? i) result (loop (- i 1) (cons (f i) result))))))) The advantages of this approach are straightforward to see. On the practical side, it is easily optimized in the case where the argument-fetching function does not escape: all invocations can be implemented as simple indexes into the actual argument vector on the stack (or wherever). When the function does escape, its closure can probably be allocated and filled in faster than the corresponding rest list. On the language purity side, this seems to me a cleaner approach, using the more fundamental data types of integers and procedures, rather than lists. It also allows random access to the arguments when that's handy, as it was above. This is more difficult with lists. Of course, one of the common uses of rest lists is as eventual arguments to APPLY. This is a fine idiom and so we should have a way to support a corresponding idiom with this construct. Suppose that we had a new primitive, called APPLYF for lack of a good name, defined as follows: (APPLYF fn arg1 ... argK n f) Applies the procedure FN to (K + N) arguments: arg1 ... argK (f 0) ... (f n-1) This new primitive can, of course, accept any N and F, not just those acquired from the "arbitrary" mechanism: (define (iota k) (applyf vector k (lambda (i) (+ i 1)))) In the case where F did come from the the "arbitrary" mechanism, it is easy to optimize the resulting code as a cheap argument-copying loop. Sometimes, with rest lists, one wants to pass along to APPLY a tail of the original list: (define (foo . x) (apply bar (cdr x))) or some such. This can also be done with APPLYF: (define (foo "arbitrary" n f) (applyf bar (- n 1) (lambda (k) (f (+ k 1))))) Granted, this isn't as concise, but the idea is more general. We can as easily pass a prefix of the arguments: (define (foo "arbitrary" n f) (applyf bar (- n 1) f)) or just the even-indexed ones: (define (foo "arbitrary" n f) (applyf bar (quotient (+ n 1) 2) (lambda (k) (f (* k 2))))) In all of these cases, it's easy to optimize the resulting code to contain no procedure calls and no allocation. Some of you with longer memories may recognize the old MacLisp LEXPR mechanism (or Interlisp LAMBDA*) in this facility. It's different in important ways, though: the argument-fetching function is not a special form taking a strange argument with dynamic scope, it is a normal Scheme procedure with indefinite extent. I've rambled enough for now; what do you folks think? Pavel Curtis Xerox PARC/CSL  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Nov 89 05:21:06 EST Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa23666; 19 Nov 89 5:15 EST Received: from weaver.berkeley.edu by life.ai.mit.edu (4.0/AI-4.10) id AA06137; Sun, 19 Nov 89 05:15:10 EST Received: from web-4e.Berkeley.EDU by weaver.berkeley.edu (4.0/1.32(web)) id AA14032; Sun, 19 Nov 89 02:14:55 PST Date: Sun, 19 Nov 89 02:14:55 PST From: Mad Bomber Message-Id: <8911191014.AA14032@weaver.berkeley.edu> To: scheme@ai.mit.edu Dear Sirs: Please send me information as to how I may obtain MacScheme, such as a source and price. Please send the information to: Collin Ong, 2650 Durant Ave. #202C, Berkeley, CA 94720. Please do not respond to this email account as it will probably be terminated shortly. Thank you very much. Collin Ong  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Nov 89 07:44:48 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03068; 18 Nov 89 7:35 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA09250; Sat, 18 Nov 89 07:35:05 EST 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: 18 Nov 89 12:26:43 GMT From: Michael Pak Organization: The Hebrew University of Jerusale, Israel Subject: Elk/Scheme on IBM RT/PC Message-Id: <547@shuldig.Huji.Ac.IL> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I am looking for an Elk/Scheme interpreter for IBM RT/PC workstation. If you know whether one exists and where can I get it, please E-mail me. Thanks in advance, Misha.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Nov 89 22:41:05 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20466; 16 Nov 89 22:34 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA03828; Thu, 16 Nov 89 22:15:49 EST 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: 17 Nov 89 01:07:11 GMT From: Ben Wildasin Organization: Indiana University, Bloomington Subject: Creating Runable programs from Scheme Code Message-Id: <29845@iuvax.cs.indiana.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I've just started out using Chez Scheme on a VAX under Ultrix, and I am interested in creating auto-executable files (i.e. those runnable from the csh prompt) fom Scheme source code. Is this possible? a T d H v A a N n K c S e, Ben Wildasin ************************************************************************** Ben Wildasin bwildasi@silver.bacs.indiana.edu **************************************************************************  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Nov 89 18:14:32 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa09080; 16 Nov 89 18:04 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA28753; Thu, 16 Nov 89 17:26:31 EST 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: 16 Nov 89 19:06:17 GMT From: Chris Haynes Organization: The Internet Subject: IEEE Scheme standard meeting announcement Message-Id: <8911161407.aa12387@mintaka.lcs.mit.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu The Fourth meeting of the IEEE/MSC/P1178 Working Group on Scheme will be held from 1:30pm until about 5:30pm (continuing in the evening if really necessary) on January 19, 1990, in the California Room of the Cathedral Hill Hotel, Van Ness at Geary, San Francisco, California. This follows the conclusion, at 12:30pm in the same hotel, of the Principles of Programming Languages conference. The main agenda item will be discussion of the third draft of the standard, which has just been completed. Those on the working group mailing list will receive a copy soon. Others may request copies from me by email (chaynes@iuvax.cs.indiana.edu) or by writing: Christopher Haynes Department of Computer Science Indiana University Bloomington, Indiana 47405  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Nov 89 14:31:57 EST Received: from iuvax.cs.indiana.edu by mintaka.lcs.mit.edu id aa12387; 16 Nov 89 14:07 EST Received: by iuvax.cs.indiana.edu Date: Thu, 16 Nov 89 14:06:17 -0500 From: Chris Haynes To: rrrs-authors@MC.lcs.mit.edu, scheme-standard@wheaties.ai.mit.edu, scheme@MC.lcs.mit.edu, camp@csc.ti.com Subject: IEEE Scheme standard meeting announcement Message-ID: <8911161407.aa12387@mintaka.lcs.mit.edu> The Fourth meeting of the IEEE/MSC/P1178 Working Group on Scheme will be held from 1:30pm until about 5:30pm (continuing in the evening if really necessary) on January 19, 1990, in the California Room of the Cathedral Hill Hotel, Van Ness at Geary, San Francisco, California. This follows the conclusion, at 12:30pm in the same hotel, of the Principles of Programming Languages conference. The main agenda item will be discussion of the third draft of the standard, which has just been completed. Those on the working group mailing list will receive a copy soon. Others may request copies from me by email (chaynes@iuvax.cs.indiana.edu) or by writing: Christopher Haynes Department of Computer Science Indiana University Bloomington, Indiana 47405  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Nov 89 13:13:06 EST Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa29550; 15 Nov 89 13:03 EST Received: from zurich.ai.mit.edu ([18.43.0.171]) by life.ai.mit.edu (4.0/AI-4.10) id AA28726; Wed, 15 Nov 89 13:03:36 EST Received: from localhost by zurich.ai.mit.edu; Wed, 15 Nov 89 13:02:36 est Date: Wed, 15 Nov 89 13:02:36 est From: "Guillermo J. Rozas" Message-Id: <8911151802.AA29786@zurich.ai.mit.edu> To: scheme@MC.lcs.mit.edu In-Reply-To: Via Fons Botman's message of 13 Nov 89 17:17:21 GMT <4520@skiscs.vu.nl> Subject: - and / with one argument should be identity functions. Reply-To: jinx@zurich.ai.mit.edu Date: 13 Nov 89 17:17:21 GMT From: Via Fons Botman PLease, let's *not* define (- X) and (/ X) to be something else than X. It might be the source of obscure errors in (admittedly ugly) code like: (define (net-gain gain losses) (apply - gain losses)) You should be using some version of reduce here. Apply is generally the wrong thing to use. Besides that, it may be cute, but it is neither clear nor consistent, and therefore not "in the spirit of Scheme". Why isn't it consistent? - and / are left associative and thus it is natural and consistent to place the (right) identity on the left. :-) Although (/ x) is atypical, that can hardly be said for -. Most languages treat unary - specially. In addition, the "special" meaning for both is traditional in Lisp.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Nov 89 12:06:27 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa26634; 15 Nov 89 11:57 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA28839; Wed, 15 Nov 89 11:44:32 EST 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: 14 Nov 89 23:10:18 GMT From: "D.A.Turner" Organization: Computing Lab, University of Kent at Canterbury, UK. Subject: Miranda release 2 Message-Id: <3117@harrier.ukc.ac.uk> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu *** ANNOUNCEMENT *** Miranda - Release Two Miranda is a lazy functional language with polymorphic strong typing and a simple but powerful module system. This is to inform anyone who may be interested to know that a major new release of the Miranda system is now available, incorporating a number of improvements - including parameterised modules, unbounded size integers, and local polymorphism, as well as a substantially faster implementation. It runs on a number of machines under UNIX, including VAX, SUN-3, SUN-4, Apollo, HP 9000. If you wish to receive a longer piece of electronic mail telling you more about the Miranda system and how to obtain it, this can be requested from INTERNET: mira-request%ukc@nsfnet-relay.ac.uk UUCP: mcvax!ukc!mira-request JANET: mira-request@ukc.ac.uk  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Nov 89 13:59:22 EST Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa27845; 14 Nov 89 13:49 EST Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.0/AI-4.10) id AA09756; Tue, 14 Nov 89 13:49:26 EST Received: from localhost by zurich.ai.mit.edu; Tue, 14 Nov 89 13:48:24 est Date: Tue, 14 Nov 89 13:48:24 est From: Chris Hanson Message-Id: <8911141848.AA03805@zurich.ai.mit.edu> To: mcsun!hp4nl!star.cs.vu.nl!xerox@uunet.uu.net Cc: scheme@mc.lcs.mit.edu In-Reply-To: Via Fons Botman's message of 13 Nov 89 17:17:21 GMT <4520@ski.cs.vu.nl> Subject: - and / with one argument should be identity functions. Date: 13 Nov 89 17:17:21 GMT From: Via Fons Botman PLease, let's *not* define (- X) and (/ X) to be something else than X. Besides that, it may be cute, but it is neither clear nor consistent, and therefore not "in the spirit of Scheme". While it may be "cute" to use this pun, I think your argument about clarity is incorrect: it is unusual for someone to be confused by this usage of `-' (I don't know about `/'; I suspect it is rarely called with one argument). In practical terms, it is very much too late to reconsider this decision. Both the R4RS and the Draft Standard for Scheme endorse this inconsistency, and I can't recall any serious debate concerning it. Perhaps if this issue had been raised five years ago something might have been done, but at this point the inertia of standards and implementations make such a change difficult; and this is especially true as it is unlikely to be viewed (by those standardizers and implementors) as being worth much effort. Unfortunately this means that the Scheme community is a kind of authoritarian structure -- but the standardization process is open to anyone who cares to participate, so you too can be one of those in authority. There are two relevant mailing lists: rrrs-authors@ai.mit.edu scheme-standard@ai.mit.edu Interested parties should know that because the Draft Standard is nearly completed, significant reexamination of basic issues on the "scheme-standard" mailing list is inappropriate. The "rrrs-authors" list is currently clearing up final details of R4RS, and debate is welcomed on interesting issues for R5RS. Archives of past discussions on each list are available by anonymous ftp from "zurich.ai.mit.edu" in the directory "pub/scheme-mail/".  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Nov 89 13:38:36 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa27366; 14 Nov 89 13:25 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA05254; Tue, 14 Nov 89 13:00:26 EST 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: 14 Nov 89 17:44:29 GMT From: Timothy Hansell Organization: Ohio State University Computer and Information Science Subject: Re: Scheme or LISP in Smalltalk? Message-Id: <73957@tut.cis.ohio-state.edu> References: <14557@well.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <14557@well.UUCP> frobozz@well.UUCP (Jordan Bortz) writes: > >Has anyone implemented a lisp or schme in Smalltalk? >How hard would it be to handle local variable bindings? > Jordan >-- >*********************************************************************** >* Jordan A. Bortz, Higher Level Software, Santa Cruz, CA * >* well!frobozz frobozz@well.sf.ca.us 408 - 476 - 8464 * >*********************************************************************** I'm not sure about a lisp or a scheme, but as to the question of local variable bindings --- I have seen an addition to smalltalk workspaces, that allowed for the creation and the persistent existence of variables that were local to the workspace. When the workspace is remove the variables go away. I'm not sure how close that is to what you are talking about but this was implemented using a dictionary in the workspace to keep track of local variables. -tim  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Nov 89 13:22:28 EST Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa27193; 14 Nov 89 13:15 EST Received: by decwrl.dec.com; id AA10018; Tue, 14 Nov 89 10:14:47 -0800 Received: by jove.pa.dec.com; id AA08492; Tue, 14 Nov 89 10:14:44 -0800 Message-Id: <8911141814.AA08492@jove.pa.dec.com> To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu Cc: bartlett@decwrl.dec.com Subject: Re: Scheme -> C compilers? In-Reply-To: Your message of 14 Nov 89 00:08:19 -0500. <8911140117.aa28797@mintaka.lcs.mit.edu> Date: Tue, 14 Nov 89 10:14:39 PST From: bartlett@decwrl.dec.com I don't know anything about the status of Vincennes Scheme, but a Scheme->C compiler was also done at DEC WRL. Besides the required and most of the optional items of R3RS, it includes: a compacting generational collector, "expansion passing style" macros, a foreign function call capability, and interfaces to X11's Xlib. The software is not "public domain", but the license terms are fairly liberal. Users of the software may use, modify, copy and distribute the software and documentation, but may not offer it for sale or transfer it for compensation (see the actual license for complete details). Licensees must sign a license agreement and there is a $100 distribution fee for the software. Send me a mail message with your postal address if you'd like further information about licensing the software. jfb  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Nov 89 04:05:20 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa15267; 14 Nov 89 3:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA26943; Tue, 14 Nov 89 03:45:18 EST 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: 14 Nov 89 04:49:01 GMT From: Jordan Bortz Subject: Scheme or LISP in Smalltalk? Message-Id: <14557@well.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Has anyone implemented a lisp or schme in Smalltalk? How hard would it be to handle local variable bindings? Jordan -- *********************************************************************** * Jordan A. Bortz, Higher Level Software, Santa Cruz, CA * * well!frobozz frobozz@well.sf.ca.us 408 - 476 - 8464 * ***********************************************************************  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Nov 89 03:34:14 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20501; 14 Nov 89 3:25 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA26384; Tue, 14 Nov 89 03:15:59 EST 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: 13 Nov 89 17:17:21 GMT From: Via Fons Botman Organization: VU Informatica, Amsterdam Subject: - and / with one argument should be identity functions. Message-Id: <4520@skiscs.vu.nl> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu PLease, let's *not* define (- X) and (/ X) to be something else than X. It might be the source of obscure errors in (admittedly ugly) code like: (define (net-gain gain losses) (apply - gain losses)) Besides that, it may be cute, but it is neither clear nor consistent, and therefore not "in the spirit of Scheme". At least, that's my opinion.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Nov 89 18:02:47 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa22569; 13 Nov 89 17:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA16992; Mon, 13 Nov 89 17:42:37 EST 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: 13 Nov 89 17:17:21 GMT From: Via Fons Botman Organization: VU Informatica, Amsterdam Subject: - and / with one argument should be identity functions. Message-Id: <4520@ski.cs.vu.nl> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu PLease, let's *not* define (- X) and (/ X) to be something else than X. It might be the source of obscure errors in (admittedly ugly) code like: (define (net-gain gain losses) (apply - gain losses)) Besides that, it may be cute, but it is neither clear nor consistent, and therefore not "in the spirit of Scheme". At least, that's my opinion.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Nov 89 17:04:26 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18570; 13 Nov 89 16:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA15917; Mon, 13 Nov 89 16:45:27 EST 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: 13 Nov 89 19:42:43 GMT From: Garey Mills Organization: Sun Microsystems, Inc. - Mtn View, CA Subject: Scheme -> C compilers? Message-Id: <34756@gtm.uucp> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In 1985 MIT put out a memo on C Scheme which listed the versions of Scheme then available in the public domain. Among them was Vincennes Scheme, and in MIT's description they noted that a Scheme-to-C compiler was also available. I have also heard of such a compiler existing from other sources, but no one was sure from where. I cannot get in touch with the guy responsible for Vincennes Scheme, so I'm asking generally. Is such a compiler available? Is it public domain? Where can it be had? Any info would help. Thanks, Garey Mills (garey@gtm.EBAY.sun.com)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Nov 89 16:00:53 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa10925; 13 Nov 89 15:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA14588; Mon, 13 Nov 89 15:29:10 EST 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: 13 Nov 89 19:32:23 GMT From: Jonathan Rees Organization: The Internet Subject: Scheme to Commonlisp Message-Id: <8911131932.AA26435@zurich.ai.mit.edu> References: <8911080749.aa12548@mintaka.lcs.mit.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Date: Wed, 08 Nov 89 12:38:51 +0000 From: Simon Ross Does anyone have any advice or experience with converting a program in Scheme to CommonLisp (in this case Texas Instruments Scheme and Vax Commonlisp)? If there is some nifty program out there that could do the job? An old version of Pseudoscheme comes with the official VAX LISP distribution from DEC; see the LISP$EXAMPLES directory. It lets you run Scheme code in Common Lisp, but doesn't include a file translator. You can get a newer version of Pseudoscheme that does include a file translator by anonymous ftp from zurich.ai.mit.edu:/pub/pseudo/pseudo-2-7.tar. Documentation is in file README. Upward continuations and true tail recursion aren't supported, but it does turn appropriately written Scheme loops into Common Lisp PROG forms. If you want true tail recursion or upward continuations, your task is much more difficult.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Nov 89 14:53:08 EST Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa08961; 13 Nov 89 14:33 EST Received: from zurich.ai.mit.edu ([18.43.0.158]) by life.ai.mit.edu (4.0/AI-4.10) id AA20295; Mon, 13 Nov 89 14:33:26 EST Received: from localhost by zurich.ai.mit.edu; Mon, 13 Nov 89 14:32:23 est Date: Mon, 13 Nov 89 14:32:23 est From: Jonathan Rees Message-Id: <8911131932.AA26435@zurich.ai.mit.edu> To: S.Ross@cs.ucl.ac.uk Cc: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu In-Reply-To: Simon Ross's message of Wed, 08 Nov 89 12:38:51 +0000 <8911080749.aa12548@mintaka.lcs.mit.edu> Subject: Scheme to Commonlisp Date: Wed, 08 Nov 89 12:38:51 +0000 From: Simon Ross Does anyone have any advice or experience with converting a program in Scheme to CommonLisp (in this case Texas Instruments Scheme and Vax Commonlisp)? If there is some nifty program out there that could do the job? An old version of Pseudoscheme comes with the official VAX LISP distribution from DEC; see the LISP$EXAMPLES directory. It lets you run Scheme code in Common Lisp, but doesn't include a file translator. You can get a newer version of Pseudoscheme that does include a file translator by anonymous ftp from zurich.ai.mit.edu:/pub/pseudo/pseudo-2-7.tar. Documentation is in file README. Upward continuations and true tail recursion aren't supported, but it does turn appropriately written Scheme loops into Common Lisp PROG forms. If you want true tail recursion or upward continuations, your task is much more difficult.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Nov 89 09:02:25 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07609; 13 Nov 89 8:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA07560; Mon, 13 Nov 89 08:45:17 EST 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: 13 Nov 89 13:37:21 GMT From: "Brent W. Benson" Organization: University of Rochester Subject: Re: XScheme Question..... Message-Id: <4005@ur-cc.UUCP> References: <13736@orstcs.CS.ORST.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <13736@orstcs.CS.ORST.EDU> rpandey@umber.CS.ORST.EDU (Rajeev Pandey) writes: >My apologies if this question has been answered before, but: > >Is there some network site from which I can ftp the XScheme source? > The sources and binaries for XScheme are available at many ftp sites. I obtained my sources (and PC binaries) from terminator.cc.umich.edu (35.1.33.8). Enjoy! Brent Benson (bwbe_c50@uhura.cc.rochester.edu)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Nov 89 07:32:32 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa04405; 13 Nov 89 7:25 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA06441; Mon, 13 Nov 89 07:20:55 EST 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: 13 Nov 89 11:28:49 GMT From: Rajeev Pandey Organization: Oregon State Univ. - CS - Corvallis, OR Subject: XScheme Question..... Message-Id: <13736@orstcs.CS.ORST.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu My apologies if this question has been answered before, but: Is there some network site from which I can ftp the XScheme source? I have seen a recent posting stating XScheme binaries were available through BIX (Byte Info Exchange), but how about on the net? I have a copy of the source for version 0.16 (Jan. 9, 89), and was also wondering whether this is the latest version or not. Many thanx in advance for any information. -------- Department of Computer Science | Rajeev "Raju" Pandey Computer Science Building 100 | Oregon State University | Internet: rpandey@cs.orst.edu Corvallis, OR 97331-3902 U.S.A. | UUCP: tektronix!orstcs!rpandey (503) 737-3273 fax: (503) 737-3014| UUCP: hplabs!hp-pcd!orstcs!rpandey  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Nov 89 01:57:04 EST Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22777; 13 Nov 89 1:52 EST Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA11094; Mon, 13 Nov 89 01:52:43 EST Received: from CLAMEN.AVALON.CS.CMU.EDU ([128.2.220.41]) by zurich.ai.mit.edu; Mon, 13 Nov 89 01:51:40 est Message-Id: <8911130651.AA18763@zurich.ai.mit.edu> From: "Stewart M. Clamen" Date: Mon, 13 Nov 89 01:51:18 EST To: scheme@zurich.ai.mit.edu Subject: Scheme BibTex file Reply-To: clamen+@cs.cmu.edu Sender: clamen@clamen.avalon.cs.cmu.edu Has anyone out there composed a BibTex (or Scribe) bibliography file for Scheme papers and books? It doesn't have to be complete. I will happily add to it. ------------------------------------------------------------------------------ Stewart M. Clamen School of Computer Science, Carnegie Mellon University Pittsburgh, PA 15213-3890 INTERNET: clamen@CS.CMU.EDU USENET: ...!uunet!"clamen@cs.cmu.edu"  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Nov 89 19:33:06 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa23325; 11 Nov 89 19:25 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA05847; Sat, 11 Nov 89 18:56:28 EST 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: 11 Nov 89 18:55:05 GMT From: Eric Johnson Organization: Prime Automation, Inc., Burnsville, MN Subject: Re: How to build xscheme for the mac Message-Id: <742@pai.UUCP> References: <2091@cunixc.cc.columbia.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <2091@cunixc.cc.columbia.edu>, puglia@cunixc.cc.columbia.edu (Paul Puglia) writes: > How does you build xscheme on a macintosh ? I have a copy of > the xscheme sources compiles fine on a unix machine, and works > great on a pc with turbo c. When I tried to compile it on a > friends mac II using his copy of lightspeed c. I have no luck. > Could someone please describe the procedure to compile this program, and > comment on if anything else is need to compile xscheme. I know that you > need some resource to compile xlisp on a mac. Do you need the same sort of > stuff for xscheme > Thanks in advance > Paul Puglia > Dept of Civil Engineering > Columbia University Porting Xlisp/XScheme: Awhile back, while I was taking an AI course, I was spending a lot of time trekking to campus and using their LISP system. To avoid travel time (and to work on LISP at any hour I wanted), I got into porting XLisp. In looking at the code, I'd say XLisp and XScheme are two of the most portable C programs I have ever seen. Now, I've spent most of my time on XLisp, so your mileage may vary, but... XLisp seems to place most Operating System (OS)-dependent features in separate files, named dosstuff.c, osptrs.h, osdefs.h. On UNIX, the "stuff: file is called unixstuf.c and on the Mac its called macstuff.c (all file names are <= 8 chars for MS-DOS). The mac version also has a resource compiler file (that is, a file you run through the resource compiler to generate a resource file). I assume (hope) XScheme is similiar. Below, I placed all my Mac-related files from XLisp (2.0, I think). The XScheme stuff should be similiar. I hope these help. (Note: I don't have the full sources around now, just the Mac and UNIX-specific files.) (Note2: Two extra files, macfun.c and macinit.c are below, its been so long that I'm not sure if these are extras or necessary--Sorry.) I'm placing these files here in hopes they can help you with your porting. I do know that binary executable versions of XScheme are available on the BIX bulletin board (Byte magazine Information eXchange)--see Byte mag for details. Getting the binaries would solve all the Mac porting problems in one fell swoop. Anyway, hope this helps, -Eric ======================== macfun.c ============================================= /* macfun.c - macintosh user interface functions for xlisp */ #include #include #include #include "xlisp.h" /* external variables */ extern GrafPtr cwindow,gwindow; /* forward declarations */ FORWARD LVAL do_0(); FORWARD LVAL do_1(); FORWARD LVAL do_2(); /* xptsize - set the command window point size */ LVAL xptsize() { LVAL val; val = xlgafixnum(); xllastarg(); TextSize((int)getfixnum(val)); InvalRect(&cwindow->portRect); SetupScreen(); return (NIL); } /* xhidepen - hide the pen */ LVAL xhidepen() { return (do_0('H')); } /* xshowpen - show the pen */ LVAL xshowpen() { return (do_0('S')); } /* xgetpen - get the pen position */ LVAL xgetpen() { LVAL val; Point p; xllastarg(); SetPort(gwindow); GetPen(&p); SetPort(cwindow); xlsave1(val); val = consa(NIL); rplaca(val,cvfixnum((FIXTYPE)p.h)); rplacd(val,cvfixnum((FIXTYPE)p.v)); xlpop(); return (val); } /* xpenmode - set the pen mode */ LVAL xpenmode() { return (do_1('M')); } /* xpensize - set the pen size */ LVAL xpensize() { return (do_2('S')); } /* xpenpat - set the pen pattern */ LVAL xpenpat() { LVAL plist; char pat[8],i; plist = xlgalist(); xllastarg(); for (i = 0; i < 8 && consp(plist); ++i, plist = cdr(plist)) if (fixp(car(plist))) pat[i] = getfixnum(car(plist)); SetPort(gwindow); PenPat(pat); SetPort(cwindow); return (NIL); } /* xpennormal - set the pen to normal */ LVAL xpennormal() { xllastarg(); SetPort(gwindow); PenNormal(); SetPort(cwindow); return (NIL); } /* xmoveto - Move to a screen location */ LVAL xmoveto() { return (do_2('m')); } /* xmove - Move in a specified direction */ LVAL xmove() { return (do_2('M')); } /* xlineto - draw a Line to a screen location */ LVAL xlineto() { return (do_2('l')); } /* xline - draw a Line in a specified direction */ LVAL xline() { return (do_2('L')); } /* xshowgraphics - show the graphics window */ LVAL xshowgraphics() { xllastarg(); scrsplit(1); return (NIL); } /* xhidegraphics - hide the graphics window */ LVAL xhidegraphics() { xllastarg(); scrsplit(0); return (NIL); } /* xcleargraphics - clear the graphics window */ LVAL xcleargraphics() { xllastarg(); SetPort(gwindow); EraseRect(&gwindow->portRect); SetPort(cwindow); return (NIL); } /* do_0 - Handle commands that require no arguments */ LOCAL LVAL do_0(fcn) int fcn; { xllastarg(); SetPort(gwindow); switch (fcn) { case 'H': HidePen(); break; case 'S': ShowPen(); break; } SetPort(cwindow); return (NIL); } /* do_1 - Handle commands that require one integer argument */ LOCAL LVAL do_1(fcn) int fcn; { int x; x = getnumber(); xllastarg(); SetPort(gwindow); switch (fcn) { case 'M': PenMode(x); break; } SetPort(cwindow); return (NIL); } /* do_2 - Handle commands that require two integer arguments */ LOCAL LVAL do_2(fcn) int fcn; { int h,v; h = getnumber(); v = getnumber(); xllastarg(); SetPort(gwindow); switch (fcn) { case 'l': LineTo(h,v); break; case 'L': Line(h,v); break; case 'm': MoveTo(h,v); break; case 'M': Move(h,v); break; case 'S': PenSize(h,v);break; } SetPort(cwindow); return (NIL); } /* getnumber - get an integer parameter */ LOCAL int getnumber() { LVAL num; num = xlgafixnum(); return ((int)getfixnum(num)); } /* xtool - call the toolbox */ LVAL xtool() { LVAL val; int trap; trap = getnumber(); /* asm { move.l args(A6),D0 beq L2 L1: move.l D0,A0 move.l 2(A0),A1 move.w 4(A1),-(A7) move.l 6(A0),D0 bne L1 L2: lea L3,A0 move.w trap(A6),(A0) L3: dc.w 0xA000 clr.l val(A6) } */ return (val); } /* xtool16 - call the toolbox with a 16 bit result */ LVAL xtool16() { int trap,val; trap = getnumber(); /* asm { clr.w -(A7) move.l args(A6),D0 beq L2 L1: move.l D0,A0 move.l 2(A0),A1 move.w 4(A1),-(A7) move.l 6(A0),D0 bne L1 L2: lea L3,A0 move.w trap(A6),(A0) L3: dc.w 0xA000 move.w (A7)+,val(A6) } */ return (cvfixnum((FIXTYPE)val)); } /* xtool32 - call the toolbox with a 32 bit result */ LVAL xtool32() { int trap; long val; trap = getnumber(); /* asm { clr.l -(A7) move.l args(A6),D0 beq L2 L1: move.l D0,A0 move.l 2(A0),A1 move.w 4(A1),-(A7) move.l 6(A0),D0 bne L1 L2: lea L3,A0 move.w trap(A6),(A0) L3: dc.w 0xA000 move.l (A7)+,val(A6) } */ return (cvfixnum((FIXTYPE)val)); } /* xnewhandle - allocate a new handle */ LVAL xnewhandle() { LVAL num; long size; num = xlgafixnum(); size = getfixnum(num); xllastarg(); return (cvfixnum((FIXTYPE)NewHandle(size))); } /* xnewptr - allocate memory */ LVAL xnewptr() { LVAL num; long size; num = xlgafixnum(); size = getfixnum(num); xllastarg(); return (cvfixnum((FIXTYPE)NewPtr(size))); } /* xhiword - return the high order 16 bits of an integer */ LVAL xhiword() { unsigned int val; val = (unsigned int)(getnumber() >> 16); xllastarg(); return (cvfixnum((FIXTYPE)val)); } /* xloword - return the low order 16 bits of an integer */ LVAL xloword() { unsigned int val; val = (unsigned int)getnumber(); xllastarg(); return (cvfixnum((FIXTYPE)val)); } /* xrdnohang - get the next character in the look-ahead buffer */ LVAL xrdnohang() { int ch; xllastarg(); if ((ch = scrnextc()) == EOF) return (NIL); return (cvfixnum((FIXTYPE)ch)); } /* ossymbols - enter important symbols */ ossymbols() { LVAL sym; /* setup globals for the window handles */ sym = xlenter("*COMMAND-WINDOW*"); setvalue(sym,cvfixnum((FIXTYPE)cwindow)); sym = xlenter("*GRAPHICS-WINDOW*"); setvalue(sym,cvfixnum((FIXTYPE)gwindow)); } ======================== macint.c ============================================= /* macint.c - macintosh interface routines for xlisp */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include /* program limits */ #define SCRH 40 /* maximum screen height */ #define SCRW 100 /* maximum screen width */ #define CHARMAX 100 /* maximum number of buffered characters */ #define TIMEON 40 /* cursor on time */ #define TIMEOFF 20 /* cursor off time */ /* useful definitions */ #define MenuBarHeight 20 #define TitleBarHeight 20 #define SBarWidth 16 #define MinWidth 80 #define MinHeight 40 #define ScreenMargin 2 #define TextMargin 4 #define GHeight 232 /* menu id's */ #define appleID 1 #define fileID 256 #define editID 257 #define controlID 258 /* externals */ extern char *s_unbound; extern char *PtoCstr(); /* screen dimensions */ int screenWidth; int screenHeight; /* command window (normal screen) */ int nHorizontal,nVertical,nWidth,nHeight; /* command window (split screen) */ int sHorizontal,sVertical,sWidth,sHeight; /* graphics window */ int gHorizontal,gVertical,gWidth,gHeight; /* menu handles */ MenuHandle appleMenu; MenuHandle fileMenu; MenuHandle editMenu; MenuHandle controlMenu; /* misc variables */ OSType filetypes[] = { 'TEXT' }; /* font information */ int tmargin,lmargin; int xinc,yinc; /* command window */ WindowRecord cwrecord; WindowPtr cwindow; /* graphics window */ WindowRecord gwrecord; WindowPtr gwindow; /* window mode */ int splitmode; /* cursor variables */ long cursortime; int cursorstate; int x,y; /* screen buffer */ char screen[SCRH*SCRW],*topline,*curline; int scrh,scrw; /* type ahead buffer */ char charbuf[CHARMAX],*inptr,*outptr; int charcnt; macinit() { /* initialize the toolbox */ InitGraf(&thePort); InitFonts(); InitWindows(); InitMenus(); TEInit(); InitDialogs(0L); InitCursor(); /* setup the menu bar */ SetupMenus(); /* get the size of the screen */ screenWidth = screenBits.bounds.right - screenBits.bounds.left; screenHeight = screenBits.bounds.bottom - screenBits.bounds.top; /* Create the graphics and control windows */ gwindow = GetNewWindow(129,&gwrecord,-1L); cwindow = GetNewWindow(128,&cwrecord,-1L); /* establish the command window as the current port */ SetPort(cwindow); /* compute the size of the normal command window */ nHorizontal = ScreenMargin; nVertical = MenuBarHeight + TitleBarHeight + ScreenMargin - 2; nWidth = screenWidth - (ScreenMargin * 2) - 1; nHeight = screenHeight - MenuBarHeight - TitleBarHeight - (ScreenMargin * 2); /* compute the size of the split command window */ sHorizontal = nHorizontal; sVertical = nVertical + GHeight + 1; sWidth = nWidth; sHeight = nHeight - GHeight - 1; /* compute the size of the graphics window */ gHorizontal = nHorizontal; gVertical = MenuBarHeight + ScreenMargin; gWidth = screenWidth - (ScreenMargin * 2); gHeight = GHeight; /* move and size the graphics window */ MoveWindow(gwindow,gHorizontal,gVertical,0); SizeWindow(gwindow,gWidth,gHeight,0); /* setup the font, size and writing mode for the command window */ TextFont(monaco); TextSize(9); TextMode(srcCopy); /* setup command mode */ scrsplit(FALSE); /* disable the Cursor */ cursorstate = -1; /* setup the input ring buffer */ inptr = outptr = charbuf; charcnt = 0; /* lock the font in memory */ SetFontLock(-1); } SetupMenus() { appleMenu = GetMenu(appleID); /* setup the apple menu */ AddResMenu(appleMenu,'DRVR'); InsertMenu(appleMenu,0); fileMenu = GetMenu(fileID); /* setup the file menu */ InsertMenu(fileMenu,0); editMenu = GetMenu(editID); /* setup the edit menu */ InsertMenu(editMenu,0); controlMenu = GetMenu(controlID); /* setup the control menu */ InsertMenu(controlMenu,0); DrawMenuBar(); } int scrgetc() { CursorOn(); while (charcnt == 0) DoEvent(); CursorOff(); return (scrnextc()); } int scrnextc() { int ch; if (charcnt > 0) { ch = *outptr++; charcnt--; if (outptr >= &charbuf[CHARMAX]) outptr = charbuf; } else { charcnt = 0; ch = -1; } return (ch); } scrputc(ch) int ch; { switch (ch) { case '\r': x = 0; break; case '\n': nextline(&curline); if (++y >= scrh) { y = scrh - 1; scrollup(); } break; case '\t': do { scrputc(' '); } while (x & 7); break; case '\010': if (x) x--; break; default: if (ch >= 0x20 && ch < 0x7F) { scrposition(x,y); DrawChar(ch); curline[x] = ch; if (++x >= scrw) { nextline(&curline); if (++y >= scrh) { y = scrh - 1; scrollup(); } x = 0; } } break; } } scrdelete() { scrputc('\010'); scrputc(' '); scrputc('\010'); } scrclear() { curline = screen; for (y = 0; y < SCRH; y++) for (x = 0; x < SCRW; x++) *curline++ = ' '; topline = curline = screen; x = y = 0; } scrflush() { inptr = outptr = charbuf; charcnt = -1; osflush(); } scrposition(x,y) int x,y; { MoveTo((x * xinc) + lmargin,(y * yinc) + tmargin); } DoEvent() { EventRecord myEvent; SystemTask(); CursorUpdate(); while (GetNextEvent(everyEvent,&myEvent)) switch (myEvent.what) { case mouseDown: DoMouseDown(&myEvent); break; case keyDown: case autoKey: DoKeyPress(&myEvent); break; case activateEvt: DoActivate(&myEvent); break; case updateEvt: DoUpdate(&myEvent); break; } } DoMouseDown(myEvent) EventRecord *myEvent; { WindowPtr whichWindow; switch (FindWindow(myEvent->where,&whichWindow)) { case inMenuBar: DoMenuClick(myEvent); break; case inSysWindow: SystemClick(myEvent,whichWindow); break; case inDrag: DoDrag(myEvent,whichWindow); break; case inGoAway: DoGoAway(myEvent,whichWindow); break; case inGrow: DoGrow(myEvent,whichWindow); break; case inContent: DoContent(myEvent,whichWindow); break; } } DoMenuClick(myEvent) EventRecord *myEvent; { long choice; if (choice = MenuSelect(myEvent->where)) DoCommand(choice); } DoDrag(myEvent,whichWindow) EventRecord *myEvent; WindowPtr whichWindow; { Rect dragRect; SetRect(&dragRect,0,MenuBarHeight,screenWidth,screenHeight); InsetRect(&dragRect,ScreenMargin,ScreenMargin); DragWindow(whichWindow,myEvent->where,&dragRect); } DoGoAway(myEvent,whichWindow) EventRecord *myEvent; WindowPtr whichWindow; { if (TrackGoAway(whichWindow,myEvent->where)) wrapup(); } DoGrow(myEvent,whichWindow) EventRecord *myEvent; WindowPtr whichWindow; { Rect sizeRect; long newSize; if (whichWindow != FrontWindow() && whichWindow != gwindow) SelectWindow(whichWindow); else { SetRect(&sizeRect,MinWidth,MinHeight,screenWidth,screenHeight-MenuBarHeight); newSize = GrowWindow(whichWindow,myEvent->where,&sizeRect); if (newSize) { EraseRect(&whichWindow->portRect); SizeWindow(whichWindow,LoWord(newSize),HiWord(newSize),-1); InvalRect(&whichWindow->portRect); SetupScreen(); scrflush(); } } } DoContent(myEvent,whichWindow) EventRecord *myEvent; WindowPtr whichWindow; { if (whichWindow != FrontWindow() && whichWindow != gwindow) SelectWindow(whichWindow); } DoKeyPress(myEvent) EventRecord *myEvent; { long choice; if (FrontWindow() == cwindow) { if (myEvent->modifiers & 0x100) { if (choice = MenuKey((char)myEvent->message)) DoCommand(choice); } else { if (charcnt < CHARMAX) { *inptr++ = myEvent->message & 0xFF; charcnt++; if (inptr >= &charbuf[CHARMAX]) inptr = charbuf; } } } } DoActivate(myEvent) EventRecord *myEvent; { WindowPtr whichWindow; whichWindow = (WindowPtr)myEvent->message; SetPort(whichWindow); if (whichWindow == cwindow) DrawGrowIcon(whichWindow); } DoUpdate(myEvent) EventRecord *myEvent; { WindowPtr whichWindow; GrafPtr savePort; GetPort(&savePort); whichWindow = (WindowPtr)myEvent->message; SetPort(whichWindow); BeginUpdate(whichWindow); EraseRect(&whichWindow->portRect); if (whichWindow == cwindow) { DrawGrowIcon(whichWindow); RedrawScreen(); } EndUpdate(whichWindow); SetPort(savePort); } DoCommand(choice) long choice; { int theMenu,theItem; /* decode the menu choice */ theMenu = HiWord(choice); theItem = LoWord(choice); CursorOff(); HiliteMenu(theMenu); switch (theMenu) { case appleID: DoAppleMenu(theItem); break; case fileID: DoFileMenu(theItem); break; case editID: DoEditMenu(theItem); break; case controlID: DoControlMenu(theItem); break; } HiliteMenu(0); CursorOn(); } pascal aboutfilter(theDialog,theEvent,itemHit) DialogPtr theDialog; EventRecord *theEvent; int *itemHit; { return (theEvent->what == mouseDown ? -1 : 0); } DoAppleMenu(theItem) int theItem; { DialogRecord mydialog; char name[256]; GrafPtr gp; int n; switch (theItem) { case 1: GetNewDialog(129,&mydialog,-1L); ModalDialog(aboutfilter,&n); CloseDialog(&mydialog); break; default: GetItem(appleMenu,theItem,name); GetPort(&gp); OpenDeskAcc(name); SetPort(gp); break; } } pascal int filefilter(pblock) ParmBlkPtr pblock; { unsigned char *p; int len; p = pblock->fileParam.ioNamePtr; len = *p++ &0xFF; return (len >= 4 && strncmp(p+len-4,".lsp",4) == 0 ? 0 : -1); } DoFileMenu(theItem) int theItem; { SFReply loadfile; Point p; switch (theItem) { case 1: /* load */ case 2: /* load noisily */ p.h = 100; p.v = 100; SFGetFile(p,"\P",filefilter,-1,filetypes,0L,&loadfile); if (loadfile.good) { HiliteMenu(0); SetVol(0L,loadfile.vRefNum); if (xlload(PtoCstr(loadfile.fName),1,(theItem == 1 ? 0 : 1))) scrflush(); else xlabort("load error"); } break; case 4: /* quit */ wrapup(); } } DoEditMenu(theItem) int theItem; { switch (theItem) { case 1: /* undo */ case 3: /* cut */ case 4: /* copy */ case 5: /* paste */ case 6: /* clear */ SystemEdit(theItem-1); break; } } DoControlMenu(theItem) int theItem; { scrflush(); HiliteMenu(0); switch (theItem) { case 1: /* break */ xlbreak("user break",s_unbound); break; case 2: /* continue */ xlcontinue(); break; case 3: /* clean-up error */ xlcleanup(); break; case 4: /* Cancel input */ xlabort("input canceled"); break; case 5: /* Top Level */ xltoplevel(); break; case 7: /* split screen */ scrsplit(splitmode ? FALSE : TRUE); break; } } scrsplit(split) int split; { ShowHide(cwindow,0); if (split) { CheckItem(controlMenu,7,-1); ShowHide(gwindow,-1); MoveWindow(cwindow,sHorizontal,sVertical,-1); SizeWindow(cwindow,sWidth,sHeight,-1); InvalRect(&cwindow->portRect); SetupScreen(); } else { CheckItem(controlMenu,7,0); ShowHide(gwindow,0); MoveWindow(cwindow,nHorizontal,nVertical,-1); SizeWindow(cwindow,nWidth,nHeight,-1); InvalRect(&cwindow->portRect); SetupScreen(); } ShowHide(cwindow,-1); splitmode = split; } SetupScreen() { FontInfo info; Rect *pRect; /* get font information */ GetFontInfo(&info); /* compute the top and bottom margins */ tmargin = TextMargin + info.ascent; lmargin = TextMargin; /* compute the x and y increments */ xinc = info.widMax; yinc = info.ascent + info.descent + info.leading; /* compute the character dimensions of the screen */ pRect = &cwindow->portRect; scrh = (pRect->bottom - (2 * TextMargin) - (SBarWidth - 1)) / yinc; if (scrh > SCRH) scrh = SCRH; scrw = (pRect->right - (2 * TextMargin) - (SBarWidth - 1)) / xinc; if (scrw > SCRW) scrw = SCRW; /* clear the screen */ scrclear(); } CursorUpdate() { if (cursorstate != -1) if (cursortime < TickCount()) { scrposition(x,y); if (cursorstate) { DrawChar(' '); cursortime = TickCount() + TIMEOFF; cursorstate = 0; } else { DrawChar('_'); cursortime = TickCount() + TIMEON; cursorstate = 1; } } } CursorOn() { cursortime = TickCount(); cursorstate = 0; } CursorOff() { if (cursorstate == 1) { scrposition(x,y); DrawChar(' '); } cursorstate = -1; } RedrawScreen() { char *Line; int y; Line = topline; for (y = 0; y < scrh; y++) { scrposition(0,y); DrawText(Line,0,scrw); nextline(&Line); } } nextline(pline) char **pline; { if ((*pline += SCRW) >= &screen[SCRH*SCRW]) *pline = screen; } scrollup() { RgnHandle updateRgn; Rect rect; int x; updateRgn = NewRgn(); rect = cwindow->portRect; rect.bottom -= SBarWidth - 1; rect.right -= SBarWidth - 1; ScrollRect(&rect,0,-yinc,updateRgn); DisposeRgn(updateRgn); for (x = 0; x < SCRW; x++) topline[x] = ' '; nextline(&topline); } ======================== macstuff.c ========================================== /* macstuff.c - macintosh interface routines for xlisp */ #include /* program limits */ #define LINEMAX 200 /* maximum line length */ /* externals */ extern FILE *tfp; extern int x; /* local variables */ static char linebuf[LINEMAX+1],*lineptr; static int linepos[LINEMAX],linelen; static long rseed = 1L; osinit(name) char *name; { /* initialize the mac interface routines */ macinit(); /* initialize the line editor */ linelen = 0; } osfinish() { } oserror(msg) { char line[100],*p; sprintf(line,"error: %s\n",msg); for (p = line; *p != '\0'; ++p) ostputc(*p); } int osrand(n) int n; { long k1; /* make sure we don't get stuck at zero */ if (rseed == 0L) rseed = 1L; /* algorithm taken from Dr. Dobbs Journal, November 1985, Page 91 */ k1 = rseed / 127773L; if ((rseed = 16807L * (rseed - k1 * 127773L) - k1 * 2836L) < 0L) rseed += 2147483647L; /* return a random number between 0 and n-1 */ return ((int)(rseed % (long)n)); } FILE *osaopen(name,mode) char *name,*mode; { return (fopen(name,mode)); } FILE *osbopen(name,mode) char *name,*mode; { char nmode[4]; strcpy(nmode,mode); strcat(nmode,"b"); return (fopen(name,nmode)); } int osclose(fp) FILE *fp; { return (fclose(fp)); } int osagetc(fp) FILE *fp; { return (getc(fp)); } int osbgetc(fp) FILE *fp; { return (getc(fp)); } int osaputc(ch,fp) int ch; FILE *fp; { return (putc(ch,fp)); } int osbputc(ch,fp) int ch; FILE *fp; { return (putc(ch,fp)); } int ostgetc() { int ch,i; if (linelen--) return (*lineptr++); linelen = 0; while ((ch = scrgetc()) != '\r') switch (ch) { case EOF: return (ostgetc()); case '\010': if (linelen > 0) { linelen--; while (x > linepos[linelen]) scrdelete(); } break; default: if (linelen < LINEMAX) { linebuf[linelen] = ch; linepos[linelen] = x; linelen++; } scrputc(ch); break; } linebuf[linelen++] = '\n'; scrputc('\r'); scrputc('\n'); if (tfp) for (i = 0; i < linelen; ++i) osaputc(linebuf[i],tfp); lineptr = linebuf; linelen--; return (*lineptr++); } int ostputc(ch) int ch; { if (ch == '\n') scrputc('\r'); scrputc(ch); if (tfp) osaputc(ch,tfp); return (1); } osflush() { lineptr = linebuf; linelen = 0; } oscheck() { DoEvent(); } =========================== osdefs.h ===================================== extern LVAL xptsize(), xhidepen(),xshowpen(),xgetpen(),xpensize(),xpenmode(), xpenpat(),xpennormal(),xmoveto(),xmove(),xlineto(),xline(), xshowgraphics(),xhidegraphics(),xcleargraphics(), xtool(),xtool16(),xtool32(),xnewhandle(),xnewptr(), xhiword(),xloword(),xrdnohang(); =========================== osptrs.h ===================================== { "HIDEPEN", S, xhidepen }, /* 300 */ { "SHOWPEN", S, xshowpen }, /* 301 */ { "GETPEN", S, xgetpen }, /* 302 */ { "PENSIZE", S, xpensize }, /* 303 */ { "PENMODE", S, xpenmode }, /* 304 */ { "PENPAT", S, xpenpat }, /* 305 */ { "PENNORMAL", S, xpennormal }, /* 306 */ { "MOVETO", S, xmoveto }, /* 307 */ { "MOVE", S, xmove }, /* 308 */ { "LINETO", S, xlineto }, /* 309 */ { "LINE", S, xline }, /* 310 */ { "SHOW-GRAPHICS", S, xshowgraphics }, /* 311 */ { "HIDE-GRAPHICS", S, xhidegraphics }, /* 312 */ { "CLEAR-GRAPHICS", S, xcleargraphics }, /* 313 */ { "TOOLBOX", S, xtool }, /* 314 */ { "TOOLBOX-16", S, xtool16 }, /* 315 */ { "TOOLBOX-32", S, xtool32 }, /* 316 */ { "NEWHANDLE", S, xnewhandle }, /* 317 */ { "NEWPTR", S, xnewptr }, /* 318 */ { "HIWORD", S, xhiword }, /* 319 */ { "LOWORD", S, xloword }, /* 320 */ { "READ-CHAR-NO-HANG", S, xrdnohang }, /* 321 */ { "COMMAND-POINT-SIZE", S, xptsize }, /* 322 */ ======================== Xlisp.Rsrc ========================================== XLisp.Rsrc TYPE WIND ,128 XLISP version 2.0 41 4 339 508 InVisible GoAway 0 0 TYPE WIND ,129 Graphics Window 22 4 254 508 InVisible NoGoAway 2 0 TYPE DLOG ,129 About XLISP 50 100 290 395 Visible NoGoAway 3 0 129 TYPE DITL ,129 9 staticText 20 20 40 275 XLISP v2.0, February 6, 1988 staticText 40 20 60 275 Copyright (c) 1988, by David Betz staticText 60 20 80 275 All Rights Reserved staticText 90 20 110 275 Author contact information: staticText 110 40 130 275 David Betz staticText 130 40 150 275 127 Taylor Road staticText 150 40 170 275 Peterborough, NH 03458 staticText 170 40 190 275 (603) 924-6936 staticText 200 20 220 275 Portions Copyright Think Technologies TYPE MENU ,1 \14 About XLISP (- TYPE MENU ,256 File Load.../L Load Noisily.../N (- Quit/Q TYPE MENU ,257 Edit Undo/Z (- Cut/X Copy/C Paste/V Clear TYPE MENU ,258 Control Break/B Continue/P Clean Up Error/G Cancel Input/U Top Level/T (- Split Screen/S ======================== Alles ist gemacht ================================== -- Eric F. Johnson, Boulware Technologies, Inc. 415 W. Travelers Trail, Burnsville, MN 55337 USA. Phone: +1 612-894-0313. erc@pai.mn.org - or - bungia!pai!erc (We have a very dumb mailer, so please send a bang-!-style return address.)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Nov 89 00:28:50 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa26047; 11 Nov 89 0:25 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA22012; Fri, 10 Nov 89 23:59:47 EST 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: 11 Nov 89 02:03:11 GMT From: bywater!arnor!arnor.watson.ibm.com!yozzo@uunet.uu.net Organization: IBM T J Watson Research Center, Yorktown NY Subject: A-STAR in Scheme Message-Id: <1989Nov11.020311.5475@arnor.uucp> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu A while ago I asked about an implementation of the A-STAR algorithm in Scheme. Well, after some work I figured in out. So, if anyone is interested, just drop me a note and I will send you what I have. ------------------------------------------------------------------------------ | Ralph E. Yozzo | DISCLAIMER: The opinions expressed | | IBM Thomas J. Watson Research Ctr. | herein are the Authors. | | Arpanet: yozzo@ibm.com | And are not necessarily those of his | | | employer. | | Bitnet: yozzo@yktvmx.bitnet \---------------------------------------| | Home: ..!uunet!bywater!acheron!larouch!yozzo | Phone: (914) 945-3634 work | | | Phone: (914) 564-4731 home | ------------------------------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Nov 89 00:02:02 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa12927; 10 Nov 89 23:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA21927; Fri, 10 Nov 89 23:50:00 EST 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: 11 Nov 89 04:15:55 GMT From: Mikael Pettersson Organization: CIS Dept, Univ of Linkoping, Sweden Subject: better permute/unpermute Message-Id: <1428@senilix.ida.liu.se> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu I see that in the R3.99RS (draft of Aug. 31) the sematics for function application still uses the old definition of |permute| and |unpermute| as global functions with constant behaviour for any number N of arguments. I think I may have a simple solution that more accurately models the intended meaning of allowing the evaluation order to vary not only based on the _number_ of arguments, but also on the argument expressions themselves, the environment and the receiving expression continuation. Let us define a function |order| as follows: order : U -> K -> Exp* -> (Exp* -> Exp*)x(E* -> E*) axiom : if =order rho kappa E*, then p is a permutation, u is a permutation, and p and u are each others inverses. (*) (*) I'm a bit uneasy with this wording since there's a type conflict there. However, the same conflict is in the R3.99RS soo... The idea is to allow |order| to rearrange the arguments freely based on all the information a compiler might want to use. Non-determinism at run-time is ruled out however. The equation for application can then be modified to read: E[(E0 E*)] = lambda rho kappa . (lambda. ;; same body as before )(order rho kappa &E*) Is this an appropriate definition or have I missed something? /Mike -- Mikael Pettersson, Dept of Comp & Info Sci, University of Linkoping, Sweden email: mpe@ida.liu.se or ...!{mcsun,munnari,uunet,unido,...}!sunic!liuida!mpe  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 10 Nov 89 13:29:54 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa13312; 10 Nov 89 13:25 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA10708; Fri, 10 Nov 89 13:05:17 EST 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: 10 Nov 89 17:58:32 GMT From: "Andrew L. M. Shalit" Organization: Apple Computer Inc, Cambridge, MA Subject: Re: Scheme to Commonlisp Message-Id: References: <8911080749.aa12548@mintaka.lcs.mit.edu>, <1563@accuvax.nwu.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <8911080749.aa12548@mintaka.lcs.mit.edu>, S.Ross@CS (Simon Ross) writes: >Does anyone have any advice or experience with converting a >program in Scheme to CommonLisp (in this case Texas Instruments >Scheme and Vax Commonlisp)? If there is some nifty program out >there that could do the job? You may want to look at Pseudoscheme by Jonathon Reese. It compiles Scheme to Common Lisp, with the exception of upward continuations. Unfortunately, I don't have an FTP address. -andrew  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 10 Nov 89 12:30:05 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa12952; 10 Nov 89 12:25 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA09526; Fri, 10 Nov 89 12:08:05 EST 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: 10 Nov 89 16:13:18 GMT From: Bruce Krulwich Organization: Institute for the Learning Sciences, Northwestern University, Evanston, IL 60201 Subject: Re: Scheme to Commonlisp Message-Id: <1563@accuvax.nwu.edu> References: <8911080749.aa12548@mintaka.lcs.mit.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <8911080749.aa12548@mintaka.lcs.mit.edu>, S.Ross@CS (Simon Ross) writes: >Does anyone have any advice or experience with converting a >program in Scheme to CommonLisp (in this case Texas Instruments >Scheme and Vax Commonlisp)? If there is some nifty program out >there that could do the job? Over this past summer I wrote a program to translate T to CommonLISP (unfortunately I had to make the switch). It was not complete, but had a framework for defining translation methods that can be used to handle the parts of T that I didn't need to do. If anyone is interested I can look into making this package available via anonymous FTP. Bruce Krulwich Institute for the Learning Sciences krulwich@ils.nwu.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 9 Nov 89 19:00:26 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa16400; 9 Nov 89 18:54 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA23632; Thu, 9 Nov 89 18:44:24 EST 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: 9 Nov 89 23:43:42 GMT From: "Andrew L. M. Shalit" Organization: Apple Computer Inc, Cambridge, MA Subject: why eval is evil Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu OK, we all know eval is evil (notice that I didn't cross-post to comp.lang.lisp, where probably only about 90% of the people know eval is evil). I'm looking for a paper which explains *why* eval is evil, and explains how things like closures and backquote and such can be used instead. I'm trying to re-educate some Lisp programmers who were raised in the 1970's (some on InterLisp) and think that = Has anyone ever taken the time to write this stuff down? Or is it just 'general culture'? Send responses to alms@cambridge.apple.com. I'll post a summary if there's interest. thanks! -andrew  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 9 Nov 89 13:06:17 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa22710; 9 Nov 89 7:24 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA11462; Thu, 9 Nov 89 07:20:26 EST 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: 9 Nov 89 00:01:13 GMT From: Paul Puglia Organization: Columbia University Subject: How to build xscheme for the mac Message-Id: <2091@cunixc.cc.columbia.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu How does you build xscheme on a macintosh ? I have a copy of the xscheme sources compiles fine on a unix machine, and works great on a pc with turbo c. When I tried to compile it on a friends mac II using his copy of lightspeed c. I have no luck. Could someone please describe the procedure to compile this program, and comment on if anything else is need to compile xscheme. I know that you need some resource to compile xlisp on a mac. Do you need the same sort of stuff for xscheme Thanks in advance Paul Puglia Dept of Civil Engineering Columbia University  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 9 Nov 89 03:36:59 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21189; 9 Nov 89 3:24 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA07781; Thu, 9 Nov 89 03:16:10 EST 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: 9 Nov 89 05:09:05 GMT From: Dan McCabe Subject: Jonathan Lee's email addr??? Message-Id: <10442@thorin.cs.unc.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Sorry to waste net bandwidth, but could Jonathan Lee (or someone who knows it) please send me his email address? I have some info for you. Thanx in advance, danm mccabe@cs.unc.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Nov 89 07:55:33 EST Received: from cs.ucl.ac.uk by mintaka.lcs.mit.edu id aa12548; 8 Nov 89 7:49 EST Received: from pyr1.cs.ucl.ac.uk by vs6.Cs.Ucl.AC.UK via Ethernet with SMTP id aa06531; 8 Nov 89 12:42 WET To: Scheme <@mintaka.lcs.mit.edu:Scheme@mc.lcs.mit.edu> cc: S.Ross@cs.ucl.ac.uk Subject: Scheme to Commonlisp Date: Wed, 08 Nov 89 12:38:51 +0000 From: Simon Ross Message-ID: <8911080749.aa12548@mintaka.lcs.mit.edu> Does anyone have any advice or experience with converting a program in Scheme to CommonLisp (in this case Texas Instruments Scheme and Vax Commonlisp)? If there is some nifty program out there that could do the job? Any help appreciated - we have deadline of Nov 27th but assistance after that date will be gratefully received. Simon Ross Department of Computer Science University College London London WC1E 6BT JANET: sross@uk.ac.ucl.cs ARPA : sross@cs.ucl.ac.uk UUCP : ...ukc!ucl-cs!sross UUCP : mcvax!ukc!ucl!cs!sross BITNET/EARN: sross%uk.ac.ucl.cs@ukacrl.bitnet  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Nov 89 14:01:28 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05293; 7 Nov 89 13:54 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA01430; Tue, 7 Nov 89 13:41:17 EST 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: 7 Nov 89 16:34:01 GMT From: Zane Thomas Organization: Pacer Corp., Bothell, WA Subject: WANTED: fools source Message-Id: <249@pacer.UUCP> References: <1989Nov1.110346.13013@rpi.edu> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu Can anyone make the source for fools scheme available for uucp???  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Nov 89 11:31:39 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03984; 7 Nov 89 11:24 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA28379; Tue, 7 Nov 89 10:52:31 EST 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: 7 Nov 89 10:28:57 GMT From: eagle!ncastellano@bloom-beacon.mit.edu Subject: Re: xscheme, cons-stream, macros Message-Id: <3304@eagle.wesleyan.edu> References: <3258@eagle.wesleyan.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <3258@eagle.wesleyan.edu>, I write: > I've run into a problem in XSCHEME...since cons-stream is defined as a macro, > it cannot be passed to higher-order procedures. The solution I'm using at the > moment is I added to my XSCHEME.INI right after the macro definition: > > (define cons-stream (lambda (a b) (cons-stream a b))) > > This seems to work, but there must be a better solution. Any ideas? > > thanks, > nick > OK...I figured out why I can't do this. I'm new to this, pay me no mind... nick  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Nov 89 22:33:41 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa19622; 3 Nov 89 22:28 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA07724; Fri, 3 Nov 89 21:32:42 EST 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: 3 Nov 89 15:45:23 GMT From: Roommate of Lord Greystoke Organization: U of Wisconsin-Madison, State Hygiene Lab Subject: Personal to Blake McNeill (email seems flakey) Message-Id: <454@uwslh.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I apologize to the rest of the net for doing this, but my email connection to Blake seems kind of flakey. Blake, I sent you an email letter several days ago to make sure that the path from me to you was OK. I have not received a reply yet, which seems kind of strange (although it is possible that a mailer in between us is playing around with the letter for awhile). Please send me email indicating whether or not you got my reply. I do not want to send out large files without a reliable path. Also, if you have ftp capabilities, we might me able to work something out with ftp over the network (much faster). .oO Chris Oo. -- Christopher Lishka ...!{rutgers|ucbvax|...}!uwvax!uwslh!lishka Wisconsin State Lab of Hygiene lishka%uwslh.uucp@cs.wisc.edu Data Processing Section (608)262-4485 lishka@uwslh.uucp "What a waste it is to lose one's mind -- or not to have a mind at all. How true that is." -- V.P. Dan Quayle, garbling the United Negro College Fund slogan in an address to the group (from Newsweek, May 22nd, 1989)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Nov 89 21:34:01 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa25715; 1 Nov 89 21:23 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA05759; Wed, 1 Nov 89 20:53:00 EST 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: 2 Nov 89 01:01:39 GMT From: CUNIXB.CC.COLUMBIA.EDU! MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Organization: The Internet Subject: sub Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu sub _____________________________________________________________________________ |Internet: yk4@cunixb.cc.columbia.edu |||||||The Korean from Hong Kong.|||||| |Bitnet : yk4@cunixc ||||||||||||||||||||||||||||||||||||||| |UUCP : rutgers!columbia!cunixc!yk4 ||||||||||...Apple IIGS user...|||||||| |_______________________________________|||||||||||||||||||||||||||||||||||||||  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Nov 89 20:17:43 EST Received: from cunixb.cc.columbia.edu by mintaka.lcs.mit.edu id aa22658; 1 Nov 89 20:02 EST Received: by cunixb.cc.columbia.edu (4.0/SMI-4.0) id AA26284; Wed, 1 Nov 89 20:01:40 EST Sender: Yong Su Kim Date: Wed, 1 Nov 89 20:01:39 EST From: "Yong Su Kim"@cunixb.cc.columbia.edu Reply-To: Yong Su Kim To: scheme@mc.lcs.mit.edu Subject: sub Message-Id: sub _____________________________________________________________________________ |Internet: yk4@cunixb.cc.columbia.edu |||||||The Korean from Hong Kong.|||||| |Bitnet : yk4@cunixc ||||||||||||||||||||||||||||||||||||||| |UUCP : rutgers!columbia!cunixc!yk4 ||||||||||...Apple IIGS user...|||||||| |_______________________________________|||||||||||||||||||||||||||||||||||||||  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Nov 89 07:57:26 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa16505; 1 Nov 89 7:53 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA22598; Wed, 1 Nov 89 07:22:30 EST 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: 1 Nov 89 11:59:06 GMT From: Torbjorn Naslund Organization: CIS Dept, Univ of Linkoping, Sweden Subject: CFP: Workshop PLILP 90 Message-Id: <1415@majestix.ida.liu.se> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu CALL FOR PAPERS Workshop on Programming Language Implementation and Logic Programming 20-22 August 1990 - Linkoping, Sweden The aim of the workshop is to explore new concepts, methods and techniques relevant for implementation of all kinds of programming languages, whether algorithmic or declarative. The intention is to bring together researchers from the fields of algorithmic programming languages, logic programming, functional programming and object-oriented programming. The topics include, but are not restricted to: - static analysis - code generation - executable specification, implementation of declarative concepts - compiler specification and construction - program transformation - programming environments - amalgamation of algorithmic, functional, object-oriented and logic programming Program Committee M. Bruynooghe, Katholieke Univ., Leuven, Belgium S. Debray, Univ. of Arizona, Tucson, USA P. Deransart, INRIA, Rocquencourt, France (program chairman) P. Franchi Zannettacci, Univ. of Nice, France H. Ganzinger, Univ. of Dortmund, FRG S. Haridi, SICS, Stockholm, Sweden N.D. Jones, Univ. of Copenhagen, Denmark F. Kluzniak, Univ. of Bristol, UK/Univ. of Warsaw, Poland V. Kotov, Academy of Science, Novosibirsk, USSR B. Lang, INRIA, Rocquencourt, France G. Levi, Univ. of Pisa, Italy G. Lindstrom, Univ. of Utah, Salt Lake City, USA J. Maluszynski, Linkoping Univ., Sweden (program co-chairman) J. Penjam, Academy of Science, Tallin, USSR M. Sassa, Univ. of Tsukuba, Japan P. Szeredi, Univ. of Bristol, UK/Univ. of Budapest, Hungary M. Wirsing, Univ. of Passau, FRG Papers must be written and presented in English and must not exceed 5000 words. Submit five copies of the manuscript by 1 April 1990 to Torbjorn Naslund - PLILP 90 Dept. of Computer and Information Science Linkoping University S-581 83 Linkoping Sweden If possible the submission should be accompanied by a 100 word abstract sent by e-mail to plilp@ida.liu.se. Authors will be notified of acceptance/rejection by 1 June 1990 by e-mail (if available). Camera-ready copy will be due 30 June 1990.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Nov 89 07:30:36 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa29179; 1 Nov 89 7:25 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA22215; Wed, 1 Nov 89 07:02:10 EST 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: 1 Nov 89 07:46:44 GMT From: Don Hopkins Organization: U of Maryland, Dept. of Computer Science, Human Computer Interaction Lab Subject: Re: Elk on SUN4 Message-Id: <20484@mimsy.umd.edu> References: <8909170005.aa07281@mintaka.lcs.mit.edu>, <8910120121.AA03621@car.utah.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Patches for ELK on the SPARC. This was my first sparc program, so it could be stupid in places, but it seems to work. Any and all bugs are my fault, and anything that works is due to help from from Mark Weiser, John Gilmore, and Mitch Bradley's kick-ass Sun-4 Forth system. Some times it seems to try to allocate huge amounts of memory, and runs out of stack space. I haven't tracked this bug down yet, but please let me know if you do. -Don Hopkins (don@brillig.umd.edu) * Changed files: ** Makefile: Put the following definitions in the top level Makefile. I changed the GENERIC and the SCHEME_DIR definitions to do the quoting differently, because it was confusing the SunOS 3.2 compiler. SCHEME_DIR= /f/net/scm/scm GENERIC= char * MACHTYPE= sparc # vax 68k 386 sparc DIR= -DDEF_LOAD_DIR=\\\"$(SCHEME_DIR)\\\" GEN= -DGENERIC=\"$(GENERIC)\" CFLAGS= $(INC) $(DIR) $(GEN) -O4 # SunOS 4.0 LDFLAGS= -x # 4.n BSD ** src/config.h: Right before the end of the #ifdef sun section, add the following: # ifdef sparc /* This is outside of this .h file cause the sun 3 3.2 preprocesser barfs on pragma, even if it's ifdef'ed out. */ # include "sparc.h" # endif I found I had to change the heap size to get the test programs to work (I doubled it from 512 to 1024): #define HEAP_SIZE 1024 /* in KBytes */ * New files: ** src/sparc.h: Required because SunOS 3.2 cpp barfs on "#pragma". Enclosed. ** src/stack.s.sparc: Implements stack manipulation code on sparc. Enclosed. ** src/alloca.s.sparc: Just an empty file. (Not enclosed. Buy me a beer, and I'll be happy to supply you with a uuencoded compressed tar file with a hand-made empty file that will work very well for this purpose.) * Instructions: Apply the changes to "Makefile" and "src/config.h". Put the files "src/sparc.h" and "src/stack.s.sparc" in place. Make an empty file, "src/alloca.s.sparc" (unless you'd rather buy me a beer). Type "make" in the top level directory. * Files: ** src/sparc.h #include extern int saveenv(), jmpenv(); #pragma unknown_control_flow(saveenv,jmpenv) ** src/stack.s.sparc /* int stksize(); */ .globl _stksize .globl _Special _stksize: set _stkbase,%o1 ld [%o1],%o1 mov %sp,%o0 sub %o1,%o0,%o0 retl add %o0,256,%o0 /* int saveenv(char* envbuf); */ .globl _saveenv _saveenv: save %sp,-96,%sp /* new window */ /* i0: char *envbuf */ t 0x3 /* ST_FLUSH_WINDOWS trap */ st %i7,[%i0+4] /* saved PC */ mov %y,%l0 st %l0,[%i0+8] /* Y register */ #ifdef notdef /* Illegal instruction. This doesn't seem to be necessary... */ mov %psr,%l0 st %l0,[%i0+12] /* PSR register */ #endif st %sp,[%i0+16] /* SP register */ st %fp,[%i0+20] /* FP register */ st %g1,[%i0+40] /* save globals */ st %g2,[%i0+44] st %g3,[%i0+48] st %g4,[%i0+52] st %g5,[%i0+56] st %g6,[%i0+60] st %g7,[%i0+64] mov %sp,%l0 /* %l0 source */ add %i0,128,%l1 /* %l1 dest */ set _stkbase,%l2 /* %l2 limit */ ld [%l2],%l2 rep1: /* copy stack to buf */ ld [%l0],%l3 st %l3,[%l1] inc 4,%l1 cmp %l0,%l2 bleu rep1 inc 4,%l0 sub %l1,%l0,%l1 /* %l1 relocation offset */ st %l1,[%i0] /* store at front of buffer */ set _Special,%i0 /* return value */ ld [%i0],%i0 ret restore /* dead jmpenv(const char* envbuf, int retcode); */ .globl _jmpenv _jmpenv: save %sp,-96,%sp /* new window */ /* i0: char *envbuf */ /* i1: int retcode */ t 0x3 /* ST_FLUSH_WINDOWS trap */ ld [%i0+16],%l1 /* l1: SP register */ mov %l1,%sp add %i0,128,%l0 /* %l0: source */ /* %l1: dest */ set _stkbase,%l2 /* %l2: limit */ ld [%l2],%l2 rep2: /* copy buf to stack */ ld [%l0],%l3 st %l3,[%l1] inc 4,%l1 cmp %l1,%l2 bleu rep2 inc 4,%l0 ld [%i0+40],%g1 ld [%i0+44],%g2 ld [%i0+48],%g3 ld [%i0+52],%g4 ld [%i0+56],%g5 ld [%i0+60],%g6 ld [%i0+64],%g6 ld [%i0+20],%fp #ifdef notdef ld [%i0+12],%l0 /* Illegal instruction. This doesn't seem to be necessary... */ mov %l0,%psr #endif ld [%i0+8],%l0 mov %l0,%y ld [%i0+4],%i7 nop /* ??? */ mov %i1,%i0 ret restore  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Nov 89 06:59:58 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa00756; 1 Nov 89 6:52 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA21525; Wed, 1 Nov 89 06:26:16 EST 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: 1 Nov 89 11:03:46 GMT From: Jeffrey Putnam Organization: The Museum of Differential Geometry Subject: Re: Elk on SUN4 Message-Id: <1989Nov1.110346.13013@rpi.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Has anyone tried porting ELK to DOS (ick)? I've tried compiling the C files and they seem to compile ok, but I have no idea what to do with the assembler. Anyone out there who actually likes these chips and their machine language that has fiddled them? I know, even compiling may not be enough - then you need to fit it into memory, but it would be interesting to at least compile it and try. BTW I tried compiling the recently announced fools lisp in Turbo C. It refused absolutely to compile because of C macros like #define xx(a,b,c) {a,b,c} #define yy(a,b,c} {a,b,c} xx(yy(1,2,3),4,5) -- jeff putnam -- I should have been a pair of ragged claws jefu@pawl.rpi.edu -- Scuttling across the floors of silent seas. /* One semester to Phinish! (I hope) */  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Oct 89 01:34:19 EDT Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa06569; 29 Oct 89 1:26 EDT Received: from linus.mitre.org by life.ai.mit.edu (4.0/AI-4.10) id AA02489; Fri, 27 Oct 89 11:43:04 EDT Return-Path: Received: from huxley.mitre.org by linus.mitre.org (5.59/RCF-3S) id AA00927; Fri, 27 Oct 89 11:41:12 EDT Posted-Date: Fri, 27 Oct 89 11:41:03 EDT Received: by huxley.mitre.org (4.0/RCF-4C) id AA02879; Fri, 27 Oct 89 11:41:05 EDT From: ramsdell@linus.mitre.org Message-Id: <8910271541.AA02879@huxley.mitre.org> To: scheme@life.ai.mit.edu Subject: SchemeTeX Date: Fri, 27 Oct 89 11:41:03 EDT I got so many requests for SchemeTeX I decided to send it to the news group. Since my last message, I modified the Scheme source to SchemeTeX so that it contains no TAB characters for you Mac users. Please update to this version even if you recently received a version by mail from me. John #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create the files: # README # Makefile # astyped.sty # schemeTeX.l # st.sh # st.scm # st.tex # reader.st # This archive created: Fri Oct 27 11:35:30 1989 export PATH; PATH=/bin:$PATH if test -f 'README' then echo shar: will not over-write existing file "'README'" else cat << \SHAR_EOF > 'README' @(#)README 1.1 89/10/25 SchemeTeX---Simple support for literate programming in Lisp. SchemeTeX is a Unix filter that translates schemeTeX source into LaTeX source. Originally developed for the Scheme dialect of Lisp, it can easily be used with most other dialects. Installation: 1) Processes the file "st.tex" with LaTeX and read that one page document. 2) Decide if you plan to use your Lisp system's standard LOAD procedure or a modified one. I recommend you start by using your Lisp system's LOAD, which means all text lines must begin with ";". 3) Assuming you do use the standard LOAD, edit "st.sh" so that it contains the correct extension, i.e. ".scm", ".lisp", or ".clisp". Otherwise do not modify "st.sh". 4) Edit "Makefile" to reflect the correct destination of the executables(DEST) and the correct destination of the style file(TEXDEST). 5) The command "make install" installs schemeTeX. 6) If you plan to modify your Lisp system's standard LOAD, follow the model given in "reader.st", a reader of schemeTeX source for the R4RS dialect of Scheme. SHAR_EOF fi # end of overwriting check if test -f 'Makefile' then echo shar: will not over-write existing file "'Makefile'" else cat << \SHAR_EOF > 'Makefile' # schemeTeX Makefile @(#)Makefile 1.4 89/10/25. SRCS = README Makefile astyped.sty schemeTeX.l st.sh\ st.scm st.tex reader.st CMDS = st schemeTeX DOCS = st.dvi reader.dvi TEXSTY = astyped.sty #DEST = /usr/local/bin DEST = $(HOME)/bin #TEXDEST = /usr/local/lib/tex/inputs TEXDEST = $(HOME)/doc/inputs # Generic rules .SUFFIXES: .dvi .tex .st .st.dvi: make $*.tex && make $*.dvi .st.tex: st $* .tex.dvi: latex $* # Generic commands. all: $(CMDS) doc: $(DOCS) $(CMDS) install: $(CMDS) $(TEXSTY) mv $(CMDS) $(DEST) cp $(TEXSTY) $(TEXDEST) clean: -rm $(CMDS) dist: schemeTeX.sh # Specific commands. schemeTeX: schemeTeX.l lex -t $? > schemeTeX.c cc -O -o $@ schemeTeX.c -ll rm schemeTeX.c st: st.sh cp $? $@ chmod +x $@ schemeTeX.sh: $(SRCS) shar $(SRCS) > $@ SHAR_EOF fi # end of overwriting check if test -f 'astyped.sty' then echo shar: will not over-write existing file "'astyped.sty'" else cat << \SHAR_EOF > 'astyped.sty' %%%%%%%%%%%%%%%%%%%%%% @(#)astyped.sty 1.3 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % ASTYPED DOCUMENT-STYLE OPTION - released 88/06/30 % for LaTeX version 2.09 % Based on Leslie Lamport's verbatim environment in latex.tex. % Defines the `astyped' environment, which is like the `verbatim' % environment except most of the special characters have their usual meanings. % Space, ^K, and ^A are the only specials changed. \def\astyped{\trivlist \item[]\if@minipage\else\vskip\parskip\fi \leftskip\@totalleftmargin\rightskip\z@ \parindent\z@\parfillskip\@flushglue\parskip\z@ \@tempswafalse \def\par{\if@tempswa\hbox{}\fi\@tempswatrue\@@par} \obeylines \tt \catcode``=13 \@noligs \let\do\@makeother \do\ \do\^^K\do\^^A \frenchspacing\@vobeyspaces} \let\endastyped=\endtrivlist % Used inside astyped environments for normal formatting of a line. % I wish I could give space its normal catcode within \notastyped. \def\notastyped#1{\mbox{\rm #1}} SHAR_EOF fi # end of overwriting check if test -f 'schemeTeX.l' then echo shar: will not over-write existing file "'schemeTeX.l'" else cat << \SHAR_EOF > 'schemeTeX.l' %{ /* schemeTeX -- Scheme to TeX. John D. Ramsdell. * Simple support for literate programming in Scheme. * Usage: schemeTeX < {Scheme TeX file} > {TeX file} */ #if !defined lint static char ID[] = "@(#)schemeTeX.l 1.3 88/06/30"; static char copyright[] = "Copyright 1988 by The MITRE Corporation."; /* Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies. The MITRE Corporation makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. */ #endif /* SchemeTeX defines a new source file format in which source lines are divided into text and code. Lines of code start with a line beginning with '(', and continue until the line that contains the matching ')'. The text lines remain, and they are treated as comments. If the first character of a text line is ';', it is stripped from the output. This is provided for those who want to use an unmodified version of their Scheme system's LOAD. When producing a document, both the text lines and the code lines are copied into the document source file, but the code lines are surrounded by a pair of formatting commands, as is comments beginning with ';' within code lines. SchemeTeX is currently set up for use with LaTeX. */ /* Define STRIP if you want to remove all comments in a Scheme TeX file. */ /* Modify the following for use with something other than LaTeX. Also see tex_verbatim_echo. */ #define BEGIN_COMMENT "\\notastyped{" #define BEGIN_CODE "\\begin{astyped}" #define END_CODE "\\end{astyped}" #define TEX_ECHO tex_verbatim_echo(yytext, stdout) /* Lex is used for identifying code in an Scheme TeX file. */ int parens; /* Used to balance parenthesis. */ /* All input occurs in the following routines so that TAB characters can be expanded. TeX treats TAB characters as a space--not what is wanted. */ #undef getc() #define getc(STREAM) expanding_getc(STREAM) int spaces = 0; /* Spaces left to print a TAB. */ int column = 0; /* Current input column. */ int expanding_getc(stream) FILE *stream; { int c; if (spaces > 0) { spaces--; return ' '; } switch (c = fgetc(stream)) { case '\t': spaces = 8 - (7&column); column += spaces; return expanding_getc(stream); case '\n': column = 0; return c; default: column++; return c; } } %} %% #\\\( { #if defined STRIP ECHO; #else TEX_ECHO; #endif } #\\\) { #if defined STRIP ECHO; #else TEX_ECHO; #endif } \( { ECHO; parens++; } \) { ECHO; parens--; if (parens == 0) { /* End of code. */ char c; /* Check that nothing follows. */ while ((c = input()) == ' ') output(c); if (c == '\000') return 0; /* EOF */ if (c != '\n' && c != ';') return -1; unput(c); } } \"[^"]*\" { if ((yyleng > 1) && (yytext[yyleng-2] == '\\')) yymore(); else #if defined STRIP ECHO; #else TEX_ECHO; #endif } ;[^\n]*$ { #if defined STRIP ; #else fputs(BEGIN_COMMENT, stdout); ECHO; fputs("}", stdout); #endif } \n { ECHO; if (parens <= 0) return 0; } . { #if defined STRIP ECHO; #else TEX_ECHO; #endif } %% fatal (s) char *s; { fprintf(stderr, "On line %d, %s\n", yylineno, s); exit(1); } tex_verbatim_echo (s, f) char *s; FILE *f; { for (; *s != '\000'; s++) switch (*s) { case '\\': case '{': case '}': case '$': case '&': case '#': case '^': case '_': case '%': case '~': fputs("\\verb-", f); putc(*s, f); putc('-', f); break; default: putc(*s, f); } } main() { char c; do { /* TeX mode and saw newline */ c = input(); if (c == '(') { /* TeX mode changed to code mode. */ unput(c); #if !defined STRIP fputs(BEGIN_CODE,stdout); putc('\n', stdout); #endif do { /* Copy out code using yylex. */ parens = 0; if (0 != yylex()) fatal("Bad code section."); if (parens != 0) fatal("Premature EOF."); c = input(); unput(c); /* Repeat when there is code */ } while (c == '('); /* immediately after copied code. */ #if !defined STRIP fputs(END_CODE, stdout); putc('\n', stdout); #endif } else { /* Found a text line. */ if (c == ';') c = input(); /* For those who want to use bare load. */ while (c != '\n') { if (c == '\000') exit(0); /* EOF. */ #if !defined STRIP output(c); #endif c = input(); } #if !defined STRIP output(c); #endif } } while (1); } SHAR_EOF fi # end of overwriting check if test -f 'st.sh' then echo shar: will not over-write existing file "'st.sh'" else cat << \SHAR_EOF > 'st.sh' #! /bin/sh # schemeTeX @(#)st.sh 1.3 88/06/30 EXT=.st DIR=`dirname $1` BASE=`basename $1 ${EXT}` case $# in 0) schemeTeX ;; 1) schemeTeX < ${DIR}/${BASE}${EXT} > ${DIR}/${BASE}.tex ;; 2) schemeTeX < $1 > $2 ;; *) echo "usage: $0 file-name"; exit 1;; esac SHAR_EOF fi # end of overwriting check if test -f 'st.scm' then echo shar: will not over-write existing file "'st.scm'" else cat << \SHAR_EOF > 'st.scm' ;;; @(#)st.scm 1.2 89/10/27 ;;; SchemeTeX --- Simple support for literate programming in Scheme. ;;; October 1989, John D. Ramsdell. ;;; ;;; Copyright 1989 by The MITRE Corporation. ;;; Permission to use, copy, modify, and distribute this ;;; software and its documentation for any purpose and without ;;; fee is hereby granted, provided that the above copyright ;;; notice appear in all copies. The MITRE Corporation ;;; makes no representations about the suitability of this ;;; software for any purpose. It is provided "as is" without ;;; express or implied warranty. ;;; ;;; SchemeTeX ;;; defines a new source file format in which source lines are divided ;;; into text and code. Lines of code start with a line beginning with ;;; '(', and continue until the line that contains the matching ')'. The ;;; text lines remain, and they are treated as comments. When producing ;;; a document, both the text lines and the code lines are copied into ;;; the document source file, but the code lines are surrounded by a pair ;;; of formatting commands. The formatting commands are in begin-code ;;; and end-code. SchemeTeX is currently set up for use with LaTeX. ;;; ;;; Exports: tangle and weave. ;;; (tangle st-file scheme-file) Makes scheme file from schemeTeX source. ;;; (weave st-file tex-file) Makes LaTeX file from schemeTeX source. (define (tangle st-filename scheme-filename) ; => scheme-filename or false. (if (call-with-input-file st-filename (lambda (st-port) (call-with-output-file scheme-filename (lambda (scheme-port) (tangle-port st-port scheme-port))))) scheme-filename (begin ; Put a call to error here. (display "tangle failed.") (newline) '#f))) (define (weave st-filename tex-filename) ; => tex-filename or false. (if (call-with-input-file st-filename (lambda (st-port) (call-with-output-file tex-filename (lambda (tex-port) (weave-port st-port tex-port))))) tex-filename (begin ; Put a call to error here. (display "weave failed.") (newline) '#f))) (define (tangle-port st-port scheme-port) ; => false on failure. (letrec ((tex-mode-and-saw-newline ; Decide if input is code (lambda () (let ((ch (peek-char st-port))) ; or tex source. (cond ((eof-object? ch) '#t) ((char=? ch #\() (scheme-mode)) (else (tex-mode-within-a-line)))))) (tex-mode-within-a-line ; Strip comments. (lambda () (let ((ch (read-char st-port))) (cond ((eof-object? ch) '#t) ((char=? ch #\newline) (tex-mode-and-saw-newline)) (else (tex-mode-within-a-line)))))) (scheme-mode ; This routine should use (lambda () (write (read st-port) scheme-port) (newline scheme-port) ; read-refusing-eof if (tex-mode-within-a-line)))) ; available. (tex-mode-and-saw-newline))) (define begin-code "\\begin{astyped}") ; TeX code surrounding (define end-code "\\end{astyped}") ; code and comments (define begin-comment "\\notastyped{") ; within code. (define (weave-port st-port tex-port) (let ((spaces 0) ; Used in get-char and get-line during (hpos 0) ; the expansion of tabs into spaces. (ch-buf '#f)) ; One char buffer. (letrec ((get-char (lambda () ; Get-char expands tabs into spaces, (cond (ch-buf ; and implements a one character (let ((ch ch-buf)) ; buffer. (set! ch-buf '#f) ch)) ((> spaces 0) (set! spaces (- spaces 1)) #\space) (else (let ((ch (read-char st-port))) (cond ((eof-object? ch) ch) ((char=? ch #\tab) ; Expand tabs here. (set! spaces (- 8 (modulo hpos 8))) (set! hpos (+ hpos spaces)) (get-char)) ((char=? ch #\newline) (set! hpos 0) ch) (else (set! hpos (+ hpos 1)) ch))))))) (unget-char (lambda (ch) (set! ch-buf ch))) (copy-line-saw-eof (lambda () (let ((ch (get-char))) (cond ((eof-object? ch) '#t) ((char=? ch #\newline) '#f) (else (write-char ch tex-port) (copy-line-saw-eof)))))) (tex-write-char (lambda (ch) ; Write to TeX file (if (or (char=? ch #\\) ; escaping TeX's special (char=? ch #\{) ; characters. (char=? ch #\}) (char=? ch #\$) (char=? ch #\&) (char=? ch #\#) (char=? ch #\^) (char=? ch #\_) (char=? ch #\%) (char=? ch #\~)) (begin (display "\\verb-" tex-port) (write-char ch tex-port) (write-char #\- tex-port)) (write-char ch tex-port)))) ;; TeX mode (tex-mode-and-saw-newline ; State at which it is (lambda () ; decided whether to go (let ((ch (get-char))) ; into Scheme code mode (cond ((eof-object? ch) '#t) ; or stay in TeX mode. ((char=? ch #\() (scheme-mode)) (else ;; Strip leading semicolon for those who ;; want to use regular load. (if (not (char=? ch #\;)) (write-char ch tex-port)) (if (char=? ch #\newline) (tex-mode-and-saw-newline) (tex-mode-within-a-line))))))) (tex-mode-within-a-line ; Copy out TeX line. (lambda () (let ((saw-eof (copy-line-saw-eof))) (newline tex-port) (or saw-eof (tex-mode-and-saw-newline))))) ;; Scheme mode (scheme-mode ; Change from TeX mode (lambda () ; to scheme code mode. (display begin-code tex-port) (newline tex-port) (write-char #\( tex-port) (sexpr 1))) (sexpr ; parens is used to watch (lambda (parens) ; for the closing paren (let ((ch (get-char))) ; used to detect the end (cond ((eof-object? ch) '#f) ; of scheme code mode. ((char=? ch #\;) (copy-comment-within-sexpr parens)) (else (sexpr-write-char parens ch)))))) (copy-comment-within-sexpr (lambda (parens) ; Handle comment. (display begin-comment tex-port) (write-char #\; tex-port) (let ((saw-eof (copy-line-saw-eof))) (write-char #\} tex-port) (newline tex-port) (and (not saw-eof) (sexpr parens))))) (sexpr-write-char (lambda (parens ch) ; Write a char and (tex-write-char ch) ; figure out what to (cond ((char=? ch #\() ; do next. (sexpr (+ parens 1))) ((char=? ch #\)) (if (= 1 parens) ; Done reading sexpr. (scheme-mode-after-sexpr) (sexpr (- parens 1)))) ((char=? ch #\") (copy-out-string parens)) ((char=? ch #\#) ; Worrying about #\( and #\). (maybe-char-syntax parens)) (else (sexpr parens))))) (copy-out-string (lambda (parens) (let ((ch (get-char))) (and (not (eof-object? ch)) (begin (tex-write-char ch) (cond ((char=? ch #\\) (let ((ch (get-char))) (and (not (eof-object? ch)) (begin (tex-write-char ch) (copy-out-string parens))))) ((char=? ch #\") (sexpr parens)) (else (copy-out-string parens)))))))) (maybe-char-syntax ; What out for (lambda (parens) ; #\( and #\). (let ((ch (get-char))) (cond ((eof-object? ch) '#f) ((char=? ch #\\) (tex-write-char ch) (let ((ch (get-char))) (and (not (eof-object? ch)) (begin (tex-write-char ch) (sexpr parens))))) (else (unget-char st-port) (sexpr parens)))))) (scheme-mode-after-sexpr (lambda () (let ((ch (get-char))) (cond ((eof-object? ch) '#t) ((char=? ch #\;) (copy-comment-after-sexpr)) ((char=? ch #\newline) (newline tex-port) (scheme-mode-merge)) ((char=? ch #\space) (tex-write-char ch) (scheme-mode-after-sexpr)) (else '#f))))) ; Call to error should go here. (copy-comment-after-sexpr (lambda () ; Handle trailing comment. (display begin-comment tex-port) (write-char #\; tex-port) (let ((saw-eof (copy-line-saw-eof))) (write-char #\} tex-port) (newline tex-port) (and (not saw-eof) (scheme-mode-merge))))) (scheme-mode-merge ; Don't change mode if next (lambda () ; line is code. (let ((ch (get-char))) (cond ((eof-object? ch) '#t) ((char=? ch #\() ; Stay in scheme mode. (write-char ch tex-port) (sexpr 1)) (else ; Enter tex mode. (display end-code tex-port) (newline tex-port) (write-char ch tex-port) (if (char=? ch #\newline) (tex-mode-and-saw-newline) (tex-mode-within-a-line)))))))) (tex-mode-and-saw-newline)))) SHAR_EOF fi # end of overwriting check if test -f 'st.tex' then echo shar: will not over-write existing file "'st.tex'" else cat << \SHAR_EOF > 'st.tex' \documentstyle[proc]{article} % @(#)st.tex 1.4 89/10/25 \title{Scheme\TeX{}} \author{John D. Ramsdell} \date{ 89/10/25 } \begin{document} \maketitle Scheme\TeX{} provides simple support for literate programming in any dialect of Lisp. Originally created for use with Scheme, it defines a new source file format which may be used to produce \LaTeX{} input or Lisp code. Scheme\TeX{} source lines are divided into text and code. Lines of code start with a line beginning with ``('', and continue until the line containing the matching ``)''. The remaining lines are text lines, and they are treated as comments. When producing a \LaTeX{} document, both the text lines and the code lines are copied into the document source file, but the code lines are surrounded by a pair of formatting commands (\verb-\begin{astyped}- and \verb-\end{astyped}-). This \LaTeX{} environment formats the code as written, in typewriter font. A Lisp comment within a code line is formatted in an \verb-\mbox- in Roman font. A Scheme\TeX{} style command should include the \verb-astyped- style option, so that the \verb-astyped- environment is available. An example: \begin{center} \verb-\documentstyle[astyped]{article}- \end{center} Scheme\TeX{} was designed under the constraint that code lines must be unmodified Lisp code, and text lines must be unmodified \LaTeX{} code. Text editors with support for Lisp and \LaTeX{}, such as Emacs, may be used for Scheme\TeX{} code much as they are used for Lisp code and \LaTeX{} code. For those who prefer not to modify the reader used by their Lisp system's loader and compiler, the rule that text lines must be unmodified \LaTeX{} code has been relaxed. Text lines that begin with ``;'' are copied without the initial ``;''. \section*{Usage in Scheme} The file \verb;st.scm; contains programs used to obtain code or \LaTeX{} from a Scheme\TeX{} source file. The Scheme expression \begin{center} \verb;(TANGLE; {\it st-filespec Scheme-filespec\/}{\tt )} \end{center} creates Scheme source from a Scheme\TeX{} file, and the expression \begin{center} \verb;(WEAVE; {\it st-filespec \LaTeX{}-filespec\/}{\tt )} \end{center} creates LaTeX{} source. The file \verb-reader.st- contains a Scheme\TeX{} reader in R$^4$R Scheme. Use that reader with your Scheme system's loader and compiler to avoid running \verb-TANGLE- and creating a temporary file. \section*{Usage in a Unix shell} The extension for Scheme\TeX{} files is ``\verb;.st;''. A \LaTeX{} file is produced from Scheme\TeX{} source using the Unix shell command \begin{center} {\tt st} {\it file-name} \end{center} It will produce a file with the ``\verb;.tex;'' extension. The obvious make file is in Figure~\ref{makefile}. \begin{figure} \begin{verbatim} .SUFFIXES: .dvi .tex .st .st.dvi: make $*.tex && make $*.dvi .st.tex: st $* .tex.dvi: latex $* \end{verbatim} \caption{A Scheme\TeX{} Makefile}\label{makefile} \end{figure} \end{document} SHAR_EOF fi # end of overwriting check if test -f 'reader.st' then echo shar: will not over-write existing file "'reader.st'" else cat << \SHAR_EOF > 'reader.st' \documentstyle[astyped]{article} % @(#)reader.st 1.4 89/10/25 \title{{\tt read-st}} \author{John D. Ramsdell} \date{ 89/10/25 } \begin{document} \maketitle \verb;read-st; converts Scheme\TeX{} representations of Scheme objects into the objects themselves much as \verb;read; does. (define (read-st . rest) ; Returns what \verb;read; returns. (let ((port (if (pair? rest) ; \verb;read-st; arguments are (car rest) ; the same as \verb;read;'s. (current-input-port)))) (letrec ((text-mode-and-saw-newline ; Lines of a Scheme\TeX{} file (lambda () ; beginning with ``{\tt(}'', (let ((ch (peek-char port))) ; start a code section. (cond ((eof-object? ch) ch) ((char=? ch #\() ; If code section, then use (got-code (read port))) ; \verb;read; to get code, (else ; else skip this line as it (text-mode-within-a-line)))))) ; is a comment. (text-mode-within-a-line (lambda () ; Ignore comments. (let ((ch (read-char port))) (cond ((eof-object? ch) ch) ((char=? ch #\newline) (text-mode-and-saw-newline)) (else (text-mode-within-a-line)))))) (got-code (lambda (code) ; Ignore the remainder of the (let ((ch (read-char port))) ; last code line and return (cond ((eof-object? ch) code) ; the results of \verb;read;. ((char=? ch #\newline) code) (else (got-code code))))))) (text-mode-and-saw-newline) ; Start by looking ))) ; for a code line. \end{document} SHAR_EOF fi # end of overwriting check # End of shell archive exit 0  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Oct 89 11:58:12 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa01974; 27 Oct 89 11:52 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA20896; Fri, 27 Oct 89 11:34:27 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: 27 Oct 89 15:28:38 GMT From: Yong Su Kim Subject: GSScheme docs Message-Id: <8910271528.AA23672@cunixb.cc.columbia.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I have managed to download the GSScheme but the documentation file seems to have been corrupted since I cannot unpack it with Shrinkit yet BINSCII returns no errors. If anyone has a copy of the docs, I would be very grateful if they could e-mail a compressed copy. Thanks. _____________________________________________________________________________ |Internet: yk4@cunixb.cc.columbia.edu |||||||The Korean from Hong Kong.|||||| |Bitnet : yk4@cunixc ||||||||||||||||||||||||||||||||||||||| |UUCP : rutgers!columbia!cunixc!yk4 ||||||||||...Apple IIGS user...|||||||| |_______________________________________|||||||||||||||||||||||||||||||||||||||  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Oct 89 14:49:59 EDT Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24191; 25 Oct 89 14:46 EDT Received: from linus.mitre.org by life.ai.mit.edu (4.0/AI-4.10) id AA00893; Wed, 25 Oct 89 14:46:18 EDT Return-Path: Received: from huxley.mitre.org by linus.mitre.org (5.59/RCF-3S) id AA14818; Wed, 25 Oct 89 14:44:57 EDT Posted-Date: Wed, 25 Oct 89 14:44:54 EDT Received: by huxley.mitre.org (4.0/RCF-4C) id AA01480; Wed, 25 Oct 89 14:44:55 EDT From: ramsdell@linus.mitre.org Message-Id: <8910251844.AA01480@huxley.mitre.org> To: scheme@life.ai.mit.edu Cc: ramsdell@linus.mitre.org Subject: Revised SchemeTeX Available Date: Wed, 25 Oct 89 14:44:54 EDT SchemeTeX---Simple support for literate programming in Lisp. A new version of SchemeTeX is available. SchemeTeX provides simple support for literate programming in any dialect of Lisp. Originally created for use with Scheme, it defines a new source file format which may be used to produce LaTeX input or Lisp code. The distribution contains a Unix filter that translates SchemeTeX into LaTeX which is independent of the Lisp dialect used. All SchemeTeX comment lines can begin with ";", so that any Lisp reader can read the source. SchemeTeX source lines are divided into text and code. Lines of code start with a line beginning with ``('', and continue until the line containing the matching ``)''. The remaining lines are text lines, and they are treated as comments. The new version of SchemeTeX contains three programs written in R4R Scheme. WEAVE translates SchemeTeX to LaTeX. TANGLE translates SchemeTeX to Scheme. READ-ST is a SchemeTeX reader. You can use it to load SchemeTeX source directly. These programs replace the previous ones written in T. You can obtain the distribution by sending mail to ramsdell@mitre.org. SchemeTeX is no longer available via anonymous FTP. John  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Oct 89 10:18:22 EDT Received: from helios.northeastern.edu by mintaka.lcs.mit.edu id aa01619; 25 Oct 89 10:10 EDT Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu id aa21781; 25 Oct 89 15:06 EST Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.6) id AA13215; Wed, 25 Oct 89 10:06:21 EDT Date: Wed, 25 Oct 89 10:06:21 EDT From: Mitchell Wand Message-Id: <8910251406.AA13215@corwin.CCS.Northeastern.EDU> To: scheme@mc.lcs.mit.edu Subject: Literate Programming in Scheme Here is a tiny ``literate programming'' package for Scheme. The basic idea is that code sections are surrounded by |\ttcode| and |\endtt|. Then there are a couple of filters: one to rip through a text and install the code in indicated files, one just to filter the code out of a text, and a bit of Chez scheme code to load through the appropriate filter. There's not much here, but I've used it for writing a book chapter, and it seemed to help a whole lot. This all ought to run in LaTeX, except that it doesn't seem possible to hack the |verbatim| environment to produce a |code| environment. If anyone knows how to do this, please let me know! Mitchell Wand College of Computer Science Northeastern University 360 Huntington Avenue #161CN Boston, MA 02115 CSNet: wand@corwin.ccs.northeastern.edu #!/bin/sh # This is a shell archive. # Run the file through sh to extract its contents. # shar: Shell Archiver # Run the following text with /bin/sh to create: # lit-to-code # lit-to-code.tex # literate.tex # lit-load.tex # lit-to-scheme.tex # tt.tex # This archive created: Thu Oct 19 09:35:04 1989 echo shar: extracting lit-to-code '(162 characters)' sed 's/^XX//' << \SHAR_EOF > lit-to-code XXawk ' XX/^%filename/ {print "filename:", $2; filename = $2;} XX/^\\endtt/ {q = 0} XX(q==1) {print filename "< " $0; XX print $0 > filename;} XX/^\\ttcode/ {q=1} XX' $* XX XX XX XX SHAR_EOF if test 162 -ne "`wc -c lit-to-code`" then echo shar: error transmitting lit-to-code '(should have been 162 characters)' fi echo shar: extracting lit-to-code.tex '(732 characters)' sed 's/^XX//' << \SHAR_EOF > lit-to-code.tex XX\input sections XX\input tt XX\def\ttcode{\ttnoi} XX%filename lit-to-code.a XX XX\sectionbegin {\tt lit-to-code} XX XXThis is a small {\tt awk} program to filter ``literate'' programs and install XXthem in files. It uses the keyword {\tt \%filename} to mark the filename. XXCode to be installed in the file is delimited by {\tt \\ttcode} and XX{\tt \\endtt} (which must start at the beginning of the line). Code between XXthese markers is installed in the indicated file. XX XXThe target file may be changed by just inserting a new {\tt XX\%filename} command. The shell script will also take multiple source files as XXarguments. XX XX\ttcode XXawk ' XX/^%filename/ {filename = $2} XX/^\\endtt/ {q = 0} XX(q==1) {print $0 > filename} XX/^\\ttcode/ {q=1} XX' $* XX\endtt XX XX XX SHAR_EOF if test 732 -ne "`wc -c lit-to-code.tex`" then echo shar: error transmitting lit-to-code.tex '(should have been 732 characters)' fi echo shar: extracting literate.tex '(231 characters)' sed 's/^XX//' << \SHAR_EOF > literate.tex XX%%% macros for a tiny ``literate programming'' environment for Scheme. Code XX%%% is delimited by \ttcode and \endtt (must be at beginning of line). XX XX\input tt XX\define\ttcode{\ttnoi} XX XX%%% this is hardly worth a file, n'est-ce pas? SHAR_EOF if test 231 -ne "`wc -c literate.tex`" then echo shar: error transmitting literate.tex '(should have been 231 characters)' fi echo shar: extracting lit-load.tex '(591 characters)' sed 's/^XX//' << \SHAR_EOF > lit-load.tex XX\input sections XX\input tt XX\def\ttcode{\ttnoi} XX%filename lit-load.s XX XX\sectionbegin {\tt lit-load} XX XXThis is a small loader to load a ``literate'' scheme program. It merely takes XXthe input file and pipes it through a small filter program called {\tt XXlit-to-scheme}. XX XX\ttcode XX(define lit-load XX (lambda (filename) XX (let* ((process-string XX (string-append "lit-to-scheme " filename)) XX (process (process process-string)) XX (port (car process))) XX (let loop () XX (let ((inp (read port))) XX (if (eof-object? inp) XX '() XX (begin XX (eval inp) XX (loop)))))))) XX\endtt XX XX\bye SHAR_EOF if test 591 -ne "`wc -c lit-load.tex`" then echo shar: error transmitting lit-load.tex '(should have been 591 characters)' fi echo shar: extracting lit-to-scheme.tex '(438 characters)' sed 's/^XX//' << \SHAR_EOF > lit-to-scheme.tex XX\input sections XX\input tt XX%filename lit-to-scheme XX XX\sectionbegin {\tt lit-to-scheme} XX XXThis is a small filter program for use with {\tt lit-load}. It just pipes the XXsegments between instances of {\tt \\ttcode} and {\tt \\endtt} to the standard XXoutput. It takes a single filename as as argument. XX XX{\bf Bug:} It will not do anything clever about protections. XX XX\ttcode XXawk ' XX/^\\endtt/ {q = 0} XX(q==1) XX/^\\ttcode/ {q=1} XX' $1 XX\endtt XX XX\bye SHAR_EOF if test 438 -ne "`wc -c lit-to-scheme.tex`" then echo shar: error transmitting lit-to-scheme.tex '(should have been 438 characters)' fi echo shar: extracting tt.tex '(2005 characters)' sed 's/^XX//' << \SHAR_EOF > tt.tex XX\catcode`\^^I=\active % tab = \space XX\def^^I{\space} XX XX\def\begindisplay{\obeylines\startdisplay} XX{\obeylines\gdef\startdisplay#1 XX {\catcode`|^^M=5$$#1\halign\bgroup\indent##\hfil&&\qquad##\hfil\cr}} XX\def\enddisplay{\crcr\egroup$$} XX XX\catcode`\|=\active XX{\obeylines\gdef|{\ttverbatim\let^^M=\ \let|=\endgroup}} XX XX\chardef\other=12 XX\def\fullttverbatim{\begingroup \catcode`\\=\other \catcode`\{=\other XX \def^^I{\ \ \ \ \ \ \ \ } % tab = 8 spaces XX \catcode`\}=\other \catcode`\$=\other \catcode`\&=\other XX \catcode`\#=\other \catcode`\%=\other \catcode`\~=\other XX \catcode`\_=\other \catcode`\^=\other XX \obeyspaces \obeylines \tt} XX{\obeyspaces\gdef {\ }} % \obeyspaces now gives \ , not \space XX XX\def\semittverbatim{\begingroup \catcode`\\=\other XX \def^^I{\ \ \ \ \ \ \ \ } % tab = 8 spaces XX \catcode`\&=\other XX \catcode`\#=\other \catcode`\%=\other \catcode`\~=\other XX \obeyspaces \obeylines \tt} XX XX\let\ttverbatim=\fullttverbatim XX XX\def\endline{\leavevmode\endgraf} XX XX\def\begintt{$$\let\par=\endline \ttverbatim \parskip=0pt XX \catcode`\|=0 \rightskip=-5pc \ttfinish} XX{\catcode`\|=0 |catcode`|\=\other % | is temporary escape character XX |obeylines % end of line is active XX |gdef|ttfinish#1^^M#2\endtt{#1|vbox{#2}|endgroup$$}} XX XX\def\tti{\let\par=\endline \ttverbatim \parskip=0pt XX \catcode`\|=0 \rightskip=-5pc \ttifinish} XX XX\def\ttnos{\let\par=\endline \ttverbatim \parskip=0pt XX \catcode`\|=0 \rightskip=-5pc \ttnosfinish} XX XX\def\beginttnoi{\begintt\parindent=0pt} XX\def\ttnosi{\ttnos\parindent=0pt} XX\def\ttnoi{\tti\parindent=0pt} XX XX\def\ttctr{$$\let\par=\cr \ttverbatim \parskip=0pt XX \catcode`\|=0 \rightskip=-5pc \ttctrfinish} XX XX{\catcode`\|=0 |catcode`|\=\other % | is temporary escape character XX |obeylines % end of line is active XX |gdef|ttifinish#1\endtt{|endline #1 |endline|endgroup|noindent} % XX |gdef|ttnosfinish#1\endtt{#1|endgroup|noindent} % XX |gdef|ttctrfinish#1^^M#2\endtt{#1|vbox{|halign{##|hfil|cr#2}}|endgroup$$}} XX XX\def\semitt{\let\ttverbatim=\semittverbatim} XX XX\def\ttcode{\ttnoi} SHAR_EOF if test 2005 -ne "`wc -c tt.tex`" then echo shar: error transmitting tt.tex '(should have been 2005 characters)' fi # End of shell archive exit 0  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Oct 89 19:28:32 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa01062; 24 Oct 89 19:21 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA20713; Tue, 24 Oct 89 19:17:40 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: 24 Oct 89 16:40:15 GMT From: Patrick Logan Organization: engr Subject: Re: Looking for "literate programming" tools for Scheme/LISP Message-Id: <1989Oct24.164015.6041@mentor.com> References: <1989Oct16.153232.19051@mentor.com>, Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article sra@ecs.soton.ac.uk (Stephen Adams) writes: >> I think that a full-blown WEB equivalent for lisp is a waste of time. >> Much of what WEB offers is there to circumvent weaknesses in the host >> language. Many lisp programs are declaration order independent (or >> should be if you want to compile them). If you want to refine >> something later functions and macros can be used. I came to the same conclusion. A couple of people also mailed similar solutions. What I'm planning on now is to create my own with texinfo. This way, there'll be a printed document, executable code, and an "info" version of the document. It should facilitate a nice Scheme library. If anyone wants the finished product, send mail and I'll hold on to your address. I'm not even going to guess at when I'll complete it. Thanks very much to everyone who responded. I appreciate it. -- Patrick Logan | ...!{decwrl,sequent,tessi}!mntgfx!plogan Mentor Graphics Corporation | plogan@pdx.MENTOR.COM Beaverton, Oregon |  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Oct 89 17:25:10 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa00299; 24 Oct 89 17:21 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA18502; Tue, 24 Oct 89 17:10:18 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: 24 Oct 89 20:26:53 GMT From: Paul Wilson Organization: Stanford University Subject: Nisp compatibility package for standard Scheme? Message-Id: <12635@polya.Stanford.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Is there a version of Nisp for standard (e.g., Revised^3 Report) Scheme? (Nisp is a version of Lisp -- developed at Yale for AI programming -- for which there are several compatibility packages to make other Lisps look like Nisp. I believe this includes Common Lisp and T, but I'm looking for something that will allow me to run some serious programs in a highly-instrumented but unextended Scheme system.) Thanks prematurely, Paul Paul R. Wilson Software Systems Laboratory lab ph.: (312) 996-9216 U. of Illin. at C. EECS Dept. (M/C 154) wilson@carcoar.stanford.edu Box 4348 Chicago,IL 60680  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Oct 89 10:59:01 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa06505; 24 Oct 89 10:51 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA12270; Tue, 24 Oct 89 10:28:39 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: 23 Oct 89 22:23:24 GMT From: Eric Blossom Organization: Ye Olde Salt Mines Subject: Re: C Scheme sources wanted Message-Id: <380001@hpwrce.HP.COM> References: <5898@portia.Stanford.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu This info is from the info-cscheme@zurich.ai.mit.edu mailing list: |We've tested installation on the following machines, and would greatly |appreciate any efforts that you could make getting things running on |any other machines: | | HP 9000 series 300 and 800 running HP-UX | Sun3 running SunOS | Vax running Ultrix | DS3100 running Ultrix | |This release may be obtained by anonymous ftp to "zurich.ai.mit.edu" |(internet address 18.26.0.176), from the directory "pub/scheme-7.0/". |See the README file in that directory for further directions. |  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Oct 89 19:29:26 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20193; 23 Oct 89 19:22 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA00291; Mon, 23 Oct 89 18:52:43 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: 22 Oct 89 19:58:35 GMT From: Stephen Adams Organization: Southampton University Computer Science Subject: Re: Looking for "literate programming" tools for Scheme/LISP Message-Id: References: <1989Oct16.153232.19051@mentor.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <1989Oct16.153232.19051@mentor.com> plogan@mentor.com (Patrick Logan) writes: (1) Does someone have WEB or equivalent set up for Scheme or another LISP? (2) Do you know of any references to "literate programming" applied to Scheme/LISP? I have a solution for Common lisp. The same idea should work for most lisps. I use the following code to read in latex files that have bits of lisp code embedded in `lisp' or `program' environments. It works by redefining the readtable so that 1. Latex comments are treated as comments in lisp .to treat latex comment as lisp comments. 2. Anything starting with a `\' is a comment until the start of a `lisp' or `program' environment. It has been used under Sun Common Lisp (Lucid) and Kyoto Common Lisp. I think that a full-blown WEB equivalent for lisp is a waste of time. Much of what WEB offers is there to circumvent weaknesses in the host language. Many lisp programs are declaration order independent (or should be if you want to compile them). If you want to refine something later functions and macros can be used. Cheers ---- cut here, put it in latex.lisp ----- ; ; Literate programming for common lisp and latex ; ; Only those bits of program in a `lisp' or `program' environment ; are loaded. This is achieved as follows: ; ; 1. `%' (the tex comment character) is make to act exactly like lisp's ; semicolon ; 2. `\' is make to skip text until a line containing only ; \begin{lisp} ; or \begin{program} ; The skipped text including the \begin bit is treated as a comment. ; 3. Devious code make the character dispatch read macro (#\... ) ; still work. I hope. ; ; ; Re-building this file: ; On both lucid and kcl there are problems with overwriting the readtable ; while loading. It only seems to work properly if the functions are ; compiled and the readtable is updated in one operation. But that is ; a one-legged-chicken theory. ; ; To compile: ; Start lucid or KCL. (if you are already in lisp, exit & restart it) ; (compile-file "latex.lsp") ; either (bye) [in kcl] or (quit) [in lucid] ; Dont be tempted to load latex.{o,lbin} after compiling. It doesnt work. ; ; At any other time it is reasonable to load the compiled stuff. ; (eval-when (compile) (proclaim '(optimize (safety 2)))) (defvar *default-hash-backslash-function* (get-dispatch-macro-character #\# #\\)) (defun install-latex-readtable () (labels ( (backslash-mystifier (stream ch &aux line) (unread-char ch stream) (setf line (read-line stream nil nil t)) (loop ;;;; (format t "---> ~S~%" line) (if (equal (peek-char nil stream nil 'T) 'T) (return (values))) (setf line (read-line stream nil nil t)) (if (or (null line) (string-equal line "\\begin{lisp}") (string-equal line "\\begin{program}") ) (return (values))) ) ) (grotty-new-character-reader (stream ch prefix &aux name (result nil)) (unwind-protect (progn (set-syntax-from-char #\\ #\\) (set-dispatch-macro-character #\# #\\ *default-hash-backslash-function*) (unread-char ch stream) (setf name (read stream nil nil nil)) (setf prefix (if prefix (format nil "~D" prefix) "")) (setf result (read-from-string (format nil "#~A\\~A" prefix name))) ) (progn (set-macro-character #\\ #'backslash-mystifier nil) (set-dispatch-macro-character #\# #\\ #'grotty-new-character-reader) result)) )) (let ((newtable (copy-readtable nil))) (set-syntax-from-char #\% #\; newtable newtable) (set-macro-character #\\ #'backslash-mystifier nil newtable) (set-dispatch-macro-character #\# #\\ #'grotty-new-character-reader newtable) (setf *readtable* newtable) ))) (eval-when (load) (install-latex-readtable)) -- Stephen Adams S.Adams@uk.ac.soton.ecs (JANET) Computer Science S.Adams@ecs.soton.ac.uk (Bitnet) Southampton S09 5NH, UK S.Adams@sot-ecs.uucp (uucp)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Oct 89 18:57:53 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa29744; 23 Oct 89 18:51 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA29908; Mon, 23 Oct 89 18:40:19 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: 23 Oct 89 17:55:45 GMT From: Jeff Dalton Organization: AIAI, University of Edinburgh, Scotland Subject: Re: Looking for "literate programming" tools for Scheme/LISP Message-Id: <1271@skye.ed.ac.uk> References: <1989Oct16.153232.19051@mentor.com>, Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu A while ago, I prepared some really simple tools for processing files that were both documents and source code. The basic idea is to use a verbatim environment (with *no* interesting processing) for code, but under a different name. Consequently, it will work for any programming language, but will never do any fancy formatting. The idea is this: You write a ".ptex" file. Two "projections" are defined for such files: one converts a ".ptex" file to a ".tex" file; the other converts it to a ".lsp" (or whateverP file. Two new environments are defined: program -- converted directly to verbatim for ".tex"; contents outout as-is for ".lsp". program-only -- like program, but discarded for ".tex" All that's required are two AWK scripts and some entries in a Makefile: -------------------- Makefile entries -------------------- .SUFFIXES: .ptex .tex .lisp .lsp .ptex.tex: ; awk -f totex < $*.ptex > $*.tex .ptex.lsp: ; awk -f tocode < $*.ptex > $*.lsp .ptex.lisp: ; awk -f tocode < $*.ptex > $*.lisp -------------------- totex script -------------------- BEGIN { state="copy" } state == "copy" && /^ *\\begin{program}/ {print "\\begin{verbatim}"; break} state == "copy" && /^ *\\end{program}/ {print "\\end{verbatim}"; break} state == "copy" && /^ *\\begin{program-only}/ {state="ignore"; break} state == "copy" {print; break} /^ *\\end{program-only}/ {state = "copy"; break} -------------------- tocode script -------------------- BEGIN { state="ignore" } state == "copy" && /^ *\\end{program}/ {state = "ignore"; printf "\n"; break} state == "copy" && /^ *\\end{program-only}/ {state = "ignore"; printf "\n"; break} state == "copy" {print; break} /^ *\\begin{program-only}/ {state = "copy"; break} /^ *\\begin{program}/ {state = "copy"; break} -------------------- end -------------------- Simple, but can be effective. Jeff Dalton, JANET: J.Dalton@uk.ac.ed AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Oct 89 23:34:50 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa00505; 22 Oct 89 17:15 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA05767; Sun, 22 Oct 89 12:28:11 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: 22 Oct 89 01:31:00 GMT From: Andy Purshottam Organization: University of California, Berkeley Subject: port of ELK to 3b2 or PC/RT Message-Id: <18649@pasteur.Berkeley.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Hi, anyone have a port of ELK to the 3b2 or the RT/PC? Thanks, Andy  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Oct 89 13:38:00 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02595; 21 Oct 89 13:32 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA19681; Fri, 20 Oct 89 18:47:06 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: 20 Oct 89 16:26:16 GMT From: eagle!ncastellano@bloom-beacon.mit.edu Subject: ST xscheme binaries wanted Message-Id: <2365@eagle.wesleyan.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Hello... WANTED: Binaries for David Betz's XSCHEME on an Atari 520 | 1040 ST. Please point me to an FTP source or mail me uuencoded / arced binaries directly. Also wanted: ST binaries for ADVSYS by same author. I have all the docs/support/sources for each, just need the binaries. (I don't have a reasonable C compiler.) Thanks in advance, NCASTELLANO@EAGLE.WESLEYAN.EDU -- _=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_- i believe in coyotes in time as an abstract explain the change the difference between what you want and what you need there's the key your adventure for today _-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_R.-E._M.=_-_= Nicholas Steven Castellano (dd) | ........................... | Disclaimer: I am ncastellano@eagle.wesleyan.edu | ncastellano@wesleyan.bitnet | irresponsible. _=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Oct 89 13:29:43 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02154; 21 Oct 89 13:20 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA11561; Sat, 21 Oct 89 10:46:34 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: 20 Oct 89 05:48:04 GMT From: John Lewis Organization: NYIT Computer Graphics Laboratory, Old Westbury, NY Subject: xscheme,xlisp save/restore bug? Message-Id: <363@nyit.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu There is a major bug in the xscheme (0.17) save/restore functions. Since this code was adapted directly from Xlisp2.0, i'm wondering whether there is a similar problem in Xlisp (& a fix, hopefully), or why it isn't a problem. i'm not sure i can characterize the bug very well (if i could i would be on the way to fixing it), but my guess is that it involves the interaction of garbage collection with restore- the image is restored in node-array order, so collectable nodes may be restored before the symbols they are attached to; garbage collection can be triggered by creation of nodes during the restore, and this GC can incorrectly free some of the partially restored image. In any case, (restore) does not work (see recent mail on comp.lang.scheme). Thanks for any advice jp lewis@nyit computer graphics lab 516 686 7644(evenings)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Oct 89 17:52:58 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa25790; 19 Oct 89 17:46 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA19103; Thu, 19 Oct 89 12:59:04 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: 19 Oct 89 15:00:12 GMT From: Kellom{ki Pertti Organization: Tampere Univ. of Technology, Finland. Subject: Re: Looking for "literate programming" tools for Scheme/LISP Message-Id: References: <1989Oct16.153232.19051@mentor.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu On 16 Oct 89 15:32:32 GMT,plogan@mentor.com (Patrick Logan) said: Patrick> (1) Does someone have WEB or equivalent set up for Scheme or another LISP? Patrick> (2) Do you know of any references to "literate programming" applied to Patrick> Scheme/LISP? I asked the same thing a while back, and this is the answer I got. I've used SchemeTex quite a bit and I'm quite satisfied with it. If you are interested, I've hacked it a bit to be used with GNU Texinfo, and also cooked up some Emacs lisp support for dealing with SchemeTex files. It is not at all ready to be released, but if you want to take look at it, I'll be happy to share. dorab> From: dorab@CS.UCLA.EDU (Dorab Patel) ... dorab> i dont know if this helps, but .... dorab> From: John D. Ramsdell dorab> Date: Mon, 18 Apr 88 09:22:39 EDT dorab> Message-Id: <8804181322.AA11583@darwin.sun.uucp> dorab> To: scheme@mc.lcs.mit.edu, texhax@score.stanford.edu dorab> Subject: SchemeTeX---Simple support for literate programming in Lisp. dorab> SchemeTeX provides simple support for literate programming in any dorab> dialect of Lisp on Unix. Originally created for use with Scheme, it dorab> defines a new source file format which may be used to produce LaTeX dorab> code or Lisp code. Roughly speaking, LaTeX formats Lisp code in a dorab> verbatum-like environment, and it formats Lisp comments in an ordinary dorab> environment. dorab> SchemeTeX is available via anonymous FTP from linus (192.12.120.51) in dorab> the shar file named "pub/schemeTeX.sh". Included is an operating dorab> system independent version for the T dialect of Lisp. dorab> John -- Pertti Kellom\"aki (TeX format) # These opinions are mine, Tampere Univ. of TeXnology # ALL MINE ! Software Systems Lab # (but go ahead and use them, if you like)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Oct 89 00:39:03 EDT Received: from arpa.att.com by mintaka.lcs.mit.edu id aa13033; 19 Oct 89 0:32 EDT From: ihlpn!rre@att.att.com Date: Wed, 18 Oct 89 18:54 CDT To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu Message-ID: <8910190032.aa13033@mintaka.lcs.mit.edu> Yo, hey. I'm currently working on my graduate project back in Ann Arbor, Michigan. If you need to urgenly (well, not *that* urgently) reach me, I'll be checking email at roger@caen.engin.umich.edu I'll be back on Monday, October 23, 1989. Hasta luego! Roger Espinosa  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Oct 89 21:22:06 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa10640; 18 Oct 89 21:18 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA18549; Wed, 18 Oct 89 08:20:49 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: 16 Oct 89 15:32:32 GMT From: Patrick Logan Organization: engr Subject: Looking for "literate programming" tools for Scheme/LISP Message-Id: <1989Oct16.153232.19051@mentor.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu (1) Does someone have WEB or equivalent set up for Scheme or another LISP? (2) Do you know of any references to "literate programming" applied to Scheme/LISP? Thanks. -- Patrick Logan | ...!{decwrl,sequent,tessi}!mntgfx!plogan Mentor Graphics Corporation | plogan@pdx.MENTOR.COM Beaverton, Oregon |  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Oct 89 20:25:41 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa09870; 18 Oct 89 20:22 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA01167; Wed, 18 Oct 89 20:09:47 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: 18 Oct 89 16:24:00 GMT From: Jonathan Lee Organization: UC Berkeley Experimental Computing Facility (XCF) Subject: A better, free Scheme interpreter :-) Message-Id: <18495@pasteur.Berkeley.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Fools' lisp is a scheme interpreter that follows, in most cases, the R3RS standard. Although it is still under development, I think it is useful as a light lisp (though it probably still has some bugs!). One of the main features of this implementation is extensiblity. This is achieved through a simple object oriented approach and a simple primitive interface. The code seems to be fairly portable: it works on a Sun 3 (running either SunOS 3.x and 4.0.x), a DECstation 3100, a Sequent Symmetry, and a VAX (running either Ultrix 3.x or BSD). You can get your own free copy from scam.berkeley.edu (128.132.138.1) in the ~ftp/src/local directory via anonymous ftp. The file is fools.tar.Z. I welcome any suggestions or bug reports. Thank you, Jonathan Lee jonathan@scheme.berkeley.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Oct 89 18:24:59 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa08402; 18 Oct 89 18:18 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA29044; Wed, 18 Oct 89 17:59:38 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: 17 Oct 89 18:02:05 GMT From: Robert Kelley Organization: Sequent Computer Systems, Inc Subject: T3 on Sequent Symmetry or any i386? Message-Id: <23403@sequent.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I was wondering if anyone has T working on a 386. Please reply via e-mail. Thanks Robert J. Kelley -- ...!uunet!sequent!rjk  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Oct 89 12:27:36 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03566; 18 Oct 89 12:21 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA21662; Wed, 18 Oct 89 10:58:28 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: 17 Oct 89 18:02:05 GMT From: Robert Kelley Organization: Sequent Computer Systems, Inc Subject: T3 on Sequent Symmetry or any i386? Message-Id: <23403@sequent.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I was wondering if anyone has T working on a 386. Please reply via e-mail. Thanks Robert J. Kelley -- ...!uunet!sequent!rjk  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Oct 89 14:50:23 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa13213; 17 Oct 89 14:47 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA29415; Tue, 17 Oct 89 14:21:26 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: 16 Oct 89 22:22:02 GMT From: Darrell Long Organization: University of California, Santa Cruz Subject: C Scheme sources wanted Message-Id: <5898@portia.Stanford.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I'm looking for the sources to C Scheme. I'd like to use it in a class I will be teaching next quarter. I have FTP capability. Pointers to the source will be appreciated. Thanks, DL  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Oct 89 07:56:42 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa08406; 17 Oct 89 7:49 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA22371; Tue, 17 Oct 89 07:30:32 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: 16 Oct 89 23:40:23 GMT From: Brian of ASTD-CP Organization: Jet Propulsion Laboratory, Pasadena, CA Subject: Re: xscheme bug Message-Id: <1922@jato.Jpl.Nasa.Gov> References: <362@nyit.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <362@nyit.UUCP> zilla@nyit.UUCP (John Lewis) writes: || there is a bug in xscheme0.17's (restore) function. the bug is || that garbage collection should be inhibited during the main part of || xlirestore(). This is because the image is restored in node-array || order, rather than obarray order. For example, strings may be || restored before the symbols which refer to them, and a gc before || the corresponding symbol is restored will remove the string (set || its type to FREE). routines called in xlirestore (e.g. || getvspace()) can trigger gc. || A fix is simply to set a flag inhibiting gc during the main part || of xlirestore. dbetz confirmed that this is a reasonable fix. I'm glad someone brought this up again. This bug has been around since 0.16, and a similar fix has been proposed before. This fix D O E S N O T W O R K at least, it does not work if you are restoring a work space requiring more than a single vector segment (your workspace might be this big if you have a lot of symbols). The irony of the situation is that the bigger your workspace, the more likely you are to need save/restore. My analysis of the problem is incomplete, but my preliminary indications are as follows: * gc(), as a side effect, through gc_protect() and compact(), causes the attributes of "vscurrent", the current vector segment, to be set correctly, and it also sets the values of two global variables, "vfree" and "vtop". * If you inhibit garbage collection during restore, those variables are not set correctly. * Thus, on the first attempt to get more vector memory on behalf of xlirestore(), xscheme errors with the message "insufficient vector space". Really, there is more memory available. In fact, malloc just returned a pointer to it. But "vfree" and "vtop" are left pointing to the prior FULL segment, so when xscheme tries to use the new vector memory, it finds it is STILL full. I don't have a good solution to this. I don't even have a kludge work around (yet). Anyone care to take a crack at solving this one? . . . Brian Beckman . . . . . . . . . brian@topaz.jpl.nasa.gov. . . . . . JPL Computer Graphics Lab. . . . (818) 397-9207. . . . . . . .  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Oct 89 07:54:50 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa28973; 16 Oct 89 7:18 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA25124; Mon, 16 Oct 89 06:19:11 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: 16 Oct 89 03:10:31 GMT From: John Lewis Organization: NYIT Computer Graphics Laboratory, Old Westbury, NY Subject: xscheme bug Message-Id: <362@nyit.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu there is a bug in xscheme0.17's (restore) function. the bug is that garbage collection should be inhibited during the main part of xlirestore(). This is because the image is restored in node-array order, rather than obarray order. For example, strings may be restored before the symbols which refer to them, and a gc before the corresponding symbol is restored will remove the string (set its type to FREE). routines called in xlirestore (e.g. getvspace()) can trigger gc. A fix is simply to set a flag inhibiting gc during the main part of xlirestore. dbetz confirmed that this is a reasonable fix.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Oct 89 19:48:34 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa08447; 14 Oct 89 19:45 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA25745; Sat, 14 Oct 89 19:38:40 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: 14 Oct 89 20:34:24 GMT From: Controlled by cockatiels Organization: U of Wisconsin-Madison, State Hygiene Lab Subject: Wanted: Documentation for xscheme 0.17 Message-Id: <449@uwslh.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu The title says it all. Does this documentation really exist? If so, could someone send it to me via email? If not, could someone mail me a message saying so? Thanks in advance. .oO Chris Lishka Oo. Christopher Lishka ...!{rutgers|ucbvax|...}!uwvax!uwslh!lishka Wisconsin State Lab of Hygiene lishka%uwslh.uucp@cs.wisc.edu Data Processing Section (608)262-4485 lishka@uwslh.uucp -- Christopher Lishka ...!{rutgers|ucbvax|...}!uwvax!uwslh!lishka Wisconsin State Lab of Hygiene lishka%uwslh.uucp@cs.wisc.edu Data Processing Section (608)262-4485 lishka@uwslh.uucp "What a waste it is to lose one's mind -- or not to have a mind at all. How true that is." -- V.P. Dan Quayle, garbling the United Negro College Fund slogan in an address to the group (from Newsweek, May 22nd, 1989)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Oct 89 17:32:31 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05898; 12 Oct 89 17:27 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA02224; Thu, 12 Oct 89 15:53:21 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: 12 Oct 89 17:55:22 GMT From: Eric Griswold Organization: Frame Technology Corp. San Jose, Calif. Subject: On helping a novice scheme programmer Message-Id: <3591@frame.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Thanks to all who sent me solutions. The fact that they were all identical to my first try at the problem restores my faith in myself and presents me with the nasty task of fixing my scheme interpreter. I wasn't crazy or dense: it was.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Oct 89 21:59:12 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20112; 11 Oct 89 21:46 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA12632; Wed, 11 Oct 89 21:41:19 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: 11 Oct 89 23:09:37 GMT From: Eric Griswold Organization: Frame Technology Corp. San Jose, Calif. Subject: Help a novice scheme programmer Message-Id: <3589@frame.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I am teaching myself Scheme from the Dybvig book. After reading it once through, I am doing the exercises. One near the beginning has me stumped: "A more elegant way to define cadr and cddr than given in this section is to define a procedure that composes two procedures to create a third. Whrite the procedure 'compose', such that (compose proc1 proc2) is the composition of proc1 and proc2 [assuming both take one argument]. Use compose to define cadr and cddr." I give up. Please *MAIL* me a solution (hints and any other pedantic messages don't count as solutions) && I will summarize if appropriate.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Oct 89 21:57:10 EDT Received: from cs.utah.edu by mintaka.lcs.mit.edu id aa19779; 11 Oct 89 21:22 EDT Received: from car.utah.edu by cs.utah.edu (5.61/utah-2.4-cs) id AA18192; Wed, 11 Oct 89 19:21:57 -0600 Received: by car.utah.edu (5.61/utah-2.3-leaf) id AA03621; Wed, 11 Oct 89 19:21:55 -0600 Date: Wed, 11 Oct 89 19:21:55 -0600 From: Harold Carr Message-Id: <8910120121.AA03621@car.utah.edu> To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu In-Reply-To: Automatic Scheme Digestifier's message of 17 SEP 89 00:05:57 EDT <8909170005.aa07281@mintaka.lcs.mit.edu> Subject: Elk on SUN4 Has anyone got ELK running on a Sun 4? Specifically the stack.s file and any CFLAGS and LDFLAGS necessary. alloc.s should not be necessary since it is supplied on sun OS 4.x.x - right? I would appreciate pointers to or mail containing the required changes. Thanks for you help: Harold Carr car@cs.utah.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 10 Oct 89 22:49:48 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa01280; 10 Oct 89 22:43 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA16739; Tue, 10 Oct 89 22:32:43 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: 10 Oct 89 16:29:39 GMT From: Jeff Sparkes Organization: Memorial University of Newfoundland Subject: scheme in C++ Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anybody have a scheme written in C++ usable as an embedded interpreter? I'm currently using Elk, but would much rather be able to use it directly from C++. I'm currently communicating with the scheme by sending/receiving strings. Somebody recently mentioned a scheme in C++ written at UIUC. Anybody know if the code is ftpable/available anywhere, or anything else? Jeff Sparkes jeff1@garfield.mun.edu -- Jeff Sparkes jeff1@garfield.mun.edu || uunet!garfield!jeff1  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 10 Oct 89 11:04:31 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21246; 10 Oct 89 10:58 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA02699; Tue, 10 Oct 89 10:47:32 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: 9 Oct 89 21:44:23 GMT From: John Lewis Organization: NYIT Computer Graphics Laboratory, Old Westbury, NY Subject: xscheme contact Message-Id: <361@nyit.UUCP> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu David Betz, the author of xscheme, is associated with MIPS magazine and *sometimes* answers his mail on the MIPS BBS. The number is 603 882 1599, 1200/2400 baud (not sure about 300), supports Xmodem file transfer protocol (not sure about kermit). The latest (presumably) version of xscheme is also available there (v0.17).  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Oct 89 17:55:13 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03348; 6 Oct 89 17:51 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA18970; Fri, 6 Oct 89 17:37:06 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: 6 Oct 89 20:25:19 GMT From: Ted Dunning Organization: NMSU Computer Science Subject: email contact for xscheme Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu i am busy making some improvements to xscheme, but haven't found an email address for the author, David Michael Betz. does anyone know if he has an email address? or must i rely on hard post and phone? -- ted@nmsu.edu +---------+ | In this | | style | |__10/6___|  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Oct 89 15:06:52 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa13904; 5 Oct 89 15:02 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA16074; Thu, 5 Oct 89 13:07:21 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: 5 Oct 89 14:40:46 GMT From: Hasko Heinecke Organization: University of Dortmund Subject: Re: scheme implementations survey Message-Id: <1659@laura.UUCP> References: <360@nyit.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <360@nyit.UUCP> zilla@nyit.UUCP (John Lewis) writes: > >Several years ago someone posted a very useful summary of scheme >implementations to net.lang.lisp (i think), including contact info, >supported machines, features, price if applicable. > Has there been an update to this survey? If there is, please e-mail it to me containing information of where to get the sources if possible (the sources of the sources :-) ). Thanks in advance. Snail mail: | E mail: Hasko Heinecke | hh@trillian.Informatik.Uni-Dortmund.de <--- prefered Ostenbergstr. 97 | heinecke@frodo.Informatik.Uni-Dortmund.de D-4600 Dortmund 50 |  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Oct 89 14:48:28 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa13636; 5 Oct 89 14:41 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA16986; Thu, 5 Oct 89 13:44:52 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: 5 Oct 89 14:44:09 GMT From: Brad Pierce Organization: UCLA Computer Science Department Subject: (S)ML for the Mac Message-Id: <27741@shemp.CS.UCLA.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anyone know of a Macintosh implemenation of Standard ML? -- Brad  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Oct 89 00:58:39 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa04719; 5 Oct 89 0:54 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA01009; Wed, 4 Oct 89 23:59:03 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: 4 Oct 89 19:52:52 GMT From: mitchell wand Organization: The Internet Subject: Call for Papers: 1990 ACM Conf. on Lisp & Functional Programming Message-Id: <8910041952.AA03514@flora.CCS.Northeastern.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu 1990 ACM Conference on Lisp and Functional Programming Nice, France, June 27--29, 1990 The 1990 ACM Conference on LISP and Functional Programming is the sixth in a series of biennial conferences devoted to the theory, design, and implementation of programming languages and systems related to LISP, functional programming, and symbolic computation. The conference is jointly sponsored by ACM SIGPLAN, SIGACT, and SIGART in cooperation with SIGSAM. Papers presented at the conference must include new ideas or experimental results that have not been previously published. Previous conferences have included papers in the following areas: programming language concepts and facilities; implementation methods; machine architectures; semantic foundations; programming logics; and program development environments. Beyond these areas, authors are strongly encouraged to submit papers that introduce important new topics that are relevant to functional programming and symbolic computation. Authors should submit 11 copies of a technical summary of a prospective conference paper. The length of the summary should not exceed 3,000 words (10 pages double-spaced or typeset 11-point on 16-point spacing). Since the committee expects to receive a large number of submissions, the summary should be organized so that it is easily understood. It is important for the summary to identify what has been accomplished, explain why it is significant, and compare it with previous work. Submissions must be received by DECEMBER 1, 1989. They should include a return postal address and an electronic mail address if it is available. Authors will be notified of the acceptance or rejection of their papers by FEBRUARY 5, 1990. Full versions of the accepted papers must be received in camera-ready form by MARCH 23, 1990. Authors of accepted papers will be required to sign ACM copyright release forms. Proceedings will be distributed at the conference and will later by available for purchase from ACM. The conference will take place at the Acropolis Convention Center, in Nice. Nice is the major city on the French Riviera. It is pleasantly warm in June: daily highs average 78 F (25 C); overnight lows average 58 F (19 C). Nice has a major airport. If you wish to travel before or after the conference, you will easily reach other cities in Europe. Many people go to the French Riviera in summer -- to go to the beach, to play tennis, to hike in the mountains or to gamble in the casinos -- so you should plan ahead. General Chairman Gilles Kahn INRIA Sophia--Antipolis 2004 Route des Lucioles 06565 Valbonne CEDEX FRANCE (33) 93 65 78 01 kahn@mirsa.inria.fr Local Arrangements Chairman Th. Bricheteau INRIA-Rocquencourt B.P. 105 78153 Le Chesnay Cedex FRANCE Program Chairman Mitchell Wand Attn: LFP 90 College of Computer Science 169 Cullinane Hall Northeastern University Boston, MA 02115 (617) 437-3539 wand@corwin.ccs.northeastern.edu Program Committee Hal Abelson, MIT Hans Boehm, Rice University William Clinger, University of Oregon Pierre-Louis Curien, CNRS and Ecole Normale Superieure, Paris John K. Foderaro, Franz, Inc. Christopher T. Haynes, Indiana University Paul Hudak, Yale University Robert Kessler, University of Utah Ken McAloon, Brooklyn College and CUNY Graduate Center Simon L. Peyton Jones, University College, London  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 4 Oct 89 16:12:05 EDT Received: from helios.northeastern.edu by mintaka.lcs.mit.edu id aa09342; 4 Oct 89 15:56 EDT Received: from [129.10.1.150] by helios.northeastern.edu id aa19554; 4 Oct 89 20:55 EST Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.6) id AA12097; Wed, 4 Oct 89 15:55:26 EDT Received: from dara75b. by flora.CCS.Northeastern.EDU (4.0/SMI-3.2+CCS-subsidiary-2.2) id AA03514; Wed, 4 Oct 89 15:52:52 EDT Date: Wed, 4 Oct 89 15:52:52 EDT From: mitchell wand Message-Id: <8910041952.AA03514@flora.CCS.Northeastern.EDU> Received: by dara75b. (4.0/SMI-4.0) id AA06775; Wed, 4 Oct 89 15:52:59 EDT To: theorynt@vm1.nodak.edu, scheme@mc.lcs.mit.edu, fp@yale.edu, types@theory.lcs.mit.edu Subject: Call for Papers: 1990 ACM Conf. on Lisp & Functional Programming Reply-To: wand@corwin.ccs.northeastern.edu, "FOR PAPERS"@flora.ccs.northeastern.edu MMDF-Warning: Parse error in original version of preceding line at helios.northeastern.edu 1990 ACM Conference on Lisp and Functional Programming Nice, France, June 27--29, 1990 The 1990 ACM Conference on LISP and Functional Programming is the sixth in a series of biennial conferences devoted to the theory, design, and implementation of programming languages and systems related to LISP, functional programming, and symbolic computation. The conference is jointly sponsored by ACM SIGPLAN, SIGACT, and SIGART in cooperation with SIGSAM. Papers presented at the conference must include new ideas or experimental results that have not been previously published. Previous conferences have included papers in the following areas: programming language concepts and facilities; implementation methods; machine architectures; semantic foundations; programming logics; and program development environments. Beyond these areas, authors are strongly encouraged to submit papers that introduce important new topics that are relevant to functional programming and symbolic computation. Authors should submit 11 copies of a technical summary of a prospective conference paper. The length of the summary should not exceed 3,000 words (10 pages double-spaced or typeset 11-point on 16-point spacing). Since the committee expects to receive a large number of submissions, the summary should be organized so that it is easily understood. It is important for the summary to identify what has been accomplished, explain why it is significant, and compare it with previous work. Submissions must be received by DECEMBER 1, 1989. They should include a return postal address and an electronic mail address if it is available. Authors will be notified of the acceptance or rejection of their papers by FEBRUARY 5, 1990. Full versions of the accepted papers must be received in camera-ready form by MARCH 23, 1990. Authors of accepted papers will be required to sign ACM copyright release forms. Proceedings will be distributed at the conference and will later by available for purchase from ACM. The conference will take place at the Acropolis Convention Center, in Nice. Nice is the major city on the French Riviera. It is pleasantly warm in June: daily highs average 78 F (25 C); overnight lows average 58 F (19 C). Nice has a major airport. If you wish to travel before or after the conference, you will easily reach other cities in Europe. Many people go to the French Riviera in summer -- to go to the beach, to play tennis, to hike in the mountains or to gamble in the casinos -- so you should plan ahead. General Chairman Gilles Kahn INRIA Sophia--Antipolis 2004 Route des Lucioles 06565 Valbonne CEDEX FRANCE (33) 93 65 78 01 kahn@mirsa.inria.fr Local Arrangements Chairman Th. Bricheteau INRIA-Rocquencourt B.P. 105 78153 Le Chesnay Cedex FRANCE Program Chairman Mitchell Wand Attn: LFP 90 College of Computer Science 169 Cullinane Hall Northeastern University Boston, MA 02115 (617) 437-3539 wand@corwin.ccs.northeastern.edu Program Committee Hal Abelson, MIT Hans Boehm, Rice University William Clinger, University of Oregon Pierre-Louis Curien, CNRS and Ecole Normale Superieure, Paris John K. Foderaro, Franz, Inc. Christopher T. Haynes, Indiana University Paul Hudak, Yale University Robert Kessler, University of Utah Ken McAloon, Brooklyn College and CUNY Graduate Center Simon L. Peyton Jones, University College, London  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Oct 89 19:41:28 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa25332; 3 Oct 89 19:37 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 3 Oct 89 19:20:31 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: 3 Oct 89 22:56:48 GMT From: Ted Dunning Organization: NMSU Computer Science Subject: Re: Parity with conventional programs Message-Id: References: <8910020245.AA06270@solaria.mcs.anl.gov>, <10684@phoenix.Princeton.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <10684@phoenix.Princeton.EDU> markv@phoenix.Princeton.EDU (Mark T Vandewettering) writes: wide variety of problems. An interesting problem that I recently "rediscovered" was to implement Conway's "life" cellular automaton in a functional language. Using program transformations, it is a very interesting problem, with many possible solutions that are interesting to parallelize. could you post something on this? say some code/discussion on how you did it? -- ted@nmsu.edu remember, when extensions and subsets are outlawed, only outlaws will have extensions or subsets  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Oct 89 14:40:06 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20797; 3 Oct 89 14:31 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 3 Oct 89 14:09:05 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: 3 Oct 89 16:54:41 GMT From: Mark T Vandewettering Organization: Princeton University, NJ Subject: Re: Parity with conventional programs Message-Id: <10684@phoenix.Princeton.EDU> References: <8910020245.AA06270@solaria.mcs.anl.gov> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <8910020245.AA06270@solaria.mcs.anl.gov> boyle@ANTARES.MCS.ANL.GOV writes: >It seems to me that one barrier to the wider acceptance of functional >programming methodology, especially by scientists and programmers >interested in applications, is the perception that functional programs >*necessarily* sacrifice efficiency for simplicity, clarity, >adaptability, etc. This is indeed ironic, because it is precisely the qualities of simplicity, and clarity which allow optimizations to take place. It is far easier to reason about the meaning of programs and their correctness in a functional language than it is in more traditional super computer languages such as FORTRAN. >I also believe that the time is ripe to attempt to demonstrate that >this is NOT the case--that one can write in the functional style and >still obtain programs that execute as fast (or faster) and that use as >little storage as do well-written procedural programs on the same >hardware. This thesis has gone along way towards being proven, but as you say, more work could be done. I see two major hindrances against using functional programming in a scientific or industrial setting. 1. There are few good implementations of functional programming environments. While the languages themselves are simple and elegant, often using them is not. Alot of work remains to be done with these. 2. There is a lack of practical experience in developing solutions to problems. Algorithm books are often expressed solely in terms of solutions that utilize side effects, and there are certainly no great stores of subroutines for reuse as there is in FORTRAN. There have been some results which have been encouraging with regards to comparing space/time complexity of functional solutions to those requiring arrays (primarily with sorting) but many open problems remain. A non-tremendously recent SIGPLAN gave a list of several open problems for which efficient (as efficient as traditional languages) solutions were not known to exist for functional programming languages. Most of the problems boiled down to simulating a ram memory, with update and access operations in constant time. A demonstration of how these might be accomplished would be a good start... >Terence Harmer (now at Queens University, Belfast) and I have been >working toward this goal at Argonne over the past year using >automated program transformation techniques. We are within sight of >the goal for several specifications for numerical and non-numerical >problems of practical interest. We express these specifications in >pure Lisp (lambda calculus); some use higher order functions. We >transform them into Fortran or C programs for sequential, vector, >and/or parallel computers. We'd like to hear from others working >along similar lines. The work sounds interesting. One of the major hindrances to overcome for many problem is to find effective alternatives to using arrays, or to demonstrate how "functional arrays" can be effectively used for a wide variety of problems. An interesting problem that I recently "rediscovered" was to implement Conway's "life" cellular automaton in a functional language. Using program transformations, it is a very interesting problem, with many possible solutions that are interesting to parallelize. I think the one big contribution of functional programming will be a practical system for parallelizing programs, and providing a basis for machine scheduling and partitioning of programs that operate at levels which were previously hard to attain. More discussion folks? I think alot could be said here... Let me plug a fun book for a second: "Functional Programming for Loosely-coupled Multiprocessors" Paul Kelly, MIT Press I find Kelly's approach interesting and intuitive, and yet I feel that more practical work needs to be done to demonstrate the applicability of the system. I would also see more solutions to the problems of implicit parallelism, allowing compilers to do task assignment and scheduling. Mark VandeWettering (markv@acm.princeton.edu)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Oct 89 10:37:52 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa17346; 3 Oct 89 10:31 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 3 Oct 89 10:02:46 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: 3 Oct 89 00:41:19 GMT From: John Lewis Organization: NYIT Computer Graphics Laboratory, Old Westbury, NY Subject: scheme implementations survey Message-Id: <360@nyit.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Several years ago someone posted a very useful summary of scheme implementations to net.lang.lisp (i think), including contact info, supported machines, features, price if applicable. Has there been an update to this survey? If not- I am trying to select a semi pd scheme. Does anyone have recommendations or experience with xscheme,cscheme? Does anyone use xscheme? (does it work??) thanks!  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Oct 89 07:33:21 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa15619; 3 Oct 89 7:31 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 3 Oct 89 07:09:59 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: 3 Oct 89 05:49:10 GMT From: "William L. Moran Jr." Organization: A Desperate and Dedicated Crew Subject: Re: Parity with conventional programs Message-Id: <304@archet.UUCP> References: <8910020245.AA06270@solaria.mcs.anl.gov> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Unfortunately, it is (in general) not true that functional programs are as efficient as procedural programs. This is one of the problems with functional programs - not that they are less efficient than programs written in more common languages - but that the proponents of functional programs try to claim that they are not. The other advantages more than outweigh this, and the difference gets less and less every day (and may well eventually be zero). I would agree that a demonstration that functional programs are as efficient in some areas as other programs is a good idea, but do not oversell - in the short run it may help, but in the long run it will only discourage people. Bill -- arpa: moran-william@cs.yale.edu or wlm@ibm.com uucp: uunet!bywater!acheron!archet!wlm or decvax!yale!moran-william ------------------------------------------------------------------------------- An audience of teen-age boys naturally likes the idea of running around with naked women and doing LSD while listening to Hendrix and The Who. The Wall Street Journal 8/17/89  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 2 Oct 89 12:36:12 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02547; 2 Oct 89 12:31 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 2 Oct 89 12:05:14 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: 2 Oct 89 15:28:15 GMT From: Dirk Grunwald Organization: University of Colorado at Boulder Subject: Re: Parity with conventional programs Message-Id: <12289@boulder.Colorado.EDU> References: <8910020245.AA06270@solaria.mcs.anl.gov> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Luddy Harrison at the University of Illinois, CSRD, has a parallelizing and vectorizing scheme compiler. There's a couple of tech reports describing his techniques. It's not functional, but it's certainly interesting. Dirk Grunwald -- Univ. of Colorado at Boulder (grunwald@foobar.colorado.edu)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Oct 89 22:50:23 EDT Received: from MCS.ANL.GOV by mintaka.lcs.mit.edu id aa25518; 1 Oct 89 22:46 EDT Received: from solaria.mcs.anl.gov by antares.mcs.anl.gov (4.0/SMI-DDN) id AA12065; Sun, 1 Oct 89 21:40:31 CDT Received: by solaria.mcs.anl.gov (3.2/GCF-5.2) id AA06270; Sun, 1 Oct 89 21:45:58 CDT Date: Sun, 1 Oct 89 21:45:58 CDT From: boyle@antares.mcs.anl.gov Message-Id: <8910020245.AA06270@solaria.mcs.anl.gov> To: fp@YALE.EDU, scheme@mc.lcs.mit.edu Subject: Parity with conventional programs Cc: boyle@antares.mcs.anl.gov, t.harmer%v1.qub.ac.uk%ukacrl.bitnet@anlvm.ctd.anl.gov It seems to me that one barrier to the wider acceptance of functional programming methodology, especially by scientists and programmers interested in applications, is the perception that functional programs *necessarily* sacrifice efficiency for simplicity, clarity, adaptability, etc. I also believe that the time is ripe to attempt to demonstrate that this is NOT the case--that one can write in the functional style and still obtain programs that execute as fast (or faster) and that use as little storage as do well-written procedural programs on the same hardware. I would call such a demonstration a "demonstration of parity" between functional and conventional programming. I believe that several demonstrations of parity on programs for solving real problems would remove a large barrier to the use of functional programming, and encourage applications scientists and programmers to consider fp on its (obvious) merits. How about some discussion on this topic? Does anyone out there agree or disagree with these sentiments? Is anyone out there working on demonstrations of parity, or better yet, has anyone achieved some? Terence Harmer (now at Queens University, Belfast) and I have been working toward this goal at Argonne over the past year using automated program transformation techniques. We are within sight of the goal for several specifications for numerical and non-numerical problems of practical interest. We express these specifications in pure Lisp (lambda calculus); some use higher order functions. We transform them into Fortran or C programs for sequential, vector, and/or parallel computers. We'd like to hear from others working along similar lines. Jim Boyle boyle@mcs.anl.gov  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Sep 89 19:36:38 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02086; 29 Sep 89 19:30 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 29 Sep 89 19:05:59 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: 29 Sep 89 18:04:48 GMT From: Max Hailperin Organization: Stanford University, Computer Science Dept. Subject: SICP: not hanging onto streams Message-Id: <12044@polya.Stanford.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu This is really a SICP teaching question, not a scheme question, but I bet this list reaches a lot of Structure and Interpretation of Computer Programs instructors. I noticed while teaching the material on streams that the examples are very casual about pointing from the global environment at streams. This (given memoization) results in excessive memory consumption, not unlike in "Printing streams---A supplementary exercise for the instructor" in the Instructor's Manual. For example, to find the 100th integer not divisible by 7, we have (define integers ...) (define no-sevens (filter ... integers)) (nth-stream 100 no-sevens) Wouldn't it be better to write (define (generate-integers) ....) (define (generate-no-sevens) (filter ... (generate-integers))) (nth-stream 100 (generate-no-sevens)) ? Even for implicitly defined streams one can do something similar, e.g. (define (generate-fibs) (define fibs (cons-stream 0 (cons-stream 1 (add-streams (tail fibs) fibs)))) fibs) where the pointer to the whole stream is from an environment frame that itself will stop being pointed at. Of course, it is not the case that you want to do this indiscriminately. As long as the stream generator takes time linear in the amount generated, then there is no harm in regenerating the stream rather than saving it for resuse, in big-O terms. However, there are cases where this wouldn't hold. You have to be careful where to reuse and where not. For examle, the implicit definition of fibs reuseses itself, because this only requires keeping a fixed amount of state (the last two numbers) and reduces the time complexity from exponential to linear. On the other hand, two seperate consumers of fibonacci numbers might well each have calls to generate-fibs. For example, we might write (define (useless n m) (- (nth-stream (* n m) (generate-fibs)) (sum-stream (substream n m (generate-fibs))))) in order to keep the memory consuption fixed. So, enough spouting off, time for the questions: Has anyone else considered teaching this idiom? Is there some problem with it that prevented you from doing so? If not, how did it go? Thanks very much.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Sep 89 11:49:52 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa22659; 29 Sep 89 6:34 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 29 Sep 89 05:55:58 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: 28 Sep 89 21:07:22 GMT From: Dorai Sitaram Organization: Rice University, Houston Subject: Re: Y combinator derivation Message-Id: <1775@brazos.Rice.edu> References: <16800018@uicsrd.csrd.uiuc.edu>, <27390@shemp.CS.UCLA.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <27390@shemp.CS.UCLA.EDU> pierce@lanai.UUCP (Brad Pierce) writes: $ $I think the previous poster was asking for a derivation of the $*applicative-order* Y combinator, not the normal-order as given $here. ``The Little Lisper'' (as someone else mentioned) has a $good presentation, but its complexity points out the price pays $for using an applicative-order language. $ $In normal-order languages, like standard lambda calculus, the $derivation is straightforward. The motivation for the Y-combinator $in lambda calculus is to allow the use of recursive definitions. $Recall that there is no such thing as assignment in lambda calculus, $but that this elegant and mathematically tractable model of $computation is rich enough to support recursion anyway. $ $The standard example goes as follows: $ $ [A quite proper description of normal-order Y deleted.] $ $is the so-called Y-combinator given above. It is easy to verify $the definition, as long as you remember that it is to be $evaluated in normal-order. Finding a fixed-point combinator $is not so easy when using applicative-order evaluation. Please see $the ``Little Lisper''. $ $Maybe it's time to start thinking seriously about whether the $current performance benefits of applicative-order evaluation $is worth the theoretical and human factors price tag. I find your _conclusions_ (ie, not the body of your posting) astounding. The applicative-order Y is not all that prohibitively more complex than the normal-order one. One only has to replace in $> Y = lambda h.(lambda x. h(x x)) $> (lambda x. h(x x)) . both occurrences of (x x) by (lambda z. (x x) z). Note also that the new Y shares the elegance and lack of assignment that you claim for the old Y. Re the current acceptance of applicative-order evaluation in the world's programming languages, I hardly think it can be attributed solely to performance benefits. Applicative-order is _understandable_ in the presence of side-effects in a way that normal-order fails to be. You may protest that assignment-type side-effects should be eliminated from the language, but then things like input and output cannot be totally wished away. Assuming you have a 'let' defined in the usual way in terms of lambda, we have, in a potential normal-order real-life programming language with input/output, among other things, (let ([y (printf "y~n")]) ((lambda (x) t) y)) never printing y at all; (let ([y (printf "y~n")]) (or y y)) printing y twice (assuming printf returns nil); whereas in applicative order, y is just printed once (as expected, IMHO), regardless of the body of the let. --dorai ------------------------------------------------------------------------------- Alles ist richtig, auch das Gegenteil. Nur: zwar ... aber -- das ist nie richtig. --Kurt Tucholsky -------------------------------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Sep 89 18:36:47 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa16366; 28 Sep 89 18:31 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 28 Sep 89 18:07:16 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: 28 Sep 89 19:02:42 GMT From: Paul Stodghill Organization: Cornell Univ. CS Dept, Ithaca NY Subject: Invoking C-Scheme Message-Id: <32609@cornell.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Two questions about MIT C-Scheme, 1) Is the only documentation available that which comes with the distribution? In particular, the documentation for the run-time library appears to be release notes and not a complete document. Also, there are few sections in the reference manual which are blank and which I would like to see. 2) I want some way to have scheme load and execute a file upon startup. How can I do this? I know about the "-dump" option, but from what I understand this just loads a dump and does not evaluate any expresion. Also dump files are huge. I noticed in boot.c a "-fasl" option is mentioned, but it makes some assumptions about the .bin file which I don't know.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Sep 89 13:49:50 EDT Received: from EDDIE.MIT.EDU by mintaka.lcs.mit.edu id aa11775; 28 Sep 89 13:15 EDT Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ; Thu, 28 Sep 89 13:15:41 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 28 Sep 89 12:33:51 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: 28 Sep 89 15:21:46 GMT From: Gary M Pratt Organization: Worcester Polytechnic Institute, Worcester, Mass. Subject: scheme 7.0 manual found Message-Id: <4332@wpi.wpi.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Okay, the scheme 7.0 manual is at FTP site zurich.ai.mit.edu and is located in the directory pub/scheme-7.0. The file is named man.tar.Z. Also located in this directory are many files that are not located at prep.ai.mit.edu. Thanks go out to: atheybey@PTT.LCS.MIT.EDU & ange@hplb.hpl.hp.com Thu Sep 28 06:47:57 1989  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Sep 89 15:50:06 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa26827; 27 Sep 89 15:45 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 27 Sep 89 14:55:24 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: 27 Sep 89 18:39:13 GMT From: Gary M Pratt Organization: Worcester Polytechnic Institute, Worcester, Mass. Subject: scheme 7.0 manual needed Message-Id: <4310@wpi.wpi.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Hello. I'm looking for a FTP site that currently has the /manual sub-directory for the MIT Scheme (dist-7.0) documentation directory. The core.tar.Z file at "prep.ai.mit.edu" does not expand with this directory. Please send e-mail and I'll post back to the newsgroup. Many thanks. Gary.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Sep 89 07:50:05 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20763; 27 Sep 89 7:46 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 27 Sep 89 07:31:16 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: 27 Sep 89 11:14:53 GMT From: Richard O'Keefe Subject: Re: Journal of Functional Programming Message-Id: <2205@munnari.oz.au> References: <8909270321.AA16595@ATHENA.CS.YALE.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <8909270321.AA16595@ATHENA.CS.YALE.EDU>, hudak-paul@YALE.EDU (Paul Hudak) writes: > New journal announcement: ... > Papers on declarative languages that deal with combining > functional and logic languages will also be appropriate. Argh! I am struggling hard to keep up with logic programming, and failing. There are already too many relevant journals that I have a hard time getting hold of. The last thing I need is another hole for papers relating to logic languages to disappear down. I'm not arguing against JFP. But would it be at all possible to come to some arrangement with JLP or NGC to arrange for papers relevant to both logic and functional programming to be published in a logic programming journal _as_well_? If it is not possible to do that, at the very least please ensure that extended abstracts of every JFP paper related to logic programming are published in some logic programming journal (JLP for choice). -- GNUs are more derived than other extant alcelaphines,| Richard A. O'Keefe such as bonteboks, and show up later in the fossil | visiting Melbourne record than less highly derived species. (Eldredge) | ok@munmurra.cs.mu.OZ.au  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Sep 89 03:49:10 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18669; 27 Sep 89 3:45 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 27 Sep 89 03:07:53 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: 27 Sep 89 00:21:33 GMT From: Sean Doran the Younger Organization: Not the Law Society of Upper Canada, Toronto Subject: Free (or very close to it) (nearly?) Common LISP? Message-Id: <1989Sep26.202137.29576@lsuc.on.ca> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anyone in comp.lang.lisp land know of any vaguely Common LISP package available with source for various flavours of UNIX (like v7-with-a-licence or (gack) SysV) or Incredibly Bad Machine PC-Clones or both which is free or very nearly so? What would be perfect would be a Common LISP development system with a real Emacs and an incremental compiler of some nature that comes with source which can be handled by Messy-DOS machines and has been released by some extremely kind soul as Freeware or Shareware that poor, unemployed full-time students don't really have to pay that much for. Of course, I'd also be extremely happy if someone could tell me if I can find a LISP-(of just about any variety under the sun) to-some-compilable-language- (e.g. C, Modula2, Forth, Fifth) or-even- 808[68]-machine-code compiler such as the one that the late Peter Ashwood-Smith wrote about at the end of his useful but slow and, unfortunately, sourceless PC-LISP V2.07 documentation. Is TI's PC-SCHEME more-or-less what I'm looking for? The price seems right, and the advertising sounds promising, though the prettily-painted picture of the product that TI's advertisers have come up with is rather unfortunately lacking in concrete details. The only thing I'm sure about is that it's affordable and arrives sans-source. Any suggestions of just about any nature I will greatly appreciate, especially if I'm pointed to a package that, like the XLISP interpreter, comes with source and thus probably can be ported to other programming environments. I really don't want to be stuck to something that will refuse to move with most of my other things if and when I scrape enough money together to buy a modest machine with an MMU of some nature and a modestly-good operating system. However, if someone *really* likes a chained but cheap software package that won't move up to anything but another Intel chip, please let me know about it. Thanks 1e+06, Sean Doran the Younger (Internet & BITNET) {{uunet!attcan,att,{pyramid,mailrus,rutgers,gatech}!utai,ut{gpu,zoo,csri}}, {zorac.{ARPA,DCIEM.DND.CA},munnari!mnetor,ncrcan}}!lsuc!sean -- ---------- Sean Doran the Younger (Internet & BITNET) {{uunet!attcan,att,{pyramid,mailrus,rutgers,gatech}!utai,ut{gpu,zoo,csri}}, {zorac.{ARPA,DCIEM.DND.CA},munnari!mnetor,ncrcan}}!lsuc!sean  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Sep 89 00:14:34 EDT Received: from ATHENA.CS.YALE.EDU by mintaka.lcs.mit.edu id aa15636; 26 Sep 89 23:57 EDT Received: by ATHENA.CS.YALE.EDU; Tue, 26 Sep 89 23:21:07 EDT From: Paul Hudak Full-Name: Paul Hudak Message-Id: <8909270321.AA16595@ATHENA.CS.YALE.EDU> Received: by yale-ring (node-add2/ADD2) via WIMP-MAIL (Version 1.3/1.5) ; Tue Sep 26 23:05:57 Date: Tue, 26 Sep 89 23:05:51 EDT Subject: Journal of Functional Programming To: fp@yale.arpa, types@theory.lcs.mit.edu, scheme@mc.lcs.mit.edu New journal announcement: JOURNAL OF FUNCTIONAL PROGRAMMING A new quarterly journal from Cambridge University Press CALL FOR PAPERS Background: Functional Programming languages have features that make them attractive for program synthesis and transformation, parallel processing and novel architecture computers. Much research is being devoted to their development. The Journal of Functional Programming is a new journal, the first to be devoted to this important area of computer science. Coverage: The Journal of Functional Programming will provide a focus for papers and foster research on all aspects of the subject. In particular, the journal will cover: New languages and extensions; Reasoning, proof and program transformation; Program synthesis; Implementation techniques; Type theory; Parallelism; Applications. Papers on declarative languages that deal with combining functional and logic languages will also be appropriate. Frequency: The Journal of Functional Programming will have two issues in its first year (1990), each of 128 pages. Thereafter it will appear quarterly. Readership: 1. Computer scientists in universities and research establishments. 2. Software engineers, including those working in parallelism. 3. Mathematicians working in theoretical computer science. Submittals: If you would like to submit a paper for possible publication in the Journal of Functional Programming please send three copies to one of the Editors listed below. ** Papers received by October 15 will be considered for ** ** publication in the first issue. After that date the ** ** papers may be considered for the first issue depending ** ** on the number of submittals. ** Editors: Professor R.J.M. Hughes and Dr P.L. Wadler, Department of Computing Science, University of Glasgow, 14 Lilybank Gardens, Glasgow G12 8RZ, UK Professor P. Hudak, Department of Computer Science, Yale University, Box 2158 Yale Station, New Haven, CT 06520, USA Professor H. Barendregt, Rijksuniversiteit Utrecht, Subfaculteit Wiskunde, Postbus 80.010, 3508 TA Utrecht, The Netherlands Subscription: Information about subscriptions may be obtained by writing to: Journals Publicity Department Cambridge University Press, FREEPOST The Edinburgh Building, Shaftesbury Road Cambridge CB2 1BR, England (No Postage stamp needed if posted within the UK.) Enquiries in US & Canada should be sent to: Cambridge University Press 32 East 57th St. New York, NY 10022, USA -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Sep 89 04:54:07 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa25249; 25 Sep 89 4:47 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 25 Sep 89 04:00:08 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: 25 Sep 89 04:20:33 GMT From: Jim Marshall Organization: Indiana University, Bloomington Subject: Y combinator derivation (long) Message-Id: <26517@iuvax.cs.indiana.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Hello world. Someone recently requested information about deriving the applicative-order Y-combinator from scratch, so I thought I would post a derivation of it in Scheme. The following derivation is similar in flavor to the derivation found in "The Little LISPer" by Friedman/Felleisen, but uses a slightly different starting approach (for one thing, I begin with the "length" function). Maybe this version will be a little easier to follow (maybe not, who knows?). Enjoy... Step 0... We wish to write the recursive function "length" without having to give it a name. Then we could invoke it on a list as follows: ((lambda (l) (if (null? l) 0 (add1 (??? (cdr l))))) '(any old list you like)) The problem, of course, is that we can't plug in the function expression itself directly in place of the ??? because that immediately leads to an infinite regress. It's like trying to quote an entire sentence inside the sentence itself. ---------------------------------------------------------------------- Step 1... This is the _only_ step in the entire derivation that requires any real thought. We can get around the above problem by passing in a _copy_ of the length function as an extra argument and then using _that_ in place of the ???. But we must ensure that the copy of our function looks _exactly_ like the function itself at all times. WE WILL ADHERE TO THIS REQUIREMENT IN EVERY STEP THAT FOLLOWS. Notice that since f is a copy of the function, and the function takes a copy of itself as a second argument, we must also pass f to f (as a second argument). Passing a copy of the function to itself is the whole secret of the Y-combinator. The following expression will evaluate to 5 (the length of the example list): ((lambda (l f) (if (null? l) 0 (add1 (f (cdr l) f)))) '(any old list you like) (lambda (l f) (if (null? l) 0 (add1 (f (cdr l) f))))) ------------------------------------------------------------------------ Step 2... We just switch the order of the function arguments, l and f. "(f (cdr l) f)" changes to "(f f (cdr l))", and the arguments to the top-level invocation also switch places: ((lambda (f l) (if (null? l) 0 (add1 (f f (cdr l))))) (lambda (f l) (if (null? l) 0 (add1 (f f (cdr l))))) '(any old list you like)) ------------------------------------------------------------------------ Step 3... We simply curry the function so that it takes its two arguments one at a time. Note the extra set of ()'s around the top-level invocation as well. This expression still evaluates to 5: (((lambda (f) (lambda (l) (if (null? l) 0 (add1 ((f f) (cdr l)))))) (lambda (f) (lambda (l) (if (null? l) 0 (add1 ((f f) (cdr l))))))) '(any old list you like)) ------------------------------------------------------------------------- Step 4... The above expression is now of the form "( '(any old list you like))", where is now a self-contained recursive version of "length", although still in a clumsy form. We can forget about '(any old list you like) for the remainder of the derivation and concentrate on just the part, since that's what we're interested in. So here it is by itself: ((lambda (f) (lambda (l) (if (null? l) 0 (add1 ((f f) (cdr l)))))) (lambda (f) (lambda (l) (if (null? l) 0 (add1 ((f f) (cdr l))))))) ------------------------------------------------------------------------- Step 5... Notice that in the above expression (f f) returns a function which gets applied to (cdr l). In the same way that the add1 function is equivalent to the function (lambda (a) (add1 a)), the "(f f) function" is equivalent to the function (lambda (a) ((f f) a)). [This is just an inverse eta step to you lambda-calculus pros out there]. This step is necessary to avoid infinite loops, since we're assuming applicative order (i.e, Scheme). ((lambda (f) (lambda (l) (if (null? l) 0 (add1 ((lambda (a) ((f f) a)) (cdr l)))))) (lambda (f) (lambda (l) (if (null? l) 0 (add1 ((lambda (a) ((f f) a)) (cdr l))))))) ------------------------------------------------------------------------- Step 6... Here we just give the (lambda (a) ((f f) a)) function the name "r" using a let-expression. Simple. (Notice how every change to our function requires an identical change to the _copy_ of the function, as mentioned earlier). ((lambda (f) (let ([r (lambda (a) ((f f) a))]) (lambda (l) (if (null? l) 0 (add1 (r (cdr l))))))) (lambda (f) (let ([r (lambda (a) ((f f) a))]) (lambda (l) (if (null? l) 0 (add1 (r (cdr l)))))))) ------------------------------------------------------------------------- Step 7... Now we just expand the let-expressions into their equivalent lambda-forms. In general, "(let ([x val]) body)" is equivalent to "((lambda (x) body) val)". This may look complicated but it's not. Just match up the ()'s carefully. ((lambda (f) ((lambda (r) (lambda (l) (if (null? l) 0 (add1 (r (cdr l)))))) (lambda (a) ((f f) a)))) (lambda (f) ((lambda (r) (lambda (l) (if (null? l) 0 (add1 (r (cdr l)))))) (lambda (a) ((f f) a))))) ------------------------------------------------------------------------- Step 8... Now we can give the (lambda (r) (lambda (l) ...)) expression a name also ("m") using a let-expression, since it has no free variables (except for primitives, but they're bound globally anyway). This step is just like Step 6. (let ([m (lambda (r) (lambda (l) (if (null? l) 0 (add1 (r (cdr l))))))]) ((lambda (f) (m (lambda (a) ((f f) a)))) (lambda (f) (m (lambda (a) ((f f) a)))))) ------------------------------------------------------------------------- Step 9... Now we replace the let-expression for "m" by its equivalent lambda-form, just like in Step 7, and out pops the applicative-order Y-combinator! The expression below still represents the self-contained recursive length function, but now it's in a nicer form. In particular, the (lambda (m) ...) sub-expression is Y: ((lambda (m) ((lambda (f) (m (lambda (a) ((f f) a)))) (lambda (f) (m (lambda (a) ((f f) a)))))) (lambda (r) (lambda (l) (if (null? l) 0 (add1 (r (cdr l))))))) ------------------------------------------------------------------------ Step 10... We just pull out the (lambda (m) ...) sub-expression and call it Y, since all of its variables are bound (after all, it's a combinator). Then the expression above for the recursive length function can be rewritten as shown below. The expression passed to Y is a "template" for the recursive length function. Instead of "???", we call the recursive invocation "r", wrap the whole thing with (lambda (r) ...), and hand it over to Y, which returns a self-contained recursive function. You can give it a name with define if you want, but you don't have to. (define Y (lambda (m) ((lambda (f) (m (lambda (a) ((f f) a)))) (lambda (f) (m (lambda (a) ((f f) a))))))) (Y (lambda (r) (lambda (l) (if (null? l) 0 (add1 (r (cdr l))))))) ------------------------------------------------------------------------- Jim Marshall, Gradual Student | "That it will never come again Computer Science Department | Is what makes life so sweet." Indiana University, Bloomington | -Emily Dickinson marshall@iuvax.cs.indiana.edu | -------------------------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Sep 89 22:06:26 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20065; 24 Sep 89 21:44 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 24 Sep 89 21:15:30 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: 25 Sep 89 00:57:13 GMT From: Brad Pierce Organization: UCLA Computer Science Department Subject: Re: Y combinator derivation Message-Id: <27390@shemp.CS.UCLA.EDU> References: <16800018@uicsrd.csrd.uiuc.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <16800018@uicsrd.csrd.uiuc.edu> jozwiak@uicsrd.csrd.uiuc.edu writes: > >You may want to consult: > "Denotational Semantics-A Methodology for Language Development" >by David A. Schmidt, ISBN 0-697-06849-8. > I think that the Y combinator is: > > Y = lambda h.(lambda x. h(x x)) > (lambda x. h(x x)) . > > I think that this does what it should is pretty patent from it, but >as for deriving it, this involves insight that I don't yet have. > > john I think the previous poster was asking for a derivation of the *applicative-order* Y combinator, not the normal-order as given here. ``The Little Lisper'' (as someone else mentioned) has a good presentation, but its complexity points out the price pays for using an applicative-order language. In normal-order languages, like standard lambda calculus, the derivation is straightforward. The motivation for the Y-combinator in lambda calculus is to allow the use of recursive definitions. Recall that there is no such thing as assignment in lambda calculus, but that this elegant and mathematically tractable model of computation is rich enough to support recursion anyway. The standard example goes as follows: Define the factorial function FACT(n) = n! as FACT (n) = lambda n. if (n == 0) 1 else n*FACT(n-1) Then abstracting out the FACT, define: H = lambda fact. lambda n. if (n == 0) 1 else n*fact(n-1) Then we have the equation: FACT = H(FACT) We want to solve for FACT. Since the only other factor is the function H, we look for a function that will take H as input and return the solution FACT. Said another way, we're looking for a function, F, that satisfies the following equation: FH = H(FH) If combinator theory is defined in terms of the lambda calculus, then we can define combinators as lambda expressions without free variables. For obvious reasons, a combinator with the kind of property described above is called a fixed-point combinator. It is possible to define an infinite number of different fixed- point combinators in the lambda calculus, but the simplest is the so-called Y-combinator given above. It is easy to verify the definition, as long as you remember that it is to be evaluated in normal-order. Finding a fixed-point combinator is not so easy when using applicative-order evaluation. Please see the ``Little Lisper''. Maybe it's time to start thinking seriously about whether the current performance benefits of applicative-order evaluation is worth the theoretical and human factors price tag. -- Brad  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Sep 89 19:54:29 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa19067; 24 Sep 89 19:45 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 24 Sep 89 19:26:25 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: 23 Sep 89 19:04:00 GMT From: ux1.cso.uiuc.edu!uicsrd.csrd.uiuc.edu!jozwiak@uxc.cso.uiuc.edu Subject: Re: Y combinator derivation Message-Id: <16800018@uicsrd.csrd.uiuc.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu You may want to consult: "Denotational Semantics-A Methodology for Language Development" by David A. Schmidt, ISBN 0-697-06849-8. I think that the Y combinator is: Y = lambda h.(lambda x. h(x x)) (lambda x. h(x x)) . I think that this does what it should is pretty patent from it, but as for deriving it, this involves insight that I don't yet have. john  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Sep 89 21:01:26 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa19936; 22 Sep 89 20:57 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 22 Sep 89 19:57:30 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: 22 Sep 89 21:40:07 GMT From: Paul Snively Organization: Apple Computer, Inc. Subject: Re: Y combinator derivation Message-Id: <4318@internal.Apple.COM> References: <8909222102.AA19330@zurich.ai.mit.edu> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu In article <8909222102.AA19330@zurich.ai.mit.edu> markf@ZURICH.AI.MIT.EDU writes: > Sometime in the middle past (i.e. more than six months ago and less > than two years ago) someone posted a nice derivation of the Y > combinator. He or she took a recursive definition of factorial (I > think) and through a series of abstractions derived Y. This sounds suspiciously like the derivation of the applicative-order Y-combinator that appears in "The Little Lisper," either the trade edition or the third edition of which is STILL the standard way to turn someone on to Scheme, in my book, especially if they're not much into computer science (if they're already into computer science, I'll forget the quick kiss of "The Little Lisper" and move right on into pure seduction with "Structure and Interpretation of Computer Programs.") __________________________________________________________________________ Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. __________________________________________________________________________  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Sep 89 17:10:23 EDT Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17028; 22 Sep 89 17:05 EDT Received: from zurich.ai.mit.edu ([18.43.0.244]) by life.ai.mit.edu (4.1/AI-4.10) id AA09823; Fri, 22 Sep 89 17:05:17 EDT Received: from localhost by zurich.ai.mit.edu; Fri, 22 Sep 89 17:02:09 edt Message-Id: <8909222102.AA19330@zurich.ai.mit.edu> To: scheme@zurich.ai.mit.edu Subject: Y combinator derivation Reply-To: markf@zurich.ai.mit.edu Date: Fri, 22 Sep 89 17:02:06 EDT From: markf@zurich.ai.mit.edu Sometime in the middle past (i.e. more than six months ago and less than two years ago) someone posted a nice derivation of the Y combinator. He or she took a recursive definition of factorial (I think) and through a series of abstractions derived Y. I thought I saved this little gem but I can't find it. I also can't find it in the scheme archives here at MIT. If someone else saved this or if the author reads this I would appreciate it if they could send me a copy. Thanks. Mark Friedman MIT Artificial Intelligence Lab 545 Technology Sq. Cambridge, Ma. 02139 markf@zurich.ai.mit.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Sep 89 08:00:06 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07911; 22 Sep 89 7:57 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 22 Sep 89 07:29:28 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: 22 Sep 89 05:45:43 GMT From: bywater!arnor!yozzo@uunet.uu.net Organization: IBM T. J. Watson Research Center, Yorktown Heights, N. Y. Subject: Does anyone have a good reference for writing the A* algorithm in Scheme ? Message-Id: <408@arnor.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anyone have a good reference for writing the A* algorithm in Scheme? ------------------------------------------------------------------------------ | Ralph E. Yozzo | DISCLAIMER: The opinions expressed | | IBM Thomas J. Watson Research Ctr. | herein are the Authors. | | Arpanet: yozzo@ibm.com | And are not necessarily those of his | | | employer. | | Bitnet: yozzo@yktvmx.bitnet \---------------------------------------| | Home: ..!uunet!bywater!acheron!larouch!yozzo | Phone: (914) 945-3634 work | | | Phone: (914) 564-4731 home | ------------------------------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Sep 89 12:01:33 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21139; 21 Sep 89 11:57 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 21 Sep 89 11:48:37 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: 21 Sep 89 15:36:14 GMT From: Dirk Grunwald Organization: University of Colorado, Boulder Subject: Elk on PMAX Message-Id: Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu has any written the alloca-pmax.s and stack-pmax.c for Elk (embedded lisp kernel) running on a PMAX? If so, could you mail me a copy. Thanks. Dirk Grunwald -- Univ. of Colorado at Boulder (grunwald@foobar.colorado.edu)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Sep 89 15:12:07 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05674; 20 Sep 89 15:06 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 20 Sep 89 14:24:59 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: 20 Sep 89 17:40:08 GMT From: Paul Snively Organization: Apple Computer, Inc. Subject: Re: Looking for a MacIntosh Scheme Message-Id: <4250@internal.Apple.COM> References: <9558@thorin.cs.unc.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <9558@thorin.cs.unc.edu> stecker@unc.cs.unc.edu (Melanie Stecker) writes: > I am interested in finding Scheme for the MacIntosh, > (to run on a MacPlus at best) for use in a first year > programming course. > > If you know of such a Scheme, please email me details. > If you have experience with the Scheme, especially in > an educational setting, please include a brief evaluation > of the software. > > Depending on the response I receive, I will post a > summary of replies. > > Thank you. > Melanie Stecker ************* stecker@cs.unc.edu > 'On the loose to climb a mountain, on the loose where I am free, > on the loose to live my life the way I think my life should be...' > -Unknown If you're talking about commercially-available implementations, the only one that I'm familiar with is Lightship Software's (formerly Semantic Microsystems') MacScheme family of products. They have everything from Scheme Express, which is a very nice little bytecode-interpreted system with a very nice little price tag ($69.95) with a lot of cool things, such as a very simple, very elegant little object system and a really cool nondeterministic programming system that John Ulrich wrote (and wrote about in the September AI Expert, if my memory serves me correctly). A bit higher up is MacScheme, which supports native-code compilation for the Macintosh. Higher up still is MacScheme+Toolsmith, which gives you high-level Macintosh Toolbox/OS access and the ability to create standalone applications that can be distributed without royalties. Scheme Express sounds like it might be exactly what you need; it's inexpensive and fits just fine in a one-megabyte Macintosh Plus. If you want native code, you can go with MacScheme for $150; it will also work on a one-meg machine. MacScheme+Toolsmith is $395 and will run in one meg, but large programs may need more RAM. I suggest that you contact Lightship Software at: P.O. Box 1636 Beaverton, OR 97075 (503) 643-6909 Good luck! __________________________________________________________________________ Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. __________________________________________________________________________  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Sep 89 12:03:56 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03380; 20 Sep 89 11:57 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 20 Sep 89 10:58:42 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: 20 Sep 89 14:47:07 GMT From: "Andrew L. M. Shalit" Organization: Apple Computer Inc, Cambridge, MA Subject: Re: Why no eval? Message-Id: References: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article bobg+@andrew.cmu.edu (Robert Steven Glickstein) writes: Why does R^3RS omit a specification for an EVAL procedure? It would seem to have been omitted intentionally. What's the reasoning behind this? Is there a trivial way to write an EVAL procedure? EVAL requires access to environments, which Scheme doesn't currently provide. Making environments first class (or even second-class but accessible) is a very sticky problem, subject of much discussion bordering on flamage. First class environments make analysis and compilation harder, and they make it harder (impossible?) to understand what a program could potentially do. What uses for EVAL did you have in mind? There are probably other ways to do what you want (unless you want to write a debugger). Also, most implementations of Scheme do, in practice, support an EVAL of sorts (for use in their read-eval-print loop, at least).  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Sep 89 00:59:08 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa24710; 20 Sep 89 0:57 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 20 Sep 89 00:13:39 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: 19 Sep 89 17:11:51 GMT From: Melanie Stecker Subject: Looking for a MacIntosh Scheme Message-Id: <9558@thorin.cs.unc.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I am interested in finding Scheme for the MacIntosh, (to run on a MacPlus at best) for use in a first year programming course. If you know of such a Scheme, please email me details. If you have experience with the Scheme, especially in an educational setting, please include a brief evaluation of the software. Depending on the response I receive, I will post a summary of replies. Thank you. Melanie Stecker ************* stecker@cs.unc.edu 'On the loose to climb a mountain, on the loose where I am free, on the loose to live my life the way I think my life should be...' -Unknown  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Sep 89 18:00:58 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa19621; 19 Sep 89 17:52 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 19 Sep 89 17:36:59 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: 19 Sep 89 18:33:01 GMT From: Robert Steven Glickstein Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA Subject: Why no eval? Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Why does R^3RS omit a specification for an EVAL procedure? It would seem to have been omitted intentionally. What's the reasoning behind this? Is there a trivial way to write an EVAL procedure? _______________________________ Bob Glickstein, System Designer Information Technology Center room 220 Carnegie Mellon University Pittsburgh, PA 15213-3890 (412) 268-6743 Internet: bobg+@andrew.cmu.edu Bitnet: bobg%andrew.cmu.edu@cmuccvma.bitnet UUCP: ...!harvard!andrew.cmu.edu!bobg Vote anarchist  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Sep 89 06:58:43 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa10989; 19 Sep 89 6:52 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 19 Sep 89 06:31:20 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: 19 Sep 89 00:53:41 GMT From: Mark Wickersham Organization: University of Kansas Society for Fantasy and Science Fiction Subject: Re: Elk source available? Message-Id: <267@Taliesin.UUCP> References: <8909160905.AA08982@tub.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <8909160905.AA08982@tub.UUCP>, net@TUB.BITNET (Oliver Laumann) writes: > > Some time ago there was mention of a package called ELK (Extensible > > Lisp Kernel ?), a standalone Scheme implementation intended to be > > the kernel of applications such as editors. Sounds great to me.. If I understand what this is.. It may be a method of getting past some real world prejudice against lisp (ie IT'S NOT C!!!! YOU CAN'T USE IT!!!) on the part of my employers. These intolarable reactionaries presently maintain an application that consists of 55 million (I'm not exaggerating) lines of IBM BAL. > two months ago. He has not yet posted it; in fact, the newsgroup seems > to be entirely dead. Thus I'm contemplating to post Elk to either > comp.sources.misc or alt.sources. I've been looking for this and other goodies on comp.sources.unix. Seems to me the alt hierarchy is just begging to come to the rescue. Anon. FTP? Please, I'ld consider the bandwidth to post it very well spent indeed.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Sep 89 18:27:24 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03099; 18 Sep 89 18:22 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 18 Sep 89 17:21:53 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: 18 Sep 89 21:03:15 GMT From: gwusun!bleen.gwu.edu!stoler@uunet.uu.net Organization: The George Washington University, Washington, D.C. Subject: scheme problem Message-Id: <1483@bleen.gwusun.gwu.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I recently sent the following message out regarding a problem we were having with our MIT cscheme installation. We haven't had any replies and I am getting pretty desperate. If anyone has any suggestions, please advise. Thanks in advance. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ We have recently attempted to install cscheme from MIT and all seemed to go reasonably well until the end of the installation when the script loaded scheme and then a bunch of files were loaded and purified. After about 12 files we get the following error message: Purify phase error 9a0, 99f numunp.bin loaded Inconsistency detected Error code 1 STOP and scheme is unusable. When we try to invoke it she bombs. Any help would be appreciated. Thanks. Rich Stoler  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Sep 89 07:59:53 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa24283; 18 Sep 89 7:52 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 18 Sep 89 07:25:47 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: 17 Sep 89 18:48:09 GMT From: Brian Leverich Organization: RAND Corp., Santa Monica, CA Subject: NET ACCESS AT OXFORD Message-Id: <2201@randvax.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I'll be visiting the Military History and International Relations Department at Oxford's All Souls College this Michaelmas Term. Unfortunately, they apparently have no machines with Net access. (I don't think the department is exactly full of hackers... (-: ) Is anyone aware of another department that might grant a guest account with Net access to a visiting scholar with research interests in knowledge-based simulation using ROSS-in-Scheme? Thanks! -B -- "Simulate it in ROSS" Brian Leverich | U.S. Snail: 1700 Main St. ARPAnet: leverich@rand.org | Santa Monica, CA 90406 UUCP: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Sep 89 02:33:21 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21302; 18 Sep 89 2:28 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 17 Sep 89 22:50:04 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: 14 Sep 89 12:53:00 GMT From: gupta Organization: Philips Research Laboratories, Redhill, UK Subject: CSCHEME on an Apollo ? Message-Id: <976@prlhp1.prl.philips.co.uk> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Hi, I recently got CSCHEME from M.I.T. via an info-server and am trying to install it on an Apollo 3000 running BSD 4.2. Has this been done ? The README file (dated 11/4/87) states it runs on various Vax's, HP's and Sun's but I'm sure it must have been ported to an Apollo in the interim two years. I ran into problems running "make all" (step 4 of Install.unx). The following is an edited transcript (loads of trailing Warnings deleted out). ------------------------------------------------------------ % make all #** Resetting translate.touch because of config.h touch translate.touch #** Re-making Psbtobin because of translate.touch dump.c Psbtobin.c rm -f Psbtobin cc -Dunix -O -o Psbtobin Psbtobin.c -lm #** Resetting scheme.touch because of scheme.h config.h bkpt.h object.h scode.h sdata.h gc.h interpret.h stack.h futures.h types.h errors.h returns.h const.h fixobj.h default.h extern.h prim.h touch scheme.touch #** Generating interpret.oo because of scheme.touch locks.h trap.h lookup.h history.h cmpint.h zones.h interpret.c cc -c -Dunix -DDEFAULT_BAND_NAME=\"//node_97f2/local_user/gupta/lisp/scheme/scheme/runtime/scheme.bin\" -DSCHEME_SOURCES_PATH=\"//node_97f2/local_user/gupta/lisp/scheme/scheme/runtime/\" -DCOMPILE_HISTORY -O interpret.c ******** Line 249 of "default.h": Error: Malformed predicate for conditional compilation. ******** Line 253 of "default.h": Error: Malformed predicate for conditional compilation. ******** Line 257 of "default.h": Error: Malformed predicate for conditional compilation. (0327) { { *--Reg_Stack_Pointer = ( Reg_Block[ 5]); *--Reg_Stack_Pointer = ( Reg_Block[ 6]); { if ( 0) { Print_Return(CONT_PRINT_RETURN_MESSAGE); Print_Expression( Reg_Block[ 5], ******** Line 327: [Warning #072] No path to statement "*". ******** Line 327: [Warning #072] No path to statement "Print_Return". (0333) { *--Reg_Stack_Pointer = ( Reg_Block[ 5]); *--Reg_Stack_Pointer = ( Reg_Block[ 6]); { if ( 0) { Print_Return(CONT_PRINT_RETURN_MESSAGE); Print_Expression( Reg_Block[ 5], ***** ------------------------------------------------------------ The problem is that the file default.h is correct. It's as supplied - i.e. unedited by me. This is what a part of it looks like :- . . #ifndef Metering_Apply_Primitive #define Metering_Apply_Primitive(Loc, N) \ Loc = Apply_Primitive(N) #endif #ifndef Eval_Ucode_Hook() /* **** THIS IS LINE 249 **** */ #define Eval_Ucode_Hook() #endif . . And it ALL looks OK. The error message suggests the compiler options are incorrect so why point to default.h ? Where do I go from here ? I should say that I mainly code in Lisp and Smalltalk and so am not familiar with the idiosyncracies of C and make. Any help will be *appreciated*. -- Ashok "Ash" Gupta Post : Philips Research Labs, Crossoak Lane, Redhill, Surrey, RH1 5HA, U.K. Voice: +44 293 785544 ext 5647 JANET: gupta@prl.philips.co.uk ARPA: gupta%prl.philips.co.uk@nsfnet-relay.ac.uk  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Sep 89 12:18:06 EDT Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa00310; 16 Sep 89 12:13 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 6506; Sat, 16 Sep 89 05:09:17 EDT Received: from DB0TUI6.BITNET (NET) by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 2683; Sat, 16 Sep 89 05:09:16 EDT Received: by tub.UUCP; Sat, 16 Sep 89 11:05:07 +0200; AA08982 Date: Sat, 16 Sep 89 11:05:07 +0200 From: Oliver Laumann Message-Id: <8909160905.AA08982@tub.UUCP> To: Scheme@mc.lcs.mit.edu Subject: Re: Elk source available? Cc: esler%bucsb@bu-cs.bu.edu > Some time ago there was mention of a package called ELK (Extensible > Lisp Kernel ?), a standalone Scheme implementation intended to be > the kernel of applications such as editors. > > Is this package available via FTP from anywhere ? I have submitted the package to the moderator of comp.sources.unix about two months ago. He has not yet posted it; in fact, the newsgroup seems to be entirely dead. Thus I'm contemplating to post Elk to either comp.sources.misc or alt.sources. You can FTP the software from na-net.stanford.edu or patience.stanford.edu (36.8.0.154); look into the directory pub/elk. I'm sending individual copies by e-mail to sites without FTP access (but not over UUCP). -- Oliver Laumann net@TUB.BITNET net@tub.UUCP  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Sep 89 08:44:01 EDT Received: from relay.cs.net by mintaka.lcs.mit.edu id aa25733; 15 Sep 89 8:39 EDT Received: from carleton.edu by RELAY.CS.NET id aa06465; 15 Sep 89 7:39 EDT Date: Fri, 15 Sep 89 07:42 CST From: RKIRCHNE@carleton.edu Subject: RE: Scheme Digest #169 To: Scheme%mc.lcs.mit.edu@relay.cs.net X-VMS-To: IN%"Scheme%mc.lcs.mit.edu@RELAY.CS.NET" Message-ID: <8909150839.aa25733@mintaka.lcs.mit.edu> This was the last Scheme Digest I've received. Our network has been up and down, but I hope is up now. Could someone see that I get put back on the mailing list and tell me how I can get the messages I've missed? Thanks. Roger Kirchner  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Sep 89 23:52:00 EDT Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa18088; 14 Sep 89 23:44 EDT Received: by decwrl.dec.com; id AA04072; Thu, 14 Sep 89 20:44:43 -0700 Received: by jove.pa.dec.com; id AA02149; Thu, 14 Sep 89 20:44:31 PDT Message-Id: <8909150344.AA02149@jove.pa.dec.com> To: Scheme@mc.lcs.mit.edu Cc: bartlett@decwrl.dec.com Subject: Scheme-to-C Compiler -- More features, New license Date: Thu, 14 Sep 89 20:44:30 PDT From: bartlett@decwrl.dec.com The Western Research Laboratory of Digital Equipment Corporation is pleased to announce the general availability of its experimental Scheme compiler. While we still require a signed license and a distribution fee of $100, the new license is much in the spirit of the conditions under which MIT releases CScheme. For example, the software is no longer restricted to Digital manufactured systems. The compiler compiles Revised**3 Scheme to C that is then compiled by the native C compiler for the target machine. This design results in a portable system that allows either stand-alone Scheme programs or programs written in both compiled and interpreted Scheme and other languages. An experiment run on a microVAX II suggests that this approach does not adversely effect performance. There, the system was able to execute the Gabriel benchmarks with performance similar to that of a native Common LISP implementation. The Scheme->C system supports the essentials of Revised**3 and many of the optionals. Extensions include "expansion passing style" macros, a foreign function call capability, and interfaces to X11's Xlib. The system does provide call-with-current-continuation. Numbers are represented internally as 29-bit integers, or 64-bit floating point values. The system is oriented towards block compilation to generate code which can run in standalone programs which may include code from other languages. While debugging is typically done using the interpreter, it will never be considered a "Scheme environment". The one "wart" in the system is that the compiler cannot compile all tail calls correctly. This follows from some of the design tradeoffs made when mapping Scheme to C. For more details on this, see the technical report is available from WRL (send the message "help" to the server at WRL-Techreports@decwrl.dec.com). The compiler is written in Scheme. Most of the runtime system (including an interpreter) is written in Scheme. The generational garbage collector and a few other things are written in C. There is a small (< 100) amount of assembly code. If you are interested in this software, please send me your postal address and I will send you the licensing information. Joel Bartlett bartlett@decwrl.dec.com  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Sep 89 18:53:13 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18948; 13 Sep 89 18:42 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 13 Sep 89 18:24:34 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: 13 Sep 89 22:15:00 GMT From: Rich Stoler Organization: The George Washington University, Washington D.C. Subject: Verification Problem Message-Id: <1478@gwusun.gwu.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu We have recently attempted to install cscheme from MIT and all seemed to go reasonably well until the end of the installation when the script loaded scheme and then a bunch of files were loaded and purified. After about 12 files we get the following error message: Purify phase error 9a0, 99f numunp.bin loaded Inconsistency detected Error code 1 STOP and scheme is unusable. When we try to invoke it she bombs. Any help would be appreciated. Thanks. Rich Stoler  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Sep 89 13:17:00 EDT Received: from RISC.COM by mintaka.lcs.mit.edu id aa23202; 12 Sep 89 13:07 EDT Received: from jupiter.risc.com by risc.com (4.1/SMI-4.0) id AA16228; Tue, 12 Sep 89 10:06:38 PDT Received: by jupiter.risc.com (4.0/SMI-4.0) id AA04883; Tue, 12 Sep 89 10:05:39 PDT Date: Tue, 12 Sep 89 10:05:39 PDT From: "Michael A. Perry" Message-Id: <8909121705.AA04883@jupiter.risc.com> To: SCHEME@MC.lcs.mit.edu Subject: List Please add me to your mailing list. Thanks, Michael A. Perry Rockwell International (map@risc.com)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Sep 89 13:55:01 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa04754; 11 Sep 89 13:44 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 11 Sep 89 13:42:07 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: 11 Sep 89 10:41:56 GMT From: "Arto V. Viitanen" Organization: University of Tampere, Dept. of Computer Science, Finland Subject: Building Scheme Message-Id: <741@utacs.UTA.FI> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu Hello, I have a problem. I got a C-scheme distribution from ftp-machine named sauna.hut.fi (in Finland). This distribution had two files, core.tar.Z and exe-68k.tar.Z. They unpacked to directory dist-7.0, so this must be version 7.0. We have SUN-3 machines, so to compile scheme, I move to directory microcode and copied file m/sun.h to m.h and file s/bsd.h to s.h (or something). But when I typed ``make all'', I got following results: make all make -f xmakefile all #** Generating cmp68020.s because of cmp68020.m4 cmp68020.m4 m4 cmp68020.m4 > cmp68020.s #** Generating cmp68020.o because of cmp68020.s as -1 -o cmp68020.o cmp68020.s as: Unknown option '1' ignored. as: Assembler Error-- Unrecognized address mode in: lea _Registers,%a6 *** Error code 255 make: Fatal error: Command failed for target `cmp68020.o' Current working directory /pd/av/scheme/dist-7.0/microcode *** Error code 1 make: Fatal error: Command failed for target `doall' Since I know nothing about 68020's assembly language, I turn to you. What to do ? Arto V. Viitanen University Of Tampere, Department of Computer Science av@utacs.uta.fi  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Sep 89 11:43:54 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02996; 11 Sep 89 11:40 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 11 Sep 89 11:39:12 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: 11 Sep 89 13:52:22 GMT From: CONNCOLL.BITNET!gateh@bloom-beacon.mit.edu Organization: The Internet Subject: FTP site for C Scheme? Message-Id: <8909111352.AA06472@mvax.CONNCOLL.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Hello folks, I recently posted a query concerning C Scheme, and I want to thank those who responded. Being on BITNET, I had asked for info on sources _other_ than Internet FTP sites. It now appears that I may have FTP access to Internet sites via a SERVer at PUCC, and so FTP source site addresses for C Scheme would now be much appreciated. This is a good opportunity for me to test this relatively new service. Once again, thanks for all your help! - Gregg *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Gregg TeHennepe | Academic Computing and User Services Minicomputer Specialist | Box 5482 BITNET: gateh@conncoll | Connecticut College Phone: (203) 447-7681 | New London, CT 06320  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Sep 89 09:58:10 EDT Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa01778; 11 Sep 89 9:54 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 3118; Mon, 11 Sep 89 09:54:22 EDT Received: from CONNCOLL.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 9853; Mon, 11 Sep 89 09:54:22 EDT From: gateh%CONNCOLL.BITNET@mitvma.mit.edu Date: Mon, 11 Sep 89 09:52:22 EDT Message-Id: <8909111352.AA06472@mvax.CONNCOLL.EDU> X-Mailer: Mail User's Shell (6.4 2/14/89) To: scheme@mc.lcs.mit.edu Subject: FTP site for C Scheme? Hello folks, I recently posted a query concerning C Scheme, and I want to thank those who responded. Being on BITNET, I had asked for info on sources _other_ than Internet FTP sites. It now appears that I may have FTP access to Internet sites via a SERVer at PUCC, and so FTP source site addresses for C Scheme would now be much appreciated. This is a good opportunity for me to test this relatively new service. Once again, thanks for all your help! - Gregg *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Gregg TeHennepe | Academic Computing and User Services Minicomputer Specialist | Box 5482 BITNET: gateh@conncoll | Connecticut College Phone: (203) 447-7681 | New London, CT 06320  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 9 Sep 89 16:31:40 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa11096; 9 Sep 89 16:27 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 9 Sep 89 15:42:46 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: 9 Sep 89 19:39:36 GMT From: Kevin Esler Organization: Boston Univ Comp. Sci. Subject: ELK source available ? Message-Id: <3225@bucsb.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Some time ago there was mention of a package called ELK (Extensible Lisp Kernel ?), a standalone Scheme implementation intended to be the kernel of applications such as editors. Is this package available via FTP from anywhere ?  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Sep 89 06:33:02 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21812; 8 Sep 89 6:28 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 8 Sep 89 05:57:53 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: 8 Sep 89 03:56:36 GMT From: Brad Pierce Organization: UCLA Computer Science Department Subject: Operating Systems in Scheme Message-Id: <26968@shemp.CS.UCLA.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I'd be interested in finding some material that has been used to teach operating systems concepts using Scheme. I'd also like to hear opinions about this approach to teaching. I'll summarize and post to the net. Thanks in advance. -- Brad  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Sep 89 06:32:55 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21810; 8 Sep 89 6:27 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 8 Sep 89 05:56:19 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: 8 Sep 89 03:45:01 GMT From: Brad Pierce Organization: UCLA Computer Science Department Subject: Scheme Bibliography (Request) Message-Id: <26967@shemp.CS.UCLA.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anyone know of a current Scheme bibliography? Or even better, does anyone have a bibliography they'd be willing to post to the network? It never hurts to ask! Thanks in advance for any info. -- Brad  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Sep 89 00:30:08 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18103; 8 Sep 89 0:27 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 7 Sep 89 11:37:31 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: 7 Sep 89 03:30:10 GMT From: "Timothy R. Gottschalk" Organization: Carnegie Mellon, Pittsburgh, PA Subject: PC-SCHEME Discount Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Texas Instruments offers a 40% discount off of their $95.00 price for PC-SCHEME for students (call 800-TI-PARTS for eligibility info) bringing the price of SCHEME to about $57.00. If you're a student, I'm sure you're anxious to save money. Tim R. Gottschalk Pittsburgh, PA  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Sep 89 13:29:22 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07362; 5 Sep 89 13:24 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 5 Sep 89 12:37:02 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: 5 Sep 89 15:10:56 GMT From: Tom Almy Organization: Tektronix, Inc., Beaverton, OR. Subject: Re: XScheme0.17 Message-Id: <5882@tekgvs.LABS.TEK.COM> References: , <1663@jato.Jpl.Nasa.Gov> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <1663@jato.Jpl.Nasa.Gov> brian@topaz.Jpl.Nasa.Gov (Brian of ASTD-CP) writes: > I tried out xscheme 0.17 (thanks, all, for posting, repairing,[...] > BUT -- the save / restore bug is NOT FIXED :-( boo hoo Some old postings of mine giving bug fixes to make save/restore work in XLISP will fix the problem with xscheme. Tom Almy toma@tekgvs.labs.tek.com  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 4 Sep 89 13:54:18 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa17970; 4 Sep 89 13:42 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 4 Sep 89 06:53:22 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: 3 Sep 89 20:09:31 GMT From: Brian Leverich Organization: RAND Corp., Santa Monica, CA Subject: TI's PC-SCHEME AND PERSONAL CONSULTANT ES SHELL Message-Id: <2181@randvax.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Anyone know for sure if Texas Instrument's Personal Consultant Easy and Personal Consultant Plus expert system shells live on top of TI's PC-Scheme, and if they can gracefully access the underlying Scheme? Reason for asking is that we're doing object-oriented message-passing simulation models of command and control in PC-Scheme, and we'd like to have a shell that can smoothly interact with the models through Scheme. I'm particularly interested in the Easy shell, since if possible we'd rather not buy Plus until we've done a proof-of-principle with Easy. REGARDLESS OF WHAT APPEARS IN THE "REPLY-TO:" FIELD, REPLY TO leverich@rand.org. Thanks all! -B -- "Simulate it in ROSS" Brian Leverich | U.S. Snail: 1700 Main St. ARPAnet: leverich@rand.org | Santa Monica, CA 90406 UUCP: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 2 Sep 89 17:29:34 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa04413; 2 Sep 89 17:26 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 2 Sep 89 16:49:23 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: 2 Sep 89 15:28:13 GMT From: "Roger R. Espinosa" Organization: The Rabbit Corps Subject: CScheme Questions Message-Id: <868@cbnewse.ATT.COM> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I'm currently writing a project in Mit-Cscheme, but to do this, I need to dial in long distance to another computer. I would *love* to port Cscheme to the unix machine I'm using at work ... 9600 baud plus being able to get printouts (without driving 240 miles...) would be wonderful. I have the cscheme source on the long-distance machine. I've tried to use "cu" to trasnfer files, but cu chokes, never getting a complete file. I am at a loss as to how to transfer files when cu chokes, with incompatible machines: the work system is System V UNIX, while the school machine is BSD UNIX. The solution would be to somehow get cscheme sent to my work machine. The easy way would be to ftp from work, but System V doesn't support ftp. IS THERE SOME WAY TO GET FILES FROM ANONYMOUS FTP SITES without actually HAVING ftp? Do I sent email to someone saying "I'd like these files?" Or can someone *send* me the sources to cscheme? BUT MOST IMPORTANTLY: DOES CSCHEME RUN ON SYSTEM V UNIX? I read the Install and README files, and System V is *not* mentioned, so I'm not sure. I don't want to go through all this effort (and waste of time) for *nothing*. THIS REALLY IS URGENT AND IMPORTANT; ALL RESPONSES WILL BE GREATLY APPRECIATED! Thank you, Roger Espinosa ...!att!ihlpn!rre or, should that fail, rre@zip.eecs.umich.edu (But I need scheme for the "ihlpn" machine :-)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Sep 89 23:31:00 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa04944; 1 Sep 89 23:24 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 1 Sep 89 19:47:32 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: 1 Sep 89 15:56:50 GMT From: Brian of ASTD-CP Organization: Jet Propulsion Laboratory, Pasadena, CA Subject: Re: XScheme0.17 Message-Id: <1663@jato.Jpl.Nasa.Gov> References: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I tried out xscheme 0.17 (thanks, all, for posting, repairing, and setting up an ftp source!!!). There are several differences in the class/object system, but I can't evaluate them, since I don't use that system (yet). BUT -- the save / restore bug is NOT FIXED :-( boo hoo , I gotta get motivated to get , out the logic analyzer. . . . Brian Beckman . . . . . . . . . brian@topaz.jpl.nasa.gov. . . . . . JPL Computer Graphics Lab. . . . (818) 397-9207. . . . . . . . . . . "let mikey do it -- mikey will debug ANYTHING" . . . . . . . .  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Sep 89 23:25:32 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa04934; 1 Sep 89 23:23 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 1 Sep 89 22:26:48 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: 2 Sep 89 01:46:10 GMT From: "Timothy R. Gottschalk" Organization: Carnegie Mellon, Pittsburgh, PA Subject: PC SCHEME Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Anyone: I know absolutely nothing about Scheme but I want to learn it. I have an IBM PS/2-50 and I want to install it onto my machine. I'm sure a version of Scheme for the PC exists -- can anyone tell me where to purchase it or how to easily get a copy? Also, how portable would it be to cscheme on Unix? I've seen mentions to XScheme on this bboard but I don't know how to download it. Please respond to me personally (tg1e+@andrew.cmu.edu) or the bboard. Help!! trg.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Sep 89 17:57:06 EDT Received: from BU-IT.BU.EDU by mintaka.lcs.mit.edu id aa21275; 1 Sep 89 17:54 EDT Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA11723; Fri, 1 Sep 89 17:54:43 EDT Received: by buita.bu.edu (3.2/4.7) id AA21535; Fri, 1 Sep 89 17:54:58 EDT Message-Id: <8909012154.AA21535@buita.bu.edu> Received: by mitech.com (DECUS UUCP w/Smail); Fri, 1 Sep 89 16:08:30 EDT Date: Fri, 1 Sep 89 16:08:30 EDT From: gjc@mitech.com MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu To: scheme@MC.lcs.mit.edu Subject: Scheme in C++ X-Vms-Mail-To: UUCP%"scheme@mc.lcs.mit.edu" I'm trying to find Russo and Kaplan of the University of Illinois at Urbana-Champaign, who wrote a paper on a scheme intepreter written in C++ (derived from SIOD.C).  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Sep 89 13:22:26 EDT Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa17790; 1 Sep 89 13:18 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 9006; Fri, 01 Sep 89 13:18:33 EDT Received: from CONNCOLL.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 8441; Fri, 01 Sep 89 13:18:32 EDT From: gateh%CONNCOLL.BITNET@mitvma.mit.edu Date: Fri, 1 Sep 89 10:39:34 EDT Message-Id: <8909011439.AA15392@mvax.CONNCOLL.EDU> X-Mailer: Mail User's Shell (6.4 2/14/89) To: scheme@mc.lcs.mit.edu Subject: Info needed on C-Scheme Howdy folks, One of our users in interested in a version of Scheme, C-Scheme. He is interested in any available information about C-Scheme, especially concerning availability for Unix (Ultrix) systems. He has heard that there is a public domain version available. Any help pointing me towards the source and/or documentation/information would be much appreciated. I'm not a member of this list, so please reply directly to me. Also note that I have *extremely* limited access (via another school) to FTP sites, so alternate sources would be preferred. This would be for use on a DEC MicroVAX 3900 running Ultrix-32 v3.1. Thanks in advance! - Gregg *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Gregg TeHennepe | Academic Computing and User Services Minicomputer Specialist | Box 5482 BITNET: gateh@conncoll | Connecticut College Phone: (203) 447-7681 | New London, CT 06320  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Sep 89 00:40:18 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa09682; 1 Sep 89 0:36 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 31 Aug 89 23:22:53 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: 31 Aug 89 20:36:07 GMT From: Ken Dickey Subject: Un*x hacks for the IBM XScheme 0.17 code Message-Id: <4596@tekcrl.LABS.TEK.COM> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu There are a couple of hacks needed for U*ix. The following may save some time (uudecode, then unarc). Name Length Date ============ ======== ========= Makefile.unx 316 31 Aug 89 - has cflag "-DUNIX" downcase-name 482 31 Aug 89 - downcases *.[HC] file names format.s 4733 31 Aug 89 - simple format function macros.s 2633 31 Aug 89 qquote.s 2743 31 Aug 89 utils.s 1466 31 Aug 89 - when, unless, ... xschemerc 1111 31 Aug 89 - my "xscheme.ini" ==== ======== Total 7 13484 Notes: I had to comment out the "#define MSDOS" in xscheme.h. You may have to get rid of the CPM/MSDOS ^Z and ^M characters. I have done very little testing. You will want to change the pathnames in xschemerc. I did *not* put in the tilda (#\~) path expansion hack. Enjoy! -Ken Dickey kend@mrloog.LA.TEK.COM ======================================================== begin 660 xschmisc.arc M&@A-86ME9FEL92YU;G@ V0 !\3G5YNU3P! ,+MZX&*-#00(2*(8,20$" MX1 C3((ETCIDZ;F(,/>M&QE"C=-#<1)L&)ITZ9@*J9"GC)5$W:;:6'?.& M[-*L@C/"E$FSC(Z#*%:VK!B9;PJ#'4&T&#RS9L/*DS]+EL&P!9LV&1%*CI'B M\>+.-M$H4&W9=4S8+M L%4.83&P%&@AD;W=N8V%S92UN86UE* $ !\3G5X$ M^^(! ,(T+,0:.@C1T038(,D?)DBHLI(-J$&2/GS1P7C!*ERA,J11Z" MB!.GSALZ93!J!%'%21(L4ZA4,>)B"(@Z;M+@F4.GCAD78U;"%#+D"9&02$#L M%#/F#9F4! V"@#D$29$F(6WN'(.F3)N40:52M8K5!9$G6N=P]9J2S)NP!\=> M1:I4;=>O+J+&G5)UKHLD+NNNQ9LFIU"^3YK4%/RF#=##1+ J3DOFJV.X4Z<8 MH1)$R.*=9NB$$?-8K.:6,3[/,8,S-6:81EK*4,W:S>S74Y(D/)*U;AJ)9\ > M!IR$BNK":>B4W@O8>-K"RG$G>7+\S?+,":D@42V1#IKK,)\(4:+ZC1@UX*= MD=)<-1PYT--+*1*$B&HY9<*023\ER^2Z<^1QF0(* !H(9F]R;6%T+G, ;F%M M920( ?$V5@_K=]$@ ##L4[ QY VT%%ZT^;3J"ZC MTNE)QX7 E%/JP('S1DY#HTB5OHPYLV:9$ H$#D029,B2(D1 &'DB!026*4.0 M%&E2! 0,%S%LI+Q2TTW4,R% I 211.CC,6C*M+F) JN9J#?'LL$*8@07/Q%1 ME(GSH_;MH6EFEXGX-*.8FV;"L)GS%T0/'R#J, =1)(J5'Z-/IU[-]$T9EV$; M;K5S%?"W/0D9 ;9X#@ @@UG3%'"NXYQ,9'#CED8$,HI&&&0[OU!J" 1985T,C MT)';&'7(89,;!)XXH(IV161CBA^F$!&&[D%"P'WYL9:@?S$@V!]7##H8885L MY-$@AB! 8@ *&SI8QA@*) ""0X%Y61^6')T!4@LQM7 DDPT^&"$*;7[6PH80 M@J2D@FPZZ6.85=H7AAMYH%93"V2T! =7J'59Y9 \M2$&&6%X^(9+4+;DHJ)6 MAC@B"C[TH-.D(-!I)AIHFJ'FD@3&"2&&"7A)H1QG)-4@" -)EU6"(/C1VQAO MT!A5'7_ZU*6K9(+HD*!R.*3J&2W8-.*:J3KYZ84_#KLH"KRZ08:UD!2 @FYQ MV+'K5LG:AANW5\J&%:&&(AH2"BM,*U%$E4[)JIC>EK%<&>BB<$="=)31 K(@ M$-QCOW\&2BZ[-/AHI"A._&JNEK%9Y +:];MOJMYW**^J9:4+;I)OW M.O1O&@$/3*YO?GR:X\@N4]A0R2#$])*#G^'DDAK2_1?@@-;6VU"MS &%JZX% M]SJ6&\"Z(:S&]^JVK[7%=HB"RU+7I"S8$#:+WYT+MAGAQ")3"!J M1W2PQT.>O/#L[D8L;\7'DI%L[DU_'*:8E%N..> $=VZ;2[9-,3H(4_ T!TNO M986ZZH?*P9SXL?L+,&MCX'XQSU9G+&;O@*(,_,/O2@PJ\=@:KS/&';\/I,?- M4\WS@K.NZ'F."T"Q#1&N1X0MI>$I;"C?['ABN_0=;WU3:E_RX*>P0Y@HX->EQ 0^^P<+UD% &/(0!*V-XH'*"1(&^?6L.82 / M&=0T(A48(0E8<$(5FM""Q4@A/E10P9ZJ9 $X?20T1D2B$IGH1"BJ 0B* $; M\"""Y%UI@K4[EOIVEL'=B>E*S*$#%H^8Q"4V$3[R^2(0A4A$QU%@@RCPG0?; M13_AY0Q_8R A!EVT02#M ( I%. *!69 VXC!-T*XGA"B4A.4# 02/2Y!R2%GP0GC($0:3?]/DW32M.:;* M21)Z+3S@&WSSA.L]80QKB> G0\FA'Y9RB-%,YBQ7V?20G 1)ZS?C]CI @M!_%O+D_GG%4 M>9.+Y.4FN3D0N' IMH%(1 8R!'*QI0QR*-_3HD:PVWV3?3T2#>\"Z=%!QJR0 MW+P?24LHSN7U2:4#U%PEN0 'WT#A>E!@0XQV.%01.<13/BUI!BO6I?J,8$0# M"0N%X)F&7I75/CNEY-2FIT% 8E.;2!7IO(KW4WN9T*GEW(VX6$HP<\U4)03D MUU#CVE)S$7.H=_U@_40H5OM[2AL M\1I2RN;NKRG5K&X3BUH3'-8(-MD>:6_R/2>(!019X% 2VK 3U7 D8$(;[FF+ MJ]KM)E=(KY4?2"?;S=I"MTJ0,^=*=^O2 U+!-XP<&17"<,D@7,M[VIHQ)6V"@4K*];6>053I0H@F*=SY<(/ZJ-!T>S@DSZ.['QG.U+[ M'KE*$ICFAT/,A2/XY@PDM@D=Z)"' CVH(7N@0A]&%H0YS*%UWP$!%*! (3M MA2=(*8-;G@P)'T_E(USVLEJ 6=N'(OG"1E49?6F;O[XRDL>0B/)MG[P'$>A* M!$$AB%/:T"L0,,%08@.C'Y8 Z:BHI _1S2UA@_R#PT:E4#9A:Z6_MQ:3@, C M>&A(A2CD$FA]S4UN@6Q18[ODI#:YK 2(*+22%-;<\;6V]>&6!0;BW8#I '%< M29*68_2ZZ-"M;3J#75-3JB_F\% W,G*Q"*#U[#JX80UAN8-0LO:=]*T8TD': M )P(QRQG03M:L)I6"I(]N7T'^\':BIODQ'2 ZW$-<)+ET\<20.0P#638(#B+ M4+H$:%YG."0PV)^4,F;P@ \[,(MZ.*HB#A4W!&E($%?:LK+M. )T[K#3EH-0 MW*Q5[J9NY0892Z6=D(4D@/QC(^-:EA1P6*Y!2P$:"&UA8W)O-F#=L9>LU(M6L>[E&O-K6*9.698]6_+D&[=P?3*@ M._AN7 <GGI&S>>$?N-V1&TR!9LTLPY3$8T5$@'XE)M M#?)U[-E^I1)03/JB0((&66O^?95-GMDO8\ZL&>9F3N?0XP)5B%JYZY&-.\=4 MC9U.5.^]1S(?7QM$>(-'#IIG!8&&RNY84=T=&%D M1AAUL$%'"V^(H4898]"14QD&"L=11 WEE]EWFSFF$G$:)K10AQOQME6(XA%7 MX(%O6:2@1B"$]X99*!2' AQU7'6"C6:58&-/,;$1AE%DA!&3&6_(T8:&ZYW M(QUY526;CW'4\08=&S'5'I-.DN838%>:E>66!S'&V6-5>OEEDT_^)".0::V% M!Y%5'2E&DDO"*=P(9N@()(<3R=%"G6SA:2222J( YI/:60F697(X7 MQIMA_B4IEEIF>A:B;;6Y*:=Q$B CH0\92BH(F):AJ)Y\.NHG"(^2E@!,%[%Z MUZ%YJ,66>[2&,2NC?889*7=SZ';"HGL:ZQ-5S,8UEY=.Y6KMA^G!5N929*#J ME@&KGE@HL,+B <)Q&AT;;;*0^K3=:P*[!NEF&FK;8HNKG]NJZ-NW8X2; MK9]3$=FKN:VB:R<(3>\^9%]0=99R11D@@)($:@'3T>-#P?U.( MAAM(O7%&'J@3L;ML ;HA/$U-A$%'X"4!.$:S?CO1P@TPS$##W\:3@7P;S:," M$E#G/#ELCGPNHU'3? .6%G#.=V=P0QLP=)6B(6@Z.;,.""RX+'KI2S4<_-C) M6)02KFU09_"1EP7G,R/[C- J+7C4RN(U'@]>3#46BUNU/A88%%2E9YH25XQ* M1C2=72=I52H)'!"RG 8^, T1G*!:R/87^>CKA2D3(M_.AB)7!>MA@7EA [5U MGRXZ;%B48R*(8$A&7WDQ79&C ^;&H,9NL1%@%P$2OLK0@H)PZ0QR"(,8'D*Q M1N5P7MVY5WVZ)$15Y7%-ZZ*0D3!72'BE8#^!J@@:"'%Q=6]T92YS &YA;64B M!@ 'Q-E8*/2MPH P[( T $25*E2=4BKB8 @($C!@M8M!H@2,'B!@Q=,R@ M 2)($Q!B\H!0\@:-FXYRVLRA(^>-FS,*%.S8 :(('CAAW)"90[!*D"E)#"(L M\J**$Z$)BQX]F!!$F#%CWL@AD^8E"#IO0$@I8\?+#*UEX$BE V(.G#)CYKB0 MN8,M""IHTO TDX9-&1!CLG#!T!(-P6Q4KB"9!ADAY,F4AY3MIZ* !4>9FSL!R0)BI MLYE.&I<\<^:Y@Z:,G+NW0;1YVC*XF=!RW(9Y;AQ$8+IN8O\^^<8,B"%/FD!) MPJ2(E!93LCBA$@1+S( #BV"!$L0)$?,MC!@=0B7)$R=3Z(#7&VW 45<88M@% M F^X757<@,EE\A,(9)3H% MI!M&MG%55F'8\48:@^4%!QUU1%B5 @E 0@"38QA'1QB(H8"3;&^P\<89:>3% MAI)SQ%8':-O-0:.-;MQ54 ORT6>?>0HTA (;8;0A!AEA@+!H"F0J:A=+:%4J M$ J:$H!"''&T8)<=#BE)$X=WA $C"#[TX%"G* PZ1!#G#4&$%)H6L&BCCT:* M0FUP4)I B! HNNEDGX::EZY*2LIL[3=E() 9(:X*:@MC$%&LZ ^NVVTP9I9 M[4"2IN$="LFYR:89SG&6D9/4/9N]:;WW0AOSQT.'D>?019>1<;&>SE$&'2&,/*JD,:P@ M.5=(6SOUX\EBNR$;U1)PMKF2NHKMY#&8JAQBGSM%76Y]A5[L 32U@'5E=4#7 MQAM/CEH&Z&6*#LD!SN(;QK9*XVV98 _6_+@)_"&>&C*EV]\;NBK3W1H! M__;W,V2A[7O D]>F2(<"TX5J5^^8M7 W9 DMQFG);G9HQG8])?C MD"D!BMQD%_]4!NS2QD*[NB0I\#TY"=!84H11.#':251 35J95"'.@5[$K4^1M5E MRWJU2R7]JJGPE*=605#6>^;3"?O<(%6Y)"B? &6>7/WC5^'#(M6P1D!M3A0&/%SUKW.U)$Y& MQ"^P>M9 =M&BD4AK6KE*57TB=2)N*%6SS\96M+05:E034D^[ZK.?H7IA;E>[ MV_>$B$=$4 :"'5T:6QS+G, &YA;651 P 'Q-E8("(N@4 P*=H ( F+, MFSIPV)0!\<8,0S9D0)B1DZ:,&S)S=("X@J2($Q8@JCAA4F3*%!<*%*!H$V:, MG#<@[J"QJ $) ,HV(1I(X9,&! HPL@Y,R=%34@/P*!(XY %BC%AR,@!(92H MT00V&Z 04^9,&C<@6 !Y2D8JU:%%C=JL,,),"D@#4JYL^1)$'3<*Y\PY>B#G MSIX_@Z)5BU0IT[!/HTZM6E1!@@0CZ#A.L+7KU[!CQY1=/!A2 05P!3)),H5* MBR%/H&0!T:(%"#EEZ-21XV8.51!LTLRA$S,-'30@W)2Y4_!-[3*VWTS]O5!Y M&J]NPK!!J9),&3-?%Z(87?ITZM4\<('Z(_G^]2X[9SUM6 0''D !=54^MF70@I B4>'@&\0:*!9"9+G64H"35&% M$*4E04455!0QGW!W^""1.,#!Y% )C790<4&6\$68<8NXTX7)MOQ@EC ME80AT-]%0*%01AQU2">?FRM*>2B=#08X8(%K#KJ@8S;AE-YZ0+D'WZ1R(LJ@ MBY>2!^I-CK(Q1QFO4C;K@P>&8"F5,^[9YQQ_!MIIB2E6FAB"J=()5ZU@_AHL M;\,2:JQFR+;ZZ6.[SGF?G83=R:>?@$++9K%P9KH;A!*RRNNV1H4& A12).&$ M::5)44003<@5IIXHP"LOO538BZ^4=,"VDXE)\@"'<@K6U&!L0)7*,%"'H7 0 M'7#4\>#""B<_ALL-A@H8#>"L&!$,-;! 1D1N![YCGF?PY-;M0.>^T@^,YL*QZV MTP'%$) , '-C:&5M97)C &%M M9 MA"$#0L2+.G/DQ'BQIHP;,B_$3'PQL.#!A"W:A!DCY\V<%UJY>G4Q1T2*GT&' M%CV:=&G3IU&G5HU9)NO6KE_CQ*GSAD[$LF>!"B5J%*E2IDZA2G5#U>'5NF'Q M'MW(9@Y9LV@'KS7L-G%_'GTLR! H$"1YC8*\&'JL*'3XHT8-66,0<&!H((,.@@A".B]!PD!/MU71GANC).)Z! I0+Q??>A>/*I4(<;Q(UY(AIA/ 6A'"HH&6-)(]&1(U!E M'#>?E/*=4:>;;3#II'%0#I4") -PN2%]M^$IF%I2;@G"H?7)]YN=93Y%()&. M0F( >7)TU9((8U9*E'ER<"0&A"+PF2D!"\;)I)8;=@@>F >I-49V@+@&_JQ\4.N7^Z:7 O. MT@&MM-1N]^J6RX)IDAMS1#MMM7UFN24*D;T!)[ONEML&ESW^&*1\$AK*JD?2 M,KEN; L.A6RP!!]W DH^YB'?K60<"VR"'=8+@E9-@6O@="-51P>_0/DK) H! M/\IJ&'# D=BK$-I)Y<062_@J"M]&![(;(@]:@*S=II311AVU@)1"'DO7%<]. *V9GSQTOW?!8: -I) end  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 31 Aug 89 21:51:25 EDT Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa07616; 31 Aug 89 21:48 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 7667; Thu, 31 Aug 89 21:48:04 EDT Received: from SUVM.ACS.SYR.EDU by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 3052; Thu, 31 Aug 89 21:48:03 EDT Received: from SUNRISE.BITNET (NFHARFOU) by SUVM.ACS.SYR.EDU (Mailer R2.03B) with BSMTP id 9255; Thu, 31 Aug 89 16:21:27 LCL Date: Thu, 31 Aug 89 16:21 From: NFHARFOU%SUNRISE.BITNET@mitvma.mit.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Subject: Documentation To: scheme@mc.lcs.mit.edu X-Original-To: scheme@mc.lcs.mit.edu, NFHARFOU Message-ID: <8908312148.aa07616@mintaka.lcs.mit.edu> Dear Mrs/Miss/Sir, I am having trouble finding a user's guide for one of your Scheme implementation which I will be using extensively. Would you please give me some references in terms of where/how I could get a document with a complete description of the language, and the name of that document. Here's the system's ID info I'm using: Release 6.1.1 Microcode 10.2 Runtime 13.91 Yours, Federico Harfouche  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 31 Aug 89 20:53:12 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa06647; 31 Aug 89 20:27 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 31 Aug 89 19:36:06 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: 31 Aug 89 22:29:00 GMT From: "Mark C. Carroll " Organization: Rutgers Univ., New Brunswick, N.J. Subject: XScheme0.17 for FTP Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu The version of XScheme 0.17 that was posted is an incredible mess for Unix. So, I`ve taken it, and done the following: 1> Renamed files into lower case 2> Hacked the makefile 3> Filtered all of the files, to change all of the cr/lf to lf. 4> Chopped out the ^Z end of file marker With this done, it compiles happily on our 4.2BSD machine. I've taken the working sources for 4.2BSD, tarred them into a single file, and places for public FTP on topaz.rutgers.edu, in the file "~ftp/mc/xscheme017.tar". (For those with stupid hosts, our internet address is 128.6.4.194) This is strictly *temporary*. My best guess at how long it will last is 2-3 weeks. -- ---------------------- Mark Craig Carroll: ------------------------ -------- mccarrol@topaz.rutgers.edu,...!rutgers!topaz!mccarrol --------- --"In the beginning, the Universe was created. This has made a lot of -- ----- people very angry, and been widely regarded as a bad move." ------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Aug 89 23:13:09 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa23991; 30 Aug 89 23:09 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 30 Aug 89 17:18:59 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: 30 Aug 89 03:01:39 GMT From: jdm Organization: Hodge Computer Research Corporation Subject: Xscheme.arc (Part 3 of 3) Message-Id: <21724@hodge.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu M6[F9#AFXU%<\E8M=<:'6O.[U0.F P&/%$UF%)=:RC'4' #01KX2DPQPZ56G MD-(,G;ZTLY"4)$W_8E.)H24=J # Q3*VL>A]+#1T"$-4$="#K;8@'=O1&M?J M%K:QE>UL:5L;6BF+U\6^%1_K2(-R \>WYN: ;&;K =K4YHG)5M:Z?%W'#[;+ M7+%]][GBC:XG$$M=Q>J5F^NH@";NEQ#_ 5" 23SE$N<*S@0LP@(XR$$H;)"# MNP4R)K M\99 W648ATJ8HGI#,=SP!;K6L82V (P.-6AR3(LL6R33%F(2J\,$=JLQ >!H M3+XP0E?^9P=Y#M"4!5#2,8P0( #L&1M220<8!I#1&>N0AQ[%<4A;V6-85E&U MD@F%:PL&VYF:N88WO2T?=&J,'LB9#CGH ;IN.S0QM_#)+XTR&/_2RRH?1AR* M 4#'I*SK9EJGVHI193>7"M H:>:(;B^AQ-\YXN29T4(.I'VEIA]4V,DA8 M1*<_'0-1\T0 ZXBV%;SQ%&[\.MAO)A&;>^L%8O<@SEWQP+C=/&SST=G. <[S M$JO!A.CB!JKHA,1V^L!N>=-43?PW06,N*C?M\UKH&-P(VTO&'D#.U#H4M^1U. M?M^"'US0 M@,.-" =F(#:+R.$QA3,<*,135O$T[*HT))8,(DK#&SJX(!W2 ![]\9U M[X(7NN2=[GE_?O-3R#T'6^-NW=U[]_B2=^;U!:W-53Z9OP?>:X-W;GC'N[:> MVU?I!U^'%.9NA,B_=_+R17KB49YY%'#>\X6G_'REOGB$#_PIX#C,E?O]E/0X MLT!?>XH9C> . ,JR(($@H6D ,/M@(&( $Y MT$<>H@D$H$T ,(>U< "0 3H"3_8 -HD -_: 8YH FCD ![V((B)J"2,>(DG\H=[*(F.4(F(Z(B+6!!YJ(D$< P&8 DZ8!6H M2 DZ$"-F&"-5* E8N(@ _!"!A_ ML"^?L%F+L7UE!A;X@&D2<%A(\01VA W1, XN\ ^G$(5PP%8!T @!, 4"8([R M,([E* #D. ,!X([D:([RR([KZ([NJ D>T(@3\(=7^(=:*(TU5! ;$!M32 P& M )!$5!*C9(BAJ(@$D(FB2 (>0<(,$1W\(26&)$0Z9#ID VCE8^)R(\ZX(^W M>(P!J0D#V0,%>9 FN0A%)&V9L)%* I#$\ 4$0%(XL0X@X!>#,!0*641#A$09 MZ9 R>2).T ?=L YT@(_Z*)(D"9"6)) $:2(L.8TN^1W&$).DJ(\S:9(U>9-& M$$ST" !/P =(L07^D(PGL8LW00]Y5!3V<%LN$$ VT(]GJ0,2 M))4J296=N96F:)9:J G8^)DG0EW3YX)&Z !(B N.L(1VT(1V\(11B)H(4(57 MF(5;" U=" SIT YA& \%D(B:( ,(D(B+@ ]7H GXT2,+<9S)R8=S* ?3Z9!5 M&(BC0(C2F8C5>9U*4H61. J4V)W461#6:8I5V(FC\(FH>)A^1I@ \(H0$@7^ M8@\]4(UV@!0?\!W:R(W>> <#T D#, L#D $T @%H*"$0 (2@ %@* &:J ( MR@,%8*$*BJ *.J$#8)X3,(NU.)]X!H5\X>TR(GSJ0GI&9':9,XR0_KT $^ZJ0X M&A8ZJD*)< ]R0\$<)2R9@))NJ1-VJ+8>5TP*J,F2:,>N@A7:@Q9BI4%P!71 M@ Z-"@5<:B^:X*5@*J1D>@1F.HU?21/TIH%20!B2(8 "P8) MX 5WM9H-N$!'F [/H%L>D(L_1!-B"0^X&(?#F*85"QAWL"_(LVPRQ7VSA6FC M0@?8%@9"-49%Q5<*PP1$L@MR8 *,D T[$ UU0 [, R@UK*& +,R2[,VB[. MP2&+L0N:P+,S6[,W*U4.DY 6&8;^"BI#H0!.D*]Q\ ]_R &2F(O- P#PH %= M"0^,8 !8FP@/JV"YN !BFP.W50+_L XHX!$>D ,1&Z.1^8<@((EQN[5=VY7T M$+9W2[9Q&PIQB[9W6P?/\(<4((EPJ+=>>R+4ET\'1HNA8(L[\)^/TSPL\A1(D4 M+6(TX*2/."^+RG595F41NT'L"%AA-,W1L$8,&1GQERBD+P( -G8\:"/A0I$D M34:<6/%BQI8O8\ZL>3.GE84(A@P12M2H0$5&#( U@>C N@Q+/VIR%T E,0)/ MV1X8R:\E.9@R:=K$B6!GSY]>\)$MRN]H4K@%F2:<6]=$1="4T<#'N ""0 A2%2- )4 @-%EV&G' MG7?@B4<>/N8UF)Z#_.#GGCY\P" ???C(D8*1Z?WA 1_SD33'!9S98V$!!@! MG@'F(; ":!MTMLX#G/FC((,.XI..'O]H)5A7")R6VFJ@N0:;;+1%@)]NO/D& MP +0T'&<%;BEEM=T6Z'[-Q:T(@1]DB4 M !+:%!MB__$*#SQ$GDGA/+$(/!\\;67?'ON&53+>_8&:-(E-[M?"SO/VG<# M@"+EC\9.L@[$/COXFCRQ?OMS+M30/P_P,8'^)OC'$1@0H2\P8 DFH452&D _ M< # $_CCREK^<8 ^6 M:O$" @(XP (>4"\*7 <$YH>^\'G'#2PS'SL R#__ ML;"#Q# @ A\20@:64!,.A"#O)EC!"Z9E@C"4(0B3,D)NT>^$*70?3@00"IS] MPP$X6P PZ-"?3M@,9ZK1Q#0(8!$'^:,'&@!0?QSX!PCT0"!UZ(\C -"#!@" M#@Y(AS78^ *,+9E:S=72 ()DDB"7113-% %('$7$ .JSACY7\PP T M"P7-=D!(/FB#DZIY(LYDR8-7TFP1V#!E(#&1CG/8R =83&,ZG/ /7?)@'27 MA4 >:1%&@@ U%PD$:2)34TDLII$>"+,T(6S:(QC$8< PPYH"3,^+",=(]3$ M72R2CD?8R _^2 =&# (?(* #U+HIS_^T 0!(DX9BG$FU)R)2.<. M!)J .F0 %]?,)HE>";.&\B 5=:M#.M81/SOXPYN0#.?+>DG(=*CBI/.DP&>^ M"($W?N /#.C! -XXG+K!<2-@?&,$UD$!3;!@6@#0Q J0J@D2(!47S5S' &;* M.RML*WQ>4.0@_*& .K3HD"@%9R.[^4UM2K*3#*!763>ZTDI>,I-T&*$-0FD# M2UI!E6_HQTJ\,),9 &,4,!L%SD9!LV70ZQ^*7 0\OB5%.M3$&#V8P!N)@-,> MN :..GUC"=8!!(N\407KR($\%4D0,N2 (&+(08L"( *)Z"9A"/#D:"UB5*2N M(P*:&(8BUZ$ 32#6(CV( (#LX85E+$.5BOC'6*&@RA7\@T3+\&OA@ $%NG73 M-9+8P$I*\ \ S$FZS,)%ER2"75,%1KI0Q:9XKPN [&ZWNW/*EA4&X0--Y M?AA#<]2!@^P

QP4H_(\[8.P?-]#$. C@@ +<")B.$,8Z$J"):K"X # 6 M1L,21)(%"XI0[X;!F-[GIHN,C23;2L .TD>3[TOG M*-\8+9ZQACO$XU/3C:.)\ZPEG"^+5SK,P((U[KF+Z]]_0%@%WK@B";VH@\NZ81'.L84\@(]MDWJ,VM< MU:9F]M#!)KC,74SS8T-:V0Q'35'PP?-N2[G% M$!K$'P2@SPDDRQ[)HD>+#M#::"&U6@O!APG$3G8ZF-T.^D@6/EKT@;9+"[80 MBB'+&T:LH= !"9;^>+1#_NF2E)S/V>$Q/X;.@(A7N_'9$? Z!.!7!S$C\%_P M=>@)SX]B'3[Q@0)YT3'_> !%OMF35SR0*R]Y3E_^V@+8?.>-X S0BQX!I#<] MXB4_=,;GI?5U>+W#95\HVL/>]A0OB79RSWE@. @:OO=@\ T_?-@7?_7'WS?D M40_MV5L^^IFG_NZED?T80F#[_C@]\9E/] BS7ORN)W^]I5U[:J-_^KIG?49 M#>WW!10 ?_+G??1G?)B!?,KG;*D7;0!8?0YB#06( 0C8?R#8?.=G@9J' M@48@#P4( C,X?SM8?TEQ?[8V?D98?CS8?T;V?S^X>]CP/.P !<_##5@X/,P M!?3R P @!=I%#)IF!-R091+!95ZF,(D!@QF38!KS&=Z AEO6901P(W'GAA;3 M$(FP'9\!#G2HAG?(AG(G>&^H !ES!(FB*UHFB'C8AH9H,0Z0B)5G!%@F#8UH MAX]8B*'WAA*0B!#P&>80B)I(B'IX!1:0B#)E!.Q BFMX&9P(8A:C 8EX'T'H MBH,(BZ?H 8G( 9^!#KBXB:@(*8G C08@O87 M?DOX1G?G#\G"#RUR W[W=M43CT_X?/[G@^H'#+R3+8S@!?YP&OS !"+ #;(0 "NP#9$P!-&0#D8V#KEW M#XE0!0J0"%V (E0! :0"$U &8J (G0 ,.P"$R (.0#P_P!PH0"/G0FW_@ M -:Y#FXPGNA0 QR "P ".M !HO !:UBD- 0IP#0!P00#>L0#=JP (=#!0*P M %1PA_F 7P9@3M$ #>*@#PK@#0J@#;' "+@ -H0#=L0 MA?.0"[TY#OM@IF+:!65:!&A:!6I: 6T:L/EP4S- .7W R0;LA,P"ZCJ :LJ M %Q@J_M0 '2P ("P#[31*M) *>N@ 2L@#8PYJ(M;!Q#PI%'+6WXJ"AI0I(!@ MG>EP"*_!!0*@ !R@ %P0 _K,51@ ( 3W< 0HP# IP#),@"9=+L1#@!_, M".'P ./0 5;@"\TT#<(P#< P#>:P",XP L@P \$P O(P ]:P ,:@ -^@ -F@ M"/W@!:>:JJL:JZ[: K%JC[1JJ_F JR"PJW2P ;XJ!PRP#A5PM2* #.";K,O: MK(,@#0"0!_V1!_^0L=-Z %'[I%3[#]>:,78[#%5@!4&:':J;'4P 8HLPN[W0 MM/[S!P"6#'4@ IKC55)4!QK@"TTZ PO\FM/PI/4P"--@(]%@(P+<"[OA"T @ MMG6@ (<0#8>P#),P".X >L@#WBP $XP , P =LP (@#^6KJJSJJC"POG10 >U[JW0P O+K 4\J!PVP#ABP#HUP MM2/P# H0##?Y!TP+ !.0#Q.0#1,0#1.0#GB #I> P!EV#]6PP"^,#3$\PP%L M(]4 HJLP"0 !PP%L(ZLDK:JT:M [!%V&5;%RY9"[14X0#,H'I ^+!3&0R Z"=+ ^,(!8$2\&%C0,$&1#O6W=/UKV>X ]/4+=)W9 2T.@04;*,3 M9RBZ!AAF"!-)TN1*!D%7 J#C :7*? 3H+%@)M*^V.B/6'4$D )"? P#J_$@' MYI_D.@P*':N#8("T'=?LG%MGP#AR.=\&N3O )\& 8XB$'+#';=V#ZXFT&S'R MQP @*;CEW)MS(%^TJ?^,(/CB)>$B(@0643&PB L"14PH, @/N3TP"!\"Y)8 M*G_448 ]Q 1 QP," ,(-0 ,(@T Q36!\71",. M-.E L\V'BA"CB#B*6*/(/ $5] X!PP3"!P(!5)1 +0B@ \0%*TB3U"Z%K4.- MD$1^5$ M$*"S I/;+#+-(L.L PQ#!O!CPB($G$G%7?:X&(TU- G@#1TP .+/ M/W2 ,,@Z?N0#C3:*R*,(-8J@$PL 'LP$S"JK1-+C)*M8LLH!] VS"#8*:'// M-KL4N0XVBRBS #)T.+"G']"H,P P$TB#AS)+"-8I,.L(<\5] 2S"QP"+,%& M(E0< ZE5S!"#:,#./(-HX HY\!2;D)33^-]*' *K$4D!@=8 2BC[AT$#$+ M!(&HTZU ^A4 B#D/*#!/K[QR$8 B)&05#3C13!,-),:-7?;9:9-M-MK2".0H MI +-7//-.7\QC")<&##(. \LP 4!@@NP >Z% G(,A"LPPK??@,N..%<&,Z! M@XG3>DG55S_ =7]?ATV /\A 0\[:T;2:!SU0P-5"MZM@D=4ZFS#$3RF0$-#* M(@ST4&0?#Q3@SP]\/*!V.B&N4BDN__RQ3CQ)K=,.0QX88+?-P-P,-!T(!*U M*Y/T/$XTT*RB+AU0KS,\I+@3P,\!'RSOT2I)K9+[.NY(8<7.@8C3_ (46,": M!$B .H1@$"H*2B#^0"0@\"$"B[B" ?KWOPLLX J&NT(!BX /+VAA& C$DP\6 MV$ ^W"""$_3?'Q9@00Q>,#5J,L .)'@'#\A! _HAP P)< <*R $"^A' # 5P M!P7(@3\4V,$%[E"7>5RA%@% 1R$HD L# ( ?\RA%/KZP#E7$(@!T.505%L&. M1IA!'PQ9A%46X0<#*"(8,BB" F0 ,$0801_W0< BNH WU4D!RGZ719V,(P^ M($ &35# ) YQCW4, $ *0(03]M$K!"3""?P(Y$=F,HP> $ ?O "FOI3%R;D M9S_I@$$ IG"K;["1 .A@P#^^L 4Y_""0#C2!(@ F@SOJ0(Z*N*,"@ &;=5 M2O]0A!QE$(Q%W..5Z "'/^10 4?N,I)&V,"Q@G_81A^YZ< "#"!RDW E!/8 MSQS(P*^)8J.B=^+F.J@ "#OL(P K(, &*KT[@' M-.QAT7I,X!@3^,8$GC&!:_CBDPJP!QY(X 0Z6 :9O '^5"G.GA(!P@!L ,_ M+ 8) &RSF\" YSX L X0@-4?3XWJ5*O:H0_%)Y-^Z&9%1!"(P$Z,!/QX)<(: MU:-%<',5P=R'*NBSB')T01A61-);/74 +&T6&.C0A03D"H"D7&H1R%@$--9! MC#&6,:RV4Z,>VPA)1$;2"?[8HQZ)T,??H0"7?;@!(?D0@$GX[B,3&, PD.#' M/@P!",?] Q2PA XS2 7-YDAO*!IA7Y\00XX"(0A)W:4$5@!F2\%UB_1*1> 6'?*@QSJ0 5TU)>1Z)! /=!!A P9 M !L P, 7%N"J!3PA&N88Z]O29HX*0&P0T\@0M33$H0%\Z CI]0,!%JNP2$$V MGG!1GB@MBUD 5.%6+H!P1Q?Q#&?:PP@/ 0=^.,$ *A1 #\>@)"_XP0&3, . M#IC /WX<9#H$X EX,0(#[F$& @P &1.0QR!,XE@(+ 8=+@ EP'PY3"/V$Q 'R"&\Y;-T!P[XSG$CG4 E[WLYSP[5@)GIH,"UESG.^?99/N+ M1Z"YW!Q\3$ ;TX*SF=&LYBX/P-*8IE:9*3T ;$Q &8.P!IP1C682S/G3E\YT MJE<]Z%*?>M:')C68Y;$(:US""U](B&O-B(]%> $!_[B# 9)-@&0+X!\W2 H4 M8DO;(\Q1CG;LQR*(LX@C(" 0_OB=#YK[!'!/[ /']4,$5F",YCX@ND>@;B0@ M@%U:,0!)=*D%+ =![R+Y5]LJ1@<3YI&.:N3JF0%7PS[D, \2%HD/TD#'$>:Q MCG,L8A[H#7@4%JZ-=3!C*?XPV2*L8(]MRU >=QC "JP1!,?2XQ[VJ$ ""! M9DB2'TO1!Q30J"1 2_((P-6H$<&[& /<Z.HA/= M"D>W SV<#G5S5/WJIL[ZUKO^];"/?0!EW]#9W:'VM!N![4F7BCLN.??7X]T> M>K<'W_U^ZJ78(P!.P$<$K* /"%B!'Y:0O DL4<"C&,!E+<\TN4ACGI$_?/F MP+K6#7#U8)C="ZP?.MSK#OZEP&/;7BZY6V8]!P(BG!42;54WE /'@8 $^ %]C !P?=D^B !QY -$C4C M+^4-\1%R_X!D>2555'4/@+ A(^ "N:5B!Y,P+B80 MP=0/F"!CE7595N1::<1;Z98"S84"@, '"I ;+( .?! /Z' #1N8#$,805H . MB] /5V %4R@/^? /3" 1#P8 #$ ?"8%>_H .4Y /ZR /4(0.3N >8$."1 / MQU $#;0.X9!&4&AD?"1Y_+%UB] $ A -^\ >0P!1])(-@Z /_C ''3 %41 J MIZ6%%0AS3K #\& '$F $=5:!BQ -8((_[@$BV+ .%V $EC@' 6 )6; %N=Z$/T6 &_* V9I,ZTB '&Y '[K # M^]%#- 37-A;A,-Y)@']3 0W(K?F /+-8C6/!B_I"#@& "U0 O/ +N.%8_& ; MX58' G /V# "^. "BE )\O "& !'TE9EC4,AQ -A[ ,DV 09B8-=: *.;F3 M/IF3/DEA=: )O^ 136(R-!$]H< _*@1 F0X5) :-+"&V\ NU@$Z1 )1N9. M%+1"%; 56 X0%<'Y+ .'."#MV('_*%B>:1;S;4+P.6)T$!(?U 7TZ T$[,# MD*0#B<0'2? '/3!<-/ '/' ?,E0$!E '*% +QN(")D$'/G ?.K1U=8 !]R%$ M12 =0 !@- / D '2X F.U #K*+0&!,120:=: NPA&" ";]K"+Y>21 ""& MP@ MB\ !*] !I+0!C];P7D'RKD-@' . M_$ 'KK .LY"=VWD*ZV +K E?(($Q?1 !LUF$"B A X";B*";EK(?8TF5 W25 M=. -:R@J7;D.X%">0S(Q$X">Z@D !,"> 5 ' ] )Q&?'SD,NYA.]#F5 72? MJ>$-L[D.V; 0. 9ACF5D7E 73I ?5L SYV05:P$/\K4(Q68I*5,RTH 6$$ > M#&"(_4(OW_ \T7 .OP Q'[A7U[ 431&BEQ05);I=/09SFBAD"F!L1N8$@3@^ MGL@4M19Z$W /6'>E*+,(SK ")6<$*>EI5HJE8_JAI#:F66I4X[!7SY0R7?JE M7 <.:>I8W&<&=(:F96H$=>IENR9E;29F9*:G]R"G?B8530&E51$5;01/1[A- M" Q8J@09$0]!@ +#& /?-8"# EC =@!+C- .>8%1!F BMY*'RF0!,"!' MZ" )^) (!9 (CY<([)0([O0%!L$ 8Y1C . "B] !O@J(O@ITONH6+BE'.F $ M"D '-'!V *!V 6D%.@67 % ! !4#I\!! !<-D%Z= 'YV0#$,8/X-,*D= *DM *E] *K9 ( M^@H C-11/)"@$7"MV7I4V^!45'4-5[H.$N >%D@P^*)7$WNE1Q *$'8)-"@0 MDJ*+O @_O DMCPH)#6 +J@ )!J "$#-S T "(@ )!9 @N3,+Y #0 -/@L M:#-S;H 2W ,.^ "0OM.0& !F; &0EL ,\< 12 )60$)"% -1:!JD' ,[>R M#8 (_P"S?S"S & *FO"R!7"$N?,'YD 6P +!; %0CL ,_<.)K ) : !H#!S M.-L!SL -D_ )T)([,_< L; $]["R!U!J>["I,#MSZ. ,ZX .0= /+O /-O " M%( +,4 !!78#=W*P6(@.634(7\@ PX .(X"YFAL)G3L)H(L.&> /J]L)E0L! M_8 .XE"YR? /Z$ ._S ,-2 ,:! "HJ -#Y ,?CL 8'L%51"Y9NL+,C #N3, M4=L''I $DD ""2"T!#!SO. /QA ''""T!\ %_V !7;"T,X<-NZ #?HL "L MA>NU0HL Y] /A0$ O4 *UK '[D &7# +_@U #O; %A- -]A#"?U --2 V#D'S "^PP9;5WB%Z( +]K!-\@0 MOR *%3 (?M M):Z/0 QQ+&!@W ,#*"A5"Q/ M#H(.;4!796!L_K $+OD)"2(5_K M,;<(^X!@9;#%7;P(>7@%C5 $]# *$%9@ MOB /4H@.AT /Z* (Z7"%4S@+\O#% %"Z/6 /J MA&( .(F!D51P(QR -%8!@ M)R#(FERZBR!FJ6N3"<$0 )8.!X( X/ 'PE*&'Z .ZR "A QA@T"' X .4+ / MF6L#0% !N" $%5!@W&3)Z, !]/#)8%@I#,JRV NSGY0[J?"R?0&^>!"]!N"W M:3("-UL 40N7B1 M E$_/L( R4P %X +!G !!>8"^P"RC%>Z 3 /UAR&]3$,NP /%\ %*; #JH!= M=?N]+(L&Y*S.N:,+-&"]9%T I[!&!AXNB0JE,/#"$%43 %.R?)>Z 5(!#*R6!Q![L(Q& %TX8.]P#;Q, C6 ' M_A#;$,8 LXT.6=((P,$05X .$0 /5_ /:F7>_( .T@#;7RAA,R9LDWHK]X . M::#<8(P"QAW*RK$(I-L(+E&ZHQ /7FS=YEV&F<#>H"S+DLH.#''+'V$$V V& MV]T'YO /= C>Z# *[X#A,# /Z, %%N.S@,A\(VA2LH/ Z '!8 .IZ /CH0.2J/G_+!:J[4.//!CW40'B#[? MR[#H]P#G>A,Z) (^M (?'!WQD#JE2X C'0)SAW>,2 HBK=:@AX M)EF: R #7O /B- %"A#I1E8.-C/D!VOK'.W11% .>=1<.)!N+G HB^ -2, ' M!X ..& .\/)%M0 AO &2#[-^Y %*Y&@#A %Z) $Y? /38 THP#[I %B, & MSWZPEG(GBH8.+U .CP P7(@ Z[ .0L[?$&;MT(X..5 .OQSQU7[K%2\-:PD! M&C_Q'._1!% .Z( ,Y0 (0I,;&:!UO?41#=!<#,"Z_6"P$#8,^I9O4?0# H!= M0) 7AV*Z&&\.N/!)Z^ (5_#M\Z6N/ " )#T%)^'_P -C_P%[V#S1L8.N+ES M0+@ / '3M #P/ /?J %Z, #^4Z'FJMJ'6D2\P ()6&@LDX#Z? (!J!J.Y?> MA9#O76CK#)#$Z* $[8 %T8 /<] "QT A4 &QT $>$QI! /A_T<;"6/U^&[S .ZY #B0\QC9\@;H4?JD\$5@0(0) (O&4, M &-D_N#=,S])C^P+[O#([< .)IF@!ZIHX;KH PNP. O +*=@/T9 .=" 670$1P#MT[[NBY . MBI -M]"KBH#'1K;<(; !9&0# M).T- % ,F%BPF,@(U^ (_\0,F# )?,X-<@"L_W )=] !-A (>3C]=V !-K ( M)N - / !64 I];$%6* %S["&ZKP.ZL ,%0<%4> !%O !H( ABN ;!\./P ( M\? #"E ,B@ .(A .,@ .$!(3 L ($ (P3 A+R$*&"("P< #(% '#? !68 % MPT "?R *&/(!68 %$"H -= ,(6 #B> !0&L#C& &V(#BV "W@ 'Y %E%(? M6X %6F #_^ "0.N(4@#DM: 9\(!BG#*Z& /Y2 +#R "UR PF /Y: +\ M(C -B3$ PI +1W@/X? WWS$,6K"*"\X0ND0$"5 "@ T* 4<@3DNL1;TP . M$5<-"O +$' "]W .D^#?!H .J/ /RB4!UK (FG(.DQ J]W .7R8!UB =)1X) M_Z!$'H3Y % M40 +9 #DDF /@D(-U* 'J\ X" )U* 'J\ -F(.JY %6+#@L<5;O]DK=;$? MBW""90P ?( #+4 @?/ !?S #2K, WB '2[0"X*8#:R '#W '(\ 1/V 'FK]PDZP /ZW &Z^ &+ !?> AFB! M_0(-W. /P, '\B Y)!GLJ9J)&8)O@ !)Y!W,(=_Z+#L39)[^)=[QGQ.TY![ MN8<.17!.1V4/Z. #_T -"@#D'J\ Q* *:J1/ ,-R#!959T5N?"]\Z *ZZ . M'A,,_0 +F; .\. /(( (2 !(< !(6 "(= "(; $(4 #(1 -)& $)< *)> * M)1 *!J ) E *!S $ < -(3 .(= .(: .(4 /(3 /(< /(; /(1 *!J ) E * M!S $ 7 "!B . A !X '$B(";B ""S "F" "?2 "J" ";B "B" "N" ";B " MV2 ";S "03 "?# "1C "8C ":X@%_9 .;5 =T "$ ("=1 /0E CC/ -)(!F M#L #@, (UR 'L\5#O.('%& "K& (X&#GZR #/) =9 )M#X-4\.Z: #!9 . M7- /X ^\ /4@ %4\"A!A %'D!&-D#2W@ Q(")3B + & "K< "-, #"# ' MJ+ +!P ,(L -(L /D0 (KCT'9P (_P $=R !=$ !2<'GCPD!)E"PF,@(WK . M96 "K>!()L *F% 5$E#_\I>YIW (# 6C8 \L$(WC!@ Z!E Z"GC. -Z^ # M Z"L R ?C& -ZT # Z"L Z"GC& -ZZ " R ?C. -ZS " Z"GC. -;#D 6L8( MWL#952$!C -CH -.6,/P2 A,T"* Z"LC& -E@ (+%@' 7 ).<,(T. (V& / MP2 A&C":P' MZ9 ) & /Q0 ""IH.-R NV!%(I -F7L*%P "N, 5(E ,T8 . MT8 .E3":P# '*C#;N0KMNV!%(I -F7L)'P "C! -CA ,OK"I\-((1@8-N7 - M)9"YIG "(%#_=YP@3EUJ]A ,^0$-Z>\E7FH/P8#LOK"IN7 -)9"YIG "( % M4P# & ["& M&Z?C:=*9HX A9T( HZ!JZYX./$!)>9BK;!X.$:ZZLYVKZ +^Q#AJCO;N8H. MU% .$:ZZZ& (M(T( ( +__^%LG"I\M!__Q ) Y ,TX .]+,HN;.ZW)"O$'8F M;6 /@= ,55 %WH$.? .Z[ 29$+ZLPCT5 .T5 . M=3 /P_ +TW\F;$ :$$%@= ,55 %T= .T= .<[ TJ$ "] .=4!QQM,.N8H. M5E .TA$P[2 '\0#M:,$/Z3 #_Q *JK8*P^#4+3#](F$/^6#GL6 9A%Z6 X[^IZT ;=6C$>,/<($^ M7/SYM*T*W! ![L.59#&VGT-7+H"X#\:#F !:B'^Y \ YC].I=!-%@!AZT # M]E ,!T '+["&I("&*##;Z'0(*X86 B .XI0*N9);!YM%Z> )N9);!YM%6%_W M 4 6(N^!$ "& "&#Y":( "$ :*, !* [)" +)/ +)/ +)" ,$? /$? + M)/ +). ! .#TGQ0% " &' ( A #%)" *%Z )&$ "%: !%G +)/ +)/ +)/ + M)* /#Q %&= "#_ +)- !!0 #XT\"OT "3!H PV#[1S@,M P$W5 I4)0. ) / MPT .)+ !)7 /)& )3 ")6 #); +'P (M -+GD(34 "F' )\I>YI5 ,)##; MN9JYE] &) #MZ5 .^>^A_H +W% "4)"YI] &)"#QN)^KF7L);4 "T)X.P>!@ MV9T.N?"$$P\#4+3#](F$/^6#GL6 3C]=_ &P-A (-A:9\ ;@0Y8#7[QT MV8)%RS-FZ]P!@)2@AC T(41I>Y#,WP^+R_/<#@!!@_P @00E "4M( WX4 M(N,MWXQY!&J1! T)]8 -89B"5@G8!8!#9E*U=E$;M&9OQMZN9'JB(S_SS) M>5#'!:!\ NH8F(I-*;IU'N@XV,. ["87V0Q0 *"4W+JVWK*]C3NW;KI3=+.% M>[O-!4^ER93BJR5 !#MH[:96W70UJYYHL :(( :-7&=HT CP _TU+ $!P6H! M('$ 50 Z!39Y2[=NP%2]V>1])4 G!:H!>FQG2YPMV"9LR! ?3^[->#9]T-!% MEU&,CG!PLO.MBZ$('#1V@,@%D%'.NE)PO_5P4)Z-G&2I]HS\ T)G@6R]< T8 MKIU]4;DNPRC%E%-0246555AY$HD=8]6#,!F#S$\7D#6.KPML$<"%L:%06!VD: 4 M,)MLX\>3@51%4AT2M,E/3W78-V*-2FDG7#Q !IB-.K$$L,X"*R2SS@%*I1/H M.@",TZ* 2T+%CV3\.*K<5?UX,HD<$-1A EF6=E/6B.F@TJAMHM;W99@&<$!F M.I#P9*DWQ WF C86@$ 759/&UT\0]2D%CUFR!;-.&,06IY0?DV;3#R!.]/. M4FXTRP\@9O0S#[63?F.%5,.=QUX_M]78IC__//!'K,(2VUPT;O@S!Y@RDD 7 MK9M\8P2XQ)';33;V',/C6'=ZP^=_PRP)A14>Q'< CP'L4XP= BQ"Q#\LT, # M C .XHX @1#@S"B)4+S."'>8<"4(77DL0,D"&).4$8H04P(P!T2G,SHT8%" M"=@D0L '7F#1Q3,\)'!' BX?0P"[ZQBS#CN,# #* +$,8,L [0SPSP )$. M 3( 8 , .@"P0@">!$!) )D$X$\ !0B0@ #[+&S DL38@8 )K92, _S4 M(.P08,45BUBAP.\,!,2$ 38 !!D.\(=F\* +!(A&.*#AC7'$(1#Y ,"I &'2IPC'W]XQ_-V,&^++@."_:CA-GP8#@TEX<'6! <@/"# OXA%B)Z M,!CI0 0 [C"%@!"! #98 !$$$,8&&6$=$+ % $J(C2A.42T6=, 77! !%!R #F[X@Y>^!*8P16E,7(1!FI,T MKK@.,<2*G_J4 T8%N0YY%)*(ZU#'26_@ C.(H*(1W6@-P+$.8!3TH @X:0WD M.(M"6M(.G*0#)^7 23B(X)?!A )2'5!-/"CSE;&<92UOF>A0AN,X " 8 8"H #7 M-_@#"Q;D!UQ?8#1SXA,7\/C#",C7 R ,80X1&(0/ @& ?"! -GXQSID$$YW MQ&H=+*BD#0C!24%P$A"<]$,H1ZE4:5;3$$\M0%1I:4NQGO.P_U L8PT!A#E0 MT@?Z^.P58D7,?]QA .O47/@ 40<%]$ (+I"#.7PQ@* @H ,( )%G$ ).C" "XAS@6@8U # ,#(_# M 4SPCQND>,5>X$<6LK".'D!9RE2V,I:US&4O@UG,9+X# ?(L@&,68@35U(0) M9+D (A@ [AD@%0O@ &H]A>6 ,@"+S71"P'PQ)ST(\ ,DH$+?PQA%VKX 8_' M)!9<^ $(H/Y!_BP0#7%$ R;J"(0^@<<('[Z0 Y M\ "@=]1 ..GQ63K$RA>6+B%[1_!$;.-#A>O 74!$ I5C #9H4#%QXW CU"8 M8N3Z"$5[QX>/=6S %[ ,A3)&[H]0(&/D)3<&RD-!C)%?'+RF1)<=^&'*6=L! M'_5U[3&9 >C]]G>JN-2E%VS[9A,,X@<- *J?O4"U*$ M4#6**#G,#OHQX'[&D,]W@[F+Q)IU!,.@PQ)VD/<-I'.=%,!['0:0CE( @._6 M28JR#!-BF!^ 7 (P^<*"[ .BA/GC20WQPW@CV^#P]>+*.(K!QXVUF MX^2!\0UA2GHLM;5)/28VFLY?J=HRZB!]=Q%L/^ %-. (U\$3Q00^OP0IQ M]P^"8@KP=%;C$ CK($&+, V1$ 33, [3L ])$ D[H UU T9E#\2H A>0 'S M] " ( [PH #3, W*X _(P ?$QD&M-@?UL$'*L [P@$0/!0A(1 <&$'X*M4O< MM"16L$X&T .\P Y]$(;;-PL T -$, %^D%,U8 !80 +I8 H 0'E5=$'IP E] M6'D"< _8X L' C4$_F$ WF8$&$P TC$ WH0(F6B YS@%$TX #\, *#MPYJ M\%&8B%$X<'\D0(ESD%,LA0"0IP/)@(JJZ (2T(JOB(FQR &T"(O,Y@(FD(NV MN(LPX(NIN(LZ((RQ2 3&N(M.0(L.N1(_C P'( MI@CZDX3? CZ8 1U8HA^ $K SYN X)0'E_@':PI) :01T0 ! \ _Q:$H4 M8$H2T ,\X0?(M2^ME693\$MV UGF%2:8&G$@ &30 Q^P #\$ C[0&L(()/^ M\ <[M XE@ LKD 1 !GL" 1 L JXX 1&L KIL'D\Z00_20=!.92P$ 1(B0X] MP2RP-P"PT *JP(\*D(1?$)%T@(3Z4 1TT 8%U0]\8&M> %_, 8%A0)_X 4+ ML U_\ "X ,NL JY $LN! LPH I#4 ?\D L\80.LH # 0 <*H I+4 ?V LN MH I!H(7K! $#X 3^L /!8 <-L +!L C(, #8X)?SP)CIM@1T, %1I&)UT !< MN0A.P "'\ WHP S^< C[L ,O.7A^J0KK, :Q8@.MH J0J0#D0 <=L)7$H J& MB9AUD ^KZ6.NJ3^P*9NTN0FWN0^P (B8 0*P !%H H\V0)+T <$8 C$< _; MH J3D LP ,], ;UF $]< X#8 <*D F[@ X#< _S@!JJ( FS0 ;V\)_!H KH MB0FSH#GS, #!L HR RJ@!!3]Q_* $ @&GL@ %P9P3M !QYPX!$'?O *)& M \F&@_$)P^B!TN[R :0=P-KHD(&X L]\0M[9 3R8$H08$JH%&5K1GE]0'B4 MA0F38 _#P%P'8 ^'$ DK_ *19$$4B6@<6$$4E2@<0P -) (8\X 2P(13I( X!D XA M$#-&(!$\X )T( ,\D -WL (\ -R< (L .8< 1_0 .( 'J_ $O.&0OW\ V! MX \]00>IX 3K8 JP4 :P(GH_M YMD Z& "?2B?M<#H+\ ]^L B+< _K< B# M\ \%< <4, FXD"'W8 ;V, ##( '6,#[V$&/XD YN\ ^]*@%W0 /"2JQF<&PD M-ZQ99@;Z,#[Z( 7<6JSXP'+BBJW'.@S,&@%6@ ]:P*[Z\*Y6P _I( /_T$/& MQV,2 !\D*9IRE1KJ@ O1J4FM7T#V*O^0 ?:$*O,53'WD A^H XE@PXK\ \\ M0)8$P -E4 =2,*9\T 5FRJ,^NJ8&L&98JJ5<:@%?"@\>^P,ABZ8CRZ:)>@<= M$*ER< &8< FZ0*SB, #X$ C_,(=^8 TS\ ]Q%P^"X@P$ ,B>TJEY 4"ZV0$ M&Q\L"QN=:@]>P"=>H YSV89Q!(JQ IOHL C!, #'$$5(6Q]H2T4E\+6-]D/, MRG+@.F.'5$#-%C#%9VF;%;;#4% 28 <#L O[ZJ KL P#D ]!Y ;VL C'0'ET M< %]4(C8($N6!A!T< %(,&!9\*]/@68Z\JT;@# 9(#_M -!A6 ,<,3\4%GF1 M9R) AXL8--(SD:C#@72- /PS(N^?'0@N'?SS8B!+EG].)/"1P\-)'3/2,*"$B,@2L "B;W=C#K)FSNF8]_ME0-4(VJMHV3.$F M-4+3 8,!"CV8Q'MP^PU_7XK "!Q >I[0TW4'S;C^0G9@!#?4,UZ\U^7O? M!>\/%.U0( WP#5PX<1[9D/=H_)BRY'MI! GI06-!(?E!X@(L?)$"! M2P&G:=( ."$Y)A][.!GP"+^10,.'07(D94^%5XH&R(>&N(A(1X*,N)V)9YH M0(JX*-)B:3'.6"-].%HQG0F+7"$ F >8\,\!BV#CB# F*'( )HO LX@Q"P!3 M1P&X_///.@+,Z<5CE;$S' )F/@"H99@Y,)@\AIE(6)0LN?B/>8Y.Z0 N,9QV MJ0$QXG. 88,08P%X]L VB!^%_8$ C_*DD-\Z#)Q*CP!U&'", 7\ ( ( /"JP M@']T0+"(%:OF-YP")(E)T@%8<%P&JN-^_?T7 MX!P4%'A@@@=DLP]""CWH SP3%BF9;)9X2(F'DG@XX9-00#JEBIA<"2,4,M)H MXZ&7L>. %5FL_%4P)":M!'^M/#/#[I T,0]ZDQ" M2Q.*&-$/-.#80\X PPPB#0#W8",ZKT:T#Y M@C!QTG%!'P*43K 0TD#U_')300@U-H0GQQC=#0S9'TP.;/4;44P0=% @Q MQ"#[2'"' :="4'L+"-DASQ+K@#D,$L,7+Y#TU.> = _8UY-6 THL47[MRG." M/(8P%7XT8P=VD(X?$#" ?5Q!4 8P$ 5"D#'$NB $40 X8RK$,YM@"(0V &74[6YYV]L0/[6(8:S " A8 3+L0*AC'.!D0Q '/OB! M)F$LAC[*,%^@,.,!'AD@$480QZ 8801S),(+Y. 1 W[E "!&Q@#MN,H!AL, MF4DE!UY Q^+V:(0^'M( *ES'(+T 4-&Q@LXFX\1- !'?_ ( W#D!X\L $=] M\(@"<,2'H\1!,.>L ,VJ5,=?F"Q)8 ,9/^XA2W+&.%1=C! M NP!Q_*Y0\LX,T75P! (FQ@#Q(H@A#X( $F++&.!MS#&X/PQPCNH(Y;U5-/ M<_HF /*T)P#\21G$PQ&L%N$!,)3@EN/XQR?PP8-06/0?#K"H+-/Q#P](H00E MM0)*/: %E)Y31J8!0!805B"+@@";IEE'&XGE1HI:%*.)N(0^>)"(0W#T'U4I M@7;6 0"$N7$&TI!"*P5@#QLQE:;L(,"7PN0 ,!V! 8FP !M*, HUE&!MJZ*) M)B[Q*0#405$&&*MA;F56PZPC!E\BQA<00$=_W%&45O"D$?KF ;,F"UF).,*J MQ%J"4)AU./Q(5E<3RX!Q)HP PZHL:+Z4@C)E0$Q;?<*8%O&!817+ )K@05L3 M$=A09K97!3#-Z2";K#$E DT\-987(IN(*UPLL9AU0EIW9 $T--8,)5AK6^O0 M ,@RP@#&380'D+L.% Q+L*)T0F6]H(#4KI98<-Q18'G4-YHDZ[='P.QX!UL MYS#5LI@A@#!=@EIO . $&; ):_TZV%/YXQ]UB)4?^ %@ T!UJ;0L[G%+0-O> MHE>]IXTM &:[V]HNR[G0+8%TD;L(!8<"N>VE$*]NM,:LSO>E]L6O?EO;7S_\ M-\"G(G"M#@R,==P PV30L ?$P.#=/C>ZTSUK;@T@80KS5EFWO2YY0_Q>$B,J MJV[\%0* 2.-TV(-70R[ !28\NIO](Q#BT!-K$1#>&21C9QW.<2AXK%S#U.$! M)S: ] !A7_8)!V\X!5C':MA%O/#S#MKLUL'D(Y) ("V81HMFH1KL4$, P:# MB 8 =A -.6R@#@38P3#D4($XN^2_=N#'G,71CU A8!UL0+2R%G& '1!+#BJX MTP[R(X?:V '4HD9'%?IA$]H.X@ !,,$@Q(1E[#)Y!K35*P/Z^M=%.&"L%#6K MD@V$]>"C> 0 E@J Q71!&*()E+,3P2L/' ++IQ6T'$3@[(-35.>F=:.@[]" M.*-#!_^0);/TM X#K(, /,?J8E,2"G^CU6+>-0QK]9'*H1?]Z,,RI1'PH?0* M-+WH4+>"W.G.5L-P<6S_8.@Z3D",E#-[MR[1ATOP@0YC^$.6" "\X%>U7GZ M&T>T4()&$."(_#0C!$(2O *F0+"+LT,@5\51?!DV WL,AA^&F<$_"+D2H;D) M$4;X!P_DH$%?F.87.5W!0_YQ!^;Z0@ Q'RP@ / +XJT# \,/@_$%D(#7+[_Y M%"J =M)AB4-[P?8'P+V>_#/\%="A H0T 2!^L((ZM&#X=)CF\,50AQ"4OPX) M2/_M"!27@#AEP*RHU(X-"$C= 7OFV M+(MP#$QU1HXA# P "4F7^?D$@3@*/P *?X !>A0#_Z0?HDE '5"!RF0?H#P M!Z+1!S;P:2Y!8, D3)IP P"P!AE@:NF'".FE ,#0!Q>0?L:07K/W?29P#$= M/#LG#4OU!OJ77IA ,#UH#/GUA/GGAH$@6@ @ +@PB%"0?O<0AX,()%C")^A! M(D1A!PR@":*!#&%(#'L$#.<7B9/(*=R0<32V#A.P#A&0?G!H/ECF 'H$;CSH M@T^F;U[@#Z\G!R; )TQ%6U,H&GPP =/&#X,P6!2P"P* HR0#9HF!^& BU0( M 'R *&H .M >=@%;L/P@^B@"O^P7Z&T -"@0:&8 >MP 5@8:IXFB2X10ZK0 M(".&,,/158MP!!(P:PXP3:'X2V#A )K@B1G0&%\1B0A 7R[! .>(#FV@CEA% M -#$C V #K*GC8/%C3-&AS7V 9D3,15&AD"(:Y"XA5R$#BV@CI;51DY +3 M \5@!=01 A\@!UN# *4' *=W5<+ *4+G!02P LFP M) "T#P>3))/#\H;GZ@ M /=P#!ZH01K(@1ZX /A0E 0 '5 :)\ *' B@0 OZA1ZD "%"9 ,UB<3") M >@19P5#!1H0*F\T6+$!8!/P&5D M#Q2R-490E(!)![_TC^>$'N@ !/\0)W-2)P8Q)^G0# !@!9KP*>R07PVX#AE0 MCOR #AS0F"$(F04@F2.8#@?R>H9Q!60I&H5PB3LRFL# !V6 'I;Y P#!G7 M25LI$290@0 DX)"'2@ 3SB#R@% T G,H5C M#/X08Q+! 80I$1;0+,U"EC-BEJ:63GS0 4XI37@" !#@B,"P"-< 9O^ #PO M.]X ,D4UC'.2@XSA9.Q@!; 0 &M#E,% /! ("\$3#*)1!P( "P#@ 2=I +$ M#R+@! J@ ,% "SWP>2MY 8X)&BB%#S,""(N0G^.PG]9E#-'XDC'I4 ?),#6X M"#.XA#9I HDH !=8@OU)>#>J;(=G>(.E?C^@ '40 $ +.^( %_26Y/U59QXCE^B"'A(,# R M EDZ"(H'@6N)35PG &&G>B:F;2]UI5V@ ;&DB9&G)X+G!,U"(HFZJ)K0J&=) M#&3F9V5ZICN%75)E==J9"6FR",J !5JP L.P 1TC7M.XCIA* %;@"Q0 (P0 MB[-8BR" :''8@0/0 PC"7./(#YK J9Z:!;_(#QEA#$UJ)]GPGUU0C991@SFZ MB . #J_0A@1@)N,SHW_J58)ZHX1*$E\E536HJ 20AYJ F_6PC^50@[=5)W[P M #5HIP+P#?^P5#? -35HIFYE 3/ZK'_@#\OI?>W:A*18@WR*L;\I6N8C>$TU MI8'R)6="EOH )X L*E78@)@L@^P3B;[52:@;$O0)@= "X<1 P%@L@? !POP M)3D* 5ECL.85B (0LEWZ #U[M**U?&7*.A*! 59'#X^GB5SZ#^F0#A2B">E M#A/F RZP-W5 !6ZT"[18C)I6!TAPJONJAP# AUD@2W]X,0C[#_U0B )PB.9U MKM:))SEEJ=NQD6I*B0!@B:'" .F@!VUX,7X[$>C _[0+([R#WQ[,?K*KZ(A M *N* #U@&G2 V[+KU=J!9[ZN1(1M$Z;M!1" 5M%L1;+G(,:AX)' L/7 &\E MM'%X@5&9#H?0N+]YIPJ;.?^@LY>G(K0(!7,&"MZ6!4R%(QY "T20.<.U-@YP MDIJADG(@8,Z!:8L@#.L C2X)EB^*,(5(!!;S>84( ') -$@#M$ #2U+3E=@ M3L(2IJ\K <-B #L@#'6P !TG *P3"/_U!^?$4.E 0%0(#! MAF1'[M@"":@ MML.@0;?2P#D5AF)+MOH+P6EKC!5L*P8PMJ;QJN!9JE!"ED\ (IPB0J@NP(@ M&G0@ 29[!\A"? APF0 #]E:IW#7P6IME7O5*64B,6(HUJ./3<5U9IZ+E'#SGF07W'R)7 HA[1\!$-,RVWU)6LH7U%K/G0@ J8:RG< =<* M #6@ 5)US$#0P^9UBH;1GS#:)>.&G@404!0 M+C *2[*-:\?+P#@8P!) ![*DBU*OBS7 M5#@2".S@")69T@P U P!]H'#.F0! 0ZU.,@TX=-G.*8T\&DJ:CU,!K0N>E0 M JEM " 3"*^C]#R: M" ?P#^S=F/?-"-'PW-$-5;PZ"-H L@#7R@!7?2 \LG!U.P"/F]W]"]L-+P MWP$>)U9@(H80W6<]VP!0VX(M3L>P \8@-01!VH*W 'JT LC]#S&W BQ*!LO= MW/PMW=2="/$]"+Z0W!)!:%6 W]:MWS'NWZ$SX;)I!RQ0X8UPX9;KU[3=N1MW M@R ^PR..)UR')OZQXBQ:FO[!V$ZEVJR]-P@PP[B UQN)6JK:&-$+!!83V9-= MV0\ !8-=V(<- 5APV?>LV>D\EK)=EJL:FP$%8)C%HMX)&L0S3?=@#*:!:4NU M +>2*S BLOEX H:J 6ZJ8Y3TGKLIPI6MTZDAZU 80ZEAN8%%UUK&- MF PPH% "V&@O.@P!0V%,.4HD!SI !!:\ <_9[(GZ@U_CC%Q*@Z I( ;F.AA M\ C_CZ+.(PCP*TC*5]PU& B@!ST0@\;P*2HB R@ \%SX,$*0I;CP,&YN!0I M\@7P&U+U5/^N"8ML EFJ(C8P\QC/19I@\UDZ+#V/15>E##1I&7%6('@0&]CD M?'/YE :0]:&0]0A?!]D(7OF!YX7+*1^0I9-*#%'W*G9N&=$;!!-:V7%)YV$I MZ@S##QYP$3MR#8*3"WHB#ZY@ (U ]A>A (+_#X1_#]&P OE@ !]P (=P#X4. MN@) "DD0#>DP#Z4P!P% "M_+",+P ?X9;E?0-]44^(/O"HL0#/< #4AP^EUR M!8R@#7\6G]B0^ _'^HSO"H[_U,5P3O-@"HI !/*M"%WP#[SJ"-I ^^F<^KQ_ M#[[?^-'@ 9+O]_- "J4U9-!/O[?O]\/?\T[@ )S/#YX/^J3@_&_O=?..^GY? MH)A^0OQ0E*!+ ..0 *JP^9V_"J"O"H(<*$OO\&HZ9\?0F.70_J(>O4.0.>0O MV2A9V0,0"7A?OL,ZV%V^B/J14U0P(>>;OJ 7!/8@#(!0!SA0&D( :-+PSC'@ MG (@!( F#9\72ONE!5D@!QQ0B$+PSA7@:OZPO7=0 +/&#Z&74PRP5/:<]\*: MSH:,DHB]J7@-P T; 63?@)>85 M)H":QW3MIHZB 1S,IN@ :(>@_\ 9SI=D?R: @#@!EDJZI@A !4I?C%X)GV M!,0;@_] LS8[WY-$*#F:ZPX8W0H@?]&-NZ\=\!^=K5N*P$H0 ,2KL^D@!$U+ M*/]@M(22HQ/B5JI+*#F*H$9+*$BKM%I[ 4U+*$C[E#'HR)Q"!SH0@Q!+!YVI MTQ^=K5N*P&"[#J", P%)KZU.S%X6^FP UJK#&';P&YEME@4P1,,PFP;@ZZL M"7O8AW;RAX1RMWEKB#'XN'CB?()['BFLTX:+N)B8#ECP#\.'I"H0@SG*NQ_0 M+"KB!C,?@Z[<]!O>N:A;!Q] N5+"MX3BRDV_X9V+NG1 IEY *'Z;NUY *$BK MM'MR ,1KO,*:SN.F(A(,!58P9TVPG<3@_H].O^:D $8 P[F^ K8( $[PF)K8 M 7%&>_Z!LWDX9Q&PG<1@ ).J#>F "IRX2MP#^O /EL# $[PF)H(!#[;!P+]?;6' MLS,K-#8[WSE+(:^MIK3G'SB+\$=0:L1@ )-Z"]+L<\KP,$)G!01000^P"W> M FUM#-* #M>@"HI@#")0#->@"HH@#-* #M>@"HH@#")0#->@"C])I9S=?0PS M&*I@&,9@!*T ! $?@#T[0"GY@ E,0!5)@^$;@"BN@ M2B?B"E# FFTA%A)@#$;0"E 0 'X@07[@"@>@!5FP!<-@ /S0"'[@"HG@"VS0 MF+[ !K,'3"; "F8XPSQ0 G00 $?@#T[0"G_0#N@P"WN"#NE "020"+: M!_(]U25 !^60"+[ !@N;#(F@W8)A"&KP#\R)"(Y ]L=@"'#P#^IQ#/>M'GQB M JP@ WD$#6D""&7CZF P!T>@")]P"-8U##VP97B3#C2 6=@ ,B)S"O\ $H0 M #) H '@ P$P"P'0"P'P#P&0 *0 0(0!P$@6BD@ "T@ #$@ -D@ )(P "\P M %'00 2@ @6@ @6@ @70!0%P!@&0#O@P (#0#P!P!QSG"&KP#R&D"8#0#P!P M!Y?A"&H Q7,-"/T '< #H#@"V1O?@2 ")9 ]NFP!_\P"*:@!O_P#;50 .D0 M!_\P"(Z@!O\ K50 .EP!O\ "/T '?@ZX:@!E#L5B0P"(Z@!O^ +40 .E0 M9^GP"0GG]V!RS?DA < "/T@ '.0 ,<-!_]0"X0F>X#0#]?D#<=MW?Y0#+?] M#X#0#P0P!]!0"P20#AOP#Y+ C" "8#0#P)P!QM0"P)P"(8 !UDWF]+@(S3G M(S[R.@%@"'"@M??@#X#0#]0",!T#X:@!O\ S 4 )A5P M!$>0"-74"+ZP!UEG)S,PX'7P C9NW6[5 HO@"VS0F(X !_\P#LV4#_\@-0RN M!O]0 KE. +( WPB"R"@",* #J70#^*0#^G0#:7F"&KP#P0@519P!8IP#'GH MWF]@NK7 M RV0EX/@"LF]P): XT\PWP6 #A4@2O>P"+[ !HWI"7 0>(UJ"&KP#ST (W5@ M 8I@"D#Q-&]P;S:.XZQS#"F>4Q\P(4^#!T#R-%A0!^7B"&KP#T"P!/[C"LDM M 'U@*REN& .@W?]P#X:@!E#L5@S0=; N@@#/NP!#N0#7_@&8:@!O^PHP,/ M ^@ "_O@WD"!#JFP#XM@"0-NC@!_L@#OEP",HP#A*P ME@ JS@[ 5P!/[@!*T M-^@0!_L@#O" 07Z0 (NP#+ NBP!?L@#OE0:/N0",#D]_=@"&KP#\SYOV#2 M []H +@ 0<@237; []H3;BPERI@!*TP $:@"B11 .D !ONP"+: !__0>97E M"VSP#[!0 NAP ?M@ JQ@AG5P#P_1"E#0!^D: ?M Y:J@Y6E$I609#@+ P_"5 M58"V#1TV5GQ6;5Y26"50LU^P;(S3;$-6>(95QU_5_@V6Q(K5BTCLQ!TV5GQV MQ_9Z:BTP'<\U5M(E;4-VQ_9*>:>%Q$X,7UEU+&"R:I-T,0%0)A$@)I&M$3WO M8<@E:,PU'3^F8]3% L<")J(%)MVO6=VE6FKG9^W?8+YEKT#H\-W% 0! QAH' MH/'E;,9%41QF 6K&9GWG5FMA SDF&VQV"?>5<;=B7'-E ,@5>]O0W#OS7#DF M73R6#IEP:$%6LU^@;XSS5ZJF:+@- &!F&!#)!=6J"1P &2L<0Z08Q3%8[TH M:'7 ;=B7'-E ,@5>]O0W#OS7#DF73RV#D8;67JE;QFV82[ET9=P7QFW#AH@ M&\8E&\BU5O>5<1@&9!P&H)BQQ,+V L$V"%] /*$U6MV?=*JE=GJ72GD%$-V? M=%\(,#+B+Y$7?L0.FEAT1<#" R4" @D#@" !=#J%%GD@$R)11[$?+2"8)$1 M YHN';!(!T9" PL;/DS(ST2 R8B-%QDQ9])A%[PF4AT!6:B(P1H#D1@T, Z M!O_L((AJP $Z,_VR9$DHE*'#11 E4K2(L((\DE_4T0#7Q& MR'=' ?;!, 4_D3%CR8(M*G!7"7U]%-Q,=)H(P)6 M^"(13Q"8Y "11F)$!PTSV+,.!EP-8@0^!)CPSQT._7.#)@P 8(0&6@$Q #Q< M/63" D<(0 <#I1+S@0F _ ! '= 889("?C% AP2W1:4 IYZ"FD4! P P:B#^ M ""' ?H. ,PZ7 #P"+&%/! FUL"T&46D15D!#]E#9 .>3SY].U+0\F4R &2 M\O- (&;P P^,5A3:&Z*3*FK$.BQ$.FFEEV9Z0U1QVC'G @# L0&>W4X&5$W& MK/3/N4&9BJJJK%;L*JRRUL$+329$#,#$_-R::TL@'W. 1.T*T&MN!,NI"<(* M,]R3PR"+3'*Y/ZU@S#H(K).C-,\6YT6?RG2*G(T$*$>,'P8P LP"Q] ! IO; ME8#8/_S(X\H]T21!!P3$^! ' &0R,LP"WR3B!S]U.. L,.O8 D [2;UM@G$ M]* VVW2DLUT!"@!#AS@Z@%-'.8MD VL./=31C0?%N#6/*1\RI6$ (O@@@ 6 MP00$4L$ B^"# A9!!P1\X #_\((\.,$)*WC !\! $>0000VH$!)$0 "1U M0@8,@@P,"$ B))B(!R:B@8E08"((\($*0N$W"0 .S" A='U"796D%ISC%(I M1C#!(8R@0A.Y8 !' $-%2+Q"Z!;QC*<9@!^\,< J& &-57 ""ZLP"0'2: 0! ML!$ :0Q&&H611F.,$1NK$%/1 ) B&BF'1PH8Q#X",(AI *!R7VR%(RBP"'"T MHA50@*0D%X&.5BP"'XH$AB(YL AX+&(8S^@C['P5E>*=$%T!L]2F! )V@@ M1K="UTWX]BJ1[;$+RJ .KL27 MP(2",(E)2CL$T X.2.9P9H1$XP'K4UKI)+6 0$V8284JFF"E*^0 3!XY(!%+,-K*\B&!QAQ#$=\PXN:FPX@X$%G@0 "0UREP?@D>@Z@6 ML@ !@#]$P K9VE9DY#$9>(!4I"2MTTG_D8YSX,T?!:A#!!("CY"MA*DA.T( M&K".+5"+ /Z *B(P: 1XI!, 4=B 5KD*#P_@ AX8C8H\HN)5FC&/*5;@:5=; MI%:VSBQA;]UI3Z$:L2QU-05VF)<-YC R&YPM9@83WF\, :;" RV#,"/F9V7'0HVIU74"6_$P$U:WK19 M8:6VMEK9(^G\!+5_M,>SJCM)Z\!DCT-DAP"K4H1P 5 $+@N >LX@'(-T#IN M+JVWOTW,.H)+W6EAH[C904!REUL Y( M=@,(8.""&-P 'B8 Y2E7 87W&$-A%5!$IR0!"HD(0A,2((6BJ " *B "D^ M A.*8(4B,*'.6P"!&,(PAC4 ^0V'A@,(V% &.Y0!QUV@3A%:C&$=.).,7 4U M@H0<-\I(!L0# > %I#="PC<%PS(SD0$[DL& M9(?! O=- [*]08'[P@'9L!C ?>^ [#X8X+Y\0/8$1'#?/R!;&QZX+R&0O8H1 MW%<1//&8#0 .-AP /-#X" !@!(W? !2T'@) . % M@P? ! !0@]!3 ["'T% ""$T&< $EHO 8 \(3&

<"4%H@A"( &\B^#D(60 M>^9\ UAG R@%19!O_F<$:Q9PX'=M25!PT.=JK%<$1[!F *!]45 %[3<$ ==J M_99J ' %2) $>P8 03 $'C@%TU<&>.!I8W!D;G &(# '>= &_H5C& 8"9E ' M;A"#609D4@8'&A9D IA_^P=O+@B#,DB#85"#-YB#1ZA__ < 2U@&0#B#4(B# M;Z"#<@ "*;B"4\"#-6:%+XB%3;B%.0@".QB&1<""9"@';6"&3$AD-&@'-U8' M*K:$")H"B* MI"@&IJB&7;B*?4B*LDB+*F:+5H.+('"*4;B+5PB)0!9E(# "(="+5O.+GU@& M #!H'18&DDB)GV8U;(")5D,'89 &JKB #?B(:9AB&I8'*_:"O=B(YDB(8D!D M9$"(W9B)[ZB%\-B-'?:/=@@ 8_ &;0 'XLAB M*T9I7]@" S8&&W8"5F,&\MB/Q0@""\EA'JEAHTB-R9B&04:*B_B'6<:1=!!E M6C8&(CD')'F&RGB25I.2[EB2A(B*4JB36OAI)^9B;E")-\F.C+B2;LB"'+EA M8*B";SB&9E"&/DF#/(F,-)F&0)D&0DF4ZZAC1QF(4QF+>;B'1JF2@4@';X!H M-N8&ZHB-DTB4A(66B&8&97 'Q9B-< D 1#8'=6 &&CD&:;"-'OD&*5:#<$!H MU"@$4N!\BEEPBBF ;08 1X" !7<$X$=\E$E\ESD%0=!GU*=\ (" 5% %4N $ M .!\;,8$;5(%4X $S\<$3Z!])/9_ 6@$4I!_ =<$5E!]1P NOD$O.F;5G"; M4M";08!]>8:"^#<%SE=]15!P07"9)3 '.E ",$ #> "UBD#V0D )< &> MU7F=V;F=W0D"D& TTD=YHF>!#"=V@D#W,F>\IF=D/">YDF?^PF@^EF>]ZCD'F):>/% %3K $3O $5^ $/D =>ND&?.F7 M:0"8@DECA3D'ASD&U+B7??F7@6F)(JIB)(J8&]JA*AJBA.FB)7JB')JB'[JB MT8B&._BB)AJC.@JBECAE;8!A>0!XA@< \O PB81KM ^."D&S % 1"E%P ! MPF:E4?H!6KH!*" 43H"7[H,!!"E+/"E@& 41H$7RH);-H 5_"E>( 4RH*7^H*"A"EJ?"E(L 41H+7QH/A'H OO"EH* $<,,7^H) A QVO"E,P!/ M!X .7QH-M%H/7[H2GZ ^O"E@0 O>H/7RH' ="K A !PC8& M"K!Z"L&Q ' MS:H # "M?S"M$0"MC3"M%@"MFS"M' "MJ3"M(@"MMS"M* "MQ3"M+@"MTS"M M- "MX3"M.@"M[S"M0 "M_3"M1@"MQ]:K30"MU=:K5 "M)S O;H%T%H#"*L M8@"M0]"P:0"M4="P< "M7]"P\B-L;="P?@"M>]"PA0"MB="PC "M$-*KDP"M MI="PF@"ML]"PH0"MP="PJ "MS]"PKP"MW="PM@"MC' O;H+T'H%"-"KP@"M M&* O:H,T/H""]"KU+"P#-"KVP"M'= O2H.T.H"6JL YP"M/_"U[ "MV-2K M\@"MA^ O7H/T(H);*L _*"T$-"K!2 !PD8"=:L #X"W&V /!-"K&."W06 MO1H"?@L!$M"K*."WQK"X"E #?CL&$]"K1^"W-$ !!.NWTJ"Y"F &?OL-+]"K M;>"WI% !O1H'?@L,%M"K=9"X&-"KA>"W)!"["K )?NL+MHL*?CL#&="KO>"W MZ* !O0H-?BL(&]"KU^"WZ9"\"C .?DL%'="K\>"W1> !O##[V"^\N##]V"^9] "O?H/YLL-4JP M"D !PN8()!"E$*#%85<"4 "O1H#8%P%$A"E/0#&QL#& M"M $8#P"HZL 40#&-+#'5@#&1;#'70#&^& !FQ !8P#&!' !B=P&8,P.B!P! M=P#&'.#($< '8 P!F"P(8-PIB9P(8-P,PA$!D@#&C& B;P)8&P' Y#(H0#& M2$ B9P*8*P!!9#(KP#&C^ B2P+8+P)OAP!ME#&PZP+8"P.%)#(O@#&!_ MB5P,8-P$!Y#(QP#&DE#-$9 ,8.P&VKP,8.P)VMP,8*P*VFP-8&P+V@P.8"P, MVDP.8.P,VHP.8'P*P\P.8#P+PPP/8/P+PTP/8+P,PYP/8'P-P^P/8!P) 9#( M U !PC8.PWP #KT![S#,###1VJ#-$3#1^S#,%3#1YJ#-'##1\J#-(S#1_J#- M*C#1=S#,,3#1C) !B3P#$XT),AT!-C#1I'#3.##1L'#3.S#1O'#3/3#1)7 " M4;H$$WT,2-T 6##1;8 "46H&$]T(*1"E<3#1]J "4;H'$RT.+Q"EA$#28=T MCC#1 @ #47H)$RT!:MT H3#1(O#6JC#1,O#6MC#10_#6PS#15/#6SS#19?#6 MW##1=O#6Z##1MD #4?H.$VT,C-T ]S#1UA#9_@#2D6T %B!L]A#9#;#9&V M-8"EH'T!H]T (@#:*'#:+ #:.7#:-P#:2G#:00#:F- 46H$H!TW42I-PE8% M#Q"E6@#:.@ !45H&H%T$$1"E;P#:LA#'#5 'SDT!40H(H-T/%?"HH&T&%[#6 MH$T/&!"EH@#:B: !4:H*H+T*$Q"EL #:R!NEN #:3< !46H,H+T%]-T T@#: M*M !42H.H,T#_MT \P#:3C#@C2QL8##@%7 !PB8%'Q"E(.#@&T !(!"E,4#A MZ'#A#3 $%,X+(1"E54#A:" "48H&%*X&7=P >T#A?+#BCT#A V "4=H)%&X. M--X K$#ARN #H4KA(' #49H+%'X%.!"EPT#A*K #]4WAKY #4;H,%!X&.A"E MTT#AK.#C#9 -%(X)/1"EWT#A",,!!H .%+YM9"X/%)X"QZH ]T#A&C"M_$#A MQ% O6H &"!L#R"T"@ !>;X!]3"]"O !?_X+V*L *_#G5P "O8H#?_X#!S#' M/O#G%E 93/ "*NB;J.XIJ=8"19""KLGJRO?JL=X" M:P8%5<_0:;Q]D"%9H$4V"" :A]K@80 M%9H$4V""+:94@5)$"H 20Y@$F3*EA9,B5P 8>2)E2)&) B7%PHI0618(, M0<*QQ)4D5)"T,)*$29&23)X$(5+2H\62"1$2H9L6$H'" _BJS>HI3V4; 7#]*97=3 #8MEHVA/@B5M&: M%_*DRNL?XK,4?\*DA94@3*I<'!]0/OOZ]^57A'E3^$=?"U!T=]Y3!$;PT",.%J4%2Q6DI%@.2$%;R%-9P3&$H!71%$5"&;AR":Z,2(J_G6HHB^ M40&?C"&^6&,+0B3QFH]'3 $ CB["B&!9-0) FU,4"1?$$ATN24634E+4@DN_ M!5?E1]HI6965XYF7$91#22%%$%FP9B::+719UIE9!(0>@0;6YP-V4@ I'A5Y M_M;"G75ZR>1'/BC8W9];[MGG$7\:JMJ?>.HY4EE_^DA%$1,:9"FF!?TYJ4%. M5,$$$_ %,643\'4'7ZC%%00?>_2%Y 1\NO$&7X/_P0=6$PD6@05\LN$'K*E) MA"4L )MFJBL29=W*)Y#P;4FKB1:E*!NM%-F(K!,9YI8M?.U1T2V"WP*@E%;: M%O&$$2V<6Q5\1!1A1!"B/N6N4S=&D:\5^59QK!8%/8'M%"@E0=NJF!)[L+E[ MW4C;K$-B(9*V/OHZ,7Q\ND?6I1+%U*1%+>EIHGNPQ; " "V8S)H00AYQ5FQ$ M$?%$$P"$F#)>1W3CB7M$A/ M"&DJ41%#(5X44L2(!12KQ70$=T\<$3/91Q2+6ME8-"FV$S\#P(/?H8ZJK.+#@6%:[!%ZF>7 K'\[&^ '\$#X4#RT /EOUT>.=Z8 M'^%#YRT,D<3DD8<^NN:*,RHZZH^KG@3GI8O^^5C,2D'ZIY8O6Y;FG\+>N^X? MB7Y[[:;G3CNEJP-ONN_$RPYL2+ %2T3HM<<&/8]9<"P]5]E:/].588U]19X< MCX]2AY\"8/ZEV)=/?H=3=-6U^N^##SD1/"6()@!0]+F:3ZEY"/_\QR/I!:=_ MEFI!O,#VMR>X!BKP3X1C MB8EMR#6_A%2M0SX:%Q2ZY\(5ADN&W;O0!%U"+H(!+2P+VF&'9NC#8CG!/$-0 MD6Q(!$$S0& ]"%H,@1"XEX$\A MS9-(](1./0?9$M^R]+<22+)+EOS21\*T+2K@P ;;$D+V*J@A47*L0-@ACH4< M":4TT>$-;P"!&( _E+:() FM3,+C:Y"P QA.&W;X##,,G@3//^=IB]#&8= MPD"'-+S!#>4]KRQUBTS[ND&9S'1F<-E0AS* 8 YT",,8U@""-]BA#'(P QO> M< < "YWRT#'=#PAM^: ;H;3L,<,CR'.83A#,=]0S*#: 92D#X/ M8=%VQO1R&!*$"0F)SHF6BI2%(I4[$S+0>I;*%8]BR#H/I2BL!L _#(,"PTZA M#F*0PUANG6L H, %=#$LL >P9!<<=02$?4*/?\P_.;RA#2)VIA&(Z64RM . MSH;V')P)!6=7NP[&%,Z,80P%8IYY"!UV9A%B&H9F7MO;92 #N-7M!CNDP=EN MV.Z9C6!,:<-RKSPHP8A'!P'V \!$OO. 8+0$,9O"&@WPTI'OE M@A-HR89@.G,$7)@"'!3\<2Z48 P6UC8_>PB/5M( M$FS.,=V6 0_-1&:\02#.PP) Y2P?.AE4G%LW_#SH=!AZT7T.]!]+?5U'%_$< MFNOR-,!ZV;'N'I[##T*B@US;&7L1JD/]ZMLA>W_= MX-PYY*$-O&4#"-P0AET"4@KZD0A^'BNXJX9 X #0>WWY?N"_!]Z69HAZED_P M5<4"L&+BT8U%QI[VJ/_6[X!_@^##D'D(@X#S7%#L:K9C][)7/O6K;_WF1Z#8 MVJL=!#*]I8(UCWGB<&/T3#0!?S>[W[XR2_^\8>__&3 *!G.;WX"H)_^X?]^_-/O_?6_ M7_S[!WYT(7YT(7_]IW[N]W[==UX&&'_J=W[S9W_+]7,-5@?)] 9FX'+3M&,3 MB <5>($9* <;Z$P=^($-%H(C"$QNP%X>V%L@J(%\1X(K2($N>((PR($SV((6 M:(,B&(-4)E[Z!F#-=!!S4 (8I6L5-@;3= (7V$S_909I0%VZAH3=!P!R<#(] M\E=2H%"^LAJZ94S#= 9ND 9Z,'3IQ4O?E6X 4&$E6(,8>(,RR((F^(8]B(-R MZ(8HZ(-;X'(:!FYC2'FOI$PSI4SI!0+&]6""UP4*$'G%1$PZ<%2+R&0 @ ;M MYH0 51ER(!(XT8'" "0#H#[@= /(:0$)!)8R?-G#1OW( 0DP>$GC)RW@"8 M$Z=.&#EE0(1\0P?$&S,@PH!P4^9,&#H44[JITT8,2 3*U[,N+'CQY C2YY, MN;+ERY@S:][,.9.G3SD Q(012)!.39 NX8",F31CTI1QT[)-F39OY'1L 6).3<.$S0J$VQ6LF3=UW @D M4T<.0;=IVH0YDW).&#ME .SM^S?PX):HQ]!)W!A.F#&I R <4&*. @ @0\HQ MV/NW& !"I!0)LD2UFS&)4133M[6^[ \8B5 M_3FFQLJDL0YYTJ1)$"=$$!8 0@#>G]MOS % &!>Y 4 -PJ 1@BC:/)#,/Q 1 MP)]_-X7AA@SZ@=#?'] )6(9Z"-7 B0=06($+ / X@@T@/OCS3S]U&$".&"0$ M4(<+N+3Q@8J@6 . (B90 X #'PSB0R ."+)B+0@4 V-&RB" &*D"& /<0 M0D<"]D C C'JG#% DEY@\8$#Z!0 @ O_N&")",]LDN0R "#)PPB4;" ( $/@ MN<$@ ##A)R$ 8.%G(0/Z:0@ :_A)Q!NB$00 $8,E)AH;DU*4!ADI<00"# \ M@9H<:;V!5Q6:@50J7E"Y-/)/NOX MH4H40QP3B0.FN )*!N.,8L0%#-01B"%UV)$,$DV4TT4/Q72QPR*>2*+%)I> MH(@ 4H!!3 EU) D(M0:##<@_U8(-#-F0.*"A?P5FB.(?),E!1T-K_T&'A0#0 M0D*>N^R] 3!^)^/W-'YGXS<1] 61A!, 3+%XOD]848041C#QQ!4 5('?Y)5? M#@ 5ED\QA;VAC]Y;L<*"E]AOD#0P@0 "$%" 0B82T$%!4SPCP4%1"! LPT4 M4$"S$#SPSPB_&P\) ;K_ WL!#_QNKNX1C= L =;K#@ !*&+ /3S>=P\ ! A% M (D"82P[?D2! $)-%#HL#[!U#@+ &04/"^ 1@X6[O^RSL() :1 $@Q %R M, $ * 6BK 890( $8"Z$-$ 3$AR" ,;4.E=(4 BQLZ P%+@\M#7 &B0D M@ G5D4(3^J.%%I3 "1"B0@N:8(8EM* .<%C#UCF!AR84 Q M:(.51 @4*!(0Q:%XS!U MV-!I\4:,FC)CZ/SH^_OF[5L@;<^0"-QL7.:QF\BH MZ;QA2J:%&<'6>X=\7'Q.GC9=,6L.R[GV3= H@L()S2:Q&#)A0GMODR(TG+D@ MYH,X42+Z=)X^<5=&"O7--\=G^Z% X'D@,.=<9"K4X49<$E:'1AAND.&;'"KD M]UU'&]&!H$YET"6:@*&=4:*';>S7WUS_]90") .@ B#< M2%IH;)E(88:SS?=CD 9()@=1)8D@X9$^428'16+X)@*+2][H$6$)SJC<5:8U M!QD(!C4UQF%6E?E@:'2$T9M ]:$PDAQC1#8&&24!1Z.#9QZ45QXMS$&''&4D M-IL;J;'Q0YN.G6E7"X+20:BAB"86IE4Y!374&R"Z,4>AAR;:!H,ZN0=?:,#9 M2(!.7-%UPI==Y=93GW5:9.A^(+671VAKDL$GG;& 0<*KOFOM6JFNV=]+E*;FCKEK&KK<-" MW.6Q^J&@HJC?S5@CMP: ,;%H+.C'PE2&=IE ;AOYQ (0R*Z7ZK6K:FL;!CB& M5D8&KI@V6J!UQB31 (!\D!-VD &@!E end  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Aug 89 22:55:59 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa23752; 30 Aug 89 22:48 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 30 Aug 89 16:38:08 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: 30 Aug 89 03:00:10 GMT From: jdm Organization: Hodge Computer Research Corporation Subject: Xscheme.arc (Part 2 of 3) Message-Id: <21723@hodge.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu MCOV(C+60? PGA.F@"L;U=4 V?;\X2R'A287 ;, G?&V(D'8@#Q)Y?A2IAW78 M(W>8AQIY?_@%B" IB"))9X0(@(=(@#UB@"P9DY/XD@THB:B'>QNA)?:4);IV MNS %8P _80'1)0 /F"(_MA!?90%/20#FGPC)UG6W.OC =A%0X^' M9O,5@%B47OMS>9FW>9#F>9 $>@BF=8FU 84Y=T.7>ER'B6R0H2CJBQP:9G6@ M!.:V(.BF;L0(@M=YFU]FG_96:YI@ A(P;J'V;;3B0#@P 74WHEX0@DXNPGWF70O# 7CX*I+D57S6FH&9IDE=THW*Y>0&!HYOW1VQ7 M5[452[>%=7^Z5$9J!T@Z,]E51)J02) G>5=$>>IE>8 SI43 >59JJ7NR$ M"Z4GJKW* "VIHY-(J(:* %>@":8@DQ0;G(UKK*)91H:;W.V;2M*:-%! S Z8SI%J']RJ(FZJ-*C"8WZEOC@ M9:GJ4IJP!!DP3@10%/Y HY(*L.YEJ@QKJ9H@!1K@:3S*L.]%2(:4>'?21*]J M,DIJL+9Z/U"**%(ZB;ZZ2#WT>785>EKJ-,3:DKKF B?'#RF'.?J0:<7RNZC1P8 MKFOZ;.?:;.D:I_*FG2QZ=KBP!//:<37&K$J+J(IJK(SJJ/]:J;BE"<. 0:+ ML K[*/!0JH4EMU@GL9[F=KFE QQ@L!7KHQ>+>$6ZL=1UI$DJJ[3*I PV>2.K MJYAGLE6*LAN&6\':LD]3K$>+"T1[M$;[@/*AMDO[K-$ZB1=165+[5;I6M;Q8 MING9=!VJM:)X;N5*!UT+CE (MC29FQUJ<2\F!F(3VO090842 836V#BNPP07VOQA,L7_T=XKK M-!];JTW:,R6;HYE[)RE[I2;LN2]KK*+;DL]JND00OR/JF=:8#G)PE"SM\K[9,/U",_[M5?+96$+KF00M@T<69DU!7[,D>UF MQK7I2@\0MG66M2#@J\'K9P$K !4F".>@*NN@'DZLPU-LK 4!!.N01F%,20[@ M>B'DMOOJPWN'>_R@>US!RL4' .DP!!]&CL79 _&HCMZJ& 59!QLPE1&9OW.H MA^EP"?O8C\.5!^B(RWG<3P0)KE<0( 1)KNFFIKH,O>I*NQ ,S7/*E+GS 91* MD)',G\%L#^MP<52ID'EPO(*WE>^'D6/YE08JEEZIJ878H *(B&NIB C(R8\8 MESY)8%/S(,)ZT!_Y F$5K:'9 EP+UOKFIYTC@L=O09MFWNLFYZD"\CIFQ@$ MR,.U;(/,P!ATG8G\R(L,KG/@R+@)R3\J=M9[D#,,D493$F8.( MJDF-=0WP @9; *VD&_[V/?+!'\MIGJV* =C%$^7YKR],N947"ART K11*M

JY42\38.5*SV=I94-",)N-E@5Z! C@"ZU4U[MD.NOP DMB MS:5],LX0#>%@VP.0#?;<3!M2DVP"):1 K--7TRR M%:?I!?2P#@Z@"(1PF0%"#R: " =@!*M##SM@ QS$!^SPJY%T "<-$U%KK9@4 MA,,E!+N(E&\Q3+]R!4WM@80':9 UC5F MU%\6R14V ^*06*'*O?O:KZB'L'ZMCK M#W50 Y/SJJ/!0 MSL_LMT&*#MX #JH"T!8JT&H]NP).W^#J27GP#W>WNJ@WY [ PYIPXO(!Q"ZQ MY K0Y&6>NP>,VEK.Y7>=YB3 YB[;14=[=S#NDF4^ 6=NUY9: M8?KP#6UNX]2(XPT7Y_(-Y4O9X^EPYWDNY)CLYX#^PZ'L'.N]"$Q>HD^>HJU. M=@8>';Z@X(-7I6@NR>@0!*3NLA/NP]VK@'(\H3>>Q6L]YU%>2\&."]A [%B. MP,/%"7?LTX:ZNB@"-Z06'U-X;JQZ0B[#ACPZ77E M[ET0[TY#?"L4ZY.H[XO601=[3%-YY_H26/P#^5,Y,9JY)-XZZ_+ZT"_X[^.[<5&["U. M[V/^EL_G X_M QXDZ>]589[@#ZI"\40GWCBP LL-\Q2&#GS #8F%Z3[\XC(9 M=$=^ZQ05NQ]?N^8NKLW6WW3PWV_ZN\L&J?YG.P#4"75UK- 3['3G3_EDD.$\F+FUNQG%[0 MG./I X@MG\M,GUG+ =&A YI_9MJAGFP&9;&T PMT^/H9'4&@^?2:J:__9^#Y M^NVI#]HZ^^:9R_7YB>*:G=+\]^IISP3I#WJ)V/ M["#P_T/KYSZ,NB5.XX'.]+K&!7F?Q.:N QQ<8<, QWO7^<@^"A/ALIM\M)W\ MR5J5\9>T4_;0![ ]9VPC #F+O-.N NQ+9&P< MXHF@5+)6+#X<.7_^I4P/NQS_ZH=>^V?J/W5P!1!?!]E^"OF_SL: !%(M6VV, M#J( PIK$%^JQR:%K[*"NU*-P#6_O2AD \8>_E[J0_VP(#+?N0O<0:Z_UYWJ7 M^L]A@0Z" Q$R 11B Q'2 +C0Y\:Z#D)PO@$F>23VP0B(QY V0@/3B>EUD1N$\0.8W5&_$;@HD &;$QD*U M1@J6J65IH,KM08Y-1V"\*YJ:(.)N1B^30 O$V@DB[F9DH*'@07.42:/@00)7 MXL]P _94!ZDS9XD0 MB@[@,C<@*NE0!TK6V]/H'\#M2WQ"W,14^TM2<:%0VLK)G$?P_'2@UO)?^^H) M4"$T7$WP#]&#\9I94:#-H!YB.K[@/^O@ K&=KCL@2G4 3M@3^GA98EP TVE M TO"_H\?W'K")\1-3+6_)!6'"I25^HIF!:J=2V6YR-8LV$7AG-"0BW;I#ZR\ MRJYT ^H9R2X$# '@ 7@5WSA28*@9%KQ^*6MG,P9W,[)%>1)^VP]<=4_O)_0 MAIJ6OTL2SR+0AIJ6OZS],@FT0&!<6<7R@*\E*Q76 /^0'#A:6<7R@%R# '+Y M6G)9=$-9!PV ]'*9'.L@^T;H(#@0(1- (380(0V "WV.H\FQ#A^ "PV!HUR# M3A4F"7&-HZX;"%J/ Z#P 'R0D[C #)J?!P(@HR=C]FCO08Y)$![ 025=1P; M06"<\9D4"P@P#2M78;OP#[9'*Q4&"_] ="$JP W80 M\=R \9I)!U+["_[#9TW") /@!0ZP%8Z (HS 9Z+=]P?KG\+-,#,0((P@2[3P M/X*T)&45)$*U[]'Q!0< U>*Q.9WS.>N0!/"*"VUP % M'IO3.53# "*Q.9U#-0QP C&,@ -E=R#W0$';@2=@P$M@0#>/@ M O]P"K, [T ]T R00 ZD0 P0@ ]E]\P;&?0< U>*Q.9U#-0R0#I(@ '" M"*US! % "]21W3=O8 '""*US! % "Z.""X=P % M'IO3.9]S*Q.9WS.2 0#>"P!0

0#MDPC(S0.@M$"]01((S0.D<0 +1 '=E]\P86((S0 M.@M$"]01((S0.D<0 +0P*KBP"@< U>*Q.9U#-11P0#H3P4(&9O-J=_9YD!_WP%/J M>_A@4NM0 ]O_V5[ "*US ;8 #L@#'7@ >J)I='!#0< U>*Q.9U#-8TF H-@ MGNA/558E '7P"]%A#@< U>*Q.9U#-0AP8=MA"$K,^^C7](2LOEC#@00018 M #D0"OY )OXIW-!0!SF)"_AP +J1!P(@HW'X2,G;VP?G:CE0)OZ R3C#3@0 M (/@ >" )4MB#,.IV3_R,@FT0-S*7TMBH,*4)Y5%49830,1 V00@'^)581@ MPOW)(SXR(,9P !(@3'E2613E0LAJ!#FE'4"@&Y-=V3OR'Y:S)$*U[[LA&3E5 M8\*4)Y5%42V."Q-^!WP=ASKBGSU2V(?='WD2LD]:>1,#(:%@(4O"V0U6:Q66 M!7"\))Q=$Q<4>3^R4<=P!-T# "9P#*B=)>:=( /C+ (7AWZ /# !RD@(83J M:G(0 H2* _P!QL@(80Z:W?@SL<5#> 0#=+0 *:D#%FR#BA0]7% )6](_]I MA$OR,@FT0,*4)Y5%4;C0$+H1!P10V3OR'\V0 _:D(# #Q/) M(SXR(,9P (7>'WE26115+'% )6](_]I!1N?O /R,@FT0#F1(3^"7\*4)Y5% M4;A@4[H1!P10V3ORGT:X)"^30 NT),> 07C)7TNB0*/4'WE26;22^-YQ!WP- M/@)W,O;$UP 0#>@0#>C Q(>C&W? UW&H(_[9(YFT) HT$OV1)Y5%*_FJ&W? MU^##5;2"])IP!WP-/@)W,OP%!$# Q*ZF&W? UW&H(_[9(YK](YQ=$Q=T,OV1 M)Y5U]Q8 #D0"OY )OXIW-!0!R.@">9 !%D 0"0 Z'@#V3BG\(-#760DU*< M&[,J #(:>3_"_JZ6 V7B#SA ,MZ P$P"!X #ECBF+4U(-R]),> VEEB L> M07C9'WE"+YK@ @E 7CX #ECR!Q7 !P@0"#[@#3@ "@\P!^J!Z0C UP1@/1.E M:$O>3EF "Z#P +IA#0=0V8)=%,[),$?0G8,P#-/H'P+B"Z#P .L TMB##:U M),9P!/XS,0"0 Z'@#^(Z( ;ZH*Z6 V7B#S@P"#VB $[0!\WP!'U "ABOF25N MK7XP2A8 #D0"OY )E8PV,X)#74@ A7V!/\P,0"0 Z'@#V1B!8/MG-!0!SF) M"RB0&[,J #(:>1[@#R-9DZZ6 V7B#SA ,MZ P$P"!X #ECBF+65G=RMGHGP M!P*@GL> 05EB L=0KEE2V(=M!8D=LD]:>4>P",<0#> 0#>"P" Y #GCB >* M P. #3O@ >: W*P L]J# 90V8MP#-$ #M$ #HO@ .2 )QX@#C@P -BP QY@ M#C@@!SF)"T"0&[,J #(:>1X@#FCR^(MP#-$ #M$ #@%@ .+P)O.5( /#V[L] M"#UR,OV1)^K9V1=T,O=0SDMR# N4)29P##;U4#U" $Z O0'P!^A@W@DR,,61 MWI5T2;7B @GP/7#B 7/R^.OP!K%=$^UV,MX0#>,0#>,P ,.P),*/ '-P!*$@ M CD /"1P(1AI >1P/N+P)AX@ CG ,YX=>3_2409 #FPB#N+:VPB0)NC )N8@ MKF9A "20 V4B CFP#A^P)![22\+-)W60"(6#!@=0V>E=29?43EH@Q2>@&XR M )6](_^A2D@0"B*0 \!# A>"D19 #NP0%EB L=@4]*E 3D /!QP M(>Z 0#>!0 )M<.-W3 E1SL/XIW- @(281/>LPIOV1)P6 MK$O2V1<4>3^2('U_,MX0#>,0#>,P ,.P)"]SVJ-D 2"0 Z'@ 3FP)$[ZH 8 M CE0)AZ0 P6!!-$ #M$ #@4PQ281 ;@#C@0 18 #VYC !"0 \*4)^FM:*%@ M!CD /&AP(9ME 6B0 Z%@!CF@='5 /&B0 Y5A!CF@"="@ .9' #B# \"S)KMF M,^?C)DI7!\2S+C;0+M"@ .9' "J# \ S)KMF 2ES)DI7!\0S)I5Q)IH #0I@ M?@00"@IC)3BP:P=S/ERB='5 /%=2&5RB"="@ .9' *'@"#D /.)Q(9ME >*1 M Z'@"#F@='5 /.*1 Y7A"#F@"="@ .9' *$@"#D /(1P(9ME 820 Z$@"#F@ M='5 /(20 Y4A"#F@"="@ .9' *%@ SD /#AP(9ME 3B0 Z%@ SF@='5 /#B0 M Y5A SF@"="@ .87>8O4_J^_#C>P_:-=,/XIW SS <)$3+U8!Y+3ZR,#UD"2]"-(JD9#TJFW<^$!#U0>G;@2=GP*-@0#>/@ O]P"@6P "FP M +VP -6P -6P -6P +VP -6P +VP "FP "FP +VP -6P -6P -6P +VP -6P M "FP "F0;=H-",HSC-IMS3OR'ZHD^_U!3+U8!RV0W28 ",HS$E:0V-E]1@HD M -G=_J__H'J((M.=!=DM).*^(_^A2B[9'\34BW4P3U:0V-D-EG\X"]EM H"@ M/ $ */9PD)I@"0Q@?@1 XMEM H"@/,.HW?9P! $0 ,,E /_P_,/5"4J6G?9P M! $@ '0 !NH)",+8#Z7-2X_/$^L7F.KY,@FT0-M/R W,'Z<9F*HT!#RQ?H&I M='4@ \*4)^IIH.G@!_]0VM/H'P+"$^L7F.IIH-T)W2A"#P_:_/B0#ECP#Y6E M^C:?('U_L/XIW PC!-+F4NM@ QHR"#TBV@-3,%8PV,[),!X@_>=9IG70 /6/ M#Q4F#OU0'D[0!\>0WL\1"B*0 \!# A>"D19 #NX0#>Y@!"0>VRXE M9P-B#T<0 % !UW $_*0$_"P Z99!QFP X%9!W5C#-$ #M$ #HSY?,80#> 0 M#># F-,M!#RQ?H%9 VQ))U]0020?P$"#^>=W;L]"$8 #W$8F 3@!!#_!]^P M#@E0$-$ #M$ #HR9@L^'ASL@#'/@257P#SRQ?H&I2YU]0020WL]1)0!@*%IB M /[0)54"#EU2)=[0)7"B 7/R^.N@ 5E-*+G@ .87>3_B(;TDW'Q2!]Y06:H/ M2X,P#-/H'P)B;MEU%58PV/B0#LZ[)/9P! $0 '7@!4L"4#8E$NL K'M]Q.P M).&L/,S3^S]B##8U,0"0 Z'@#^(Z( ;ZH*Z6 V7B#SC00]Z P$P"!8 #EA" MXK8CC&+?(_KA!O@0 (/ A_'Y_M+@!YYT!__ !P=P'G)P2__@NE7" (:B)0:@ M (:B)08 #UU2)>[0)56" (:B)09@ (;B)5 2)AR0 V6B 3E0)0Y@*%IB .#0 M)57B#5UB$M%C, 20 Z,@ #E0)0!@*%IB /[0)55" H:B)08@ H;B)5 2)B"0 M V7B 3E0)1!@*%IB .C0)55B#EWB>V%"#FPB#GCR-=%@#M%@#JZ'Z=W3 E1S ML!9 3DP"AQ3CCF)"UJ0&YI0#0(@HR=C#"81 ;@#C@0 18 #VR% X8"$#@0 M 18 #P".&;"1 P" &=L<#4/(R "A'(D\",K1$!( B!X<432 !J.9' +IX3 H M4-[(@PD7;FO(#T=$?3@:XG/IP1Z.148,1 .WDY@'"3D&8&N( :.%C>QHJL/A MIP664& T\ .*PSJ*-AA M1$&= K@" %@G8 8PIV?3KFW[-NX"NG8-Y 60+DV M@N,(*@S(!V7QX-SEM ; M2)S!!=#HX!VP]P Q+P9,*#J J0=I.A-Z$ ! .9TG #T@T*Y\CO&)QW4CQZT\ M"(!:!C@5; ;0^7/HT:5/*U#-VC7M,&K9:N;L&0!H.L@SZ]07#=NZ!:=38Q5[ M1( 4*,>3+V_N/71XY'6CD3>/WLOT]5>UMT46.RA31P([8'/78GSYE8XEQ@5G M! -T%!%?7?-U]QUTZYCF'W6MS5;'".DUPT,W[4EG(C=?"-!,#C[8PT,S/2AB MPCT\>+*@7@T"LXZ%$E)XPX7*<>><:+B0UJ%T(.9&6P7I!2@ DSNTM^->??F8 M)6!H94<87'4<5E<=BNF5#B8"0"99;8ND*5Z&1W+H86JK88)$#P\ 8$=E9:2) M333CN/#/*1,(P,\ ;Q P@P#&", %H@0D&@NDB58:Z:6)8C! 3E>G=75@]Z:1HH:GW7CEG1P)\" !1Z8 MX)4]IK,*< H(5R&NS&GX7)+1?7BJB"2B9B**4_JW8HLOQCACC3?FB&R6Z63! MK+-#PB5?KM.2RN2INM4!)6I24FDE7CRB6\&Z$]*!!+3T;4CMDM965P!M4WWX MSQVI/4Q E ]'? L?:1ZC MKP!U[#"#/>OPP&18BQBSTTY"D:W5/S=$2;CA/(&3.-53WY"U /T,0@P"(->A MJ(\(&+'#/7P L]@732WC 2Y<8 "%)DL$4 D FA.P3& WY[RZ&ZYK4H;LQI7C MU.I]]![[[+7?CM8@[#!0]^H:I/!Z @"$L4'M02^PV.L+PX,!$43DO/,# Q M_NH6]2Y% .77GH@%'8WR$2[' / Z,0.4#[Y/'TU5E0F)R H #^ 7*$#A'S;H M" (_H@D% *!]FWL/_>S'/[#\+RQH(QO&4B& ."A F<$ 'BP=N]IX ,)H#D$O.\AHYA( :&P.E'0T(8?) 8! MU8'#5IF<8NWK(H*6:@5%ZX.'+Y4(S"]F,NR M[!(7VDBF+4DXS 6,Y:X8(A((A/".)%:PYP$>Z$)T&>28]Q!I, YKSFZNSASS:&$0!C- @^X0!/-^3 M)WZPH%7L:4Q*A$GW"TGN=D27]=$DI+2KBB=SEX1L+H5!):N;$6I M P!X! 8,P@!5C2P&34A"1AC!'HGP CU.0P\3P%("_S#":$5KV@,((+6K+2TL M)P!;TK8V +5E+2PUD%O9'F !O6TM ((+2P@0]P )..YP56M;6.*6N;H]@'&A MZ]L"''< QZ49=6^;7>7"=H@RTX?,\*&)4PC B9J]H'HG>DY<=#*H0U6K49&J M5*;BP*E0E2I5<6!5?6!5JSC@J@N]"E:Q*B8"9D4K4=/+7H'B8@:/32.#6:A7 MOJX."#<=:>TF',#)[I4!JV-"A#>,6+Q>00*4A<#JHC#BDI;X?P&T &4I<-G, MOKB$)PR+9T$KVN8> +7;=>YQ>1ODWWJWR TX+@&N>]SIQK:UUBWRDHNLW2<+ MN]-_:BB7U*/?@2=;Y)76I3GYJ#J$ZU MJFKQKU(!+. #$#BL8\4%"A*^5 JO#PZ@;S5X-4!8#Q%LU2CU 60ZL;A"R M-K$(* N"&O-WPIS5\6=#JV4@:_FY6B:REH%;9##[.,E29G*1G>QC+D=WREKV M-^8-Q'3O9QK5W=[C:[R>L^K@'8R6SF\QH6V.OM,^H\-C?F11H7CECT^Y @12/0=!(2S^-TD.)7>)EQ-DA1#33]1L81 M(45#T%0=&0>#%+U TWAD' I2= )-YY%Q*DA1"C2M1\:!($4?T/0>&2>"%(5 MTWQDG E25 )-_R%Q*_@CJ?S YSOC^5!,NM6%VUN='$SPNC^D%810D6B??# %O=P@2W@,X/_SJ"*"!U\TUC>_#@A2M0-,% M5+ZE='T?0T?AT-51X/.7=Y\% "'%B*XN!*@7[#0W^X&&H C)J#I"6)/U]E? ML/8&H %&9$!3&? ^C;['<4-X@!$=T-0'QZ\E-W_?$!9@1 4T+4+T?TE.ZAL M!AAQ00XTT0T(P)+ARQB$#S11$-%H0A\]*X! G* !OE(9ER !6@0H@G(*^ A! M! Y! %R 1" 5# MAC !>?@( Z .0E$ 7V F G$!!T (!Y"'E*B' MA4)*", $!" !3 ""7 &": )": +"4 ."5 $"F *"B "U")KFB)KQB+L#B+ MLEB+$^ %"Q (#$ *#8 ,#K /#Z "$7!B62@5J_&%BP /L8 TV .6RB"Q>B% MW@$/SPA/)K$ !B 2M;$._K .4A"-QV@&0$"F1%&F1M8='H25>YG@: M^L!,WG0 [R,2HV 2.V !(">/Z3 !_N!4(H>3"N /JR,%VZ=,W2<6+QF3.#"3 M. :M1$( ("#.DAC+B"" J )V6 !8V54_)!4_F4!26%?!8 /_X!?.3 '7P5H M!G!G_*46:6<$^L!GB*:6.K6!#?F0Z&B,1^"&$1DY)8D-5_&2<'E. L%^;Z0) M-D !8Y4.7] /,L,/X;4Z9/!YOX,\FY,.2< U%B 2[H@#"TE"[R&2=RF-)%F1 M?AELPK1"B,:1#M /$+D(8KF2'@ 3GK657J /Z] +.D_#XB2M?D$?0 /N4D5 M6E&7(\F7I#D5P)>1'K"1YI@.L\ /K?F:T!B;,<&;MHF;M:F;LYF2O@D/^*29 M)A&<+>*94 ":Z8B/>[D3?1E0 \2140"=H1F.R0B0)K&=M8D3^A 9_$ '(L"6 M^!DJ!B,OV7DJ944'#M"8X:4);6!@M6,!C6 $_@ %G?DX$CDY=[ X-X"@8Z8) MN# !8_5)6LF5WV&/V2F<)(03_E"AI9F<-&$2Z: *^^ 3*(>1+8H#Z; ),1J? MZ#F?L+E5%VF=OJ9&;JF?_.F?;@F@\5(M+4F@/WB@=N"8&[J@'ZI$#@JA$OJ1 M)PHYB..7FI2A3YJ@'3JE#!"B0PH-=4 "$UH5A:.BBE,YJU,'D@D\/?2=.+"9 MXCF<:NH$*1H.T1 . Y -?98.Q?"6.IJ/R[B/L'F>_LB.(HA/7[D4!4 /8TEG M9EE@'[I?:F0,]W3I\]$0(7B(!!Q8CH?^199@ 0@1RA'.5J^C-D5;,V;.7?V5(DV78:C!0\F M7-CP88YC!NCA LKS)"Z'F6*?BGPW)GB\O.A8-7.FJ ["9^'='Y;\;FA0 M&$ @)()$%B2/NORDSS2YDD-=UMOW:UC 9 6?/1!J8NG2 =2FVX3O:=0_ ])% MPG?QDT:.'D&*3!<(WT ;.1A%QI'(P^5T#<#A4919A!Z0#!#Z:_($!!P:D@X-^ERVP'ATD&(A@"0$ $(@XE"T M#1T%X#( .L@,-!EBF'2PP( T &!9Z#9<)DF;4QH0$ALV< /#IZYA".1.N*@ MR2D"T&8;;KJ]E\T]"&HH&8<>7@:BB"0"8"***K+HHGLF(20CC38>&9J2/5(( MI&=#%HEDCCM>TV1MQ-R6&PZ[X9".'E1FN&&'>WX8XH@EGICBBBV^6.8!,H9( MAP'G;6; #-LX,@RFZDG6WGLVW%-54$.=Y%-6.^Q9!P/]758'I1Z@M\ZEF6ZZ M3:?LD9G. ('B8"4.="" J::8KC-2K.FM]ZF?X]@SJEH$K-;::C>HF61LL^&I M9Y1^YF)/E1O2D"4.6R+JI:)A-DIFC#U(>N-G2.[8YH\B@7NE HX6-^NPMN*Z M;#I8?"OHE>(6JN6A77ZYJ)CYFMENC>_2R::/0-H+++[KPF3 OK5RJJRN]]1C M,98&DXMPHF R.B:,#KMKK;P4BZ3@52OEVU.TB1PA *EK32?RP, 2&MS!7**\ ML+HL0_IPFO"NR6/,QY9D*E9:P=@3 CP=\2.TZ?Q0CX+$?,"($?PDXH4^/!-@ M<1W9#;-0R>4FC*[*#2N](AW9<;*0$?HL0#;;VBUD!3^+\!VWT>FR=#:[*];Q MQKB'GTM' ^-&HT\TV*S#0+XH1;N(SE) LL3^9<,C$XXWY9COLX"Q"S> M^4DZ;Y%%:A,H$\44FK 3@),B0U[0,V"!I/.MX& _';_6N,LO!]E$ @"@ M21,';!*!\'VFPP$]8(M-MMEH0[MVVV\/;7+1DA^]\J,RWIWWWGW_G5TD@J]N M^LGM)QZ[/HP#@.,@Q[\O4:YDKRN MX+G:96$%V-B [GCG.^ 1@'OOV<$\G$<3"T:/02R$G@>DQCRT3"\'U=.$)+*W MO3UU+Q_R"-_8RG:VM)TO'<1(WX&(9BZ%I>M] <1;.CI!/[_Q W"2R)\$"S@W M%BD.@ YK'!P(R#X#5@Z#FN,HM!/U8B'$,=71/,! M#7!))&,3NX@T^/5 ?E.LHOW2D<4(&HZ+*?.B'<,HP#&^$99R+!T=-0C !H). M='"#Y0'51\<%PLB7;=0$ 1#@QXV44)"73,<\X#&R&HA2;K$L90#K$(%_V($? MWM3'T]PTGEHTI&G7FA>0TB$*>&R2B.4;RA&?H41#E9&44*2E%%&ARBMFAXJN MW-\]L_G%*&8'#_5D(C:'N40<%%.->(3@+0>:2]:AD9=W9*/M=J",/S" #P38 M 3;F "M9T8I8M_K8>VKQ#D3J+Y)HB2$D%;D@21J >M9C1 :T%\TYO..=Y#/B M)[/3C(2N;Y39S*?=:I0=4_03<)O0XBL'>K2"ZC,[=C J'!F*H(XM'0P;62!9DI#Z=T4A]8CQ4Y[ MR*UT&,$=0.VD/(>:#GI>$W%T6]=5T\'/TED1< "=*%*K.LNE2A&ACY4<5R_C MU6."]9=(HP&'4D8S+R*+[Y0A/+9)QSK8\04O M+*(<75A&%1;!CD&P@P!6N,(,_K$.,,3. ,7I2[3"-C9_F(T?O@C1.F(0.WYD MU($[L (#ZC"!'1A! 75P0.P!X--C1-&SLJEX=+-"6O"@R;5-;R3HFH"#6N 8VXR" M PH I'440!/54'4!0O=YSGV'$&JRQ!E92,S6U ML 4\/0UI%"X9")_UVY4/Z%<]E,A!>PJB'DQHVP.6V,P6K),#J4B@T\\J5=C6 MD0!8RUK*CA &B+W #W+7Z-7ZD+4F;G$!"A5XKCNR@ 4HM X?.RW(Y*0)>M7+ M7O=&[25B W2N7)*V3?J7WFD;G3]$3&G_T9M=:#I #QQ0(RBLXPK_-H">V\-G MB_^WXAZ8]DRJ?6T#>+L]X=:XB!,XD'"G!MO?+L@Z.-#A-@M@U-[TAS?Y<9%> M>!>\><(QPW?, "O(A1T'*DD!Z/&/_OQG#J^6D)LBY7.'(=GE,J101#OO/Z$N+@@ @-"%P@(Y.+M:UE[XC2R3 M,@RQ@B9"0 #:$($(B;""/1)A!/ I#14OMO\#['[+5"*,PN#;2KG>U,:?'=?:5R8)5 VGO9 MK[5GTNUOA[OG.1B -X"^[1QX ?SLX$T(X$T&'GKL )7F(5;V$UH^$V2 MMP%1V(;$L#$/D'1+)WF[P(8A80!RJ E20 !2.'4#(0<&,7/*]AH,:%N:P&0% MD #GE8W;"!;2(@$R(_^F([+=H_NR)#NM3DD.'/TQS>BEPZ3 M,(*KIY%?@ #SAGIGT&'(E'F;UWE?4@2Q0P\'IC,)MF UX& 0!@.(A&%_F%<. M,1$OJ6(JI20V0 $$1P0=IC$E*6(D5@>1H'K4!A,4 'JB5SCXX#?Z($5B ()V MP #>I 780\(*!X89I'LT(:'Y@>)1E-9P6B.U@.11C4=QRB6)C68YC":=FX2 MX6DE 6KK=@&EAI"H)FMEB WQQF[N!H&$*6]&( ]FXTY;@0-CXPYFPP[KD"!> MP XQ*0!QR2(:A)E>P2Y)1@^04?=EB363CLX#?N4 ? X$WRX$WPDZ6'YI9'SAXY0*95>,'JE*0"1.9D>"9)/.9(EN0XGB7VG)0 J MR7GTT)(_B4P))@]U4)-& ]U@)-[9P7NH)H\^5<_B91!J0E#691':9I)239+ MV93#N9Q1R9'#2956B95:&9MV,)NX$ *VJ0FX*9;ON&.U<99I*35KV6@"0 =N MJ9:2MIEU=&G6YC!)5@=XZ9.?!BW5M@Y^25/UZ(""*1+P)@R&&6N(&6\E:6\H MH@GY!H&H*&(%ZG#VAI:*QI8-^J *&J&P5&GA YH"E*%ZB0-\^0$>^I?J^("L M1J*)>:+OEI@K>F@M^J(%T)Z>$/3. (."@PB1F 1-D?"UB705 UB M 8L8&1F1E\@+O$$^-.4 \&= ND, 4*IDZ5(. ((&32PZ8&+!$0%TF. \N.C* MPITE @ () X @ 70Z!3 -0# N@5#31#[8$+1 4P]#@"H$R+K5A/WCB 0 (". MA'\.5 X=9, @ :T!!Q8\F'#AOX8/(TZL>#'CQHX106;$ZD%.#JU?[FX5::\D M/9DKI6K2YY&82:WJ:N HD& B M:N[=!C+8\U M/$T)9M:%?[E!EN P]U&(#V>P0/:(L9$ XZ' V"#H%\-!=>@A1)JDEV#VWEQ(#%? MB&<$>2X:L<,]+:6CQS^+6"'/(D; \X47BY33Q3)5+,+.(.P0@!D ?HR1U4X] M_41'#U,:I=,!22W5U%-13575569QY158!HSU5EPYS%47#I+EE55?##GDT6"* M:<211XJ-5]YY *3G#VO\:.(>?/()2J@F-! P@)/$&)"(!?3@,(H\./QC@S Y M: I,IS94JBFF#J C0CZV%7EDDDNR X$53T8Y)4\^ 87E7CIIB9123#D%E514 M6<583F>=V4.:=:PIUUYTV8670',J5&=@$E&4YV%\%B8222;%*B6N5-9*QPI9 M'L4EKU_^*J:P97;U50]*)0O7L@8U"^>S>N5$YU]V"F9M87HB]I&V1E3FQ64I MK91C'3$E#.6W.85K);G@ZGJNE[Z&&2R9N!;[;KS*MLGLFW%"B^N^@-WY+T8! M9\NR 3-LX\@P,8]6VI,+-SR3K.#2:N6M$5O<9:]@ COFL =YC*::\XI<+\GX M1DMBO]42QC*VB0&\G0>\Y."GBT]JQEE$H1BT@P$2Y&!'#X.X8-<,P$"1WGK3 MQ? HL1) <5I6JBF(@!Q*#"8WIHH ,"CMF65B):)'+!. 9K\@0$'!F@JJ@V8 M:H()!'@3 04!GJ7D 0(0J")-8=#*BFEEF):[I8$80K90C#>M?A"C=M;D8] MPA-[TE_0'ID)BQM _!%.N@WG(JR'XCJNMQ-_P'6AUXZ@ P@RH(G=>".0H7>+ M8Y_($0R\OM/WUB].^O@0Z-ZC/T#R@_[PBUMP/ 77:]B1%/7QI"&%W(_"C;#@X6]KL@(*VV>4Z MFK(%J&B1@\*E+G'08YSC(" M@#1'A0--4& !/2>BXAW!00;J+LP4 $H3 MX4G%'%4G/]F!%1A0!P?LP @*J$,"WA>_="#B)D:%D8P4B0\@X6,!1M!''78! M2E&JC02FA!/,B-SD#3'2@=U @KPWR#I!%%(]A:9@QT?8 MISEKIEORYTZ;]-?( $D!'@*1B""[DZ5Z\E\WI&L.D=$7MMXU[XIG6^G(Q??6UZ3_WR-R?1 M:YR! OSA\(B$ 251P&71R@ ZE*!'PL7JA/.(7"\(%L-C<0D=_K%&I%ILN>RP MP@SLL0X'#%@D!3: $8"48",@H+00YO*05VMA&\*K+.=!I$^.VE@YF4 M*D?!RM,TXLV @RD!)L6I47SJ-)/ LT?%Z)W)&, 7.4@$UW)P&DT(6L].M9ZA M=9'HT^3@GTPBP&E \>@XI;E*('D77F(?H4'2M>O23I7E/ M,Q@-09A-36>-W!!(X/ \ >H+!W_9@.?G!\'#A-+51S MFE<@QP:(UE372F6'?4R$ :=)!K5Q,8QK9]L&VT9'%[Q-#'#C@AOCOH:Y095N M(K#;W>FP]9X_[4EFM*8,7JI; MZ,,VI\E'Q$%%<72,XN(.NB4'5F,#B=N@XX\ >7%PP8"1:\KD'=^#RD\C 9>7 MG.,Y*-499HZ+R9$<5ZJ9_#=W5( _!(&/_&@V^+P",^!PD5&[%@;;WP5 ML4#"%^[V#EX>>5">ZRT#%5+65,X."5TH(803^KC-M?1V.#U !/ZN,VU] S^ MV5&@B1" @D6E>NRK,HB=K@4 ( B$(% YK: 2!U0"%#A^S682#F1<$_(PI, M*#J B:(=BW8P:N2HD&1*0#\ U/GV\>$@=@RL7%GDQ\$BE N,,*A3P0,N,AQ< MPC3@ )VM?X.((4AGA< B*PR.*B@1 $ @<0 +(!&IP"N 0#6';"IDF4/"0#L M#$B'P2NV:.-<_#NE#8 S C@"S!-0:0"T 28(7!,0AD 7 5T&Y!G0AP" L@$X M!,!$0-X # -F$1 8<*#3,U$K7M0DY #"K S2F1O 6J "IVQBOYQ=^S:QW,H& M#/(AA@, /AZ.0MAAH#F?IKCD")]:M0!6K>E*#<"%8J+LF!DW'LAJX)@1>FEM M,C*B+Y$7?.F@ 5@.QCF?$$?1C.M1XP!Z[C@%!\*QE05 M#20B,&&% ODC$#\@5C4$B;GM 0"2\]5WWU'X)*4/'7N5\,\Z93@%2)G1 0P_61XD MD%KM8X]-3I*2E6!B$?" WP* 8;X8_&-Z)62/%WK"#BL,HB@ZL0#Q<(<.5>2C M:X=XDP?\D -.>>I$5SA5OW9@ 3CDH Y@H(X;OJB%=8C 'H2(0PG$I0 K:"(M MC-@ $8BP#@' +V3 Z$!9H@2)>%0A\"H S,,AT8U(H .;=1$61XA1SK:T1AX MM)X>^5A#EOS1&#L4Y! IQPZ2..!$7S 8$8YCD ,0PX(8 0V' $,4Z%*;^UX M7>PZ][G0E6-TD:Q*-? !O4YZX9-8,]42*U6WYRV$DS\A@">MV+$K1 M1!' 1 MC&1$HQ\@B9G8U-#5-J0W>\AR<[0$758@@$M550$?#UH'X^R@.CLX8)@+0HH5"N]%$O_Z'> 'D2)#A58APFUBIRI6"):(5DC'R>#7 UO1 M@0I_$$$+J-<# ^1E+_( P"+^$IC!E*<9 #@' "(0 -:R=@X 6 ( >L "^N&A M!SO0R5Y\,5LPT&\)Z3 &W"K%A0" XE_*W%0BLFB"1!P@'=( @%-,\%)-+"$ ME=@/,0C@%![\M5(@*,!Q'T27Y9[*N>&1+BZ$\-W9A'>\6BDO<]'[-ILM@P#P M36Y*S-O< ZQC#3:S@ 'R*]_S^C<*-I/#@)%;X/ZN(U4P9,$ \KL.%KRP4JK0 MH %LU@OQ,EBY\ST +LJR#G+!D! ,R.\E:^:SO=#"'S, QB9!XC(KA$(=.*". M!')@!PL,P@4XWBF.37",1*6%R =("T_"1EG3,0[3QLU4= M]J*(V>:6#@)81P1L)N'\IB,: +CP;#*L1PLT0D:Y1 <,PI3)!CBE"=6];G:S MPEWU5=<( (B# OB\@Q?5 0@[D%$==D G.]7!SKCP0IZQJ]UIZ4,@^+#9+ 0 M7P3@$\>#,$"0L:A%_](AQE!PB9GLP ]-2&0 !'B0-&/$CT;3APX32*B,3+1< M%26"16+6-3\^C8/FAAA.]+%/ID^<8N2N^!\MMK(_@#/I/6]7DL4ZMX&8X MJVH'K4) G9VRAVI76MCR]36PBUJI,B/79BA6<0[C]^5M?"\%=("T(LS-9VQ# MUF8"!*%7YLWBMGQ/ 74@Q_=\YD*;L=E],_8).]IXA1G\X\8Y-L".>_SC(!.; MR$8& )*57 F.QG*^I"R$:@,@'0$0$)&L$=EZ7_@'GQHAK#3@0JXV'C"/!N-I\75?"]F&/:N&C% MW@D0N5ZJ&3T!M]+ *0L$G6"'%^U%SWM+9L;38^3A['%*,V*/D=D_*.+L2*;< MX_P,?=P]D)"NQN@QKF,>DZ#C."! W\OT]U?'.KZ1_[J#2][D)W]<:*\(@_D & M?8 BI C-H (0H )1F S')A?'WA .F$,-F ,*0@ W=82FL 9!^!.!OG!0( M[. ,:<:"';AZ\8,%NI4."" ?] "/2 $2?@+ ? '$- #(4 _3M #Y;%EZ0 * M >!R M #1)"$SQ /? $22@+7^@.9D@&2<@+4S@!"_2&LR4&20@(7Q@-9O@& M2:@(9H@'2<@*7^@+ >!FAB #_Y!_^V> =& '3J$/+V6(B,@Y288$&G!\7*@, M > 4_Q")C7"(B:@)E7B)6I%)>P$-FX@+!> !4"")H3B*F+@7ME"(GSB)3O$; MK?AF."A3N'&#G$-^$-ASV)"*#\"*UD5I?)8.R' OE=*"S@8/MJ<)N'$,#2-!E"--K.(V,A#7. 45K".H$B)[HB)"6$!.) #H6 #.; .8> 4 M6 "4DPB.XEB*@60 ,R -,;8.1 "0//A56F"0"(D A 5P&D0 G .1$OE5CL@Y M!VEM"."#VD8 0D$4"N >_J!R&QD76U!()7!(B;1(C81#5^!&&7"-?)9)%_"0 M$4D <_15E0"6;KD(QY )B^ $/A)0FH +208 (.-&E7"-P) EY^F=.;">XYF5)>4/W%D WY,#?N"=08">_F $ M]-F>,09\5B"0+=&$,97&;&D87.$$_XDF@ MP! Y1/03!B 4)$%V.2)4A;((,.('^G!-.+$"=) 3OH#+5 '"7 2"K@:,G($ MUV1#HV4/AZ!& E 'OI0D..$"=> !6.H>^D!B6LH/82=5EH0-8"JF9-HS=4 MCW*<4UH$=6!Q,L*F93&E4"JE$H4357JE,K(.;QJG2>*E=!JF)3"F[("G>@HI MAFJF.=$6,98.V2462;$4>Q%%16H"3[IE)[%A,'2/^9<[/F;_Y:B9:C^84HV",>G9NQ@!\ MR72@,2&N=6 "C. %_N >_" +'K .#H D6*HD.V ,=!"PAYH3=9 .[%E'!9I3 M63,;P+AYA"S A!4 25L<"EQT_(K-O,. 1"S"&!T,\(6%R514[DLCB!<6*'%-R\4AOQ9F/%"JSZ(A*:$A,/$KZ->Q(&.XG4M>7A M('L% M^W4$8@*<]S2ZV-0IJ72D 64X20NXA;84$Y!H"(>P28(B*H(H2*,'8),D8V=% M3BM44$L'72!L#B,D-%(D$-6E=M$D.X!1+/(MJ$L'+F!5O6\&?-Q_42^.E'".4#!*&S! M%_!]'H(JFC .+;RB'KS"&LS!H_7";BO#0MP6-=S"Q]NWN\LQ@,NHZ4NX/QQK M,TS"_R#!5WS"HZ;"&%S&+@S#.QO$#\S&-LS!L^LQ$&O(0US$!W#$2;S$I>;$ MS0M5&I-]4SQ536+%6/S''[ .6YQ]X*>U7QS&$3C&@>S&'IS&CHS(;DQ-2 7' M6+2]6"*XZGO'CJS'?/S)*1S*JVS&K1S#KUQRB5P VKLB[W-,3O$!'\ YZS MGQ",R^ 4(O#,FA#-T\QGU8P+)8#-VDS-3H$"X"S-XHP+*U#.V[Q=W?P"ZGS. M,_#.W.P4-R#/[.P4.V#/!-#-/Z#/W3P$_NP41Q#0N+ $! T%!%T%!*T%!/T% M!$T&!)T&!.T&!#T'!(T'!-T'!"T(!'T(!,T(!!T)!&T)_AR7NTS$V6?$X(+$ M2IS23'P EOQ4X"O%'T#%=>#)?OS+HLS%IV+*8,S!8OS"9,S*:$S,,TP'*=#& M'&Q&19JJLAH&5LJV426\H93&^KNI*G"\(J"\"\6\,OV\VS"H);%G!+* MHSQDI7P#IPS4J2S4P3S(((Q.>8S3@PW*0RW,15W(1VW,;ERVBQ>YS94H7W$\ M*R?7DQW8?5S9.OW89PS#EK?+E(T#%5S8EPW91KW&G&W&GHTAH#VYHTTGIBW$ M?H#20Z;2B4('=NW2E=S5W@O%?%ULFQR]@-W+.:W%/.W%;AW4PE#;K1W9L(W: MOFS!K#W,FHW;2AVAN\UXH?T^5D#:O/3##"SAYS;Z.TCBL?;*;+>OUW:/\P =HF7:>'(?[ 7IP T[??LDW8*%)JYQ>V M6N$B]A C]*"WZY!S%E[8WIW%T.<599M][#=]=J##/,SA>=O>,<)+[4TG)$$/ MZOUK>W0?\_'A7D /-.W**#[#?Y (PI93$,"F*L=R,[ -CC ,3Y[&Z8 " 3#7 M*1W)*SW)RHW7S/W$F$S3-CW?A*W"AUULB;W8;^T7CNW?W6T$\F ?\) .?[ ? M0!9]D+=^(=9W) $/TF(J/3SC'_X>0T[,66QX=1"^])#&P68%>47HGWW@/)[C MD=WGQ#L?<>X%.60$\) 4\D ')? 5\G 4\)#74!Q1?O[77$@%6"'" > '>^$, M#I+'7X#H*J#?@GWAECW>F2U4Z] "NZQ$%C[;&2Y_2R;(O";I+)+D\(WEQ:WE MQ]W2Q?W2IA[FFNS7TGW3X%W=M'WF6:O8V=W8V\WK^!W"YGW,#0X _*ID3)#B M>2YYQT;*7:RU)A),0A/H>EO!-&NDEF=X=+#5-[YRU6XD$84A?TT'BL#L00K$ M>4S0E7,YWV\:<#5307F M! ^]8JT31[" 36O5?EN]X')(2NRW!^Z[ [_734O%=+ +"H],"^SL#P_M$=_E M$Y_R%<_S%Z_J9&[9WI[FX?[QW"WR 47RZ!YEZKYR2E8!,4_,*W?E[2U::?WO M*,]02S_5/A\, @'CN^FU7G%,N,#!$ 0, < Y4- Z[S/;_W MR]#W$!0E>*_WU*QM#(#KJ:WKJQWR10WD]$#T\B?)TO[PU$[Q7QW%39_M3Z_3 M43_OX.[QK5WU1?W:FWW>Z;[N<3$#];XAPA0K B$@HWM\=!"^^,#H-[#OD>WO M ._>.Q]5!B_==# *06_XN&#WG),*#D#XR@_XS?_\U*S\B*\)SD_XV@8!CA_> MM$WNF"[GE@_Q7#[MRZWTG?_[H 3+\$:7CJKX76_ /R5\6G/,"$##-<[0, MJ*8)+P !TSQ'0C^RXV_TY:_YYX_VZ2_F3I_QD&_=\M[3\;_FIT__JB_<#G_Y M6Y[<1M\#"_<#G_Y M6Y[RSS51J7$0&7V0 U"$& M.1"EBV"42*F4=#RXC=SP=+WER6W^7H[^>NWY?3U1':GM[0_U\*_FVHWZA#SR M^-_"/MM,I1;<(^SPE[_ER6W^7H[^>NWY?3U1':GM[0_U\*_FVHWZY2[9\IWQ MD-_?@OSF $[#QXQNBU>Z!A;T)MWP=+WER6W^7H[^>NWY?3U1':GM[0_U\*_F MVHWZA#SR^-_"/MM,*8$HJ;OP\3W"#G_Y6Y['"W$"@Q[CTY6._&%L /.! *^H # M0H_'PNWPE[_ER6W^7H[^>NWY?3U1^J/M[0_U\*_FVHWZA#SR^-_"R>R[C7S: M[;_KDD_((X__L8PC.K("9^_5>JWV4X475KH(1HF42DG'@YM3&" 4W<_M]2W( M;ZX.]H$.6!_+Z) 4ZD ',? 5ZG 4Z##\$84.$Z4_=? )($.EVX$ZF ?Z+!7 M1X$.2:$.9F\%ZG 4Z##\$84.$X47!RL0ZB 0Z*#FKBHS5M2V1N .]N%+[-"Z M*9OI\$ 2[' B?V!'%L ..(!Q!8 FS3<'W'=RK2\C:?'D43[E]1_DA-ARH&#G M0?85CR[D++[GP)!J),$.S.2^./OMEF[O'A+H&QYX'>LB];%RA4[Y%7R\B.?> MD*OL6&*HNU__07XA:1RG?CYVX:_I9]<'>Y$%__ 5CTX/W"KT>"S<#G_Y6Y[< MYN_EZ*_7GM_7$X47VM[^4 __:J[=J$_((X__+9S,OBNR_V ##AQT'%MT-+YR M5,OH,!#L&0_YS51JQ]["D!MB@R C>"S$?Y ,"?[>"Q\4XV_TR"WQ,,WY>NWY M?3U1<*'M[0_U\*_FVHWZ,$SY7_'H])#71N'H 5(Q%X-#4:7CB^ A$+X7HK ? MI]W^NR[Y,$SY6-_"S*=Q/(8![N[H ?)Q[+=DW3>D0<>Q14?C*T>U5GWM/V[_ M%;P.%/ 5CR[D$L5^@R C!. $?9 . .M&0B>1+E(?I1WP^!"WPNWY?3U1T*GM[0_U\*_FVHWZA#SR^-_"U"L F6"M<-_(I]W^NR[Y MA#SR^-_"U"L F6"M<#\YXV_T=! $$@_3G*_7GM_7$P6==2#LN4[L+[T.$P#_ M:LYGQ]["UNH!A!_L&0_YS51JQ]["UNH!VB^W1M3P=+WER6W^7H[^>NWY?3U1 M<*'M[0_U\*_FVHWZA#SR^-_9!,X/>6T4"5@Q%X-#:K\('@)(?!"^&B4 !?L' M$X##3A$,V-R6VN6QI%NSH/*^6%OL_>*#XV_T=! $$@_3G*_7GM_7$P6==2#L MN4[L+[T.$P#_:LYGQ]["YT<(($#XP9[QD-],I7;L+7Q^A "VB]Q(SO^1H_< M$@_3G*_7GM_7$P47VM[^4 __:J[=J%_NDBW?&0_Y_2W(;P[@-'S,"8X/>6T4 M 8\/%7,Q.$3\)^(A@,0'X:M1 E"P?S !;8]I3D$-V-R6VH6 !#YLK'MU6;=U MX=!UVN=<< NQ1M3P=+WER6W^7H[^>NWY?3U1T*GM[0_U\*_FVHWZA#SR^-_" MS*=Q/(8![K[B>FY@2]9]/;Z['G(,!D /."!E!B /.*!D+? /-D /./ /-B / M.."S5?N^6)OF,IX(%D /.# *\H #3M 'T%#!BV !]( #H2 /.!"WP;? 1M3P M=+WEF1]_28_VZ2_F3I_QD&_=\M[3\;_FIP_^!D /.) ('B /LHW_-VP#]( # M_V #\H #FM +[ ,YP:-0<>Q14?C*T>UC*X"^"0/FJ^TD!MB@R C.R4/T%W5 M!D /.) ('B /.. $?3 -"8X/<1M\.O4/-L ../ /-H!C_V ##JP)VS "Z]PB M%# 5AL *!ST<2D4_^ $!M '!U#'Z9 -8*,B.COR1H 7E'V $_@_##\ M$?6H=@$7!XO#:KZB"9C71I& %7,QBX /:K\(?R S*=Q/':)=TX 0"=T$OEQ M[+=DW6>5C+("OJ$J1? =>W3Q5Y=U6Q<.7:=]SO4J:!<-WE_L_<*M0C^RXV_T MR"WQ,,WY>NWY?3U1T*GM[0_U\*_FVHWZY8X?K#7^1H_<$@_3G*_7GM_7$P47 MVM[^4 __:J[=J$_(QIN >6T4"5@Q%X-#:K\('O(H?*#[M&L,?3 !..P4YX#- M;:E='HLA5PNWY?3U1<*'M[0_U\*_FVHWZ MA&R\"9C71I& %7,Q.*3VB^ AC\('ND^[QM '$X##CXC-;:E='HLA5P /S*=Q/(8![A[P^/!Q M[+=DW;=A&)$#52$']Q"WP"S?&0_Y_2W( M;P[@-'S,6GWV7JW7:J_J17F42;F4N&S'"X_'\IWQD-_?@OSF $[#QZS59^_5 M>JWV4P479I^ PQ]1CVH7GF&EBV"42*F4=#RXC7S:[;_KDD_((X__G4W@_,!% M1UD'!D =2BD^4&NEBV"42*F4=#RXC7S:[;_KDD_((X__L8PC.K("9^_5>JWV MJEZ41YF42XG+=KSP>"S?&0_Y_2W(;P[@-'S,Q[L"9^_5>JWV4]615KH(1HF4 M2DG'@]O(I]W^NR[YA#SR^!_+.*(C*W#V7JW7:C]5<&&EBV"42*F4=#RXC7S: M[;_KDD_((X__L8PC.K("9^_5>JWV4^495KH(1HF42DG'@]O(I]W^NR[YA#SR M^!_+.*(C*W#V7JW7:C]5,&FEBV"42*F4=#RXC7S:[;_KDD_((X__L8PC.K(" M9^_5>JWV4U515KH(1HF42DG'@]O(I]W^NR[YA#SR^!_+.*(C*W#V7JW7:C]5 MT&FEBV"42*F4=#RXC7S:[;_KDD_((X__L8PC.K("9^_5>JWV4Z4_5KH(1HF4 M2DG'@]O(I]W^NR[YA#SR^!_+.*(C*W#V7JW7:C]5^F.EBV"42*F4=#RXC7S: M[;_KDD_((X__G4W@_,!%D 7_0 U.$(7U241YF42XG+=LP0UA_X5O "T$_W MN"#]FF %+P#]=+_\=Z\)5O "VB]Q\3W"H=_?@OSFJB_?&0_Y_2W(;P[@-'S, M.-SVF%:A"4J54;H(1HF42DG'@YM3= #A>R%_SL* )-D !3Y930=']W%[?@MS=!D /.) ('B /LHW_ M+7R5N. 9(!,*%I #5[D"*#P(A7%^! "=H@6-FA "!""1'@[BQ%;I0# F6"MR-N# Y[,? M;H /R84A.FN\94\&9^_5>JWVJBX$S*=Q/-8!*;[(5# 5AL **P)%F !3R973D!99<$'>\$%6.$&^)!<& )4 M!D /.) ('B /.(#:FF #%/!D<1M\"USHA9S%WE_L_>(B];%R-"($TV<#]( # M_V #\H #@9[LC>?[*COD!D /.) ('B /D)]5(3!]-D /./ /-B /.(#O-+YR MB6 !]( #HR /.'#V7MVBPE8Q%Z/V'C,*#MSVF%85B= J<<\0ABP ?5!R@JP) MW4 KM 0A\4H># 5DMLI%+ID??C]K\(%L ..(!Q!2 @S3<'W'=R*1X*#IP) MU@KW'\=^[FX!-("4,O#XVN=<[FX!_( #H: /./!Q(6L##IQ>@^ &^)!<&**S MQEOV9'#V7JW7:J_J0L!\&L=C'9#BBUQU+!YB2]9]/1['MISL!K8.*4#I!L . M.) (D1<*#FRU 8#"QV ]( #4F8 \H #::$)%F !3R973D!99<$'>T$1@^ & M^)!<& )4!D /.) ('B /.(#:FF #%/!D<1M\.E7HA7SH"9C7$D/@_% Q%Z/V M'C,*#EP58> CS(P+) "$%06G$,*!N *WG,EW6P"( !!'NWY?3U1%:7M[0_U\*_FVHWZ,$SYW<_M]2W(W6T ]( # MB> !\B#;^'_#,=%W3,:Q[.$B];%ROE$1_S^T6*,)]3!;%""VM+86=3 ! O%V M=D /XPP";!F6Z!;IDBO:%L ..(!Q!2 @S3<'W'=R[A[P^/!Q[.?N%L #2*D# MCZ]]SN7N%L /.! *^H #'\=^S*=Q/(8![A[P^/!Q[+=DW=<>&)$#9:$)-D ! M3S8Y8F[O'J()3V"&%."J%U]DGB%R1=:1^Y'%FF !%O!DR]!WFF )". *WL/. M_V #1_D/-J"4FF )". *WL/.VA;?(^SPE[_ER6W^7H[^>NWY?3U1%:7M[0_U M\*_FVHWZ'VP ]( #B> !\B#;^-_"[ D%?<=D',L>+E(?*^<4. "4(!/\H#F M8H,UFE /LT4!8DMK:U$'$W ,!D /."!E!B /.) 6FF !%O!DZY#5Z=W;5>?C M!D /.) ('B /.& SG9 KN ]$7C'P_ !\H #S*=Q/(8![K[B M>FY@2]9][8$1.5 6FF #%/!DZU #^"0/:"[[]_X$9D@!KNH!\E!L1>89(E=D M'2E%2LD(!D /.) ('B /.* )%F !3P:QWE_L_;*X;&$"F@"3'/RY-D /./ / M-B /.* )^F,<"* ),,G!YP=HQB%DT.U/!D /.) ('B /D#\M;%T52KJBQ]3] MW%[?@MS=!D /.) ('B /LHW_+1P*\H #"V ]( #7!@,HF4!]( #H2 /.##\ MGN8!\E!L4Q4!]+,7;X1/\J#Y2IL(%H /.# *]H #-#('BV ![( #&%< M)\ M<\!])^?N%D /.! *\H #'\=^[FX!,("4+O#XVN=<[FX!_( #H: /./!Q:^L! M]H #C& ]( #B> !\H #QX 1#PP FF #%/!DZ^#U'B /T%W5!D /.) ('B / M.* )%F !3R;T0@;=*5O(AVX!]( #H2 /. "YRM[C25)DGB%R1=:1 * )%F ! M3S8YXV_TR"WQ,,WY>NWY?3U1':GM[0_U\*_FVHWZ'VP ]( #B> !\B#;^-_" M^"0/T'U%&855RS#^1H_<$@_3G*_7GM_7$U51VM[^4 __:J[=J/_!!D /.) ( M'B /LHW_+8Q/\H#F8H,U#ABS^ZQM\?W $9X.403A>R$'4O3LDLP$$@_3G*_7 MGM_7$Y5D=1 "8GX/J#O6H6_=\M[3\;_FIT_N*YP6]^W=^-_"P]?VF*8)GF& M=: ^"0(.9#&01^71F3DH[H?1KX7NWY?3U1258'(2#F M]X"Z8QWZUBWO/1W_:W[ZY+[":7'?KHS_-VP';*T)*AJ!! =M5KH(%D (2"D( M2SFRFH"6C$D$<1M\VP;AH[H?1KX7NWY?3U1258'(2#F M]X"Z8QWZUBWO/1W_:W[ZY+[":7'?KHS_-VP';*T)*AJ!! =M5KH(%D (2"D( M2]D _FNMNWY?3U1258' M(2#F]X"Z8QWZUBWO/1W_:W[ZY+[":7'?\\$/]F%\^-_"OM"1C# -4=X(/E[_ M0;X.*W F;:\)*NJ!.<)B5KH(%D (2"D(2]D!)>@/_X\(!S @3M 'TD GF6"M MR$'4O3LDLP$$@_3G*_7GM_7$Y5D=1 " M8GX/J#O6H6_=\M[3\;_FIT_N*YP6]ST?_& ?QH?_+>P+GL$(TQ#EC> %]C ? M(>X%\K .*W F;:\)*NJ!.<)B5KH(%D (2"D(2]D!)>@/)"$/)H (!W 2\N $ M?2 -F"80]O#V/!BWPR$'4O3LDLP$$@_3G*_7GM_7$Y5D M=1 "8GX/J,NR$'4O3LDLP$$@_3G*_7GM_7$Y5D=1 "8GX/ MJ,NNWY?3U1258'(2#F]X"ZS!GZUBWO/1W_:W[ZY+[",'G?WHW_ M+7Q-3//BF!9#,FN42*F4P3W"#G_Y6Y[NWY?3U1258'(2#F]X"ZS!GZUBWO M/1W_:W[ZY+[",'G?WHW_G4W@_)#7$D/@_% Q%Z/V'N,2;D]!BV"42*F4.>4 M1M3P=+WER6W^7H[^>NWY?3U1<*'M[0_U\*_FVHWZA&R\"9C7$D/@_% Q%Z/V M'K,H$#ZJ^V'D>R$'4O3LDLP$$@_3G*_7GM_7$Y5D=1 "8GX/J,N2TQ!,X/%7,Q48SS2NOA( [AH[H?1KX7NWY?3U1258'(2#F]X"ZS!GZUBWO/1W_:W[ZY+[",'G?WHW_+>P+GL$(TQ#E MC1#DX:_IZZ !?7X2J7X M" E;D]!3M 'X[ (1HF42AFWP3?TI]W^NR[YA#SR M1CZJ^V'D>R$'4O3LDLP$$@_3G*_7GM_7$Y5D=1 "8GX/J,NNWY?3U1258'(2#F]X"ZS!GZUBWO/1W_:W[ZY+[",'G?KHS_-VP';.V MQN$51HF42CDY3M$?G),&'. *WG//N- ]$(^W':[;_K MDD_((X__L8PC.H($9^_5>JWV4P47]WKV7MVBPE8Q%Z/V'A/-N !MI4IYK#L( M.<$'$U"J_9()U@KW=#RXD^,4.@ "$%06G",''> *WG,EW *WG,EW0P$( !!<,$YNWY?3U1%:7M[0_U\*_FVHWZPL!,WFWD>U$'^]'P=+WER6W^ M7H[^>NWY?3U1':GM[0_U\*_FVHWZVVV54"[EV_#C]H_UL4P/20$I1^ 40P " MO_B A.;HB9YH]% '!A (AQ$7*N 42@ "O_B A.;H=5 B48/N"80;V<']. 4 M3P ";!F6% @,J<9D',L>+A+GG'X/QN 9=:!$ W$>;E\/LT4!Z40!OG$>;M\ M9D@!8EMX:5T'5CFXHHQNFFYLDBO:5C#JG!ZWPNWY M?3U12:;M[0_U\*_FVHWZA#SR^-_"U'LJX"(N$W!-]NXAFO $9D@!KBI11>89 M(E=D'4GA@]O(1KX7NWY?3U1258'(2#F]X"Z8QWZUBWO M/1W_:W[Z] _@-'S,U'LJX"(N$W!-]NXAFO $9D@!KBI11>89(E=D'4GA@]O( M1KX7NWY?3U1258'(2#F]X"ZS!GZUBWO/1W_:W[Z] _@ M-'S,U'LJX"(N$W!-]NXAFO $9D@!KBI11>89(E=D'4GA@]O(#4_76Y[NWY?3U12:;M[0_U\*_FVHWZ,$SYXV_TR"WQ,,WY>NWY?3U1 M<*'M[0_U\*_FVHWZY6[CPL_Y+9K@^% Q%Q/%B_>W'I/O#4_76Y["S?&0_Y_2W(;P[@ M-'S,Q\LC"3C\$?6H=I%D3G)-]X"ZS%F41YF42XG+=KSP>"S<#G_Y6Y[NWY?3U1%:7M[0_U\*_FVHWZA#SR^-_"U"L 2) )U@KWC=SP=+WER6W^ M7H[^>NWY?3U1%:7M[0_U\*_FVHWZA#SR^-_"US0(?R XUJ41YF42XG+=KSP M$#"7(DQLX:_IA9(.@[ ?#4_76Y[U,I\D MO!H7+Y#QT)VRE*_O00XM1,O6@"<$[PCARI#@^,"M0C^RXV_TR"WQ,,WY>NWY M?3U1%:7M[0_U\*_FVHWZY2[9PNWPE[_ER6W^7H[^>NWY?3U1<*'M[0_U\*_F MVHWZA#SR^-_9!,X/>6T4"5@Q%X-#:K\('@)(?, 4I6T4 M"5@Q%X-#:K\('O(H?, 4IT$,^]'P=+WER6W^ M7H[^>NWY?3U1<*'M[0_U\*_FVHWZA&R\"9C71I& %7,QBX /:K\(?R /<,' M#"!UB8($.W ,?= !..P4C@ ";!F6Z^"Q&+((?R 3X#U+4RU ^ -\P$/]N$. MDKD"QK H1V$/%*()U\"Q15>QPR:^!# ?(>X%\K .$D 2[E 7)"$/)H (!W 2 M[G 2^.L$]M 'Z4 2\F "O"I:"NWY?3U1%:7M[0_U M\*_FVHWZA#SR^-_"S*=Q/(8![K[B>FY@2]9]/;Z['N($QV ]( #4F8 \H # M\2&^!# WA#9%?8/-D /./ /-B /./ /3H /)K(2M!#X:,F81+#A@=>QB6 ! M]( #HR /.. $?1 -%;P(%D /.! *\H #<1M\"VQ$#4_76Y[Y\9?T:)_^8N[T M&0_YUBWO/1W_:W[ZX&\ ]( #B> !\B#;^'_#-D /./ /-B /.* )#? "RW!N M\T8AFG -'%MT%3MLXDL D9T.=B!%\O#PW@(NXD($^"0/FJ^TP\\ ^"0/T/VS M$P63=3#*\@#=/ZL25;=XB' )X$/ZT !^"0/:"[[]S[U^"0/T%W5!D /.) ( M'B /.. $?+ 7A/ /)L*KHI6 /HAJN"#]FG (,. *WL/.J(8+3!#XAP #KN ] M[(QJN- #@7\(,. *WL/.J(8+1Q#XAP #KN ][(QJO1/XAP #KN ][,R>?Q_X MAP #KN ][,R>$,0$@7\(,. *WL/.[ E!/1#XAP #KN ][,R>$'0$@7\(,. * MWL/.[ E!OL,YAP #KN ][*QM&" 4XV_TR"WQ,,WY>NWY?3U1%:7M[0_U\*_F MVHWZY2[9PNWPE[_ER6W^7H[^>NWY?3U1%:7M[0_U\*_FVHWZA#SR^-_"5!O^ MFNX>Z! ?B^1P2=_\Z7;.1& [R/L' M#- #@(]K/= # [0.8] #1S! /< $9[T.5W!V?5"41YF42XG+P) .#1 9_<' M17F42;F4N P,Z9 /%#ZXZ1!:9\<'17F42;F4N P,Z> - '!V?E"41YF42XG+ MP) .RI V1H .)\$.1X$.B:8.?; 1\$.B>8.?9 G_W 4!M #OL.%B0 R=D# M@ ]7/= #]',$Z7 )LW4$].,%/< $]#,"Z=!E1X$.B:8.?/!X1L .B>8.?5"4 M1YF42XG+P) .:D#VZ)!HZL '17F42;F4N/R>4W 4Z)!HZL 'CV<$[)!H[L ' M17F42;F4N/R>-' 4[)!H[L '17F42;F4N/R>'7 4[)!H[L 'CV<$Z)!HZM ' M17F42;F4N/RC<1M\#"_<#G_Y6Y[NWY?3U1<*'M[0_U\*_FVHWZA#SR M^-_9!,X/>2TQ!,X/%7,Q:N\Q9[F8 *WL/.J(8+/1#X6U #KN ][(QJN' $@;\%-> *WL/.J-8[@;\%-> *WL/. M[/GW@;\%-> *WL/.[ E!3!#X6U #KN ][,R>$-0#@;\%-> *WL/.[ E!1Q#X M6U #KN ][,R>$.0[G+,%-> *WL/.<2D4XV_TR"WQ,,WY>NWY?3U1,*GM[0_U M\*_FVHWZA"Q4&.4AXV_TR"WQ,,WY>NWY?3U1,*GM[0_U\*_FVHWZA"Q4&/4' M H#U8>P'T/GO?,E&;@1'@0D/]E (:L1&0 ='@ [7'@& )"-W!V5KH(1HF42DG'@[L.)'!V?%"41YF42XG+[QD!9^<'17F42;F4 MN/RC<1M\#"_?&0_Y_2W(W6T ]( #B> !\B#;1KX7=; ?#4_76Y[J M;/T/-D /./ /-B /.* )#@ RZ!=>6L!]( #HR /.(##_V #]( #_V #\H # MFG *SMKA%D /.# *\@#Y7F$!]( #H2 /.!#<(QSZ_2W(;Z[Z0ASAZ1!%$+X7 MNWY?3U1258'(2#F]X"ZS!GZUBWO/1W_:W[ZY+[",'G? MKHS_L5PGMQ;\=#+\!3]1^D,'. #\"8X/PU_P$^4_1>7V4]_VF(;#FB %+[ , MVH4 ==S(#4_76Y["S<#G_Y6Y[> M,(4+&I "G .%84"MR[SP6T4"5@Q%X-#:K\('C+^1H_<$@_3G*_7GM_7$P47VM[^4 __ M:J[=J$_(QIN >6T4"5@Q%[,(^*#VB_ ' H#U+>Q&Q2*10(<&!R"12^8""0!K MTV<#\( #_V #[H #;]^58!MX'9L(%D /.# *\H #_V #]( #_V #\H #H0 ! M.9 )U@KW&QYX'9L(%D /.# *\H #_V #]( #_V #\H #H> .9 )U@KW&QYX M'9L(%D /.# *\H #_V #]( #_V #\H #_V #X( #_V #WH #;]^58!MX'9L( M%D /.# *\H #_V #]( #_V #\H #_V #!) #_V # I #;]^58!MX'9L(%D / M.# *\H #_V #]( #_V #\H #_V ##) #_V #"I #;]^58!MX'9L(%D /.# * M\H #BV !]( #H2 /.,"M0H_'PNWPE[_ER6W^7H[^>NWY?3U1%:7M[0_U\*_F MVHWZA"Q43A$,(, Y"R G=-0XLUFK B!P3I$,(, Y"R K<.!8D+RP " MG+, B!PP9[QD-],I7;L+7Q^U! @?AP. 4S@ "G+, B!P_V #^( #_V # M]H #FD - 2!PFL -E#8Y6-_"[ E3N* !*< Y4!@&U&H RX#U+:P)13 V27T M>"S$$9X.CB!%SX[Y$@_3G*_7GM_7$P47Y:_YYX_VZ2_F4^49VM[^4 __:J[= MJ$_((X__+5S'C6SD>^$(4O3LF"_Q,,WY>NWY?3U1<%'^FG_^:)_^8CY5GJ'M M[0_U\*_FVHWZA#SR^._&1HF42JGD$+X7CB!%SX[Y$@_3G*_7GM_7$P47Y:_Y MYX_VZ2_F4^49VM[^4 __:J[=J _#F0X/$+X7\; ?1KX7CB!%SX[Y$@_3G*_7 MGM_7$P47Y:_YYX_VZ2_F4^49VM[^4 __:J[=J _#E(_U-TS[=D /FM #'K ) M$6"L"XRL,U,S=H"_=@ /FM #'K )$6"L"XRLX+"LGM$.Q4H,$("L^$ S8VD' M^&L'\* )/> !FQ !QKK R#HS/0".[%"L6H&L^$ S.-SVF,:LSNK#"X_'\IWQ MD-_?@OSF $[#QWR\69V PQ]1CVH7<%$'"$C@"B@&Q\L$9^_5>JWV4^49=: " M2*(R+", QQHS]+"L'9D &/ @FG ,%<69G'.M @FP.*SF*ZK+I]W^NR[YA#SR M^!_+.*(C69V PQ]1CVH7<%$'"$C@"B@&Q\L$9^_5>JWV4^49=: "2*(R+", MQQHS]+"L$I$/Q:H5FG ,%<69G'.M @FP.*SF*_K#'-#]W%[?@OSF $[#QWR\ M*W#V7JW7:C]5<&&E:_=R4,N%Z"!:"3C\$?6H=N$9YC,,P:LR+", R$H.-",0 MZB 0Z" 0YB 0Y* )'9D &/ @R,H.- ,S1D .S8 #9L .R$H/- ,S!L -( S M[]$,.I -,.,#]L #-*,()G //. )=: ",&,$[* )QU!1 &#)TE ',,"/=; " M,&,$[- ,.& Y "R,H.-+,.&@ S!L -( S[]$,.I -,.,#]L #-*,()G / M/. )U@KW&8,+*A#X"H FQ !\0"3C\$?6H M=@$7?WKV7MVBPE8Q%Q/%.*^T+F(.,4(.OI $<;$$QUL#9^_5>JWV4^49=3 ! M2*(R+", R,H.-.,+@ :P.*SFQIK'>V$$$7H,/= "]%.<+T _.) .-Q"A\0-H M=. !/9 $]+,7*(#>YG 4Y' /VG# @U 8+F(.,4(.Z2 !!0 S1L .S5 #X("L M[$ SZ2 $1H_@$8'1] #24 _>S$/TV(. D$.FH *'K )$6"L?F ..D$O?D . MX[H7UJ#BYG 4Y RS7 #1L --,-GS8 #/D .(("L[$ SO@!HZ4 +TX*_=@ / M N$. L$.F@ .'K )$? @,&, Y "S8 #=L .R,H.-),.CH#'\IWQD-_?@OSF M3YO67(@V9^_5>JWV4P47YL,'6-8#@$8'.= #24 _>Z$19^_5+2IL%7,Q48SS M2NLBZA CZ. UHI6 >2TQ!,X/%7,Q48SS2@LRS7 #1L --,-GR$H/-),.@$#V M.*(C:G#V7JW7:C]5GE$'2$!9@$8',= #27!S'/05YG 4Y RS7 #1L --,-G MR,H.-(,D*L,R H"L]$ SO@!HZ^ !2*(R+", R$H/- .P.*SF*QH_@,:%-!"& M24 _>X$" R"9/= $2:@$4\@"/= "]&,&?U !/6 "2:B)/: "]&,&/; "]#,$ M&FF&+T _<] #19"$8/"%O-D#7D"&<=@#49"$T=4#4I"$A9$.9=@#;9"$K-4# M?)"$E?"%V&C M?X B48.=[ 7<"@27Z$.1X$.A68.L)X.@L@'")!HY" '>R$*"Z,.1X$.+F(. M,4(.Z3 )"Z,.1X$.(-,,-V $W$ SQKK R(H--/,5YG 4Y RS7 #1D --&.L M"XRLT+"LGN$"&#!.QQHSV+"LS9I^6_$'"V,.1T$.(V $Z# "5J .+F(.,4(. MZ> ""V,.1T$.28$."V %ZN BYA CY) .&; PYG 4Y# #1H .,V %ZN BYA C MY) .!! FF #'[ )$:"1HG4,/? "],,%?R !/: "]$,$/; "T=D#+4 _*0 U MLU4$@3A;34 _7] #;4 _S8 #7L .,.,#]L #-*,()G //. )=O % MZV !,/,>S8 #7L .,.,#]L #-*,()G //. )X$&IQ,_@$8'-9<$-[<.)" 0YB 0Y/#V/+@.%" 0^&L'\" 0[B 0[,"LSJH5 MW%KX?A#X$_ FQ !@9IT!Z8X,6&3%WZ*A)0( ""0. ( %T'KB&@!@W0%B.$TH.H"I!U02(C!03@SX8>*S2G$P6@1PO1I4H/E,Q)0#I6 GH,$3VM=!'1V0+T M8"+Z@.M(L>>()A' G >'X Y#\"+OZ?M'K9!VG1E@'Z+H:<8/NF( MT-YB 0R"& #I7-">&_@TZ 5\Z3#P'6+B20%%,S<8P4XS/0Q"# $1(=!,#EZ@ M0Z(F @"0"@8F(I#BBBV^V(0 Z!(# +IF$ @?AX"**())J((CLJLNAB#YHX M _%]1XHY,Z\N@CD/"L%=YB1H8X8HDG7IDCE%+Z0N./9CZIR8X]UIB.+EYV M^*&829;))(YNOA -E6RN2>64,*Y93J$U GFG4B2N6239VIBP9^!VCAHI(;* MZ82B13(ZII)MOG@ .Q4&FJA6LJ) :=A-@KJI6X^ $ :UH*J9N9_IB..!M^ MV>F1G^IYZXM2AE#KJ6^FJBML_]BA3[/X:!*,!PDI262KP3[*YXM^24663T0P%TZ 0C@5S,\=%,8CO"0V-ACHG527 VRB;9,9QB M)AIGIHFF2&F9T3%$.JGH=IMD.>C&FV1-3&>);M!)UDYG$!S'DQP],"<9*1#R MH9MPDME2VG62H0-A&@&L: [(*QH1,#K] "YY)1;'N64E6X.CN=V1&['Y'94;L?E:6HN^-W#H*XZZZY? M[B>@-6YNBNV@MR[ZI+S_N'DBP*\>^NN:C%IJ[[/WL$X;GRLO//.RT@J]%X.O M$T7UN(M>K.S O?_D"\D908_K77]XM^=W[1$3[\.>>K+@(K.- L_YH M%C\T,8Z@6*L<76C(0R(RD8IIHD ,Q,@:/@ 0P!S#! M @I#AQYX,'&!$0 (WX(PN2RL*WWY2.).\K"R<*4.&N%(#DXH$I*8!"47.*$) M_G$'%?[C!@0TX(E@(I.4K"0H3)Q)36["C[JTA85Q41A=V'*7O.RE+V$)S& * M[K$'1M(2 #XDP#WT ( R(#'N(@Y*<9!U!-"01C8C$ M KK$6C$1AA-9XI(HTL0F.+$B5!R9L+G(DA]XT0M?'"9&P)#1"O)0##S<(X_. M;& ^[H''?2; %'D\!1Y[_$^ #A/,K^5/= U @%7:Q9C%%$4?=-# '?-(36$2 MZ8]&H,4+&Q862YIE8OL P"VQ*-,M%BR77^2E8'QI&,0; Wed, 30 Aug 89 16:33:04 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: 30 Aug 89 02:58:49 GMT From: jdm Organization: Hodge Computer Research Corporation Subject: xscheme.arc (Part 1 of 3) Message-Id: <21722@hodge.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu begin 666 xscheme.arc M&@A-04-23U,N4P 1=A 0 ",2-ZX_PJX* ,*,B4,9/&31D0)<:\:0,G M#9N#"ADZ+).B@0*+ 0<6/(BB1!D\<,*X(=.B39@Q3\8 GRI440D C0M(EB3IXV8MZPV8EB3!@Y/%VF@ G4 (J'=&:B:"E2 M(%049\ID;?HTZDL0)TH8=4,G#)X4D ;\A(1@:-2N9>3,5; 5)%ZH+7W&A,07 MJU:N(_/.##O6*>">*="6,(GR#5RY@QG81>QUKH..G$N>3+FR;\C$CZ52A?19 MH9O2CLU&!NUW9 LV:>8T)I/Z):0#713G5GS9IB<.[%KGRO4=>GI7457AEU6/)VITD,;WPW5_67R]F$ZUQB] MZ<*&#YD%P@@AO $''6F\X488;+#DAAW;V961&6'4P08=+;PAAAIEC$''3F4\ MF%Q'$0'($7JV448:5UF'5AQUO$$'1T[Q!L*233(W6&%6GH"EE@>E M]>-J?'7I)9A.!I4C"C^"L%9;> QYE9%B(*DDDTZ2-X(98F)49XD3R='"G6[I M6>212:( YY-E2DDEE&9FN>5,74(U*9M5'IE&35M[.80"5M]-.K"9V0@C 3IYBX3FLG)\=;L0&QSEYC MQK!$ZLI:L\)[,INKR/:^AM;+TKW<0LQ?H:PR7 7DN ,(5*!QT))LL/'&'06= M 8)" FU[UTB)'RO6"UBI0+E8 M/B!VBZH$?5(4;:=B1UQQIT)$'"&_81$5*(PF>1ANX"PZ"$TS> M4<89:8@$0A*O(4@'CP<5#WB':+BAU!MGY*$Z$;WGEJ ;Q-O41.B"FX3@&$#_ M[40+-\ P PV (T^&\FUX'A60H#KHR8%SYKL(7UH6HY)AI06= ]X9W-"&$&4% M9Q'JSLV^DS,,6NQ:8(N-!\'VK1FIA%->PB".ZH5!_2R0/R>2CUA: *=MT4LF M/WM662I6KQR"S3 HN,K..!6&@]W'7QHD&MEX-B8ZA0$.")$AAB*8A@E6D"U+ M9-/12$BP<*',B)#HFP+]@S:'$0M/DLM*"1_(0S*:*%9G-%;EHB@C-J[J;&]< M%QJQDKDQT-&!,^2AH48#I):UH"!;.H,\7T=2-5SE@Y M8>@,!O'6:E8038(,D?)DRL+*=]+000.B#$Z=@N6 ,%.',YTT+GOJS','31DY M>'&#: .UI7 SHN6\#0/]. C!==W(!G[RC1D00YXT@9*$21$I+:9D<4(E"):8 M,P7:Q (EB!,BYUL8.3J$2I(G3DRA0UYOM &'76&(<1<(O>6&E7$$(J<88XY! M5IE>)VE6FQUA !;:8/$-9)5@:.U4AAMTL"&2=ZBIQII9>:Q41AOP*8 "=E;A M%0044!1Q7PN0I9?%1RB<<>(<>;210@H@T+1<'2OQ]10(1KJ!9!M8:16&'6^D M09A><-!1AX16Q90 ) 0X.<9Q=(21& HYS?8&&V^;# YAVQUA,;='#7> M6$9V>!740A'TV8>?%#$UA (;8;0A!AEA@/!H"F8Z>A=+:64J$ J>$H!"''&T M<)<=#C%94X=WA!$C"#[TX%"H*!@Z1!#H#4$$HPHD (D!3P:Z:25HF ;')CV MZBNPCY91%@JCEJJ7;M%:.FUM.*4@D)GR?4IJ"V.002VIUHJ++;)H)9+301ADM7+FDNK\: M\.A<99U@,,+EZB8PP?5**RZ^W4K,!L4@G""5E1V#.W#*X1(,+*T%>1HLI))2 M:NFQ^"X;[,F$07NE&'/2BS/$:$X=[M,#??IN5FT(G6V3(&C'1F5NU"&I=9Q9])+EP%RVZ+.X6P(*9]J:0PK9-Z5TV=2 MWNRST;; (1O M6@;J3ZM^0+4 AV$NSB K7_JTX#Z?[=KY6FHY'9B_WI6E$77NO1V@HYGRZ>6W M'?5E_?Y[[>(G] :Y:-&WG[AN\,NOM&@-PS'R&%8Y0_I^5;G+>0Y5* C? 0=8 MM$U9JG2GT]WJW.6Z4FD.!K)K ^TZ1)KD[:YWOWM#\(XSO.)UY7@27![K[-<\ M_,TM?FZ8'\/.\K\ @JP A3N9< YVHH0MK&%)ZN"9#&"I$AP+-PIK#O$29SUT M#8!;./R4$6^SDR2.P3E,=*$3A6@^2"QO8]73HK8(H#L4;*][%OP>"CBWP.B= MKT,,Y-?Q+(>UZ0TLC&HK0*CP53@'&HZ*>W+)V.( @CQM2UDH8-T8C#.&-;3@ M6T>T$G=:8 9(P419! 08(QT)24!RYUPZ":0;ED2WX[1$-X(T@YL @QPS)2"2 MHAQCH'#D!KPTI@A#6$(+#(6H^@3H/TYHE*5H1JR;92M3UG))S\H6MJG(#5FN MM-8F'UDJ6'Z2F55#&\EP=L@$) !:H2G0,W,&@A&8(6?&8@,=,9E(=QW.?8J; MV\5ZJ+ 9)HFQ;9%HX64U/"K*%39N<-$=*S198\Z0M4QL" M9CFH'('',;G<910.E:A? D@_3 B"04= !]F102LB;60 :4HH$/23I[YEFP3!F"I$B3(CI !'$#XHD8-67&T&GQ1DZ:,F[HE"$#8LH8-&7:E"%X4(25 M,G+FI'E#$8:+&#=80@K1)(R.' 0#'CPA)H]22!^(A+&3AF23 M-"?#E&$#0D@9.GJ>BH#BXHF+KF_P$*5!XVD'*%]ABNGXILX9-$.=( $!8P:- M&CAT=D!AHV\*$#EDT&A!(\9?$"C0O%&90N>$(6_@Y/%XEP[D,8>+'AW:%(14 MJE:QHM'*U2O8IQZ"L.$J)4WG.2"DE)D#T\[(IPO@RFF39HY,FB"*@S@C)TS( MD2#,= 11QXV&"" M"U(QA4X,7"A@11HBJ""#+D B@@Q/,9!$@E(\04050U"1!((IGC!#BT& X,03 M"H)@1(Q-@$!%0Q)5<>034J3805L*',1 $5A (4414TQQHQ-3I(A"#2T*\2(1 M+QXA))--= E)"3' T.(41411Q8)#E.EE##&T2$013 2111%$@%"$%4$P4440 M-N(("5$L1@F)BPI*@>B6*:80PXZ.,K"G$2\FD2B7.3K6(A-)3$&%D%4X4>.6 M:I(0 YB9[FFJ%#3:: 5_I)J*JJJ?JHD!3F]FT8003S"QZZH(JBE"#(%E>FN- M3![;:XK+(I5I$%)(FH6TK*8X@@QN9KKAK5)HB2"WR:;H@0QY9DI%%E#P9R6@ M20R!*);>RM"HE'$>2NJ[(,Q+IKT*JOF!#+!*B:VG2#QDXQ#H@@K)NC:TZ$05 M#TE1KX%/- '%PE.<:T2JR$IL@0S62BDF%5>4BNL31]1;:,1J9C!#N%+.6B;- MU,[0;LY4:.R$F0=Z#++()$^+T S[/LH0MD'46(04'!NM<"DZ:[-@V8TJ=[?;O3=U]^#3UTT 0O!BUCK5L>1 &$ M$OY=(23XF8222LGAYEQR;<#!1DH@T1$&'3-1](89(-"!4DDG<0\"''*\P5P8 M;1#GQAD@L.'<&75$N)*C"-R1AOD@* ,>1.*&XQ2P?&\ P1SJ &^;E )PB@ DJN P*?3&@,=9##=4+"ACQ@3WO<"\GW MPH>;\8% (>FCGARJXX8.T@\YYMO??9(@A":T H0RG>^('C/(RTPU5,0H$0R3B@(Q#E#&,X" M@B1X1CG@R=[V1-)"$-S!(W0@8'(H$L3UM>]]')S?&NTWO_PU[P1#.$$)HUB] M (9!)GT4( &E2!+_ ? \4_SC_P0IACJD@0T;Z> :S5 =C=!PDDNTGW%V0T<[ M5G(J83AE&,2PO4$JL"X_F9!TAH- $'3'#2U88Q[%X\7R4(M+CG@AJZ9E++E E MN)G#9":TAN[<87MD:)X-(TJ]Z>0*"K#\I4K66!TIQL1[4?0A"&Q82/"X80S_ MI$,-R1=!C&B$(]^\H"$U"#_YG4&::TP""*ZS3)"0I)!S><,:0"""*62G#AI) MX83:F(3GR(%]7YDA.LF'F>S5021R6",4#KG!.8B@FRY$@D_B29(@B&$K&J5( M&X\ D_*01 EA<.$4SC.'-EROC7"H R^+@Q(RK+$T(IQ0$SP5L.L8)Z6%;,(8 MCM"<.[0 ":=LS1ND:J#)P,$Y+AQF_:?(@ M!JK0KXW*/1\31KF]-8YW#G" 275=*)4>;B5@9S'"-\E@6+U2LB>!1 -Y<&.$ MK6RO." IYEW7B!(VP(&5;$ J[Q;<.P8[N,$@!-Y^#N* 'OTH2$/JF)&0% 0E M(2%:D'@ \R8$)1!:&$C\R7"1CL2?#B])"B!, OGR -S5^&:2+LP@+U."&T^B MX8:Q'8H9RO!>,UQG0F $@4V]IY'@/A0!JBTP'&8JAQ*2@2HXI2,4MG?)"5U' M)6VX:Y7-]ST%=A"G0,[AA(JS1ESJ^U&@*T3S,-O@R#"#0[UU6ZQNN,!)_ M^AM*?5T(RI@0>"H3NFN #;L&F?HF)J]TL_W@C!P\V\$G'Z&#"VUHV)-TD)9) MG3%PQU >KB3Y.@"MZ%!W;&,;&6QT# M3HVC92[S)L^(=F.M86) 8]8AS%,PMEKG8)23A#MW@6OI=)PQD.*4+ MI3UNF<#YKL-\,JEG(U.5*'B(HC;VK"F)YU+2#[?N5(F0T_#2\LG!A4F>M5J@ M:A=B Y,W;# #2V4R/W7+.9A*?H,4AXJ:D=0RXOF>T +%O9LY(-B7(O?AO,]G M\:'PAI(D]_<_'UC")K;3$=#H(Z1GR-W/8VNF],\)X7$\\0RR,<3AGO M*IL0BKOL90*E_K^' M0V\B+ES@&20TAW,>4+5IR%[[?*--G?HQM-V;5[V_13XR M>HR;H7 M\L\.]26VOU>&1_LQL HTI>6+765JCV0.=$3"/%L/$[CS#PH""@*<3/,$'P$) M=L$?_H*0$ 15 0H$Y#(7ET#0LB4IR4 -&<(2=E;]O3QDC9PJ%Q5"$(*J*_4. M=6$#2=B0AC54._/J9B)K/=)RR8 R.M.A]AVBPUHZ:'4.;48&G%1,&<=.YH=S M=^ #(#(1 80' M8&4.]8BUS%D*Y1E51=9M58>=3 A-'4^;]B& MOA0#-!X'0$=N'5ZV"16A)1 V*8:ZO:'<*8<<]%2%-4BRG$] M,-$^8Y9 @5B'? =%F4A)EK@]AH< *" G* 8"/$ &$-@&/E 9_',"L3B+7CA- M#( "<5 ';^""N>A_M'@8K:>'K%=/"32,[^8#=,0#4D&,/A!M+O1KJ-4BI2<' M;N!,J&99W0.),T4^>-9(=>$X1[6(B/"KB+%O-N,$%K*AD22,D# ML@C0X539*!5 M2D:2RB%*@11@I2$3>N1"@]A$+'=Q%Y@II[5"0<0;N"% 8VA N*%:A91!;@F7 M2?9K"P=2L-0BA>03^%-YR@A_IS5+[Y@<=#"1?%B6WS,=;?259EF54F*8EH68 M.6>4R,B0F'4^EE4'J"13C#D2<,EF@&E1T%%(LUF;+6>9+BF3J]B5Y:@18XER M$]018VF:2H26:OF%3F8<^D-W,=5R=59)=$E*>GE3?'E;?RDE@=D]*$&887B8 MKZ28LID19?"1:2A!&C$40=0B'U:F<&M$10]%&E2D'E]D]F?EKFZE/Q32? MF:(2YB-SH(EW./61O4=WVY.??P^D9JMES- 24)'2,\LAZ9""?YU.? M][D5RUEERN&.Q82?%16>CQ(&#=0^[+.0$X*@DM&9,T@&:C>B/1=HL>EENT&; MX/-:4F*C,E=) ]J;Z[E P/E=%HJ9/RB$4LH>1:@?PI.$58@E37@04%B=>,.5 M?3(L1- C/%!GY3$'8SD79) 'M0@B/& $'6%8Q36-8I1^)&&-$BBG^?:?V\1^ MC5="N"%.Y)0&=X6:CW)7370'%$H2/*"F;%IU=4J;=[I5=/>+@\B'/$5M5!9< MBXB-8KB:-$1'/6(_82:+YPFJR.&A2/E$#-B6N'D=TB0E> @25-$^;E!YO@1. M0]9DV!9@IP<_8F"J&4J&R*&;J7F4(%I)7Y828@8=#AF8$(1LYW.;;PFK57<% M*#%0B$BMN8D;]H-6<3D;T.%J&D4].I@_7"&#:L[9: A8FL#-DB_@-XOU9Z400=I2$&R"53AKB%.X8;C7@^9LH&',JGGN&G M"SAXEO5C341JCC>3\=<1EN5 U_E=654>$7NA>2B/3_2O7/%KBG@=)-&P830A M&9N1B^I&GHJ>-,&PVMI-,K=ITBJSP"JLGZJAR*&RF8>-_ H=O&&I(4$>L^%" M#3LA CN [FJKE0>:-O[&1];2D M0LJUB]D^C4E"D6EX#/"F<7JF=&I_ZK=U2.:P\92H,E5G.J 3$-"56@B=(+ % M(Q "3P %GS(S7IFX*3( 7;"X9\$#@3BLNXC@NY6R*Y M;T"Y:7FYIJLXIZ*YG+N6CN( O7H=A3M-$#"Z8GD0!-")>.>1+KNG%QJZDTNZ M!S$ G2@^YA0^SJ2NW6.\FXN\:0F\(F!9=/!6T!L2(!)9)'1VYB-ZT)J9>%:F M>3NG]5,GK% #=1'1_E$JL5:0)&_P5N_:RLE]XM[[*MS&4$3&.03$ZN^;1N:CO>\ M3PJ@X4B9TSK U6J $L&\(9RN([Q-N@9_"*P]'_&R>M4BD;FIDS%*GF=UGEE) M.UR7(?IJ)ME,7+' E70&#NJB#+"4YW._9%1F]@D^/O<1'PP"4F0&82"D' &? M=/ #+0)6 :>Q*HR.-%<53X1G"2AXY8,=*TIDQS9)+9(9+4R\N*JO9SR (QFN M7#$=069DB_W3.-6\ # MY8%6VR@2/M"Y7RBVY(.OS*8WBR>\BN%,$#T+SCS0Q';/9& ] M+:+%Q34A2-Q&W0&+&:V-K$?0L)81)EC#_JQNOTD'<_RSITJT8MN.!11K/\W+ M:X0"43,$6@J+J=B%L$BK; %)D9?+859X&'0UW4+O<5Y2?820U%1=S4$;W71=#74#T$4ITE?JVP MUL3#UK3NW+ M CZ$"U:E1S@\69HEQOR$4=@L7+DA@0+0]@-*T$F[_")M/\9$6WQND=JWOP;! M=6:X7;G2@7W8X5/A('*[$]+.SWQ+;J"7)DX3"SK($K[A5AW#ULC$(H!7)S3A M%_U6F(UN5QSBNHL"?#)\/(#;*,Z+/6)3)(';T7W0<.712(FPATSB^XW4.Q5[ M/$>&-U;C%*ZS5.924 0^?:RI["V_TT/ER?AU^NS6*$M'V!I@Y4OB;.[,H[>1 M;S[203V_AM5!,I7D,>X&/B#F"CV0&D[AK1G>N-41+K78;KNUGGQ)1.W<2NY+ MA03FO,'3)JVV#7G%:YWFCU)(W<-Q)Z3!1QVV*5U(+ H=FL[1F9*#'?1L?93I M=F[3RZCD'!M$VMHBZVW4+,[2#?T5)YW>0FW?*5UJ TGB^_J:[R?3Y[; ',N? M(T32%QE ,XW#/EX&?1[I]UU3&OP_LISJ[0;/#.#?/@W@9!"5)NA&)+2\V'YN MB7[1;B2V.C60NK[HBBW>O]ZUE#Y3U-;1G8[2!%[P QZ$!CYA6$K,6KK@7=H\ MUL*5S1?A)%ZY%OXH>!CLTXC;UM.A4FYDD[%:JUQ,G#%>/?0/8QX>/?G_4;ND49"O8:TSA[1]$R2I#[HS?[1[W=5 M<+Z'/YDIAHBR*E\__P[EPX[S1._#%+U5U]$B-\WQ]0X"(W!')4WLGEZTB#7.M$F]H&BQCX%FPDA[S^A9YS0J_T-AQ_*228 83=W5%Y[%K<4975@ZD3(J3ZK;_:TK00J_T-JQN4PL=9YW7(0'IFZ_R M+3+(4&Y#^[^FG&[V*%UU18#AW>3]/R2. ^G>0H[]:SJ-#BG2UY':;F"WIH]G MT6_M,\Q^([&?KIK"4;R 8>!^5ZS)AV_<:H ME53:3EQFT<].8/K;*D#]WG\&U[__:ZK]CS(%\+-5N.'\88A3YA3%K)UHWG\& M'3\AW(;! NVT+133="_R%;M4>=^B3T5TWG\& 'P^=E]1))1/A%I>F3*)O23/ M5KYF]>^T:: 'X CV#8SAAV_<[ 2FOWTE$-.HWG\&U[__:ZK]C\+]WG\&X.__ M?JMN1!ZZ*'#^QIW^ZU^+:\^+;;3_:[JW=GJ0E;J'-,BU3K2I;;"(@8^2[G+( M[MWQB5872&>QNX&QC[BQ>4970IG F>W>5=>)9'@&$%V@W@[*:G[J*K0;(!MP+4?__^,#49GICIK8 M3]/R2.Q2W7 M5KT:'XR-34M">\14@0^HGEGVJ7V#T=9H+?<_ZQ-&!E=>4)] 6?QIP756Z-I' M3)5",G%C^TM+5?<$FHJ]VF'9HLX >\14E?1H4)L]#Z2 Z?P_P37: AI&!J=V M"036V(CAL+C^T^AC=>$9HTA_]./$F\^UU]C>Z.^,]&P^P[Z"6&'9RD$5\02B MW=ZN9K"K9 ]%6?QI0]Q&GJA"TX'C.F<;VRBN)%&M0C?YK\EL$$S__U/H];V" M6&'9RD%M!><3NR8E=T5J]]=<2=KQM3SE2-P<%!W%%-$47@\_*MQ5ZM8&8>09 MRX0\14^PEXF;[^AE*Q9I1,U3%DLT 6PQ&A@4^ MD9D'L]_+N(^$% GE:2B2;:T>TB#9B9%H:NK)\GE/^:0'918+4H2=4$'B47)MF_[ MMF_[#H;[2 @!>](G?Q(H@U(HA_(I_3'\C0(B>](G?Q(H@U(HA_(I((("&S(% M:10TAU,DJAD#IRH#%P\!0_!O+HC*<+^"K-5JDG%N(/BRA?FI,0 900[/$,#H M\3,2--I"A]%&V!:SY9-+7"'.GRH#D(%M,1NZ\AS.@;H5@04=U6'F1A($FU-) MD3D2O76'"01*H;LA4Y!&07,X33 4W3-%Y'_.UMWEN+&_NY&[3T$!*)#%GY9G MK+5$/N&Y6X,"6?QID.$]IZ1 V<%:;7 8*#!,:(8"8T &5;:"K-4&*9"6(((" M>](GVR+H+J_]D !1<"O5B[.@ZYD_X;G>"8"&40](GVW(=EMIX!0T!R:9N&40](G6;"@/?BGX&.N M0T4_I@!JZ4;_/$#R)O83;*:WQ51?SH=NJ3,_G89_I^'9:'&>W*# $1$ UI\5Q%P\!AIT=.AA_9%!E:DC('&>W*# $>( '5'-:'.>Y MCX("0X ':4DUI\5QGOLH*# $> )!$ UI\5Q%^\?Y2E,K;2QK5FG>J=:>53] M&"!)D U3+RV! ?0_(_2002!)TW$"1' "B_^0 M07 "H=MX2I28TU%(]D(UK'13EMU&>'8"1"!)C:=$B3D=A30$1 !CC@(!K'13 MCD='<(JB!013.#44*& O1$ U>' 8A7@^]FFNN($"]@)CCG*X0T $5(,'*=!; M((("N7(JJKGVNCL$_^:">/;)V!:SV!Y#E@>^3RS*!8H2H$34_EN8@;*_5'!6F91,G73%3S>J"3FI)X]FA:Z%&NW M4 T%\<+[B_R9[F^X0=! =0>_F1^G1.Q#O42Q$ZD$34_EN8L:U%:QE%B53-UW!H3O48D[JV:-IBTS)O(@"5Q)]_$&Q%P\!0_!O M+HAGGXQM,8OM,61YX'L^]FFN'QRZ4"Q .&5.OG0=ML:'^"G1&0TH_4+<:&+H]\3KZ9T_/JN\H$&!8=#!M]&.B\9J8 M=1%%[!I V:-IBTSV-R_[H8N'K'13&XO%)DB'F$Z1;JRB229%:"4_:R:.+@H! M)HJKAD4'Z5.8G[J@#S$L4Q,=K639H(0;_5(H/^![_9%9#F$%T=%*E@U*N!$G M5O #54?MDN4041 =K639H%30$! G/V"W4)TE3P QJMETZNNYCP+566(%I]IT MZNNYCP+561(%I]ITZGOQ$& $R#5) 102'W=G>F4Z MGPR\GVQ#I^6^"TIJ569##OQCI\5QE13 D ![C=P2'<^8T &**K>APB:Y\9* M-[6Q=.<30.$Z>&98 M=#!M]'-:'%=)TM%2)4CV-R_[53?1(V31W!ZZI)X]FK;(9'_SLG_!T=%*&XO% M)DB'F(X2H;O2SV3*6!P7P_%I<8QG[N="AD4'Z5.8G[J@PA@ 3"20&748&O04B M*) K5- "_[$YB^P9;G#Q$* ;#^URBO7)$>0]GW:G+J3+5-%R40?X+@H!)HJ9 M7$NQLV_[ML\_$G:EFH(E08,\M[)0I7(V2;/@###\R'9:'%=,JKF@2#SP!+MK_6$^ MRK&_UH[NLE;#=HL"?-T"0T $4E!^I\5QIWKQ$# %7Q%_9%!E:DC('%=,JKF@ M2#SP!+MK_6$^RK&_UH[NLE;#LV_[MF_[ML_\$G:E$3 %PD(LA9,T"QX!P^_@ MO#@%PD(LA9,TK (B*$ LJ4($/Z! >= &%P\!NO'0N#'V<8QG9]!$8N!,-E_: M3JQS>1!F\;3W_?'Z,T71%LU.((("4R LQ,($+4 HAL(?#8'>1!F\;2@2#SP!+MK_6$^RK&_UH[NLE;#=HL"4R LQ,($ M1Y0KIS('>= &%P\!?,7:^BNC,*%IBUQ1QH%---I)__-C>#8'>1!F\62W*,#7 M:20LQ,($1Y0K?3T'>6!G--QX%P\!4_ 5ZI9!9:EIBUQ1QH%--'IY (1G&">*9_0U$=7Z312IL'819/"SJCVQ3]F!JZK)X'819/9LL59JB^ M7(MG8"5UKH9G;O!N8A:Z,)I> YOU>+C^3FM(X,1VE20"1Z"]2'<^Z^^TH>L& M[R9FE10#R:Y >1!F\51)NZWN@#I)=MP]OMZ>+:"MY51_PW4Z@96A)=17U&@JW' ->E!H6OZ>.8&[R9FE;3; MZLZN[B8>M+9 9D!X&?45>=X?R>9N\"8'HKK*4\3J>1!F\93$NM4<#,FN[@9O M:>4H$* <9[:L0F5<"R0&2[N'V_2_Q70$"S(%PF*VL]P?$D)MS>&";O!N8B;F M2[N'-&BW*' $OZU >6!G&00'%P\!?,7:F\^U>)9!9:EI7(MG6!G&31EJGGQ$# %7U&)?B^.0U66FL:U>#8'>1!F\;2@ M&00'H0O%P#L'>1!F\13%9*]N&526FF9,\%/&*!&Z&526FO8"2)Q'U0^.G2B MIJQN&526FK;(E=X?$#P'>1!F\33[4HK[2!@!ST(%T>(YO7(0$3#\$<^+ST(% MT>(YO0(B*/ L5! MJKGVNCL$_^:"EG:B?B09YV:BF-F:_5G+!8H2H$34_EN8@;*_5'!6F91,G73%3S>J"3F>*8' M,&%MC@(!(7D& .0;$FJW*- $0; $1= "ST(%T1*2%P\!/>%^K^8;$CKUNZWN MJS4_YF.W*/ L5, D+2 @0W,DZZ81%P\!?,7:,@L29P! :KAN$FJW*/ L5, D M+7 E!>(;3>8&%P\!NO'0ZA82/V:BN*J&ZR:AD*$',)% 8M!E9-!;((("ST(% M3))&OUU^OM%D^,\^%P\!4_ 5ZA82/V:BN*J&ZR:AD*$',)% 8M!E9-!;M5_[ MM4^ET"-A5QH!V*(M-.,@40@NS\, V*(M- ,B*- $0; $1= "V*(M6!P#6"P# M:Z^[/>%^DY1OS>%"*. ;$LJUOB&AKD]5WO! M"J17HMR:7U0&$I)6C@(!"R0&XU1.EH<">@ 3"20&748&O04B4)TM?I)&OUU^ M/M$B7*K?E%92 A:>4H$+! M8C!.Y61Y** ',)% 8M!E9-!;M5_[M5_[N(^$#S N4R-]-',0(E:=[/(\## N M4R-]- ,B*# %PD(L3- "/J SOC\'>= &%P\!F-'5,*%JE!(((".C,T+> #4R LQ&(L*WCQ$( 9 M70T3JK:""'O*"I0'819/=*0;#YW/CVQ3] M9:Q?N$%J9OT_(W20QE0&=Q"Z*"^::BI4'<^]DD],[I-T<]. M((("ST(%3-("/I KI^(;&G'Q$( 970T3JN8;$NKF%$M'NO'0^?S)^1NZ)HJ9 M4^\;$FJW*) K5- "/O L5! M%'OQ$( 970T3JO;)K>H;$DI'NO'0^>P;$JKR MH6NBF#GU%&NW** S0],"/I KI[*"%P\!F-'5,*%J*XBPI[S(Z^M/#YW/GYR_ MH9L5.XE68L[J->E!((("N4(%+> #.N/[%'OQ$( 970T3JO;)-I05.\G*IZQ M->E!5:<;#PW3C@(!*RA3V!:S2J:3.LANK4GJVX.94T^Q=HL"3R,%+> #Q5,$ M1S U2J:3%P\!F-'5,*%J6;&3K'S*8OL<$B('=*0;#WW%PE3 M.CA%#GD]7U0&$B('=HL"Q5,$1S U+> #3T,U;G#Q$( 970T3+3I((B$A529\ M=:)4_?A^J*R3.@@3=*0;#UW0$%!3.JF#H209YR9\=:)4_6CMA?1%92 AP&[R9F M*?7ZH1N,(V31[!2Z3J"5Z2P%D.A,;O!N8M;QJ1^,Q/85L== #T2PN]8?!6BW M*% \17 $4_,#IWKQ$* ;#XT;8Q_'1^_R+CY((B$A9D=)KQ^ZP3A"%LU.(((" M3R,%/W"J%P\!NO'0N#'V<7ST+L]-6;&3X-I&KQ^ZP3A"%LU.(((".C,T/W"J M%P\!NO'0N#$"<7ST+L]-*VC=E/3ZH1N,(V31[ 0B*/ L5, D/W"J%P\!NO'0 MN#'V<7ST+N^&)YI2KQ^ZP3A"%LU.((("5O($4CTC5_(#IWKQ$* ;#XT;8Q_' M1^_RW+2_LL5$8:15G@L)$-!&KS]3%&W1[ 0B* %3$(%/W"J%P\!NO'0N#'V M<7ST+L]-J992KS]3%&W1[ 0B* V2G)$3$(%/W"J%P\!NO'0N#'V<7ST+N_B M@Y18GI%J*?7ZH1N,(V31[ 0B*/ V9G-$3$(%/W"J%P\!NO'0N#'V<7ST+N_B M,W56B>49J992KQ^ZP3A"%LU.((("J],Z-?(#IWKQ$* ;#XT;8Q_'1^_R+CY3 M7IQ2KQ^ZP3A"%LU.M1]A1JCP$? N\1(P5S(P]^*$#U*=BO$\O5@$!-("J],Z M-?(#IWKQ$* ;#XT;8Q_'1^_RE51(Q^D9 T^PN]8?5Q($@<) R"%%(N%*91U ML$P^L]9+3B[NE49)KQ^ZP3A"%LU.((("F])A3$ %+; ZK5,C/W"J%P\!NO'0 MN#'V<7ST+E])A72]621QVEY M229%:"4_:_:S T="K X_#P4!Q[F^_O30N#'V<1Q$ T="K X_?$<2KQ^ZP3A" M%EW&^I68K639U_1$5REVX'L^)HJ9H6M#\#L4OB&A-51E*^A#N-&"9LL58G=V M1I\'Z570$&!#;O!N8H:2O&CD4? #IQH#IRH#%P\!936>]621QVEY229%:"4_ M:_:S T="K X_#P4!Q[F^_O30N#'V<1Q$ T="K X_?$<2KQ^ZP3A"%EW&^I68 MK63995EG^9RHKYVN KB:H2MV9P=$%GF/B%@4ON+Y4$:9R4H40#& MC@(!1COP8D\^O4J4IH5I+<>4<1Q$ T="D=V0E=X? 6<&=*A=#;B:M'3!5G9I M,B12TJH^TS/[MF_[#H;[ M2/@ "W,D#K,QGM,K!R%BU2D#7\KD&G,D#K,QGM,K((("6C U3_ #QG3Q$* ; M#XT;8Q_'A>0&[R9FE:0',''*E/3Z,T71%LU.((("4(!%GI($M_(#QG3Q$* ; M#XT;8Q_'A>0&[R9F2!I&XLYUE/3Z,T71%LU.((("3E $1S IM_(#QG3Q$* ; M#XT;8Q_'A>0&[R9FE41M<@0^7$=)KS]3%&W1[ 0B*" C1/ #QG3Q$* ;#XT; M8Q_'A?1%92 A*%I# IA2KS]3%&W1[ 0B1GXK3O #QG3Q$* ;#XT;8Q_'A?1% M92 A*+JO=$Y)KS]3%&W1[ 0B1HX%44,%/V!,%P\!NO'0N#'V<5Q(;O!N8A;= M>*"#*?7Z,T71%LU.H>L$6IG.9LQ*-V79Y;'&HZ^-N/'ZOE2 9D:#H2M .NAN M\!83K7F5>? 5L== #Q3@4H("+T(E44,%/V!,%P\!NO'0N#'V<5Q(;O!N8E9) MGX8'.IA2KS]3%&W1[!2Z3J"5Z6S&K'13EET>:SSZVH@;8^]+!6AF-!BZ J2# M[@9O,=&:5YD'7Q%[#?1 2XE*! T)',OQG3Q_K%O9)S/;O!N8O9U8OL<$F)V ME#3P'QRZ0^W8<0XB*& $3/ $T>(&%P\!NO'05VP__NG&7U0&$E)[P4CU_CE% M9$81;F"W*"#5F[,S;G#Q$* ;#WW%A55J;OQ%92 AM1>,"B2GVS-F,VA,=HL" M,9(J@>(&%P\!NO'05\Q$,?NG7U0&$A**QC04[=-2")M O$<1O>JB$)#;JY%R M:YQY%4EDA&217U0&$A)-(((",; "QD2[0(C[2/@ "W,D#K,QGM,K!R%BU2D# MR:R[NO'0H&[?7-N ::BI3ISZ[R9F=HL"+1 #*V!,%P\!NO'0H&[?7+M 8I = M.IB&F@KR=E9(;O!N8F:W4"T$#>(&%P\!NO'05[Q+&B6/+MCOA>0&[R9F=HL" M1S $@>(&,6!,,G#Q$* ;#WW%S-%_;KQ,R!%P^>3'1EV1">0&[R9F*,F+*" I MO*]A;G#Q$* ;#YW/IQGR;O!N8I9Y%4ED%*$',''*E(1,,0 9%-$&HSU@C@(! MU_-%92 A0&[R9F*37PH&[?CAWG((("+6!,,6!,,K#VNCM88I =.EB8&-[X M@-YR;O!N8C;W(>\&,9!2 __!H3O4CAWG((("*F!,,6!,,K#VNML$C0U#5^P& M[R9F]T\2 P_J]NW8<0XB*/ "QG3Q$* ;#XT;,? ";F"W*/ "QA0#QB0#:Z^[ M1.">XF1,,3#E#OQC$/QECB]3;O!N8G;_)#'P!0T!C-VD(VVWK5@%0)($'6), M,6!,,K#VNDL$[BE.ZO9%92 AM1<#4^[ /P;!7^;X,N4&[R9F!0T!;33PH&[? MX"D2$E)E60D^VFTD^E70$,!*-V79U_1$7U0&$E)E 9=/X6.W*' E31 $8S(U MQA0#QB0#%P\!1.">XJ1N7U0&$E)[,3#EA?1%92 AM2<#*37P'WS[T"-A5_H M"W,D#K,QGM,K!R%BU2D##JZ[7^;X+F6W*#!96>,&,6!,,K#VNJL;#WW%;O!N M8G9Y %1(\A-Y[S;2=HL"31 $6&!,,6!,,K#VNJL;#WW%;O!N8G9Y %1(AH4' MD?=N(VVW** E6>,&%P\!NO'05\QRF*IN;O!N8F:W*' @#>(&%P\!NO'05PP> M+(>IZN8&[R9F=HL"_Y$U;G#Q$* ;#WW%,"4AVP3!;O!N8F:W4*TE6>,&%P\! MNO'05^P38] "+(>IZN8&[R9F=AO<6&1,%P\!NO'05^P38_ =8?1I4^\&[R9F M=@O5_Y$U>'#Q$* ;#WW%/C$&+0!3$K)--H0'=@O5_Y$U+H0'%P\!NO'05^P3 M8] ","4AVV1#>? ">&"W1EXEQG3Q$* ;#UV82Y5+!.K$J6^W*# %42 %I^(& M%P\!NO'05SP'OWAV[1.,7.L&=FOD57(J;A #QB0#%P\!NO'0Z1@#2Y5+!.K$ MJ2\#Z[-[1,321'@(0&=F9#;C#[" \]$G:E M"W Q&;,Q1?,Q5X,T:9,L!Q$L&[R9FN&%8=$"O M)SP26,%Z*?7Z,T71%JW"<)I6C@(!LPY3.#4470D":N%">G 81COP8G]'Y*,6 MRK$]ET5F%+%K_=%&4.NM7D=F%*$'LV_[MF_[ML\_$G:E#+ R+3-\3 S,E,X M2;/@#1"%-_,\#+ R+3-\3 S,E,X2<,J((("3 S$V],,6!,,K#VNJL;#WW% M!EN1 "81O#_U7U0&$F)VHFRW*, $,',C5.,&,6!,,K#VNJL;#WW%!EN1 #9( M3'0>#EH15 /!7U0&$I)6C@(!%6RW*, $,(,%T>(&,6!,,K#VNJL;#WW%!EN1 M !:&3'0>#EH15 /!7U0&$I)6C@(!%6RW*, $,'-AQG3Q$* ;#WW%!EN1 !9S M>A1#]^T&LV_[MF_[!0X]$G:E$: SON\YO7(0$1"%/O,\#* SON\YO0(B** S M0]," C(T1Z) V7'Q$* ;#WW%(7D& 3!*^A#=HL".C,T+7 Q3, $/Z! V7'Q M$* ;#XT;8Q_'K%Z3]>>0>!:29P! -J0',''*E/3ZH1N,(V31[ 0B** S0]," M00 %\<+["I0=,;#VNJL;#PWJ]LVU,)I>(>MR-1F[R"/F2W*# %52 $.N/[*ZA 9X2A473Q$* ;#WW%"R0&*YB&Y+.""G1&0_I= M!WQ&+6JH$.!4UHVAE(0"7U0&$A(3O77!2W4_UAZ/Y^&@H-P?C5?(;21 3'0> M#LJU3C7[MF_[ H[[2+@ .N/[1?,Q5X,T:9,L4A*%3/,\#* SOE\T'W,U2),V MR0(B** S0\,#/Z! V1$#"I0=,N"YCX(".C,T/? #"I0=,:! V2$#GOLH** S M0^,#/Z! V1$#"I0=,N"YCX(".C,T/- #/Z! V1$#"I0=,N"YCX(".C,T/M # M/Z! V1$#"I0=,G#Q_E&>PM1*&QMSV7-V*^A#]T\2 R_V=_2SH;N"/H0;AD4' M]'K"(X$5K)=2KS]3%&W1*@RG:>4H$##K,(530X$".C,T/ ":I$'AV&T R_V M=T0^:J$(#/? #"I0=,:! V2$#%^\?Y2E,K;2Q,9<]9[>"/G3_)#'P M8G]'/QNZ*^A#N&%8=$"O)SP26,%Z*?7Z,T71%JW"<)I6C@(!LPY3.#44** S M0],"=<(#(* 6>7 81COP8G]'Y*,6RK$]QA&Z9$81>4!'0S!WRG&5,G$&/31K MI$;?53<"/6)8=) ^N#$"PM1*&QMSV7-V M6;&3:'7_)#'P8G]'/QNZ6;&3:(4;AD4']'K"(X$5K)=2KS]3%&W1*@RG:>4H M$##K,(530X$"3R,%/ ":I$'AV&T R_V=T0^:J$(#/? #2H8&,:!D M:" #%^\?Y2E,K;2Q,9<]9Y<5.XE6]T\2 R_V=_2SH9L5.XE6N&%8=$"O)SP2 M6,%Z*?7Z,T71%JW"<)I6C@(!LPY3.#44*/ T4M "=<(#(* 6>7 81COP8G]' MY*,6RK$]QA&Z9$81>4!'0S!WRG&5,G$&/31KI$;?53<"/6)8=' 2N#$",YO4)A4=@V]O$H8",V;Q,WGM,K((("5Q($@;(% MJ<;-NJL; '?_@3_W(<_J_UW#Z_- *7W3J1:ZD/W?0!U_*228@Y18GI%JE>2. M=*0;#UW0$'#T+H]W +>IUW.Q37VQ((X$5K!?' M_X-W&,ZJYU-W-C1KY>4H$+!%^OM =HL"5Q($1- "3T,U6Y!JW*R[N@%P^9P5 M.PFN(&]GK/[?-;P^#Y32-YUJH0O9_PW4\9="@CE(B>49J59)[DA'NO'0!0T! M-:63.CA%_T82I"D^7AS%!SQ#5(?A MK'H^=6=#LU9>C@(!6Z2_#V2W*' E04 $+2 $61 D6Y!JW*R[N@%P^=P4+@CR M=L;J_UW#Z_- *7W3J?;=_;';ZLZN2I9"@CE(B>49J59)[DA'NO'0'QRZ3>&" M_T82I"D^7AS%!SQ#50H$'"<7VQ((X$5K!?'_X-W&,ZJYU-W M-C1KO;1%#P4!J6:W*' %&A,DJKFXJ<;-F8("5O(B,7"JBYMJW*R[5P!(:8S_ M+E^@Y[/;ZKX^#Y32-YUJH0O9_PW4\9="@CE39Y58GI%JE>2.@=P?HN]'@"1( M._=CR:9N5Q($@<)*-V79I.:B$/!O+^MKTK8&$ZD<*N$<;2O%-?G]9KNR4NN= M,6NH$(!;68GG;905.XE6/89Y DI_L.EJ(Q"ZZNAX=HL"5Z Q"M("3T,U0+$% MJ<;-NGL%@)3&2J:3.CA%3JQS_UW#Z_- *7W3J?;=_;';ZLZN2I9"@CE39Y58 MGI%JE>2.=HL"5Z Q"M("0I %00(46Y!JW*R[5P!(:0Q7+NC$.O??-;P^#Y32 M-YUJW]T?NZWN[*ID*228,W56B>49J59)[FBW*$ F4P!\?G*JBYMJW)PI*& E M+P(QJKFXJ<;-NGL%@)3&^._R!7H^NZWNZ_- *7W3J1:ZD/W?0!U_*228,W56 MB>49J59)[AC(_2'Z?@1(@N1C==&B+I250TH_6;&3:(62C@(!3I! 68GG1@NC MZ>43^587E+2"/G3_2Z23.LAN.1>ZVQE@/E87K#TA(W"1WN-XL^]@N(^$#@ V M8O,V<>,YO4)A43@#4\B+*. $17 %I.($_+$%J<;-NFM5')S/^I>^:+ZSNZWN MZ_- *7W3J?;=_;';ZLZN2I9"@CE39Y58GI%JE>2.LV_[MF_[MB^EN(^$#? V M<;,AQE,X2;/@#1"%=_,\JE,VU[!!Y[^9N\%9E-F2BF,FU>/;)R1:ZF*R_]#?//IS;U_-% M92 A$ZINAH4'D?=N[@9O:>4H$ #97U%,;I#2_U-)K\^NZ4L<9$]W%3M($_<_ M>1"KD. ?^L6P5YS%6XQ**9W;?PP=(&]G-55JG>\H$(!"*J1=-C_P 2XE*& E MQ6-%L7,DB^L&W*R[F!$2[5-!!Y[^9N\%9E-K0]?;;E>$9MC0<=%!NZ MR6:V*ZN_]#?//IS;U_-%92 A$ZINAH4'D?=NH>L&[R9FE<0;%6M,*?T_E?3Z M[)J^Q$'V=%>QH=M!$_<_>3"1RE&(YY/%6XQ**9W;?PP=(-\&H5M3I<:N2I9" M@IGRL7_VM5_[M6_PN(^$$* W_,$WQ>L,??%-\GM,K7PAX MTI%"4V_.@MMRC[L@T=%*&UL^8>!^DS13S:N!LTS!DUQ,!TO&4>P9L]9+?%-\ MA9A O\9M:T81U>\3NU:D,J?"<%IEU>\3J45VNZY?'2^Q_6^G\,?J>1!F\10F M+X(M64!'<#IFFG11!F\60D5'(JI$81 M+$O*[!?@4H("C[L@+0 V2M(">L,?*[BX3-%!/I$'W*R[3Y!>!Q1U9&=,\$.P M('<^*VC=E#3P]S](B57I_9%J=HL"C[L@+? V9M,">L,?*[BX3-%!/I$'W*R[ M0_!O>!YU9&=,\$.P('<^*VC=E#3P]Q^Z=4$'B>49J6:W*/"X"]("00 %\<+[ M+: W_+&"B\L4'>03><#-NOL$Z75 44=VQ@0_! MRY[."@TN:#>14,C7P!0T! MUU,7=)!8GI%J=HL"C[L@+5 %4#"F"M(">L,?*[BX3-%!/I$'W*R[3Y!>!Q1U M9&=,\$.P('<^*SBXT]%!B=6B)%$7=)!8E=X?;33P]S](B44'+U 7=)!8GI%J M=HL"1_#;+: W17!$6.0IR9-J%P\!NO'05XQ"*J1=L]9+#B03ENV0US,^9L ; M=T013>',H0OR=@959:#$_):&1CUKJ@@B*,#7+: W17!$6.0I6U)^J1:.9L ; MGM&K-'CQ$# %7W'%**1"VC5KO>1 ,F'9#GD]XV,&O'%'%-$4SARZ(&]G4%4& M2LQO:6C4L]9+*-"K%-&K-!A OWBF?)$"OM1 ,F'9*-"K%-&K M-!A OWBF1'$8TQ' D !=??WO80"O4H1O4J# ?2+9QH4O55UNO'05ZQ_H3MK MO>1 ,F'9#GD]XV,&O.$9(&]GK'Y&W]Z^J@@B*# $3(!%17!$3'(JJ7;Q$# $ M?)G&C)]J=HL"0\ $6%0$+0 V2G)$3'(JJ7;Q$# $?)G&8NL&B>49J6:W*# $ M3(!%1= ";V,V1\0DIY)J%P\!0\"7:2P^9Y58GI%JLR^EN(^$$* W_,$WQ>L,?*]B6%P\!3Y!>.SMKO81M,6M, M\&/MNSUD=YIXV9%2D1FZC$G(9-ARC-VD@Y18GI%J@#I)=JS7C@(!49J3;[MF_[MA\? MN(^$$; AQE,XAT,%B8,E!Q$!4<@XS\, &V(\A7,X5) X6 (B1DXHQJ*:%P\! M19"TZF;U.WL&320&SG36>;U-2A2Z ^^9"WV(=@O54 !\V\*8>SH'%P\!09# M('?"V$3 !7H^GZR&HIQ2 Q^ZC(U*=HL"31 $*,68B_R9[F^X09# ('?"V$3 M7S?)BVQY=4:P(!<&C4:DD !X*%"NP&R ==R)HJ9/;) M(-\&HL&54X3 MH8M8%O7##GE8DUQ,C$E'0U!J5BZUXP2C#P4!^ZMY__-C>-:7O73)F$=J]Y=L MH0O%CZF_O+G)Y[-D'53E]N89>*Q*C@(!NCI!?I2MZF8O3, $+=!]+3 $B7,E M"=("&V(C%U,[6;._#P4!>!R9 5[[M?_+$G:E#O XD8,@E',V2;/@(E:=-! N M(/(XD8,@E',V2<,J((("+-8"CQ,Y"$(Y5'#Q$* ;#WW%**1"VG76>4W?(((" M5O($4CTC5]("CQ,Y"$(YI\*8%P\!NO'05WS6>;U-(&]G>+:_/1Y&6F6W1NX$ MD",YE$,%+6#\9=(@M'KQ$* ;#WW_@*I1S639GPP>*K0;(!MP+>?$U08'H=L& M8>091@8_F.IR_UW# 83=\TW)O&CD3@ YDD,Y5'!$V-(A =35%P\!NO'05SR> MVW36>;U-$+S;ZAZZ9YW7]%W[M5_[0(C[2 @!FL,Y-',0$1"%HF,?F6,CG$,S M((("3/ $01 H*WCQ$* ; )=2F._ /P;E(&]GK/[?-1RZLZ:*((("3/ $04 $ M+? CI;(YV[*"%P\!N@%P*87Y#OQC4 [R=L;J_UW#H3MKO41;7W3L3&IY3GQ" M*228,W56B>49J6:W*! TS;<0&@.Y+7 N*WCQ$/ $Z75 >)8=SC%.Y>09L]9+ M4'<^NZWNQ@0_?&>H$'!72GQ 3;1X5KYF7J6##DIW85N@J^$9LZ:*((("0=-\ M"Z$QD-L"!&($%P\!0\"7K'H^**1"VI4=SC%.Y>09LZ:*(&+D6. I%P\!ABW2 M(&]G!=A-TC953AR:8"E3XBJA*37P.FNFEDT3H0MF'4%H]BDA*=U#*445K;G;ZLZN+M0&HSU@ MC@(!7U0&$A)-5><$,L=W).$;$@IKTH;ZYZE$! MRDH$>C@(!\%,7,EF2L08^ M?39PE'33XBJA[(I WC/+_>$&[R9F7-L=XL2N2I9" M@NEN\%9E-F1D<-P=XM3YC@(!;O!N8L:UW3%SO'$&ZZIN;O!N8L:UOB&A='<& MF!FZU%YMWL,5;O!N8L:U38'GI?:(L.G$$P*"<&"W** XOWWQ$* ;#PW K3UE MV]-G> =P+^"A+S"C?3I:<##[MB^EN(^$$3 %64 Z1>(YO7(0$1"%J/,\## % M64 Z1>(YO0(B*% "]D(UI\5QGOLH*% "0T $5'-:'.>YCX(")<#7+6 O4E!^ MI\5QI^JYCX(")<#7+3 $1" %Y7=:''>JGOLH*% "ST(%3-(" C(T1[)N&N&Y MCX(")? L5, D+7 E!>(;3>8&GOLH*% "ST(%3))&OUU^OM%D^,\^%^\?Y2E, MK;2Q6)Q K X_6_7!'!=SU8%6XQNZ/E87K"VSK!5P+7<")2!)6;&3:+6@ 6<& M='BIW]T?R2:56$P36I<^8S!5A:1IZ:7R'*?.?WJ_L0H)_J%?N,%H3_0_ZQ-& M!J=V"21 \/-I6/P]>+:"6)6VK+H:E=X?XW\^]DD]7Z31W/A/WBA#EOVLN103 M>]\?OB&A%EQ'9 \"*O!H>: "6'P_,%$7F=D&,F>"F^;%[=B7H3N8PM1*&_NC M[YZ."01H9BD2?UMFK)2V#P4!UV%N3Y1.S66TW;@;VG6<^KBS]KE2C@(!:QS% MK'U"*228ZP9IR'%-H&;[MF_[4HK[2.@ J],ZKW,ELM,AM3-]D. 48@[SP,! MJ],ZKW,ELM,AM<,EAFO&-LBU!?A,K JXY_R>/E7I_=&-N_&-&YN[3T$!0\"7 M$7AVW;@;W6/LI^6^"TIJ59:_3T$!I\5QE03NV4-V#MA*EDWM)T0&59:_3T$! MI\5QE<3JB/;DV#W?E#Q-%%!68R>9K'13&]N:W;@;W6/LOB&A%FPD*/$4%&"B MN%IFXV,&O.$9,%!)4)4'(M&/.E>3'G3!3T$!)HJK938^9L ;GA$#E11UK639 MT5_&*/$4%&"BN%IFXV,&O.$9,L!-GVQ#T?]$^?L4%,!*-V79%;R@)HJ9)12M M9L ;EK=+NTPACD(!X'L^];A;94^'ICSEX)X]9&>H%- 4(M&/H#9-%,#5\IW7 M,MF:W;@;W6/L\,NUOB&A*.DH%% $&+YN$NKB 83=\^T91@8_97P^)HJKW_,4 M%# ^9L ;G@$#W/3)$#P'>1!F\=2V979VI:U*CD(!R3;W\%/&YS,'>1!F\332 MYUW(938^9L ;GA$#AD/"]TCD(!)HJ9K5E(QTD')Z"SC><<:%;5(XV2 MMF_[!P\:"%A30TA%344N15A% %U>1P$ JQ)Z/TKC6@H" Q-M&@!8"# L@2 M!%P)\.]?FP_F $ Z($+B@ ]H&0HZ8"1@ 8(0VP9G&;Q0(?%WPL]C'-@$H MPKP$D&4FC9D29K(3 #,<3P#/?O[ZB>MGJI^=?D;Z2>CGG)]B?E+YN>&G@9_D M L"TIA5H5V!=:74]U351USY=X73]TK5(5QI=473MT-4CS$P 8"+*"V (WQM\ M3_#5P%>? $H;Y!W>H&ZQN,7:%DM;K&RQL,6Z%LM:K&JQJ,6:%DM:K&BQH,5Z M%LM9K&9Q5,1:%DM9K&2QD,4T%L-8S&(QBL4D%H-8S&$QAL44%D-8S& Q@L4$ M%@-8S"\ 8GS6-]#+#B\[N^SHLF=%#"X[M^S8LE/+#BT[L^S(LA/+#A8QK^RX MLJ/*#BH[INR0@(08(MD!DAT>V:F%&!K9@9$=%ME!D1T2V0&1'0[9P9#= @0L M \ Z W@H1X@ ,$!B.@)XR$F* "S"(A0L]L"B"BPZ8A @=RHEH=)W.C"C71Y MV X 'OI") "S'"G*D9<171S)Q)$<'#D D(>X.$O6L;491-=#M E+@9X M2$>9 (R!YA-HYH"F"6A*@.8N!7@X1)T 3-,A )3L":^P9QI[9+.#A,H8" M@$>B9B1*A@(>6@$I -,&D\"'E:":8N;VK&I&IL^L6D2F]*P*0:;&K#I/%@" M8$ZKW+2Z2ZMZM%I&JR*T>D&K$CS@X3D.>$A-L 0RPGQ#I"[ [$EM. A\H\ M"P OTJ8A[172(D"!A^M,X"$XW@+ 3+C"A M+N#"$*T*X%X3+0+@ A%N.!!Y^ M0R\ RMP+R[V/W$O(O6' MP3, 2?S\P\\T_(S"SPW\?,#/\E3@(39. Q!,U*Y$'4G4AD0M1]1H1&U%U-1L M"X Q8O,B-BQB:R+V'F*_(3858CLA=@YB?R V+1MX:$K>-/'M ]^Y:."A&H(# M $;A1!2>0^$*9.!A/QAXN$OD2%*."N6<4!X(Y6U0'@;E3U#. >7J?."A-Z8# M8$WJQJ2^2^H!IFY(ZF"DKDT''C:#.P"?[#[)[C;LCL'N NSN <>AC*"AYDL M#X 7SN?@_ O.-R."AX)YY]P_@?G2W!^+B!X M&$O\ 1!?P[TLT!_,"=X^$G_ $ " (UA @^1HH N ("F8! $B"P&27PT!,B M"( B4+ '%*0 !=E! @^)HX.J Z$D0*@($$Y@!1YZAPH\5(T5 B 7+G2%"S7A M0D*X< TN-((+>>!"$[BP'BGPT#."" !!$!$/1&P#$7M 1 L0\14H2%X4 9") M*=9ABF&8XA6FV(,IRF"*"ICB)U[@H3&X@$=G!$ -THB"-"8@C?%HP:_D"(!N MT-$9=-0%'2M!1SO0D0-T[,,,!C=( !BAD/20@8?,H4@ -*.1NF@D/V+@H710 M$@"@N*0D+CF&2T+ADARX9 (N60T8> @/I@1 &5)YA%32()4:2.4[!C D2# ME@1@!"ZA@,M$"*"6L:GE;VHIB0#4<@S&), 0DEF"9&X@F>B@% $ (G(8!:AF%<1+@!>:44RUA48!:FZ@GLY80"V!H8!:XJ*@!' %0C>!4"X@- 8(-0!"MY& =5:4 (6X MJ!8NB@H$U!("#Z@ELFH)@P;4<@80J.4&4DH -C!@02_= !EB"H:8ULD&M:% K&=0*!K5R0:U84"L5U H% MM3)!K4A0*Q'4"@2U\D"M.% K#=0* [6R0*TH4"L)U H"M7) K1A0*P74"@&U M,D"M"% K =0* +7R0P'70:]VU L/];)#O>A0+SG4"P[UD&A7DZH%Q/JI81Z Z1>1J@7 M$>HEA'H!H5X^J!N&@7C:H%PWJ?11BP*!>AR(&"^JE@GJAH%XFJ!<) MZB6">H&@7AZH%P?JI8%Z8:!>%J@7!>HE@7I!H%X.J!<#ZJ6 >B&@7@:H%P'J M)8!Z :!>?B3@.F?63IKAD69VI!D=:29'FL&19FZD&1MIID::H9%F9J09&6DF M1IJ!D69>I!D7::9%FF&19E:D&15I)D6:09%F3J09$VFF1)H#E&9&I!D1:29$ MF@&19CZD&0]IID.:X9!F-J09#6DF0YK!D&8NI!D+::9"FJ&09B:D&0EI)D*: M@9!F'J09!VDV%6)@D&86I!D%:29!FD&09@ZD&56(H4":(9!F!J09 6DF0)H! MD&9^(. ZY]9.NN&1;G:D&QWI)D>ZP9'N6"$&&^FF1KJAD6YFI!L9Z29&NH&1 M;EZD&Q?IID6Z89%N5J2[HX@A1;I!D6Y.I!L3Z:9$N@.4;D:D&Q'I)D2Z 9%N M/J0;#^FFP[L?@!ARL'P#X'@Y-UZ.C9=3X^70>#DS7HZ,EQ/CYCHN7 MT^+EL'@Y*UZ.BI>3XN6@>#DG7HZ)EU/BY0%Z.2->CHB7$^+E@'@Y'UZ.AY?3 MX>5P>#D;7HZ&EY/AY6!X.1=>CH674^'E4'@Y$UZ.A)<3X>5 >#D/7HZ#E]/@ MY3!X.0M>CH*7D^#E('@Y!UZ.@9=3X.4@10P#7HZ EQ/@Y0!X.3\<EJ8'A:F M9X7I46%Z4I@>%*9'%F(P87I*F#Y IF>$Z1%A>D*8'A"FYX/I\6!Z.I@>#J9G M@^G18'HRF!X,IN>"Z;%@>BJ8'@JF9X+ID6!Z(I@>"*;' Z:' Z9' Z8' Z;' M J:' J9' J8' J;' ::' :9' :8' :;' *:' *9' *8' *;'#PUP'2.H'24( M#R7(#B6(#B5(#B4(#B7(#26(#25(#24(#27(#"6(#"5(#"4(#"5(+8B!"R5( M"R4("R7("B6("B5("B4("B7("26("25("248("7(""6(""5(""4(""7(!R6( M!R5(!R4(!R7(!B6(!B5(!B4(!B7(!26(!25(!24(!27(!"6(!"5(!"4(!"7( M R6( R5( R584HC! B6( B5( B4( B7( 26( 25( 24( 27( "6( "5( "4( M "7(#S&%#S%%#S$%#S'%#C&%#C%%#C$%#C'%#3&%#3%%#3$%#3'%##&%##%% M##$%##'%"S&%"S%%"S$%"S'%"C&%"C%%"C$%"C'%"3&%"3%%"3$5(#'%"#&% M"#%%"#$%"#'%!S&%!S%%!S$%!S&E#@/@ 7P">M8 )0 .Q(#QY8 -U0C\$P M %Y0 *6@CP6P"?ZX!_XH$_N(!?ZH OX84ONX#P*PC]_0D'4"D94 D7< D4X MD34 D1< D?D0 /NX#1Y9 +T0DI\0DI40DGL0DB00D@00DO#P/ 40$?OH##!) M## )$_LX!S 9!3#I S I S") C") 3!9!P>PCUEPE 70 TH9 DI9 $J9#@:P MC\TPE04P"U:I"E;)!U:I!59I!P6PCUH0E@7@ V0I F2) &3Y#P2PC]'0E@7P M"G!9#@NPC\I0EP6@"GBI"'BI!GBI!'AI W@I GCI '@I#PJPC]*0F 4@"XQI M"(PI!XSI!8RI!(QI XP)$(SI!8RI!(QI R(4>"G@0& !?0D&FDM80!I#7PQ5 M,;3$4!!#-PQ_,&0R@(.!'!T-E!/@41E) \!.;CI)#8#'9BX-L(J)*2:+F!5B M#CO@D9P!CY5^&J@CM(%05P4\ DIJP I3800\8HIJ0,<"C]X4>.RC]6?7:@D\ M4@AK@!\"C[7.&NBD%HQ:"FKG/? (;JZ!378IV>7EP..=O@;@ ,;4P..4PD,9 M>(2AV("J"1[U0#:P1()'#Q$\JKG@40QG _,L>(0FVD"#TOXJ>'2GVD"ZUM-: M*VJ-I762UC]:0Z'@\1 &CWE^&S@CW(0 4@<*'#_P+@!R9\X/M(I^*7J>Z&RB M;XD.)#HG ,@5@3\ 9SRO <8.F$)_ !/[$^PCL!_ OI* ]%+N'Z 5(+V3_@=T MEYXT *3W2($'>'- >M L>$ 9#E[AH#(&I+=+A0>(@B$E&": X3X%I'=-B <0 M0^(J)#Y"(AHD:D&B$23.0.(')/I#0'K;W'A ,SH:H2,..M*R0'J,#'F 'T9. M8&0!1@:B0'IR/'E %%(*(64\":271Y8'@,'E%%SZP"4-7); )0)MZL M>4 8;D[AI@(0:/E >EG<>0 !>O;A0'I>_'E $H*VTD!ZF1QZ0"**EJ'H%HJ& MH.@^#*2W2J4'3(*I'YA2@>D0F+: Z0>80C%!>C&<>H $JB*@ZA42I!=$K =D M$T%ZO=QZ0"BZ7J*K&KI2H6L+NC:@:SYU'E!.L@804$ "Z@SP+#+2)M!(M7%4 M6T6U(#T+0;7K"/#L,^(FX$BY$I2K1@#/PL!N A2\6P< SUI!;P) W"O"O?,D MEP J_M+A+PK^6N"O/ 8\"T[""4 " ,-I,(P%PT

A-R/LPF(P_(Q++/" :."^#X( 8HC4;I"3B!.@RH&Z4T/04H M+4[L"41#>R:TJZAT'K2303L1M&- N\>O$Y"U\6PCCPKR7B#/!/(I(,_ DK/ MHX#2X5R?0#+:%Z0T -JODX#2V8S_N/FWF&^*^9B8OXCY@)A/A?E&F-^#^2V8 M[X'Y!IAO#@)*>P8 $["+ :9B@)08X!\&J(8!&F& .QC@"@;(@0$F8(#.8(#2 M<*'!!$2B@VSHH!@Z*(4.!J&#(^A@ CIXC0#$00''<*$"&B%#*L@0 #*T!P!> M.),7KF&'"G@!$'/RPG(,X!,*N,81%9",)>YBB:U8XB>6&(DE#F*)=5CB&9:8 MA24N88D]6.(+EAB")4Y@B058XCT$@,1TL%$!VWAC,][XBS?&XHVC>*-]D'B( M-^;AC6MX8WZ0R(,W[B, 2"P'(I.XR# L<@F+S!L2Z0$ ))JCD@K R;/@,DH M8#(%F-P)$M]P "1FH90*B $J$89$;A@ B;1XI0),(4L2R-(!LC1' 9!XBETJ M(!*^3(,OM^#+ 2B2!/!=B@GLMP !)'H4\%9**? MDN@G(OH9B'[^!9S]7$<#D-B-A2I #@Y5@D.!X- <./0%#D6!0SW@4 HXU!<, M0"(J0JH 39#4'Q- HC52J@!DL/0)+,T!2U? TDQ( (F#N*D"ZJ#3840 B6[X MJ0)D(%0."-4!0AT%!)!8B:4J0 5._8!3 X !)*KC DBD!E85P(JM>F*K,]AJ M";9Z"PL@T11F58##TBJ(M%X@K0E(ZR J@,0VT%4!1;CK#>[:"PKPTJ_^!"P% M (N,#2#Q$8950!P2NX7$-B&Q?= $N<@6058+?LZ !#E0M#YN:"N3]@[CTX@,1X4%L^X;J[& $2JR!> M!2BAO#TH;PG*>X'R1D($IH2O F8@WP[(]P'R[4,(D&B#_2H !/[%!PBL.F % M^*' =RAP% JLA (#H<#>.,%A):R 0%!X A0N (4=9@(D=J'#"F@ B'U1 B3" MHL0*$ **:8#B09!@E"\>:HR7L0(DUJ+&"K "CH& XW"H (G+^+$"^"!D,PBY M'"E XC.2K X,%D+3-X'"A(Y906@HLJ2J'(8JNR"*MOB!4@$!9@S.68HC-D( M8_[!F&LP9A>,F01C]H<+D(B..2L@$7:>@YTI8&=_M ")G_CSG06M D%30-"U M8 &@%:T (#!:!8Q&!PR0N(U)*^ 7EH:%I=M@Z058^AX#<$4#GA'J!G2BU/40 M@*BCH>H&-*+581.U#%H=@E9;H-6P"("H4:'K!CBBUW;H=1-Z'0X B/H7QFX M+9+MB60[+-DC2#8R#B#J3U"[ 8*X]ABN+2%1_^#:%[AV J[M"0.(FA'F;H , MTJV =#.C *(F ;P;0(%Y:X, HJX&OAL0B'W_8-^L6("HFR#P!M2@X.]0@*C1 MH? &@*/AT6@X*AI.B(:_4-1F:+A#1#V+!(B:$AYOP!I"WH20NR#D(0AY D*^ M#P2(VF$N;\ "15V'F%;T :P@XI4:># :M&>P.&H78O MJ)U4HD: VILQ 5%OHNX-4 3>Z8#W-.!]"WBGA@1$W8C!-^ .AJ^,J#M@> 8 M7AT1$/4W(M^ :%!^!Y0WEJCA 0%1:Z/SHP9],$ / ]!' /0& +TV+B!J9K"^ M 59XO0E>#X'7%^#U][" J.&@^P:(H??MJ("HMR'\!A2C^+HH/BN*7X+B7Z#X MHJ# QZ7?@$%0OPW4%P/UJ4!].6Q U&'X?@.6('X@B%\&XE^%!FB^_@8PH?TV M:/\*VM^!]J,A Z+6 OX=C@%1WZ+_#1 * &@) (@( (@/'S!\"6A\"W@+"]@! M"W@ "W@.'N!Y%=@ O7"!H'"!CG"!<'"!8G"!Z= !PT>"#< &)J@%)H@$)F@# M)K@!)K@*'"!JE3"##3 &-E@%-M@#-B@#-L@!-I@9HM81HL8/(R!J[G"$#4!> MHG8$2L@-(B!JSA"%#? %5%@%5%@$5/@"5!@"5 @*(2!J@Q"&#= &9/@%9,@, M("!JK[" );K@(;N@+)R!JKE"'#8 )>*@(>,@ > @/)B!JQ1"(#6 *A,AA MHF8'A(@&A+@+)2!JI?"(#; #DE@"DF@,)"!JL)")#; (G&@(G)@'G$@'G/@$ MG(@#G$@.*R!JUK"*(N>*7>"*[: "HH8-M-@ #G.+>G"+;'"+ 7"+\Y "-">, M#; "Q%@/*"!JYY",#0 %S*@#S,@"S,@/+R!J[%"-#5 +V*@#V,@"V/@!V'@ MV)@/+B!J>B9J:E".#< "ZF@ Z@@/+2!JXA"/#9 #])@!] @ ] @++"!JHM"/ M#4 # "D/,R!JXU"0#= ,"/D+"$D ,B!J\Q #HK8($MD =5"19U"1_ #2,B1 M_.:1<."17^"13N"1/>"1+."1'."1#."1Y7 #HG8,,-D N3"30C"3D6 #H@8( M.EF&/0D%/2D$/0D--2!JPE"42XB41("4,X"4(H"4$8"4 ("4\$ #H@8.5MD MT)"5P)"5KI"5A)"5;I"58)"5J; #=H>6#1 ":@D!:ID/.H"$<=D U#"7QC"7 M1S"7/#"7(C"7%#"7HI #HN8(@MD +U"8&5"8#E"8 %"8>8 #HK8#D-D 'C"9 M"S"9V> #HD8-FMD Q-"9MM"9IM"9GM"9CM"9>M"9<]"93M"9/]"9,M"9']"9 M"]"9_= #HO8'N&F1NVD%N\D$N]D"NSD"NTD NZD//"!JW9"<#3 -S&D+S,D* MS+D)S"D)S*D(S$D(S(D$S*D#S.D* [ )$> >XMD&X1D!4W">0G">+'">&W"> M!'">5R.>XR XED-]AD!LR:>))"?A! XND& !H!8#"@PP XMD*"/I3"UH M""">^7 XMD.$AH!X5"AU5"AR5"AO5"AL5"AI5"AF5"AC5"A?U"A:5"A6U"A M1%"A-%"A+5"AQ' 7D4>CI".>U% XBD%1!H!/'"D M$7"D["*>^D XBD/4!H! &>^D @ ALBJ!&8(0?!E\81&$0A,%O"P8JBQC! M%D51%.TI&#@LP4!( #Q&6"(2'(*!,4Z.?#"P!LL(#EX*>&G/P4!U-B-XRRDM MI[&([B*4@#H*8 ^(%B,U!&%AMI_%@;.BQUA M'&U3M'G0=D%[386!77Y'L((IS*0ZD^(CB_S:PU3#0 M$_<([S)P%!_A%OE5Y#^1GT3>#?DPY!%A&,CDPT ?]B/ R%\@OS8/ ^T"X' # M@#3!.P4", $W"4Y038.^- A*@T@T&$2#,C2X0H,<-%A!@PXT:$"# 328C@ & M%H.B@K6L.$$J+H;AHA4N)N&B!RXJX&(] 1B(3H\*>@/D!+D,67J[A91A>1N&E$E["X"4&7I)S@(&H MO*G@(G).\$2=/]1)09WP&&"@+GXJ"$J@$YA3@('A'*I@-HI.\$NCI32*2:-> M-'I$HR8T^D"C\!!@H#&>*FA*J!,\0NH:I))!JA"DKD J!:2"HH"!?LRJ(!2V M3F!# @:"P*N"5B!@( ?"*E@ 3U0T,X R:+#+ 7C/!O,LZ\\>\FS6SS;P[,9 M)GO"L[0(D"R,R:XA+@5(G%O!N3\F6TL R2("+P5MS+O%O$;,.\.\(=#U%USETO4+7@SB0[# - M3-PV!8>\G<;;2[S=PML/O!T/ \E2PS<%Q?R-B *!BX=@0#H XBKNC.#Z* M&S% X0L$@,T%JP#0S@44 (#/!5D P,\%>@ 0 ;T3 [ $@44GHT(E&R@PPBQ MTT#[!B[VV , !JT(CT$IQD, P 48= ) "!@< X +& @0 /41 M7(_!(@!0@0$# (S@018"O('!% .8+TGZ&! D>(/"^!^##WP0 J6 ! "N M8' & ++ #( B $N , 7&&@' (C!I@ PL 4.Q( L2! [5U!P ZJXH"DN*(H+ M>N*"R ,'!DHG0BZ4('98..$&J*#"&0 'AB8A0$*9X #%.X#-@2 /P1@#PR8 MJX=$X"$&8A& '@ZAB-]#(CL T,/B]; '3,1 YWHH@@"<( ,-L&(&Z & *P*C MBQG(W!6K $81 ( '&:B# 'R0 2*R\1,!8.,:XI@!'- 1&P!@XP8 L(8,N(&/ M&> #(%,!R&H \E]]W$ ^IBO/M)AD1E 4R$R ($ *"(#2[PD,0!PR2UP,@/] M"( G,G .46: %Z:4URCE 8!1*J*5&= !+&T @&%D !X 0$8&N)'+#&BBEX+4 MI3 P(T,[(*8@42F&)#) V2^ #IR$ 'H)D!$P" '1FH 0#&0@" M .J1 4F,,P.W.*<' " #0 A 300#< $,\;T%,#* " !C0 !7UJP ( ^( & M5A ^#62N!AHH P 0.H6%:H"6""4! (" S^YI0!XY5)[XE >_SL&/3?"S P"L MH(%F * +&I H&S2@ "L5(UNT$ 5!!#33@0@IGZX*3]UR@&=&C*F;P! 3$,@ M5 T<0P";T, Y!I#4?@@ 'AI0(U1U\%0-"*"J\0@ 5(L$55)H50-7^"H2OHJ" MKQK@J^)XH0:\"=4)J%4% !#!!AX0UPTHM 4;$"=>IXG7& 2 !ANX!@ VR7 MFF&P&] F8!\FA0W0 "-C09D-\"$! %U"PP8,J-EU:C8& (##!M@DVB/> M80-5.FU93WO6TZX# *?M!6PW,(K9OO*T2Y@M#F9;@=EB21:ZB)T+$F&!8P2 M%C!H1@@6X0+"+<(#+ " ([0QBCX @!$& %,B/+"P1+@@$@ XA@$" 8!__.-' M#O1!'0"PB&,L ANY^,/@P1!,@(,"U,$:@&@&(.Z1C40X8+VY(-PTQC&(84!@$.. MQW;S<%UIK$ =B_"!%TH0B'^PTF @#;;00 0@&F%6##$<"@A1*NH-PO3.,<^G"$-!9QCGW, !@N<(0! MC/L+#:0@%XSHP0J>,0]5. V]$"!)O31.@!H A\S! M - ,#1!W$%!V0)?N M; %\H. ?-IA#>6T0ATD'%=)MF+28- $^+4%!$ZV#89H]8%Q-R"$ EV6T/5"P M"';0@@F*, (!E)L+!VQ)%\],QR$ X %<+%2YV_4D=KL %P0H ; ]L 7KFL M,N&B ,@.P7;'P&R%XL( T=[N_[";AF(#H 2,4,9T=5&" "CW \/H];>+80%/ MGKO7!"@!NY?][F?+VP+4KK'6T0.+ V = M.&CYR\=QC*)?-AM"ST7GQ#'THI?@!UK[P0!\#8 Z7*#J_C!OT/VA]<7YXQY% M_P4NZC!V5"^B'%T8!I9@ 49 ,/EL "!.4!A#A!@H1D">,85#*")3_09%S2H M02X6 (!?!%&YP^V "QA1! $,XA@$ ((XXC'W:&=^\YT_P!<&X0/R_J,.!D#' M _XQ"O)Z@./L\#@"H0-7Q<8<./#_[D"]!+EI:#"OP0[FBWP "+D V , [ C[ QT, " $ XX,'\ 0 <= M@ H%0 <%@ YP$ #K0 &H( !PB [[LPXR@ H80 <' 7HL"18\%HE $5T( )2 M, -CA@U"$ WK, ?[0%PV*%ZV4$6\Y@LV: 6:,$/#,PC$0 !:L 4'D 5>@ 4? MX _LB7/,'\#T =R@ Y+M C!0 +X$ CY8#IT4 :X" !O^ 6XB (#0 =9T / M$ !T0 4]0 [(^ 3[MX9*T -L0@=%L'\$0 = ((W7N ,] UK: ,]@$=T$ ,] MD T&0 +2>(XBL']XV '2B(<80 Q M4$L26 [-D ,^@ HBT P]$ HH60( < 2$! 1T8 "$A(P!, R$5 1TT Q600/B 6*0 "* M0 8"P ! ( +@ CD\ >(P)<22 *'UP/#((9D:(;) (7-@ V&D X>1@$C@ Z[ M<%XCP&O%<(^:, &W\P'H0%#H@ K_, RT6 +X\ \E WP4DF/- SH< RG*8$G MF9(KB9)I@Y(_(($N@))G*8$TP(#BD AZR9>+@ SV$ TBD Y.^ ,J4 Z%J8 U M0 **4 PJ0 YTJ731AEV8( +;90DBP @.0 CH O"( )*5P+*A0_+X 'L)I[K MV9X7B'L>QP 2Z ?TH))$1P\-(#R)8 3V((%N,* [X ?O-X'TL A6H ]$AP]W MUP7+@"4(X */8 #R4 6:@#TH*&,X 'V4 #\H&9@X@N R0 XFP I P C% M< C6, F+8 /K-0C&( !% M)P"X@&H#, P#$ PED':+P \K@ ]R 9DQ@C X'N, U8%@5), ^DX'>JX C= M< CR< C9L BH"0U#@ X/ ME6F,8 %!=1B)(%*,0".#4 P$8 .L(*G@H ]TT YG%J!09@0"X +_X (9"J0 M, ,%!FDLI@DVU$.@* #O=0"C4&G$)6D>,%T+( Q(YZJP>F;Q]0^)\ .,8(4F M^& 49F'QD @'D A6>($+D Q]T #W, WW$ TE%@"#(%GKT (@$:5S0 "!,$P0 MH CI\&/24 X"4 ^*@ [3X"S0<)TE0%?+L+!]P /&[$36[%/1PTK, P;&PCJ M ?FP\B>PXRL TK, TGF[(#L++%T+( L Q1<+(_AK1*JPCC, WK(*O+H C< MP+0H]@ [$ UJM /#L Q68 F24 AD* #W, Z1@+:$>@_F, #(8 EK.P#1X 7+ MH L\@ +K, "Z$ 0HD NM Q(&AW"$%@*Y< *W9@0H8'#*A:^7]:WZ\&C-E0+? M:@"6ZP(*D (SD SKT YN@X($&)/-P"Y,#E58 57T&J+D ]$5X1AL0A>X "+ MX 00L+!U@ +( UTD 8+L V[> _&578[P<=@_REPW/>P\$L CID L@ !70*XSL)S@$ W2$ W6$ W7L /]( <+< <$ ML /S( <%L +SL ']('KGL 7W, P 0$" - QL,C8HFO1UMT;1D#@@7O:[F$; MI W %R]=E"$ <&_>O6,!Z0A8)&R&M'7L $ B4&41NT'L7%CQ<,6 A0.+C#A8 M9 5"+ +3T T0ELB(/ _%["A(9(<>(R_V< 5(T *G'X8 %0=>!#%0^-O,AS MY.&M+KJX "RQ\<^&"P"4;< X(*1A50(7"0R<0K!5Q>./H=>1!J!C4<&-K\V MN#+!R^+RG59UO(E.P(><&$"H'MC#PJ#B$'' M]8JZIFD"( &8D)W F!U%N!"-*$Z "\%B!")OLN[$0!Q%)1/9,5?47[$>,&/ M"<1\08 )BUPA (('[& !&3G48< .!HB1 QT,!#A@@0<2\\$Z!LRPC2/#B'A6 M(@)&IT$*NO$6Q@;EG4?''-$A8Q]^^FG'GW]& "@@@08BJ""##D(H(8468J@A MD!U^&.*()6YSHH#'&$ /#@ 4*4\6 (@(HDF&L /#HEXH \.C!B #YD>V(,# M,1Y8D$.:[+"I#@XY\;. $?[0X< _=O@#*#^:Y !P:4ITD1 U0"0'++03* M)BP$X.@RRT0WC7>S!$#* >5)19V*+&HB! O9F< B!R1BP96C<+D -'20H8D7!%RWB 5UAG)G ?C\0Z$$.6BTL'68>=7'0?E+UU M.>KBP"X.[B+[<,04) W2OEM4R-&8**;#@"@034$C$Q#8F*83,G/.A)H^$^/)BAR@.::[#/ M=?(M"<@/ -3QK*ZA4 + @98(A#D-@A?F>^:/!' =8K&(#@%,P"CV^&)R[=K M]%! @;UN"@ PP,GE&"P-#J- @X/%.&R<@QT9D&SRQ..'8K[./"\8\SH'@"PR M080'0)VWX-*$-;P'/CB9CV<'2L01!+"][6FB>]]+C@%W]C($N.P((0+&**A! M/A>D !<2\,X37+",7!5NA"6TVS_^ 07+:>(5 4AA.1R8AP[(D'XOL]\!=#8( M YA,8 Q:3G,:*#WN$3 YXB.?^="G/O:YCV;P.]_\/-"R'+KL /C3'Z+LYK\6 MVH$"@)* (]8C@DB\((,+*(#(5A #QRP@A?,X 8[F(+'10Z 2M%$'Q(@0URL MT(N0LX,#-+&*$^I!F0"28$!GW'"LL0BDY,<">$%"' :1C M$H^R @(R60+_!4(<65I87W Q #@+T &:-WK>N _.GC2#0" )9 $8+H\[:E/ M2.")/_)42@"<,I4,*P K7;G#'[D.$ST(2!U,8 47FD( )535>>K@AFIVK5@O M&$ VG;;-+7C3:[4J @K&:8!U*"&3FZ3##'@R2B,8H)C'_%TRE_E*+\3RF=', M703.62PFJ("=ZW@ 0?\&@X,"0%7(T55S8$( 2RI%EP5:$(<"QB'3,<(#W,!! ME;2! Q<$8!U&@!-)3?"/.RSH'S< E*#L0*@# )&L@. K9)@H4:0*4[:^E/ M/;#2EA) $R1(P3@5(*IU8,< )$4 4!ED@@4LL ZMB%Y$)^F_PT]@:M:X"T$0$""!#KL*$(/;<9"?3D8Y0 MUO.>GD5F:)FI2X#6TI/$ 3#< Q.[3@B0387G2:L5I-Z"M'!)""$;^G4QSV M;!T?"QFBMB?8.\RV5FPL[R()] &>65"!!+%"M(P UOEZ"$BQA"-^V3O?EK[T M!@\DH'RKV+/(T<_ =VWO@0SL '1$X!_9T<\C"9 .-P3@LIG=K"@[:\S/JE*9 MHFTF::$9D@F@%A?4Z&YK'TJ,>BI@3PP8KC%"N5\%X-/$^TQQ@!0@2V@^-QVA MR*47B+R(!4:6 ,.-A)*9?(4#-5D /U8NBEVY@"'OLLBTS)T9HG..[GZW/%[. MJ EV4.4Z,&'-5TWIDK]I%RX"LE."V#.'UY$IR:BP()Q[I0O8 P4]G#1/=U0HP4(/>TW MOX8+ W@G%JBFL0'NN.I:-92=E06Q9CEKSRR#=LNC!7,M*_!B=\AX7N5(ARF4 M',LK/YD./=!E@JR\0%^?F)]=CJV: 2I-51=:TVJ[O4 M@8H^9!Z%WMM=64$3VW#H(N!A1T$26H]\I#$"_,C"O@^2TK*>;G5!@%U$VI#& M!#"O#M&K10/<708P!X!\/@X%1_X0PC#-ND,3&P$1DE#S1,#(KF B 2N T/0E ME _VDG=ZHL/C&#W*$N[UD:4O16DK]$"1/'#O#_^E@Q>/,H([]@0/A\,C)^Y0 M^G+[Z0XPMQA0?+>#.Z+3![4[2J?;PSZ@W)%@\M:8/_@HBCURHH\]\CDA*'RB&RB$>@:' M< JG:V' :\A58EK&3RHF;+GS ^M&;0+ '_!0%,O',"K $\^G? Z""-5"(89P M(8IC!2GH#@X"!A?B2>3@#Q3B!3>8#MLP3$;'29ZD!A_V.%G!V=8?@2@4^BG?NSG?O!G!?)G!/3G!?8G8!B4?_NGA_W79_^70(T$%07( MA[A 0E(='RR.IA&>[%'!!&(61,8A'10@48(AAK87$Y7!QX86],&A2)(@JIT M@C((?5)X) ;P@G00@S-8@SV8@SO8@S\(8L/%"$68=!&7A!NXA.EP!DXHBNQV M9;)H2^DP!55H #R(C$HPC';V!0=GB?Z$BYY42A;(B1,W=D<& - H)"#('\%G M% LS7.@02O20$_*PB@E@A<.U*3R1CD8ABW70CLP8(9[D"\DG#WM"#PXGC_*@ MC4PG#]97AH!"#X!R%+C "VL(?D5TD D)AW*(AW3(%78X 8&XAWUX!??UA_J' MA_SG1COS?V-EB#HT@(FH#[A0 8U(! L(B0Y8>Y2H;=(H@?ZT#@T0'=W0D-JA  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Aug 89 22:52:47 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa23747; 30 Aug 89 22:47 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 30 Aug 89 17:24:20 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: 30 Aug 89 03:04:52 GMT From: jdm Organization: Hodge Computer Research Corporation Subject: Xschsrc.arc (Part 2 of 3) Message-Id: <21726@hodge.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu M]0UQY=%K?9C M[&4!7WOBU_L2-[WV]5A^V_A&QYYVHAJ"90K.>M%=K="0>"A56VA4/. M.E5= 9.&""/4H11[5"@RJ+%5;.080>"#,TY!4TU( M@A- 8 (3' H$/+ QCH. A4LFX,!12BN$3>R&!3N6NG$5"PCQA0)-.:$*3>BG M?;+ZA7>=T0T&CBAJ55L3UCIX;064<&R_HQ;:FJ& %,2KAMXE-D#E]LUV^; X M1>Q;-.>Y#2<^(@B,P(0G.&S%0%WLBZ7;8BBK,(2$CB>6M7P9+N-9PE\.DU#0$-AW083%0EWTH*9; MF^I*>0PA' (2;$=I-G 9(I#QE3+1H.FQLI?!K;6#:/@3'8ZZM=3)!BG,3(V> MDJHG0*HNH"@-LU)82UO[!?UND7]'WB[F#HP;;6\@"N7-_H5"<[_0T%*3PA MQ\4R.*<17F:%'P1.O1HUF^&:;0M+920C3<])P8W;&QX=#4G?JQVNWJN9ZQ== MI4Y_>CP_ MJX,8&+7F"FO1.A6\.(\$+X<7$(3QY>YXX >/@GZSP S 9D%^S%#?6E.GWSNM M' I4@/DFBY"G2^(\5\Y.;UZO/N&=5+KA.8RF#&WH)!JN^ETT!%>M4]^39H##Y,JM^&@?%IR "S!P @ & M!^;7??;'?7$G?&(V=&P ;;O"4"S45BKT44XG(-IT&6G03;DE4A&8-A!8-E"5 M@68E:._B4R@W?-8%@E90!$- !1@T4R+H9$5G?*220W,E@;]&@2,A%=G4$ABH M@2&50[7%7VSE@39H6R%84R1('2:8?KFFU_P,R*X5$W88L/G=R_$4$W7466@@^!$*[XR/M5CA'>0;6-$(B?B M>2CA!GJ(?@KP7!"U:5&2@D># O!$!$7 G[X)F'G@,[!AG:!/[21>&X(AR(U M0Y089PA"AQ_36]PAB2?A$I6('6#(ASPB@B>X@(5(A2 (3\JB8U40!%20!/$$ M@S4%B35X!YZ(@[&G@]O6@]M4AD&H0[UHAYXH%$*"BR-H34DD&J*">FNWGBH=(.TK @E3 C"MP1SL%:F"G%&G0./R22?4%=_D%C:;%BL0W@_+C?K[2 M$!/H%QLHA*Y6:$/ '2GT:R%$>TN($J#GA/,6BE-42T]T15QQ9Q(#8G>223(F M4+F71F9426\$ G%42(7D;\<$$Y0$ C?W%9FT29DC&Y\42J-4 M2FEP2F642F6P2HYE9M?$/[FT2Z[20[_4!L$$& U)3.-D3 NC3,P4DOT43=/$ M,=64D\+X@][4D_CH4$5) "');SNW5 .)AO9T&P$5DC9G24^9D *!9 M5E7IU ME<.GE,4G/X8$,QP)$@T!*W(@*Q,!&;:B&$K!2W<1!F0@%1U!;JA$.!/12"\! M('-!)B"A'4^PCR&SD8G4D9BG-(9:,Y(9RCG+3L3+BK M4,VB+YXD5>-I@\[B6#CE6.^2!F5I10*!&"!15X'Y8UIS(KUY!VB0!LV' DQ) M8V<$ W#D&E-3CU.),D*8GW?RD6'45'>0+9&50^4)+2A@G.$U7B5Y94SP1B@9 M5@M830=ZGV\($7'80ZSR371EYJE!BS5!#R%18U2_"X*X:8-_28@_9HG5')32 5AQ&8 MCX_)CPSRIAY1>3O'C*AH>=.H@+S1'Z>"=BRP7&%VJ!WRGO&ID&[6D*X&D0\* M92,9=A5IDI:$D5\1EX@TF'G@D1&)J12Y1ISJH4ZJ2>2RDIX$2@/RDAH1D]11 MF,%BDU6$DV:IDR[!D[WD*S\9E"M:+0^5J4NU3"V4J4LI36R#D/)I@3YHIT&9 MIU;I>E'J;UTIA966II.#Z1*AI&VM0(1;'2X9Q C'A'2OQ$WI3. \E8VO3 MD"N0BAIHI':0)$VJD3"S=9,YJE%%2 X;-Q'K4P*:(Q9[I2K922T9JZ0TJP$2 M@32)JRVFJ\^*H$&IG%DD'_YI)LUW)G/C(U?IHCG2K(T&LM^JBE7TK_WA$0FZ M%!>"KQWR4,NEI%RI$XL4KEQ&KC>*II%*.@M9)4&)%2:AGZQ"8+W9HRCPHT7; M33M5I$4QI"V0!D86M1%KD5N;$JR8ECK4@6SIC@EV0+K(81G;F@T!JE=S-"&Q ML5&2&7_!%"!P @0Q)W4R!@)X)Z"JL:)ZB@$ILE;Q48FA0;D9 MH0KLKKM*LWC[P^W2L \:HVQU1A?*-)2< @1D0#' B-GRA4T&"0- Q>O[%<,' MQG5;IV6XR0SZ4* \HUY8AIE61;N,3C1JL^>:KC$61A6Z+=!4B;5R5-7N#]V^W=@.X91L]S/,G3B^FMW!C60O6- M/-U#/70 W7(DW2C0W_?M/8I1WBBP/6;PW^23W]R]X-SCB0*> 3.X Z>X/,= M)>DS$1"^WBW4X15.X")>M](=E#U2ML(+M Y"?DHBG"U")$;2STMZO0]ZV4"[ M7$3QX?M=>9A=X9E$XC]>MYQ-."B1PGOCNF/P!1/G%XJA;IVMX6D]!W? ,4K2 MFGK)V'CEM80AW7^1,E=)Y5;^V3E9T)_G*H=-0+VII)Y"0(#X=Z&-(0UQXEY[ M&XI)%X\#8ORBC]Q!X' 6"3'('\N!ZOHJ).-/OTY!U-E&'9@V9A=U$==A@_% M<&5@!T#J1HX%)[IY1H-NXN'=*KI9J<8DO#NP TWZ%;2:!B([ X!3H /G&^0RU (AD,YE>:[1,!<$\@< 2G ^4> M(Q-Q=WE'!.R^JN8. CWWK=XSB^8$K,[P*OI;QN\,)3!$9 !0K_I?<4!A"_Z)7.2OQ. MZ99^1L4>\D]4[%SYZ%^1 !;%'-1\F#>.VKS[.I!?+[_\$EB6O M\BB?22K/E8GN\NN&^X!F7:[^X. MZU7=T^[)_.0N&>!N-^ MIK2.[5NOC=RX[VAO(RO8@AC$]D]4[XE8!'*O]=H>3[5X9;1HBTX \!F?3EM: M\ >?\#,OW4_5\PIO]6& ]5=JX-T^-70N%C="L$BRAB:0X$:KN'62 5[1N MMJ5^2<(N$!@LL.1&L(<9$QA7Z761&0YY]E\41DA_\3*F\@/??;T>?A\/1U,# M*BH5K&AB!CT5%1O''$K/Z- M]-'O2#"/E"V$]#M>V_H-]#U_L:Y\_P&5_Q6_'*[\%:[,^*=O_D]$]51_\QB9 M +OJ_<+4<"E1%N._EO#_\CJ/E"U4__ ?5F :4/FO^#-/]?^?(8R^'*X,(GZA M)*NOUD$Y>"-AHK2> $O/\C*/^@::DXV1(8S>_,:N3R&1&2BQ)11AF]!/ #<_ M\PR)[<=WAL'D;&Q5'3U+Q)OW#\KT4^)?-S&W&"N^:I MXB[3Q&,=-,\KH5_Q%AKKL*YQA<;@6?D,U*MQ7U7 M-M>ZJ5-@A5@8QD_4K?ZVA6_0A5\H]MP:5?W/M>9JS]UJ5,QA!\1LS]UJ5/Q>\YET\Q!@HFR:0LGN59MPCQY_7I*L/:V"UFK'0+S/@+ \X[ MY55>!DI2HG&"2DI]E69;GI%EUCM5GB#PQ [(-6;.$8FYF4 !UZX MR.7YMV)>!G#@A1;-(U5>!DH24H1LGCZTI\8AYF4 !UZXR.496),LGN59Z)+- M*"D&,%X-48;.*.V9UO *>_SCY8QA]E=IMD +H^ [(#5ZHSG:!4IQ%U\&O@/2 MRVK+$$=LI##@O#3.I%\A8[B>I8+/ZSXF^L!^[4]$Y6\R[5FJ53MW[7._]? G M!50 \#*&1?17!C!5X?S.'].F&:#%%?17!C E@YS/^*?/[S6O]->Z5%1:!%:Z MJO]0-=OS5_\U>:I8+/Z^L/ GX@^J3?QP(!'QEAU"C1$+:L M@=]4$<.E$8S,UX=X\/Q..X-Z,) 7B;P3F6,5-&$LUWDL5WY?N MO&EMRQK8UD\B(KW9XDL5XUA]1C%>(Q,1LF=H41H &@A84T9404(N0P!.2P!= M0,GCYPT9]#0 8%B3 H0,7+@P,'"81X01,+8 M24,&1),T8]"$*<,&A) R=/2<3!"$35,I,&7. 2&ES)PR;, MZ6@Q+8@S,+ M@<,F#XH4+/",6'?G*, M4<9_"98Q8'KK675'&O1%R,8=;] W(1UHF!&1@_ 5"!X;;X1!!GTDFAA86A&9 MAQX>*9+QH(@$E>$&&7/4 0=8\%7F1AEW],A&6C\&B5YE!Z9;ZXWIEFM@DA&7 V M^:1Z84 R )INAF$BGQ":*">>= (*)AE^ JH>HG7.B:BB8Y"AIZ%J@K?>=Y#F M.4"C> J:J8F-@BGHH&_^22:=I)HX:9IW1JHII(B:ZB:CI#(::J6+Q@HKH[#J M62NFK!KX%1WK*3ILI(H.Z5NPX(FWXXWT[266'%^A&(9O<(211K(VGL$ABFGU M5889X/IV4$3,UM>9&$S&UYD=]!W61AST73O'&^^]:"^\^JI%KYW"YM$&:Y8M M^.*P\[(MGV/APNF(8=R,<]&5,!WUP')V>[T,,'AB;717O&&L M44;2="S]HATBN>$M&O39L1>Y4P^;+M3*WIQ>V%"G*Y_3K<7E8GJMC5NOUT<3 M)+!OQO:U<=QNU&%5O5&W42X=.J>7=QOLRA$X'AV_(9)<@=.8[;:'/]PQ&X=7 M1%?&AD?+'^45*I7YP7W]?#C4=S6.*QPQCU7'7H='J489&QV.F1EAZ!VU&*_' MGFY%)0-^%^#T&0?X<7#\?GCQ<@ ?=QG_IL<\O\['4<=BZ>H!%DLDO[$61V(= M_N,987!?1NMT'OZTC:;?65I_RJ=7T?JZQPWJ@P35(0;]" 6=WAF11BM7<7Z3 M'YTF9K]XZ8T^P($>'J27H1?M)8#QJ0C3\)"NM;BA0MJCST$NV"\)ZHLP^@O/ M!M-5FLC%(7GT*:'88/2&,VA0#AE9#UWR0R*I0:@,$?E9M#QVHKB1"'S0>M$/ M.Y*L%N+!ABP\0V#$1B,V8$F(S$MA'-@0LBABK"\5[$O5)M:7O%DE!( MQSU^R(]P9!X50?>2/AHRD.E*2FLL1Q_+25*0:T)#&Y\((4V*Q(])R>,B.\G' M.ZI'DY",6R@CPLE3ON23G7N)(F,)$U.N,I5?PM5>3!0M,ERREV+(PPP=B",N MH9"8)%HCSMZ@']S!KGTTNL-+AID>:?[R1=(,)C7Q(,TM_4Y#;?2("^,&G#F0 M)PQKPT.1AO0CF%'R1:@3PR[)\"UXR@$S<*AG+N_$$AM1Z$7]#$SPGA6&@=JH M#A4BT5?^"2&%EJ&!#=5>PV@D,C,4;WMLF1A4+*J]-$R'@Q!:'>],YJ;5":]W M)XN+F#SRPB0QDVO.PX-',0BQ#R$0=H6!@TTQEJ]]"DLH#:V%Z7!#G!+ MC@(F8X;9&24(0TB"$ZCPA"D@X23-08UV<*,;/*"!*..ST<2X=(=G51%P@H6G MQM)@/9+9J UOP,QYU)I7V_!U(,_*U@J?%1@YR&>4]7F#6*(6+]$&E9U0@2B, MWC=9O&)'K]OIJS?O !?Q_'4,(?PK9FH+A]N&L#+\X6-<>HN4H*EU!&-,@QDD MHURW-F$*1*BK:VNSU]P,Q'(XL$$EW:#-H JONQ/+@V\ZBXR5VN DYB MN8'D2)YCF L(>H 3&>P@ !7(-%I,75 P*'P@QF+SQA)UK1%L*0LA7P9B8\(0A$"#4+3;3M;G^;""UPPA.2, 5AD]G,!HK1 MBM92'EISV\M3\#.Z 0R%(DCAU36Z48YV) =[O[D$0V!"$*8PA707X0JO]A&0 MRNUE5$MA",2&-ZSOHJ!M3V4Y8>)(WL+G8@1AF5I/CO*4HQR^I!SYO0RFPY:M M<_!/0R$& +=/#"@N@A)8?-6MQKG&#P2@I.S\T??N>:[Q7.TB"/W,X-E0ASYT M=%.7P-O@?GJ\2R0CGOL\U1C7^L8;M'-[?UP@A^%09 ^<=(0KG.&[GH(3'AYQ M917)ZPE?>,.#X(0I7,'?Q4:2F)94<*0?_ E"4$(1AO!K=L\=XO >0)2F= >O M P3B3X0H*3*$2HLA3(),F2*"10)( ]Z(&<,FS)PY"1+T8=% P9X$(DH$'%BP MQ10D3ZXT?$A XAPT;^YDW-BQ8X(7*D"P23.'#@@S==R,H9/FC9LY(%2\Z/A1 MQ) G3A@ZA%0 SQBCR] AR2! I*ZE:#2-GYM:F0XB G5IU#)FR6IEV#?(U M;-LP9,W*=1I$K=VQ;_5R=4JD+ENK9/+&'9S6[V&W@1>C#0)Q+4Q>"-OGES8,B0"@!6/GDO$\VG HL]V+6SXQO7?@T9 M=W BE^P[?_-OZ]->^QO[V3IFLY M@?0$JO2RF'+9YU\ZG;F UAW'&4#G.=; M@(P59EY^OI'AH'#A(78;A6BUMAN&&OX&XFP0=>@61/L1!AV)U3D'$A-)3$'% M7SOU)*,(04 !11%.$)%?&'# 488;9.PH11%6%"'%%$7D)T<9=I0AQQQE)"A" M0C:V $4029Q744]PA)%&6:MM">015""1'QM'GD$'&CLV44030CB97QMEM"&& ME77>:<5??+9A1Z!-1$%HGW'LJ- 43PPQY$5OC.'H0H,>9M$,46>#Y!!,M6!$$$U5$V:VY=H3!1AU9IIDM MO_X"+##!17#[T !X4%NNH0HSK"7$\ (,1:DW'MP&'#G2\7$1!H'\KYZR7KM[F!-%O3$ M>;C3H7N=02PA=O!4#+]G&&M064;N:.;&_/ M,+%FF[#C80><;LA)9YK72]'" MJ?G9P>J.Y9O$LLRHV4&M8%*#0)8<8>3!.[N^,]M4$\D3VU>D$(0L/"]Z]\N? MIZ1 P"R0J;JC2E;JVOZXAY7=-<1G M?& C*72N>QO[U;ZHX$(G'*$%+.Q7R&"XJJ!IJ7T^(%GZID>'E+FJ2SXH'ZWH M4+R/T;!S.!1BMU9EQ#21#(DL%Z" M "-J5.BHERA*RGME]&D7 ME4-&M302@H3T,A)1 Q$C6H0G&*$%-2T(*'3H&U"N"47!SJH+ .CLM^(+S(F0&-KSA>%\L0A)H9$,,E2$-.PF?ENHF M+R%%B'#XVE$,5O"7],1@1RW8[E_F4 7>D D(]HMZV)'9'L7+"7VRE8D\1 M5L:A K&G6-S=J[@W-]QT97=I7%HL0.$OJO4L2*80!9".-PXR+3(4F-95/, ! M:KD)[A%P](8SN'57HZ/#'7@R2..> 9 *N^L)UZEE5UKW,F;.KR:?< 1OBJG+ M1;F6EK$P7#AW&0_(M2*=G0#A-W79#6_ :DHK 1($5SD9&^=@%#5_;3 \ MP-%%=L2#'N#(JSOR]&&\&LDT^4#41_2C(/$0?T4Z4I(IT=V[=TUH5J8-MPU,7>]7T/H(/ M[@UK=^=Z"$DH=[SC>F[4^;+:!PDXO+$-75"/&XH 7_AENCCOA_\["?8>>!KP M;?$; GS?&I=3]1:]JWN&82A6JO4ZZ2@%@4=(C7(H^(KIV6E[HB'F[4X3RR5. MG)O/^XOTS/C+;XYOH'\%Y$.7@\AG+D: N_PS-X?NIG5.SX37'$-1AU.CJ-[T M)/"\-U&O^'6J_O&O6R7J'!][UY$.];@N78]O3<(+GJ#RO5CSS6)A9I*FVTHB M'(2>4B+#/2WYB3>N=+5T!1]YL;$\/Z$?/.D+*S8A'-Y@H)?#XD>?ILZSWB0H<7*$0C_Y*->^ M]-F#RI9W'W.C>#FI-1I9 ?/SQSF@3(%SJR'34#.X-N[HL5=@+NQ?4]D[1->W M),])];,&::.L"EUU%ZST,W=W[O7:RK+7^YR2MGZE3IG7EQE%7GO1Q&)]5P_F(,HI5(?I396T8-$)30L(X/:LU*$U4U0T3U' M8P87I5C\LS(&88)66%C>Y 0RXVLUPX6)M5A&\45YXSH&(80ZZ(1C\% C]31N MR$"/DX$IU8!-V#UUB%TOY4;A!P)/ UURI3\%R#\'.!@TY$I3, 0N-&5 A6.@ MLRJT1&DJ5EL$%!62F 24Z%,1=(GX](@9U< 9G1FN+:$*7UA2/. 1BDX41@HD- MU8:<>%KM: 2C^!KP2%1F@(K^MT?B9&QI=HZ%M!<)8U- MT6Q?,GU6=B1EHFB"!22$)@4 -"L1DH*()@=MT%9IT@1/T"3-LR=O4"7&4R=_ MN7U5T0:#F26N\EB!N46D4S,5UIB(B0??MR],V0)'0$!0()1#H%Z^!I5G &U' M.08&%Y1#*3:;V2.>"9IX<)2],II$4IJGR1C:(T:KV9E)\)F ""=D(9MP0)N+ M,0+2AI/AU]#0@T (@ M<#0%B@:#%(A30GYWZ!,QY1._PP03 VDV2E(HD ),T1$92@!30@FE(.C!**HA,ZJ0> :7543-5>J59VC%U:;_J(+I M<@)>]0,G<%>7UD8!&@2FC560JD@8*EEA:F:^CNJI)"JJB^JRN"JN[LBKZPS:=6J"^HC5GTA.7%J4X2:O-:JNX.JI^F@!3.J@H M8%M%0*88>AHE1XNS\Q-I4$IUT 9SP (_H7G[RJ)( FEKA#\H=R7C>AKEB@(A M<&QLP*RK.J8@\*KB,@=C5BUH<*59DP=& K'2E (3:Q.@@24@\(!8$$H7*BY1 MVJZSB@( :&40"ZTJ"PD)8 (FX*9T\+*FY+$@>ZLXJ[/[&K.+*K(;5+*75P5- MD++N$:A4VK+%]0:7! =":Q,96K,WNX4 VP8\BZX_F[5"*Z_B,K*#Q')*N[*R M:J4H<$]2JZY42[,VB[-J=!6]LK4^"Q VB[-GRM 9@V;,&S)E4(214:UG3)*W_ =ZX;,ZJ9S[OJ%NA&CX)$A0K-A<_5,C(<@U$Z<:!DY L=.D)QH0)#L)($BQ.JC31P9BC8\@C/\-IOGCBQ00F3( (2.=SZ#;- M/6<88OSY)QI]#Z$5WGAT&<'$$^FMUQY&[X44WVEAT#&?65W9!PE^^A5XVG\! MIC#@?@*9,>*!'*HTD7CD#8%$$%*PYV%''UF( FMR;*A8APG0D=W]Z.*"Y$TQ61).'&%CD!3F&)ELM/G(U80@@B#;&)NAP!^7;IQ1(@MG MOD4;@B8>!@(,3\)(EQ5%#$'%$S5.B.-C.MZ66X\(@CFDH'3H%I159&GEI()V M@C $A%-UH=EF(LR)YX<:XX*IZ'ZA;HC&:1ZQ\(8K"((R0 * M:L21K5D"&EE))UFVDD0MO82HHE75=)-FG'GDUAUO@##L;G\I()6SN"7J4;$H MV)&5'?6!\%583#B[[5D22;G. MTH36WP1TS9,Z?3YZYB*P8$?K:&G-M==FMQ&&&W'==+CRS(>.=,EE MOQTW4DHQY11Q>B>_?!Y]EPM8X(,7_OSWTK/]>/$2:0 :"%A31E5.,2Y# $Y+ M %UR'0 *1*7MJBF E$ PO5(# ,\=,'3YJ44F9.&3EV MRI#9"N5LFS1SYHSL"!?$&3EAW-!1Z_&-'! 'Y92EHS,D7S\QIE\>,@=NMT8:;/?EM]]E M"L@47AEX["6'&Y+%-EL8M=V&((,.=L2$%4$P,9!M;MC! AYLR,8&"Y^9$48= M&7WQAAAJE!$2"X354<8.,F%XEH8<>CC'%P>)\<9!9."8H&H@Z/A@A'(,*9(; M%N:F)%UZ)1D'"BFP4$8<=F"I91QU2(:ED0H*9(9?=ZCDU&>JB5>^V&:9D#+5;22:JJ5T=(DX( Y1T@L $72V-0516" MH^+1*I8R[2$3") 0,.H8*IG(PAADH"69D<02,&RQ 6(% AT177O'&Y/*<09^ MK=$19V[1(NML5=21R!IOWF):;K,F\J>K2B=9A)%& M''ET4$AS76?N"0WW:BZP"@CK<+&CVKH;M,7JS%*Z;)PAV:WW$I#OOO46#;'$ M':'@,P@_]*F2T[<&I0,(3B3!A,<@'RER5"0W9')&&W7T$?6:U3-=C[WL7#>G?>'>Z\^]]_\*HT5TQ1SCKCM M7@ODYY^^H[VJYGR./'50UK6>_9\HB!!&&"(DWIU,,H>1//H@J/\3^R*0 ;_\ M79.9_Q95G?Q=KW!^ I3[R! _1LU/ 0*\7P'UE\#VD8&! +Q=G_#PG[],;B[C MHM_FPM!!+$WP@$VKH/O^T\ =/+!^]B-@^E"X/@7Z[W\.#. (!VC"&48,@?RS M'PY=J,/R(>N",C3@#U/(OPL.\86;NV$2*1A$^[40BD;TGP1]B+W]V="*&81@ M%'F(/RHJT'X8S*$(LUC",M+0BQ9D81A1Y:?!A0]X(12C$4E(@"F^485\O&(1 M/32R_VQ1B5U4H?_DJ$8]$A)90O3C$FO8/B$^<9"I>A\2>XA((-KPAH)>2HDS5(@= M2TJN< !I)&(P&Z?)8O;RALG$XB.U>+Y=FM*68&RD -'H3$5J$9=9E"(GS5A) M-()SFJP'HE&/;R %F$#@<)8SR0$V)96:' KJN)NQ[H &C% $ M!1@E@WI 8 (3] E.<*#:;CJV%94B-:-R6,$*ID.=$X0!9K";FNQ <+785FI&&/>R-LE.G)+36>G4LL6JE[R"%H9?G6ZV)-,; MO:07TI*55C$I0V[;RG9<.K)5;2$?UW8/1]E^V%0])KPNG2;F!M]GR+7:% M2@#A*K=ZQ_5O37; M/8=TUG%B6V_O/EBY^%Z.ON0CY&KOI]_/P=9;LO5OLVJ[80%;ER*Z/?"1#88P MQV77P2LU[MUFZ[@'PW1ZJ0-6P,;-PK'QW'9?SK66HW3CDXDO1^21+CG)"*:(@L4\-RC/ M"\)3%O)?K,QI"V8D,SJD(Z9NF0?=K!3SG1?06X0"TQ4:(%P) TB&9H>.CW8W0"7 /&B3M:8T.M)73!) MQ45#M[XUD2K1@5LY/2F#^TJQ-OBE#/6: Y;0-RT$)+M6^^+/KZ#4(+ZQ8-F" M0P!1C=KM;X=[W-792K38_3.#M9NY"8@6'"CS*1-Y+.#%XK>Z+<;O=]?.2 C7 MKJB=AFM^'SREZ:8.OR$>K7/#X2:82D#7HJ7J+DF_X,SF+&A0$.-%5R MJ]G[ZLJ]/.9DD'6O;MZ:,O_YM9W"$(V*.@<6Z&LWNWY6I@7"5 MLFM3BIW[Z/U>M@M)5*^%^* _(&CM5L+3=*<\7=I4(4V5WN!7;-7E:==>\F19 MQ)*4*R !54>!PDE':P>V*JH6=^'>^Y0\BY/[[@(G. I8KN]BN=TDU/G5S"SN M\*UQO%@>!_G%^>I7BAN[!\JNG83095VX7)X 5#%+_LCL>3H,'2Z;)P#6^?-X MB)<\P+P9PQI D+9LI[M>4F=)=KF- F\+YMX=R_?=B3][T--N:Z,?;O2VG(#4 M4R34Q2TSUD<4M J/^VZW+_+)37JK8Z^<8RUWLV#2(@?5SWS&=:[<^L]B%IV[ M;?[M+T.M?1QT7?-Z;M!E9-E6?G&'?ZJ778.G+BSE4I=V95P68&4';5"7=M7& M$FQ7>B8!=]B6+7-76787+7EW;EKW5"4!>!CB0(/'.8:G? DP<'-0<.BW%>5-#>=<658FS%?'!FTF,EB7$FD09^HU9^TE/M>! M=2V@A)A37X24A&&PA/O747SR44LG@"A7?MFE4@K8=Q?6@,_U6&;"$8F&;L:6 M,,/7>7_'6%1U=_-F&]D#53^1/++S'XTG>^47>7Q8- +9]%(.XEB!Y,(?^Y5.?O8C@.QCUO8 M1_,H$>58CUP2CJHF,HD2!_U(9_^HCA(1!P*)!P]9D/I#CUO"D!KTCJS"&-[6 M$0>54'WQ%^_X ONHDA49,PSE4))"CV8P!LY(4?3Q5S/IC)@":+UB=+>2=&R@ MBKB5+0Q"'&4A%[W'+6SP!F^P>U6W6TOV@?@B?=YW.F08BT1S.AAV*FI8*TSI ME+Z84T4Y64C9$;WX%XL7(:'';"0X''3H0BIE5E/UC,2'5#F9 BB !\LB5E7S M'RS8<6I9;'1P>F)P?&M@>U]HB!TH?"+V1HPGCBV&!Y0R!Y82D4\X6I-I*1>9 MF9?2B9=U:I5R*?;(,?DX$)/)C^\GD5#H57%A!YO9FAJI8J&ID';@D9$YF1"9 MFI?Y7KCYFG-P)9XY.+))F:(9![:)*IP9D@)%DD["$13QE*'Y JHV-18:%((UAU1XH=%2ERIPEWFYEX 2HBQPEX>7 G@<5DH M!Q"7 (4);H?YAS_(84'(@65!=XO(2X_9D+CC,\5AF35GB;?2 L5QD41:!F80 MF[SD*2BP'%5@C*5)(K?"&QAAI)48A4FJI6S I%F:A6P I5TDI4;0(5-@I>D7 M'IYR$O2Q(Q'RIEUZG3#9*=AB.&:@+V?06B P'U5B+GL:!F>P44#G(3Y3GJDX M-S?I!NHI*_09E6+(8%*![R'4+SG5WC!'F4@ HK: MI\UVBVWXIHDX=0R6=\FHAV,E6(XJ*RW0 L](H8"265^X5FUE5X(AJ<:6)AE( M$NW1&D/"$ZG:>35Y=[DJ![O:/KWZJQ8HK*%:K,?J6"9GC6%H;/IQ!ASA!AS1 M'KVQ9,QJ&ZZHC?JD$H/:'A\JK54#-3I%AV0EF%7GM$-)$<0Q5XDEF%)+MXA;M2M+ M$*^ANJ8#LWV;'C,;N*WKNR>[*PQFN"L%M@SXN)Y;C3OJNDU"4RN!%/FI/^NB MNRV5MDGK8GC;!M9[$I*;+:\+O;'[-',KO#AKMVN;NWW'NUO+N?]'C8:64X1; MO%Y[O+4;MG.SN-W'GXZ[LY ;8-_KO+ KO9,Z-Z5EO2A@LIVK9J5KA-F+!ZO( MNNLY>B!;ON%[%K%[N^NBM9*BP,0!!X\JO_<;J1<'R M Q?YRZP\;:^B6&S,J'*XE+3<8?58R<]HT-2Q+KO, MQZ=C??/1>2& S""-JVQP6&206(L%TLWV:\%F*\-V;&8@SQ01>5/CTG,#(?;, M'QZ-L(]LWW?$:1!OP1 RZ$UK4*(BZD56E@%#Q]&X((*',]!\EG M,RVH>(^9 !T;>19#@W8]U'C- C^M=BW5U$2=!AU3>0>7>3@(<J^'UQ GTN=6>U65<1@(?CJ(\T.$RA:>M%^IL!RDA&*O, MMZ/"QW?#T2NURSI[RY*,0,EST@^<%B'ABZF]FL1];55XN\GM%\F3=QI+'2:0W"W@ V[P!7;@/[RQ!3#0!2YD?.#F+>+F M0,\HW5IUT&-LD$!:W5?JK31BHVB? WRV W1?)W]B=S+&E+-+-SU7B MU@#8E8)KQ_[]%TH]T9C:'J0#JVU0-"#"'RC0JJ]Z'-\XC0$(U?.9%X *;)$A MTT"UQNM:;\<'W_BFU[!!L/V%PB2 )'\'> A$/P-KF#6&Z05 ME;_WT 2]%6/@@I^R8BX:'G.P%,3&X\)V(+GQHH%YW17N-*W!*$7>)\>W%W%; MX0W3@OP1WI(QWN5]WKT1!NK-WF6NY3)-;-B]YGD'91\7V0S1 A_N ]2!C&'W MA_2]5=3ARG.3HPJSXC'MXR]^Q]%B?3+XY0>3X"!"YN&1(BN2$1S++7CNXP-[ M+=RR;,<6@(;H6WNNL%T4I)ME!YO(I>%\ M@MZ+J(B78KZ[G.B>S[8X7::,R\ M4@G>V_Q;MHG$C20>J\((BJ)(BJZ:U#ZN?^3U'P^^B1>) M[9NHX(N:X?;MS$,^VLG.X2C0[,0([>MRX;QL[=G,.'90I-S^7K>^I+M>',_M M[[_=-/?NI'E)7,5.[Z?K9MB.[P#NCZOI[16NI$X:[@/_I+8M*16/RZ_N[V+< M+P@OI+'!\ $UDD_%,%6'!Q4?J6^3\G::G1CO[]CMIYSB(=AMJ+;&)[WJX"P! MT, [P?,Z? >&JAN^[!UN[+78E<,JJBANJD'OJW%(,2$.XB*.%>S>J\E7J]S! M!WPP'R! Z (F[S&/TKKJW"(PKTXBM4F/KU9/Q\T;&VK>K(RI[H5SV!6X>!7^ MS[V,.W8 M_E>.;=>6GJV3'N/%<]=6AI?.(/?4@IX\ -P[8E/ZP(.\<4M!RT M^!1O^!?/)XE_^ )O^!V/)1^O08\/4"(Y4 OSG+Z(\G +E2L/MRT_\[%A^#%/ M4:-2\[^.\TT/N"%UDSP/O[?E\TT?J;UU,# .])_AJT/OC;%Z.OH[?;;,GZI^ MKZ/:T$Q__#'>[F@=C%-/!U7?]%=OJR"@]5SO]?$^[78_^1?ZKO%:]L%_]A>8 M]L:Z]E^(QGL.]Y%JB)1>+*4%]^>OW/^\P'(O\*8+\BA?W:S6\*HY6K?N [&V MZ]6]OO'(?S1?W3J?'M,>T&X_^<>6W/]9[&(+PW<3@$=^U>57TXR1YI-_;%'. MU_I-L]..U.)B_LE].GE'(B*H-2YTK1?>]87N0B@]@Q9#]X\,W1>>)23RF-&R M@U$UU7+?-"0"ZY'I,\D-^:OI,^-MX';K,\G]W-4=W=.]^U5RX0$MN]E%(LT/ MH&(+P\UVY 6SYS7-&.(:]R%UX?PQ[B3RF!U7W?P!YI.?P--^.M[=YN)-WN:- MWG2^WBYTK1?>]86^=242F)Q#(@8WWW!0WSB=W25BNCV+^/K]P/RM$GB!%'VO MCFQ5!BV@$GB1!P?.5N^-%WF0S/RM$GB1!S'@)>\+F*3'WRJ!%WD0 P7?==PW M'*>S@U&EW6? W7(O\*:K:J/"WRJ!%WD0 [(Z!L=:F]W)$EWG0J."4=YB!S8_ MHE5RX?]\BL#>;"A>=6*I9!CK:($5614RJ!%T@!E: ;]R&5=]EOJVL- K5Z MX6^] HR]%?L/U*M\@UX2U_RM$GB1!S$@JV-PK+49\!3SY]]7[VYVVG[5]\&C M$GB1!Q)O!IL)\+??RO :!GGPSTVO\_,1T-V"%TO,8"J!%TA!.L7^J&?7+7B! M%#_/8'=X5-I]!E[7$BTZK\G/J6LM]7H1[=Q/]"'N_9+=>6P-_N*/UE]7_DNM M$GB1!R)*QF//J^T/K.]_K_'O_1"G$GB!%!VMRT"]RBJ!%WF ]Y)-TM@=52J! M%WD@HF2LTBQ-[? :!GG@@W,3Y8JG$GB1!PZD5=I]!F,0S86#\@!_I91B+7T? M/"J!%WE0^5@1^/9$*82?^:T,KV&0!__<]#H_'P'=+7BQQ RF$GB!%*13[(]Z M=MV"%TCQ\PQVAT>EW6?@=2 @ RTZK\G/J6LM]7H1[=Q/]"'N_9+=>6P-_N*/ MUE]7_DNM$GB1!R)*QF//J^T/K.]_K_'O_1"G$GB!%!VMRT"]RBJ!%WF ]Y)- MTM@=52J!%WD@HF2LTBQ-[? :!GG@@W,3Y8JG$GB1!PZD5=I]!F,0S86C^H2? M]P-Q'UX!^:MY'UYAS'9['UY![L%N[LW\_ B-WV?*(F5*S40K!R![M ]7[V[6 M&XP!^:O9&XQAS';;&XQ![L%N[LW\_ B-WUW4&XS!R]4L!R![M ]7[ZMV*\#< M\*HY6CYCS';K,R\;C_S7RN4>+3=^[,\,P]%<.#X35=1,M'( LD?[+3=^[,\,P]%<. 52CE%%S40K!R![ MM ]7[VXF)"@+;FX S VOFJ,E)"@+;FY@S'8K)"@+;F[PLO'(?ZU<[M%RX\?^ MS# +O8&M9S7( LD?[+3=^[,\,P]%<.'OZ!KT15=1,M'( LD?[+3=^[,\,P]%<. Y&'9Y.=RX"(]5= MS7( LD?[Z-?"V*_!3&GPDP!W< ;%"G=RRM?WB0UU!.*10Q M!5G0!$+P!$R@ ULAY$A-!W PUWEY<,BB>LHA!4G@!$>@ UN1 .H!$CB! L)A ME-UHV$E-& .;EUFB',SA' >7 ,)AE-V8',O1'%@@'5W%!3!P C-:HVP%<L/H!%70!#JP%0E@'_A1CDC-_42?EP='HX8)<9Y.=SJP%4)N&_!*]BH==:[( MTOB*!P>-F#D,0<,+(H0-"!@@5+QHH")A@R!LX>>2D M.8.&)8HQ*4#$R($#!XN*>4 0"6,G#1D03=) #%.�@A9>CHD9D@"!NK4G;V M-"FES)PR;,&=DQ+H@S!\L6@&!)V;7W"K9;-#9F^T'9E8"<($1)DW9KZ\ M$:.F3$@6A>N4:<[;-700TJD/9/.1!1[<;NRX9T.;N7/SL$%P9 E'CIC!89!! M!QHL] <:' .2]UQ^1B3!1!$OT6$&'.3)%)!U^,5FE1QOU"&2&[EA5IYOZ_7' M40PHI#"?B2"E6.%J?LEQATI/@=:92F&(1)))(AKQA!17!"$%$>A-5]U9(M'A MHDP^ BDDD>D=61ACP:E4QI(*-!GDD$6J!Q%DC:4T&)86"H1'&'# P492#5F$ MD48<>7102'2!< *::N9Q@FXR13D0GFNF*-,>,H$ "0%^JG3&'"RH0*%JAA)P MX1E9&1>1G"#IV)%>3RE:QT1[@&V',X:H<9Y"I0*235CH@19Z"RA)C!['$*0AMA+$&17.D- 9%)%E* MK:MCK,'GL+KR"NQ"J\)WQH HR)H">9&2UBT*[RD*U(O$"L083MJ"D&P9>YE$ MTG'Y^AI&M]]&:L9?(,#+1K4,T2KN&6,JZU6[ PB,E01'NL#.L:Z^'5,\ M!AER<+QH"BEPY>@**XBLDLD>TWOHA8 F=2RF=&8+\,W[]EMPN#5CV8=J%^(Q MQF1LC+%0FQ=EM%%''^7'R*C"PPM:+,8!\Z2OW7F*3G>UVW87$N-\4K8K"?BDH[.L:QTW< MT'O53OYVQBRM"N(=N(>N*0JHVVXPPL!#1C'M9T.%,!+8%Y$!K1S!0MV56D:7""&@/K M=((*FFTW:*L@V]P6J3041V'R @$/6A*4]QP'.V6X0ZX:1Y_'@< )#M(; ,Y"'AH184G;B-80Y,A(,!*0SG@X"H5!I2\83]H05R^^/44[.2K9_@C%>,FMBH3(&\+\1J7]NB(1ST> M;V&/0N+;+C0'IB#K,5%7.8J@#R-)=:T !#7B9RR$Z")ATQ.7_QF ',Z0!#V[X% I0T" L4"$+ M4"A""C(),93I4)H_@6,%8R! J#S/?RR@^WH>"$WY?&1]5.6J"0YQ7Q9T5E9 M/-HJZ=C/GX3*8?+:WF)"!3ZAC \$;DL 'M+'O5 FP(0)RUBUX(4RB'*E7>@\ M6LGP8,Z/'LI1(B,91\F3@",F8)@4B>BI0$FQ3EK,I#ODT,;(.2^:AE$K#5*U*!17=00**Q9*;&:Y. *L9XWC:,(=.U5X="E4N M.Y1'-YR )9SQ#&@6F*DZ9>TL[-DJKR#HH@1\%8MY8JO4OG7$).)AG2?I73:W M&*.!5/!;(403BLBGQCJ>L5=T $]P!'D78UT*DG)K%N/H$!R*P4&(\QSE(*MZ M*5=A! 2.O%E]Q+-/_3F0 !CU)60]"]I8O,,+#%,LP,#27J"F70PHP$T0PQG.$2I]AA"8KR0E/^2X>AF!7Y%1:Y5P24%@>J@"S+H/!CJ !)!\H2KI"?1205$WP M7Z@@_%I*-N^2/-WDVVSJ:.11MI1J\9Q@55FGUR(3!3-H9TBK>;LB> +)UJ?$.XGF &JIC%W&K\$*"B? M/YE0ABR4)0TU( AL6[Z)/C6J7(FM1G?:49D>BG^P?AE);5?4DSIZ9",EMTMA MZM'RS91AJZ(T2R-%,B'RE-PS=>H-<^A3-AP5-D0U:I=ADU0Z,K6_+XGJ70EG MU0WJ+'%:_7"KNVK NS)+K&@@*QG,BE:0J/6]E[IJMMY:E>)(/&CG+2X$]4IF M&!=MUFB(06##-MC#]9/( (((8H<,\\4.BHY^.K&?+>MK12\KK/>EXXG+FSG! M?4XM*T&TT37L+#<\9U-;A?YU.(N>+IWB YV;P'A]+4H%K3A#: AHWY"-?TP+.IB4P&,"JX/FC2JF41^BC7KDQ]G8:ZY00]Z MR1M*>1-^S=!/L9D("PBO0_A#2 43,G06]G8/ISA?P3CYESJL EDZX0;!TDX( M5RM9(3DZM"N018&!\SZ;0V.=4TB\1SK>D71OPWL 9@>?M1)#5 5,P 3[1WTQ M@V0G)'V.-G]A4']#U2J^TH#!DH J0GYET%$]L"I.H()%Q%^XT35_@0(B<#0< MAUIPP"\>D7PBP (\J$-(TGJ$MW\H=FFFI&DTQVG9XFFTE$RA9FO-1'BOUDSJ MMWOLEX:Z!!_R=&E=-C^7A6&+)DF>ADYH6($3MRIQ)F%XI4 -UU9AB&SQ0E>2 MYU?KAQLRUQ";1E@WUW=IH"]6AW:FESAG,V2+6 8^US:<]!! =!8HX'6X@0*Q MDR+I9859T7J?95["1800Z&\#-U2)&&- )%^7YS1QHGEV$.PV&X254-6(83\5FVR&%0 1V[_Y@8ZQ%17&'U9."&QJ&\, M"9).QT/O* ?Z R!/\5KY2 95QH^UB&7EZ(U;UA!BZ4^]@2']819SD2W/,H\ M4P:KE2,4D37XN)8!^& ,L $=Z.1D*&3>MT1\Z M!(B%83.)\Y;#)I?L59=0PR%M\([ ]UI))HOZ*& F4)ERT&VJ<5>8=DJ/2&8) M\&G+Q%+OA)3DADYHB9NPQIC>6&M#N%?C-5=Y,D-,Q6X1-7^=,7]70HI7LDOD5I6E M*& N640LA7#G6)]-*53D*1,N9R:-.7.@4W-U"'\ MF"\.IA_T=2D/2ALZ$0:WT9 ^ ;'(B-B>A1J4!DL8:OT M\VL9]EK[Q911:65^Q:>-B$J^,Z (,Z4[QXWJFJ!^TJN \S;VBJ.J"'K0::_S MX:G[ZJAO *G^>HQT]%.SB*XQ-@=YT 8YJ*2ZR*1[=0(,NUUX!#TYN)%1ZA - MFX,)&H%FVBL-*P9X-$,6>#D<24>V.HK,FH"12J/]Z1"%4;$0FV.\2+$[Z8 8 M.[)XM+$$,;,-^[$W"CD:Z8 F^Q47N*8J.XL)@VNOP;)TD+%&NTNI:*3)B =O MF8LV2Y$G()8^*Y;T&C<34A@L4!\"&(7 %VA[D4C/6PPF# A@+#Z*+2CX)H&]NJQTF&1*4!:Z7PIJ-6XA+ZY0=@0( :[5^)0=D$'XUFWE<*Y:+ MX7MR\+6M2[MAJQYRJV?+@@8Z)+<4@P)U2V-W&Q1ZFY%\RY)X"[@HVH"$VY&& M.T,K^Q,V!CE9 :ER"X2K4@1/8 1Y:QW8P;FEPQ+,:P?A1[TP>Z2L*P9YT#E: M"[M-:B>RR[Y\8;OT2Z4_)V=BBR!RP+NS]+O\&[S#*RMX>[PAF[PH^+>!Z[P> MPJ('B[0H*[U,NTTZ9[UT@+W\J[T@P+W>J[>;"X*F4[XD9FJHE@3>!$[B!!'I M>[6L.U91][[3&+]=2V-DT#T9MQ*VZ\)^F[^1,,=QQ+U MT0/B W3[6QC^"Q%4","%(%&\'M5%!EW#=I\#=H3,NLT\:JX\IQ/,1U;+9X_#VO MRL=J],,&$W)I"N;W=B\B'LK*,/+X"!,EP@#Z3/)6E*U0916HE=FJ; M?,*K]LFJ&V-N"\*@5\H2NV-NVP($_0,^.]"-;%X\?"B) BPZI"B?=*9A7#G1 MVTXK:]%#^XYI:28/"L,'S4'\Z+/\B-,>P;]E M*YD\[:4^#9J*)-252-2'M+;BAVQ(/8%*.X+ G# #;,4&;"M1G< DO< J:M70 MR\R4M=67 K=?'=;!E;U\Z*(Z</W;R1KJ+^Z3+80 MH4/D'+*9?&J\/<5,3;Q.?<4A.]Q:;-PR*MD/#,;+[2'-7=O//49>M\_5;=:B MG=WH&-"E#99JC-HW*]XZ7-XZW,HE <>P3+LO(_3-^(_=O!G=_&7-Q4_;S_O=&_2SS/?,9F MD,8LN<8J@A)NG.&O+,0(GKD,J3K0M_C'ZYDLD M<09*?N D;..&C>.^W=3 _=3"W>/,^^/^_38GJ]S-3.048^2"3LK5S.37[.39 M'.53SAS=K,?C\\A;+N!='LE@GA]BWN G?:1D$!>Y!8TX!K\3.^O5PBMZ0M,# MH>NU+M(2U5Y#=0+RC=##8]%G4BO-=B6+L5SF^.,ON.,#>F0W=_('>24 M?=>631&8_< L JF;G<$*?MVC[>!FLCNC B(G\1IP$1N=V4#L'1?M?PSA%\F2\/ MVN[(4HFVZ@;0]=6>G0:@?>YAGNZQ?K7]\1\T/"!<-H#1@@>%^BD@8&KC,O'_.C>2 L[T@@XBM]85\FL?-^.IA]L>\# ?52GZ!&GQ5(K_2L&_4#XO0P MXN^%M?0!,B O@/8L?S9/, 3JX2=TOX\6JGU\XR@6BIBS MK1Z*+<@3SY0 3FZ./\>J0V(;HRA/7>!=-^,( MKOJ/W0+"6:-W#;K@WM6'QM47FJ&,L[*E#QAZ_+V83.,E[,_B]/L*;-(H;8.3 MB.8R;(-UYR'(EW>^C@?,+]8#88-U\-TW"_WR4SU\X?X^ M:X-U@/T(J?TD[^KZ[WJ')Y.,QP>OU____W@K$)1D[H3\PGL-X8Z+VRN1,8D( M(P86+P=)P7N$;_C54?\(B84N:'W8]X/^R#?=]WUR+'X^"/D$,) .28,VF"*- M,G\DBY#W)[;)9WW85P;3D@?N'>4)V'\.\G\!./!$A[84D8#QJ$2"&H*.^S8) M&+S:K),ZJ#"V(K4/V$X^."U)4=\$[.@A6[$DRP9:;-)?+.1WW:;]) 86+P=) MX8-RFN.@,2U)0:G[9JD1%5L^."U),91.BQ9** 2))R19$)0XU7V+ @)\L"JO M)P2))R19P%+L%EL^."U)0:GK<3]HH8144 3>%)3]AA8<4C(B(!C>\09 ',U] MX8X^.(4^."UYT$XPICF9J4CN&*BEB6PI24U9/)\MZ'TO:-C!*WTNV#P@\'I" MD'A"D@7I# (P\+TT:(-D' ;ZYX,*/'\DBY!D' ;ZYX->O#%L3 M;-*1 I]7,^NOH?JCG:A2!'./['I>18MT+<^FYZB2/^T+>TK;LS)_9&M ME##L"=J8BYZAN)XS7HK9VT[P>264.Y_X[TSTJ>YH%XIET/SHC^L[EIYG$?T: MT;<^FYYG(?+T3]O2ON(([+?)_9&ME##L"=J8BYZAN)XS7HK9VT[P>264.Y_X M[TSTJ>YH%XK7\=TWFYYGP?X/WP)]Z[/I>1;S']$*NKLW/NV/+M7)_9&ME##L M"=J8BYZAN)XS7HK9VT[P>264.Y_X[TSTJ>X#,6*?-1>'X_P3VRKNWP*?-1>: MXK,C]EES\3MN/I"T/']\\17W1]O2ON+&G-P?F:XK]W M$!$@<:\&<]@9:<7\UES<3BK8NC:E+HI;D,9^><7=Q,_ET M]/GE_)%?+.3W[.I]F_K \M0C7=($INX#D33T>?7\X?^<5"?L^NCL"@9S)//=(E36#J/A#'W;<6=.NFO&/'W0)] MR]#5?]Q]"]'IC>=Q,_ET]/GE_)%?+.3W[.K#G?K \M0C7=($INX#41AZ,0?9 MXOP36QAZ\1 Z@2 *;5;57QAZ,0_WHT#N6!AZ\1 Z@2!HZ]6/ M:XI8"5&H!8KJ:8I8>3$2XFCS>3$PICF9J4CN&*BEB6S3*R$SB)-#E8".9WL: M/)_?2T2/;?(H71AZ,0?841S./[&%H11N?B'1 M,BU]PS5].A@@PR]G18E) 4G-Q^VA#XC1,BU]PS5]:AQY41(BR;=HY2\(*:<) M(R&4)(2P>%L3;-* F)[$=#.%H1_)^E8/9]!46=.NFO&-2>P;76 =? MP=#5GX/9]!40G=YX'CQ"6\5 Y%=:DV56%_\[C2!84KL'4&GA5S8"[HFE% /#&]]8THW]3: *)(_)^E8.#41S./[%2 M>P8M,!AFX+,Y.!A'3O]QDX-4^"E[/O!$USC,< 1H3I?D)0\;!*^,20ORFUE$K! ,@P =\,//> M[*5S8"[HDH-!T1#L9(1HP2$E(P(< 1H3]7F'EA<.6 93:&JZYG2V+\=Y<1B! M?<^N3DWGJY,Z"#R%O 5NT 7D;R9S4 =B(+6$[OP3.P=U( 92J\K5/P=U( 92 M^X 1_>:@'N?BMSY[M#P>#EMB]2N1Q4@L !^Y?"1VLSQG*[6$?I>_\B&$WK96 MMY&&-!>:TGQTM#XK+K59W:42N2TJ\2&$_EES06;TIC]^3OP?W%#C_(>3-ST"&0X:=_;=2O MM3Z.II,Z6#Q 0(MS-S4 =B(+6$_EHKNSS;_;-G)DG./[%2>P;08U\^FX/VA>$_'.IR[N$* MFH/^BSJ4?]DAB#"O];!$*[4934.C?YE=&BW3XCG!)IH0&H((DX>]E(/MY#VK M@H/F@BXYF *R/^1CC'!$9,W-HY,Z"#R%O 6HHSW.YCVF/FU&J&^_14WG"U4M M@&+_ZI,Z5&\;,_N)'.;/JN[K02I22^C./['VA;$YJ\K5#_8Y^X 1_>:@'N?B MY^$*FH/^BSJ4?RF,]M5(?2N^HQ8A@3!F()KTN)QTY#WEPB_G M\H:I^S8/JSLQ)+7!@CHK,/MBG#".II,Z"#QE[6S>8^KKH6_H]K*8JVVTNS$B M];+IA5.1S*C7BP;3?24B];+D5J[E1D-B\/=Y\(0_(6YXJD,HM2HGP 4P< (D M[^HYN-U22^A4(B;.F"W,5_TYN#"-#E$_.L$Y2"5BR9/13$B96@@(GP 0GP )&0!U3($[ ! *DE+-G MP ,]H+?PGX-E$ =L@+>R9/13$B96@@(GT ,GP )&0!U3($[ ! *DE+-GT -Z M"_\Y2"EQ@+>R9/13$B96@@(G< 0GP )&0!U3($[ ! *DE+-G #YZ"_\Y>"XE M$TL_.L$Y2"5BR9/13$B96@@(GP 0GP )4( 55($[ ! *D ME+-GL!AIP ,]H+?PG[%E$ =L@+>R9/13$B96@@(GT ,GP )4( 55($[ ! *D ME+-GL!AIT -Z"_\92REQ@+>R9/13$B96@@(G< 0GP )4( 55($[ ! *DE+-G ML!AI #YZ"_\9>RXE$TL_.L$Y2"5B.F8,R0/F7(K6+_0@_0@.R3*70P=,9I2TECYRU#Y< 1$N\51P( /MDVTG MI$5G,:*ME#!Q(3]/6#*TUE&T1C'' 41W@!;4._OE!ELG%!?R\X0E Q%,%A00 MX1*K"/;=+E1@!' M0TPGX ,GH ,)<,DQ]SVSY!(BS>"/;=+E1@!,!6,A.8;Y4O'R7B<9,^MD%BES M('@Z)WV 1&WMTBL4<0(\< (ZD !&_RMT(',-Q4@R9P(FT#>_0@"/;=+MTBL4<0),< (ZD !&_RMT(',-Q4@R)](,_M@FW2Z]0A$GT ,GH ,) M8/2_0@"/;=+MTBL4<0(^< (ZD !&_RMTX!(-Q4@N80(FT#>_0@"/;=*133T>?GY&[G=P? MF?)_9&)'.;4=+ZL;^C:I/I5>_))%'X#8]14(B;.F"W,5_U?LC"- M#E$_.L%?0B5BR=,EH "95,B8G MT ,GP )&0!U3($[ ! (7$GX]H+?P_R64$@=X*TN7C 9@4B5C<@)'< (L8 34 M,07B!$P@<"'A!SYZ"_]?R=,EH M "95,B8GP ,GP )4( 55($[ ! (7$GZ+D08\H+?P_R7)%P=X*TN7C 9@4B5C M<@),< (L0 524 7B!$P@<"'AMQAIP ,]H+?P_R5I4 9QP 9X*TN7C 9@4B5C M<@(]< (L0 524 7B!$P@<"'AMQAIT -Z"_]?LA-E$ =X*TN7C 9@4B5C<@)' M< (L0 524 7B!$P@<"'AMQAI #YZ"_]?LA.%@;>R=,EH "95,B8GX ,GP )4 M( 55($[ ! (7$GZ+D08^H+?GY&[#7XQQZC7BP;3?26J7]' LN*[#7YHX!*K$MUH,-U7HOK)_9& F#%0 M5U6) T1W@!9'0TP8=33$Q!%GD>$BD6F:GS!:=!8C&EMQ(3]/6#*TUE&T1C'' M 41W@!;4._N(FC!Q(3]/6#(0P61! 1$NL2K' 41W@!;4RV3V7.Q@526#D2_A M-S"OT7QT- >"IW/2!TC4UBZ]0A$GP ,GH ,)<,DQIT*SY!(BS>"/;=+MTBL4 M<0),< (ZD "7'',J-,DN(=(,_M@FW2Z]0A$GT ,GH ,)<,DQIRJ3[!(BS>"/ M;=+MTBL4<0)'< (ZD "7''/>/$LN(=(,_M@FW2Z]0A$GX ,GH ,)<,DQ]SVS MY!(BS>"/;=*1$2;PZ/RY[AUADGP^:R-A$GWT+[8'0=;]._!$AS&AR#44 M@0((,]T_&(]HZZ=_;=1Q>Q 73=@9G6P(K^..SN-2[>-Z__ .'/&C3UG1,BU] MPS44<0<4<0;8:AUSQ[88$XI<@RV 44C3C2V-+*>0FYYSP#51+WT'$10F8 (@ M$ (3,2#8MS$?@3)&* 9_GP=/*'T'H6M=Z1UA H\HH.N]X.T854WX56+Q%_D12%ZGU>#?12 M&IL8_L.A+N<)2/DA!X\)>!101[+$U'V$_BP/VGV$_EH)R*A9(;7!DI%2^X!7 M_9$ZVH56+Q%_D12%ZGU>?<^N_AYQ84ID' 83\=0C7=($INX#P5[',1@GP5[' M,1B>$YM/H5U_D12%ZGU>#?12RE[',29N/I# (1S$@3C"H1Q5H4-P#N5RGH"4 M'W+PF(!' 74D2TS=1^C/\J#=1^BOE8",FA52&RP9*;4/>-4?"8CL=1R#<:MJ M\13:]1=)4:C>Y]6/BP*1.RKL=1QCPH.8N[(F#8BV.NN#$1*"2&BE]43*416G M0P=D8'<>*P);\*.SN)&*=#.Q(RIZ614@T 5##AP;$SO)H9=5P0*S MC](0A1Q&,\14AZ+A[-V00DZ #F6HH//.) 1J,X@9F,!AE MP (0DW:,3.VXA_>1Q&,\14AB#":3^WVW?E&^?D9^><7HR@RMW4&[OHDK/HL]?D9 M^><7HR@NL74&[OHDK/KX.?HL944I874F,_N96YF<8C),9L\"N3!EP!40TW2) M.\$0DW8FX0:) 1HFX09F,!@441(7A\0/@72(XRJP=)$V]%O#C^#'X2JP-&#T M^<#Z]EO#C^#]W,DI8 P:4!>R\ MODA("!@3(1?>Y]5TY+"$3K12F]$$@!:XY2$>*P)HP2%R +BWIU]=8W<>JY,Z M*+QS< 9>O$9=8W<>*P)3\J0Y"\=8:XK$B4$:WQQ5H@5N#J3!)[<7Y]39:C>_?>3AW M$!&#L4A(:/-*PS6#\?,"V35VY[$BX'MIPB]]P1& >WOZU35QK:@'H6M.9Y'P M]7O.CFQIAQ8<(@>^9W5'J+!%PUZ5XORG;!99\;5FD14).I# (1S$@3C"H1Q5 MD=P?./YKPWQI( M[^:5_I&1HM)H(C]6I@$:"%A324U!1T4N0P!+ %V/$ (Q)PN Q3\", PO M5(# ,R=-FS!GRK@8 Z+%P#ECT)1I4P8$Q39OY.0!81!AQ3EA[)1Y(:?,'#H9 M*YJIXV8,G31OW,P!H>)% P4!$PQY R>/G#1GT- !@6),"A Q7-$FI9L MZI"I*()@Q(D*T8C@C%.@G31RZ-2I;#%,Q,\52YZAZU?.S,T*RN#I[08$$RM! MF QDL]+-C@0) H(84T=.R;X@FKN$61RX<.+&D2O'PZ:,&SO/HPND;MW\4/.O MY<2DB-W[<+;%CR=?;J=R>NG]A5;1&V98],9)()0TAGL26N($09F_PFD(F8@$ A"@'5\1 >&-('X M'7[A[:?"B72L@1(<+8(P9(P%TF@CCA2VIM@;HX$P!QRV560?>$Y,4<01313A M!!4TR53&&?1Y^)QT&R(HXV)18D:F>Q^R!F 9+@F& E]4&?;9&4=-666.-^TX M(@A6:,FEEV"J8(>;968C0(:(GCZ*:>H&2654:0;WV47 MJH9OC!'&2W=]-B.=*%GJYX*:"DJBCW8,6>21D\(JV*Q6@EBA0&>P\8:*6_7W M4QABE!?GICQV&J.*UH61!PME$/C%L6K RL)H9H11!QMT;"M&MR[M$*B(Q:G1 M!AQ?B%%'@4-^49Y(;*@+[:!&5.$$$448D1U+-XJQ11?Z#HNJJLF&L6RS)FEZ MX4L,/6&$$51D 4412)K!0F!FF*'OQ%>!8$023'"L@AE$RBF0K;3)5\=+I#YK MJ\DHJWR@&#R9AT(*"3L9F!QW.$S5:&.PX?"JW#UK,<8:#/^CZ= M\<;3V<'3U4#?).T8KUDM!]8N+T=72!4Y!))(1DIDT409;=110II^-A1Y:XN$ M@AENA$%1"C>!,!T:#M,$N."BWK1'X9 0P%)!9Y!*%5:6JC!&RPJ $'F66W;Y M99ANZNLY 7I+F88>9;#@'.0$2 L'"XIR#KMT/1='A]QOS S'S-FE49ZFIZ=1 M( I_PP%"#S'.P3,6KI2A-5QY?@U'>1>I&O,B=80QH6U_G(B>= M._S$+S$"WORD=*,Q9*@@K"L@ 1S8H3*8#7E:BUH*4 D(?&D!25\41FP%[33 M-?"! Y*@W%1P+(?M)0\"F4,>VL"SK>!I1@Z#R66F$Y,+]>59I^.@7SY(MJ^=  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Aug 89 22:51:43 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa23745; 30 Aug 89 22:47 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 30 Aug 89 17:29:07 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: 30 Aug 89 03:06:07 GMT From: jdm Organization: Hodge Computer Research Corporation Subject: Xschsrc.arc (Part 3 of 3) Message-Id: <21727@hodge.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu MK8;5R@,+8:=$#UZMB1_,EAG,A2XZ3'&!&X0A$[WV07")BUQ2;HI"MA2895A6$+,$!86(K#/%V^<@Y?P&#CPK=)%(BR!2TH MC@^8!P-1KF %L^L8"%; /&42" 5.> + L!>6T\WA#AV*""?ID ?HH0 .V -! M+1-P.E7!R A2*$(1=!"6!(AA:FO0%STC9\^*#.$)6>)G^.JY(H,RX0E3J$(^ M%3I0 A2T*D6@ A+$25&&P@@*4GA"$Y*@I8X2M*$@\)(5*)J /-XQCPF$SLY^ M1P<$PF&77V G]#X&3X$FH(IC=&)1'/;.%$!B #X%ZA7)>$4RG V>1_4IR K$ M3=6Q[IOA'*=/_UF&, 2TG">%T12RT 0A/($))K4H2I\@!"4480A42.M%K?!6 M*CQ!"G)%Z4$!EE<8'?1+2>!>$*B0!(2RU*4A@ZGZ9.H\FMH4ISIM'+9 7VUH14J!,RC;3#K<$P4U?^04[]/)&SVR!,D$P31!4 M$P3@@TX2/7LV+%ZM=M?\(G2FNLUN6A:KXASM5@$J4(]69 I4D$)@CW!8K[S4 M*S%-P$QG]EC61I:GE)TM9KTRA_*XX0R[XVP_E7HVT$)MD*65JITVU\?,ZNF\ MG&V(;"U+6VJ*,K<5W6Y-4: Y.%P3O/(-67&MJD5P)I>R7/5J><[X-4QDV \4)(QD[PC@U$ZXZM. M<>80H075925DV0AP3I?E\D6W"LJ]R8L5QK?"Q*IM"3+)FR4I);9198 :XK$'C$25Y?=Q9[@3- M..K)X7K9.Z7W#V!ZT<8TF2)56KJ@B>-[+)"=XA(VL E@;)<^,. MH6#<*W0UEKO:[1E"\88YW&$/)>D&JBA+B#-QC(/XHL,YUH('H[5RC/L%P4G_I,JZV1]W.4_RS8 M0"?R((W[ZMZ@R?T] M"/Y*6,$2UK"1+[S)GQBRQ$=N\8V'WN.G/F$"0']1_#4NN8F"[M)7__JO#4-] MO0+I*ET^OI$_;6K![\O8SI;I_^TG<%< \X[/_./53[WV&]QZYQ.@[;$'7=+E M!-25?/5W-8CW?9#E>,P#>2MF?3B%?=LG7MS7%^EV?RFG@*SE6KXT?G10?I(V M.V* $G>03)M56O[73/0U7A[R('N27]#T?OZ%6_*W.==D=&* =%66?PJF>E?% M>@]6?0 8/A<%!7<55P;(/*.' @GH>03G8=_54Y&71T]V>=PS;#Q(5?N'7"?V M@$.8 !<544* 5[&'!6)(A@^H?#''?&;@?]P&A5/' E*8ACC%9?_41\U1,%N0 M6==%!T75!2Y@!F203'7P3UFX8"1F8JYW.E_(6;&LF-*%";0W!;,XV M'=5Q'4,Q;WKF$9KR4$.P'[J8;>"S:)]C***3*+)$!YU$:H42.H@2)M^Q*&-" M:B>3,HK#.8Q6(A89.:GS.LKV:NO!BNZV%;FC6AFA1S^DBSEG&U''P_X8B$6*F.IE#5' .W8;BBI9 =IFGW$FG#B2HL22]^!E99IFT>4F2]V.FR$DMY6 M01GRDI:90@VE/NUH(=:E84/A$(!IBN('!PLYH4*&>(46=!W# MH; 3:D7:1R)Z:"4JH/&)'5*9B$&7F7? H\/SH]'47T(:%D1JI$BJI&]8H?'( M;73&Z M>BCPHG?A!C*:F9&*H]+7@-2WHSU*%$ *IV07/D5Z@\RS,SJHHTF:-BB7ISA7 MG6\ I9D#(E4* EI:>HMZ.EI*IHPZHE\*2(]J L):/&;:HIB:IJ2VIJ7JID&: MJIIAI#CXJG-XCN1C;$T8JPHD':,7CQ(G$K%!9]:)JS%2')]ABGVZ'V.S?$R( MH;PJ=ASS!EP*1J!S**.C J1R!Z#D'C]#.PD).\&J8("4IH5$L/2J&-\AK$@F M$>"V29SJ0PTG)0=!%L&#!VY0!VU@C:AS/&^P/ =+KRD R# !WQ %"%+ES$ M=BT;%MZ(/)V2 C,J<.OQ$;:*KO7&HS/1AZ-I*9;86WH MA-MZ:VT+O2*4E$\KMTX93'8;LM+9?(NUM\PK,BZF9FGC6Y;B$./*%HOTI'TQ MC7;LB% %^?ZOT^%F.*#CN7SP*,UATB&LS.CL\4! MM#U;O"W<&T'+24 YE:$TE7>IFDQ;M%HKMU%;=>&S=8$UP5]R>3QYNI$3LZEW M:VFJ/ Y!PW";OKQ$M\$D7)?HQ5F[M1EDO?SW8,!YP=+QP].X&$,!ECQ:''RQ M$Y:(HY&?L!BHZ/! J65P"6RH8,A$Y:6&*ESE;\:.8V6D01P35<) M A:"R3U;$2H";H)<:\=C!RA)?S(X(T,2F^[3<'8P;_]F66#;R[\<;K65*SQA MQ020NK[$NJXK$_/B/I/!()8L*[R8N_4+1JGERZ%":N3<;(BX:;"SJO173!5* M:C$[AR^F 1H(6%-)3DE4+D, $L 73P/ C$O.X\G$H'P #"]4@, S)XV; M-'1P,DC)\T9-'1 H!B3 D2,'#APL A)@\((F'LI"$#HDD:B&'*L $AI P= M/2T3!&$S58I-G"FEH"PCQTX9,EFAD&V39DY!D!53GI$3Q@V=LR#,O)$#HHX; M.2CIU!QSEZD;D"W&O&DS4P8!>HX8Q9Y+GU;0,B"(-F'&C 1!YPV(.;T!@PA#-,_=BG9]$R]Z%S9% MLX3WJF2I8(1G,P8IPA&# D^*!"A4O'[C><4*$#UT>D]QV:7 ,VS>B,D(PDZ8 MFF'$L$$YO243*T$P 0(;:WPADT<@9<0"@5\ !MP._@$HH'SWT94'"X+5408+ M9;QAAH%BJ%$&82Q<%T8=;- !HH@DSO&%7V&X9=-)9$"HP'\!@C"&B[C!$0,+ M.WZA%V"YH?%CD'<@A 9V^QWI8GQAD.&DD'N-448,-N(HX!A?L ''?4 V^*4< M89+Q!AUAQE''F1NZJ":;64KXVQ=EV,<&"R[Z)09);I"!YQ? D6'0GX&2A*:+ M@9(E1YPYN@A'37:-$>.&!=8!AZ23L5"@F7>X@6D9C KH(G9XF-'&H4+&9RH= M-M8F4!EXW"6'&_39AY]^_%FF *RRAJ1&&W!\(48=9O F4Y=U2F4CKV2%9$05 M3A!1A!%Y^45'?EMTL6RLS2*7$T%UB.&87=OVZJV.E61D<4U87<1?3=L=<:9;"G A]N5'0&32>NS"H M+>W1$@B0$.#7Q!5#Q9=XSMG(,0$&Y41''G!LF(;)'6NI(WD8/]SQL]%.JQ(< MK=I,@&V3T6'I<"$=#-E&'7T4DJ+2H5$7&?N-3-W):12KL%6_PH%";\'N9Q8; M*3B< *P(H1!#"CV?;%M&\4EZW$1M[&74D+Q%!(*_<@ L,$6ZGOPN6_$J7!## M:+>GMD!&9[0117383:$<%A)\\N.1IS>&'7/DT<:>;* @@@I/"!&$%%($D84* M(A3N<]!V:H@"Y6%<>-(=T 6' A)3)*%%$6&GW?':9##5.$69;_[&5*"+3KKI M O56-T6P&]5WQT%+-9I=*)QA5>MEO#X?Y+&GP,+&D#S@]!QH9&\5<)">H3X= M<- ZD?<5AB\^[KKS/K[-#R@F,?W@NY 3DL"$WAGN=Z^R"UF>!X(.%4L^+,K) M] C@P!6-*">6 TG"WE4&!8(00IHX% RP@S A OI\E4%8,-!&* M<@+!"TJN8S),D04)@YZ9_8^#'@2A"J1EA"!4@0E4,*'X4JBZ%MHF<1IA& .9 MQA>G]2EJ*9D@ZS+B.B#*"H1%(-T3I- ") 0A6DP((^J62$#5G6R+G.F>%\D" M0F@)X0G0(D(9STB$-$IAC2ALXPJ=B#B)78LK#!Q6&E+4 H-4RU,(DM@-"4 W M%*2AAS 8"AQZ: 9KY6<'((!#"WQ@!C( 2ET@"$%ZG'!$)H#2/&D8BGG@T!.- M*2 !*VM9#RT) AXX1%UCL L(?@ "+$RA"D*0 @ATH)-+^G)'P!0F,8=PS&0N M$P35E((!;_FN=(D+!:(DI2GEMZ%<;BB=R+ZQ8FV\@>I@\0 5@C'+G*4CB* @A22X(087-2A<=QH!SMZA952H0@A M'6D+2PK1F:)4I2P=PDLS^E"92I0(29@"%)A@NISZSH4-].!P$.DA!A:/=3@685!D*Q/@]-256')U;CL2$E(Z#" M4*A -*:D<)(\W9I7RSE8=Q(@L'/\H @L*KX,-8RD,#6I3Q6;PA,R<:T"R:'* M?!.?.Y#E4R P%!Q*$MIB7?5X"]UI9+OG*$C1X5.:^@*G/#6I)OJ,K4+;)%T? ME;*\[ 4W=$@)W=Q0A\V1);6K$U(:2G6J'B86A$9( A98V806&&&,30A"$E,' M6:+&=%3+7160,"<8@[@O"49H A6V^<94>:BYZ7GNYXS A"=0U[K8U>X:NZO1 M4:GJ5.-EGWE18(3TKM>P %4D&X1GMQ/4*2,G>"1AE#9)Y_1P=LY! 0WL.8;1 MHF\G-#-L]?8S$>PYAP69G)V W> ^&. A!C)@;T/O0N*9@M@S+/B1?(L@H=2) MV"K6*S$=;KPA&0!)@T;M*!8LV\8?T_AZ0S[Q#%@@WR$\H0E0("!.94P ,HQ$ M:V?#[&^"PSB[,8Z >@I!L,*A3PT#&)B:.RZ.@;4;+>P:5%H,E8:! M3\0-;6F'6]NX]K.S!1W&:5T;!8K>-K55+6P<5#H'X8XU"-I-K6KK&Y1X2+<" M=/T%*%1A"DA V[('(&QP:YMC!S XPA?>;$ +^@A2<#>BL8WJ&2C\T0*)] 6 M @-OPP#6'<.XSDX. E J!EB+I$S%03V$ *EPWA\7-D5@0')9=ZSF3!!0J@5. M<*#?G./5SGG(4RUNGN?[YS8/M\!5ZUW7833(-C[QV<:[F3>D"S!$#F0!;7NX M@.;6K?E4'$5E,;Q??#8G M[SW*?=?Q216K I8F@0I)"%#^UFCX&O,=QU.^W)T]%YJ(3,0%%O&QWBV/>!S3 M@,J+]UQ]@T $T5/]\&&O >HG"T(J!#J-TF8"Y5?H99F8C>P('/->RDR1,[<] M5PPE@)YW"6>*R=EI(ZOS^@*/9ZOHF!)W.#0 A* M4.* )ZA]]V=T.?A]2L> !MAS)V-TZ#=S%Y=Q. A*U%8#32AR3/&#/YAR5EAI MW@9**L U7B,5*G"$16=S2_A_V[9J+C@ Q>)T_@9U02=U1TAU&G5UI!=V6W]9W3 1\4!4T0T-7N.%(\2$3QU=A-'-A97 '&98#=B<9>!=BHP=E89=B MD[AY+B8#.,!E(\:)6C=[$J4"MK=4/%8$NN=ZJP-D?2AE 49]GL,%;N #K$&* MLFB*?7=Z\H542L5460"+;]2+0A9[J-A1&<=ZQCACL'=B-K",*,5C ?*,AX6, M6==W-T"-BE53C[=EE>>+."84\J6*M]>*K\AEO0=FA@@T9)9(QH%F-*-F';-\ M;M9\(0-]=&9GMIAG&<9GMD5PF&9H[Z9HX,=J!#!IY4< !;F 0Z>&ZS=_[1=L M<0A_$,=^-(B"SZ: ;1AO'XEJ ;@# _AM^8: ^<> 1DB%7Q"!OP8QU&:!<,B M&@@#'(AR!."2(-ARK(&+NB@"#YB"![>"[A>',"AN,CB4&XF$-FB%(6F36RA2 M/FARQ :&*T=LH"0H <,&L2.12:60=F1TK:6(1D#9B" 2_=P!9AO?EF7$)EJ9I"7@J:68>F& M?1D&@'EN!"B7Q6:8YQ8&BOD%-_B46CB6YU:3)N=M5MEO8R@2][*2-2AH2MB8 M(.F9U18#]D:'2$D 9PD#F:F""F>1ESEN$#>#]<>15:AQ%(AJ=>>:J6: )J>! MHUEI&@A*#\8&F;F:PYEJ6YAJ70B%=BAT,7";0YF;+7ANQ1*#$:>4O\F4P7F% MTWD#U2D#36=R-Q"$80@#[PE*=U 3=^&5- >6TYF02R<#E$:'/D>;48>6J:F9 M3LF:J#:*QDF77FAORPD#]D:&9I@L;)"&+"F=U/:&&+AH-4ERLUF;4Q>+5=<] M?$B.&_*'=A"(=0!V)U:(-@)/M.$> W%7:(5:##$@;_ &:V I+S!94S45IW57 M?3$93,%5=.55=@%6!D56;4 P9V57">,PMG0R,E,\@W1;S2,3+7"&4_$H;V E M9+"B!F57@$4G=N)L(G#HBFM/AK?#0Z>L12!K==GEHH)3&JDUJJ5'"J4J!'>$0%J\JH MR94HD .K,WJH(B1&9'2KN1JH)_.F4D577+DY9$ <&@$<(+ &99 '>$,&]D@ M#'(@2D,?L=I1E1IHD&=?UVA8#.(@.0$)!="M*%6I&>=K@8JL,"2G(' 29[%5 M1G&DI[E ;]%(_L,4FW$BDW&MQ8.QU<@$4S"R>EA4Q8,AA25FB+A)@6(0+^"J=-"T MH*HH@+5:"O.IH3I><+ 70[:T;L "4& $7Z"J57!@_$6T5FLH6*NU"@.J:/NU M7T"L8\N+(UJUO$HFEY.UT$[LI;] IGT*YP?@$5^ $F2NTR56XKS6Y M$*L"0.4$5- "I:NK (51B50'BT0'C102_F,2=9 T<.%-&*51 M\E4"V04%+L5E03(D]P(1Q0L"QUM4R7M=9%0$03 $2-"\ ^LB2=(X3'(E/52] M,96\5_!X2&!=6N:]*Q0D13B]YBM9$E4"JT<$[MM"SULEY&N\5'N]8S0$19"_ M,5IV4+0X#M%/"S%!\B&G:M42,*H!&@A84TE.5"Y# 2P!=V!( )$1.4C# M?18J ,+U2 P#,GC1LZ+L: :#%PSA@T9=J4 2$F#YTR8]Z0F6CPHAPX0,GCYPT9]#0 8%B3 H0,7+@P,&"8AX01,+824,&1),T#\.4 M80-"B$@])Q,$8<-4"DR9*U39HY!=^X 7$6Q!DY80Z& M!6'FC1P0==R$G$/GY9B+1=VH;9&QC40Y8]*$85JG:X*2)T^.,#B&39V-($00 M?!BQC LT(B13MHQ9\QPQ&3=^#JW@9$ 0<\*T@<-F(MR+- WRE5/G;QJU6>%X MA2V;=IF;D!6,V&C&X,0I4H)0*9(@!@Q( R*C%-@FS!@Y;[+2>>-6) @Z$$&$ M(4-F;]8W9LZG3SUQM\$S=.VJ!T$?Q!LQ:F T4W++E=&<&Q.=(1)]NZ& QTTH MH)!706<@6%12=ZF0@H)TV.?&&2APB)I&93B8 G;:O78&&_\MEE5R'9T'UQAE M]&!$$$Q,4<0.";S6EW<3E>%&&&+41I))"L2(!QMAR''&&#SV*%"39]0AT4'\ MO9'7@$BJ,=L78M01'VI?D'$6'&'0\1"/KU5T47]FSH&FFA!EB*1K I6!AT=# M,F5'DXH5R=61)^G))PA,6('C0&R8D1<+2PII!Z1L_,G&#H7NZ=5:B2XZQQ=\ MF>D&"Y^&JB4=I'Z1EQA:ND$&I@H8NBFBBC(!FZI#H@63A2PP%T8=;-#QQ7\! M_L5"7W64 2N>(,@J1Y\@@%<'';OL=B"P.,9B(/SY$I&U67L27VDBA9<;%%K('QI- MDB1&&%VQH (<4 Y,1\$*Q1C;;+7U )UT.Z8HT)XSEJ'60A35D4:P+1A$5UZ^ MG7S"CS2VH-8)A"K0J:TD ZF6MR?M<1((D!"P)),$.PFT D030/-$/8! A115 MA,QTT2'14<>S-#F1!!,IP-J'R ,]#5]\#(6Y,ATMK^6H&S&O-7/)-IMA!L[) M[5QVR6& T[40, MZ:DY;FY.Q&#.F']>XMN&,TWKHF_#^G?3>A](AK_D=K=&&5]D=)!!=13\<]B' M$Q#2&6>-I#<=L\'Z>!G$\S7/:]3;]F4!K4 M+I:&'A.A9]OUSLLA,.!+OJUX>6J2B +JW$?JAAWS <]=&.:JVM@I>"+T M$AQ00*8XS>DA FQ:\%[CN3%L3CZB(Y$*"5"7NZ!@!SNXR=^B\AK.C&$-/LS2 M0<##E-$E)P%IB \*6M""C1D'!#SHH!BCTC0[&BEJ'YL.K!+0M/"8<0WVBLK8 M6J, *8$ )#$B8>(,TL7N4.MD;XPC39Z6.D(6;2/T^8)ND!6WFFSM5'"8%KO> MQ@(4="0%**!8"UAX' &2,4^9LR)N2(B@/?GD35H<)6_BEK,$S.$.Y'L(328V MAA6L8(^-W%<+GP"%+PA!"E30053@.#]F.A.// !#G; %A#P(6K>7,$@X2C' M)5GJ)B^D",0FL@*VK%,,(0G#]J(BS8E0TYI2,((V&\E-=%+LFSP(YSC+>4Z2 M'%2=V]0D"D+@SL7 DX/R;&$]J;=-?)9!GX/L)PC^>DZXTE+$&STGOG<9S3G.=)J,B$)V=QF19D"0Y$LI3,'<5"C'I5. 9[4 MHR#E)T__>00I%$&@VT2>#HMZD=IM&D2'2I:Z:#6$NG/(R@0@0JJX 0A/(&P1&@!$H+@!"(PH0A2 M4($(3C0 $/PM =@Q)$3.F,A&8B>%+8B:#,C9)N^L(8=8?*1"WH@=K<[/=KC3 M';7G)D"O7#WJ5VO2 M)!9_:ZP=S6E(IPIA_TZXPBF]<%91K.':[*_#'S:2B$ELX@SS9\5M7:<(9;S< M?Y;O#X<94J*7?K6*KQ'@*.F'#O,BZ&*6%X&=QL2Q/]J(UE!D$. MDDY:W2>Q6J:.[*$$OYJE"P)<@]QE@W?#YL@P)/TG)'P;,0'^;I3[LYI6I4(5 MI."$E@L$J!N^/@]D^X;GAZ [%%XV?C7RI XM M90(/FL97WO"W8!#HM Y)(G, ^;@)6O4OT[T)BI+"$;P.@C:\0=\AB8/*0E*4 MH5/P/.2Y_.'GP"(NK=K@C!]A>HC_AIE(7 S# ;A$Z=ASA803!M N6OS"L++ MCB?X9;B#>IPTP8/,8;*=[^KG+2UZ0[, #K%>_5-/[OJ>?@'V3Q#S[!UI>WVS MQ+;\XGM8(G;"5Q_%AW@_=V')EUK,YWQ6 GU'5&;MQ"36!0(^ +89UF<5C3E MMGXUUGYI\'[QYV)-0WT4^"3VM4V:MH$$T($SQGZ:]RTAZ"O (BS$(B!QYV7[ M=6JP%QVR1WLW5Q1[,1,"2(2N4GNWES[!]WBP<8#2EX"+IR*-MWP'^'S1MW,) MH&UF54#.]C4] 6351TYTQ&082$[9%SAG%36ZDWI+(B=;L 9=P&XNYH)5]H$Q MZ'Y#Y6+M$6O5EX.F%F\XDFK9Q'_Z5!]; T%>,1%-,A'59GLA,7Y5\E7O-C_(HBPY)G=69W^4,V&2 M=D"MJ(,/]@504 53@ 03-@8+MX7M5FJE^$]#P 1/H",3-FOTL41YB&MTYB1V MAF=YN$Z2UG"5$1Z'"(R44G+"^(K_1 1%P 1!D 7)V&;+"(R+-F>Z)HV>YF+5 M: <@\09FT17:*'K=6'__)!U/T 2RF(I1@P)I(H_H" (_("/) @(ZT(654XM_ M2'=%$ 7]F(8T 6-1 W]+=!,%N8H(J9"DZ(W5Y 15P 0L)U3^.)&I6)"4LY&K MV)'X6$U#\ 1., 41R85KJ(T6Z2TLN8,I)V;E2!,AX$!\P8SMZ(SKF'D+1I(2 M"8P$R1]V^$X;^6SWJ)-T-P1$( 4].5% 20="^4Y$"8V[AH[46))*69 J%GKM M^)2/%I6WZ%\J9Y6^YI-KN)46U97T\I73N$T?P23[8I,CJ):GQI95>94A$)?H M2)?1:)1TX1W=,E0B>)$Y>8M!0 1$,&%.=I,N)E$0)Y?M!@(F8 )TD09X M8&LM=H;O"'$2-V!T@)I6,I#UQ"&L.7%QEFGM,A&7!5Z_&&6/]''3R"@;-#_8 M15"=)I%XP"W?=5^M)Y7V-P55( 26^6J8J6?W(YJ<>1.?&9JC:6.F69(-%YNJ MZ9UYB#*P*9JI.9LJ6)L:*)Q%DYOUM9LCUYO5!YSK-)Q<2!#B.9X1UYKA*1 ,6IZW1ILM=)M-PYXM1DZ_ M")^6*)\(2ISF(B\NAISTIYS_% 55\ 3^Z4+Q)Z#42:"@::"W]J$TJ:#DV9H1 MZJ!G^0+TXYWF25":QA9R-*#-R(+JZ)5XUFM 6IM&FFM(BIC!F)\>^04Y(I-# M]I_1^9;3F9WA6: O>J#JB89<^)TW.G'A&4XY*IO#M90:F9!0>9X5RH(8&C;N M&5P<^INB-9_:5Y)MF'HC*J4M^04/.9)I!ITMJJ5$>I9>FIU@.EYB^FEDVJ!F M>I;-EJ8VQJ:\,1%NFI9P:IMR^G&ZN:'M2$[QF:HM',#4K M6I&'*H$TD:A.N:BDZ5:G.C^1FIKA>8&6VE:8>I";NI!+&J=A.J<:RINCZIL5 M:*IA*FEX0"]7]J>LZHJ-1(/!TH_2=F4B,&?^03$D,E\-]W!E2G$6AW$:EP(J M0$<4(W_X5:*+U#2+M$C,(FQWP1"RLQ_PU6TEI!YK(2F!IQ9$ES=/H'*V$CO7 M1CN2P@+^(H++-C2K8RL-ZR\NA243\SU!$SQZ M]'?\TV@*24[.)+(](2DIMF(E9U<>FQ4Q9FZ@AP(EQP+8-TA:>#;S$P/D=+., MYFA,X+(KL&X@8+1JN&(WJZN-A%=RY"^*HX8U%K5V]1CP9S?S0[(G]78TP8U\ M5#3S:K;!([:3PZD*8*_X@G3=A3).%[_L1;'I25L M4!30]Z]Z%1=%04)Y&[C (A:-5+@GDW87!?P 8GEUR&P@0:" M2[@1BEG M #%YT :L(J(+'+\-S%-X1P5(\ 25B;_RL[_V_:Y>C&CSU>CENAT-#OKO#OMK,6I\SI%HS>R)3%S@!@20P9\ M ;)84A#H\[K$H6\Q%\YUC'9W;%I;A'!1M)X?5Z[>B0(5=W$9MW&QI!!I,T^4 MQ3VBVL. (ZIDRTC#RQ_YU'='.#XG%'D1+<]U#" "PKR1]X^OI%1\L0;CH4,, MT889&CRR17GA)]&VA0(,?1S!_8@WG==F)W:2:]')L;?S@=,TQ[B#2Q&CRRB68KH*8+#W3,4A M,=B/[,\;^\?:H@)3K= S\=3<\]1[]=3]VS12C1CS8P)#Q=5>#=9I$@9;\-1Q MR"AR,C]M2 ="S1)FS=IIG;)L;8*_C4YT=-KG3#9/\@7Q^"8SP1#3O=.-C1N; M2T(=X14@851W47CRV,A4(2#ZD1S1?=U_$4O@0=UA\05F, 8A)[$QHKWJ#1CP M+=^P)$ W3U8(JYV@](9X;4Y7-)=P3WVW=X"\M[Q'7*=A;NJEYX#S,OTL\.J M-TC"K%&J1;+FW+9D8\9;LKPE712BW*TY8\^+ N*JC&=4DCJ6JS=4XCK!DU[K M]:WK4;MWNVOSU>*6PTBE]8QU*1PH ZY%.,I";N*).&N0ETN(2"^-.(N,# M-&? R^//[>,CTR["G83YNFV641]X[!]@(0=FP"+BI\=!S>5^W&E$8A=@)0)] M!1MASN5E_@9W@'Y7K@$:"%A324\N0P !+ %UF!0 +Q&YE3"R80H PO M5(# ,R?-&Q M!LX9@Z9,FS(@TKPX*.=-'3IIW)29 T+%BP8* B88\@9.'CEI MSJ"A P+%F!0@8N3 @8,%"#%Y0! )8R<-&1!-TC ,4X8-""%EZ.@!F2 (&Z-2 M4J[D*&5C&3EVRI!A"N5JFS1S"KYQ$Y'C&3EAW-#1"L+,&SD@ZKB1LY$.RC%K M?[H9VV+,FS8/Y8Q)$\9HG3EE$G@$"7)$QC%LZI"!*((@0X=E7* 1P3BDP#-L MWH@I#,).&)1AQ+#9V/&C B-)L%#) J7(0#9F"NHILZ-S0!!E\*R5XX:T:=2J M62]6$'PX6296@C !,>?+'#ID,K*H?IV,13K;K6._*B>\7#$6W9#IK0#D;SQL MSB0=@Q"$?)9A0 Q%B_=JVXIM@)"?&6FL!L);U-E51A@!+I<12_#=-P8*9L!A M5PH@@0 "=-*U9:$<[.V1(20$P,:$;2I4R!X()#ZH'QKLC4C ;Y>-L49;"&8$ MQT7__06"&P6V)F,:9K14H5T@]- #"$XDP02&"B3 4)(@%/&$$3$JP.*, KU! M1T-RW %6&3;5>*-;<.4G1AUFF'$56_N%T1]D2&E3>-P=/93!$ MX8;:$PGUPF,%&&&?,86NR()@ A1&?"%$$DX$(446,(6P M) S*DLCL@7.( 6V%TD;9*E/+\MGLG_?"D>^6?716J4!TT5$'<2!\"5&<)R7@BZ?).9S$\(5,QX2-LL 0E!IR.%VC.T2D MUHLARD@CIVYSI6N=;7K74)TEA@@."&&L !?2'PAOTCDK#!P<4]?%-B*D@>2Z[T' M-Y&9 Y\2HJW#\&EUEEM3F_SCH)L9,(YD@U+]R#B'.LHQ6M9+F['@@)*;P:V1 M$>S(=69W&C*TP(07$72 =8UD&6XO'.16S91D5R\B)]JT\G;Y:?OF7D# T[ MB HFJ9Y*7O*!F938,1-E%Q3TS7#[D:1=3DFB]/6-E[X$I@Z'N9W@*<"- B'/ M,EGR2!>%KR/D>4Z,1G>6QDM7.9"52 1H &@A84TU!5$@N0P 2P!= M4Q4 $42LY[/'=8V ,+U2 P#.G31@Z:%R, =%BX)PQ:,JT*0-"3)TT;.BT M2.,&1!@Y:1!.I)-FH9DZ;L:0?.-F#@@5+QHH")A@R!LX>4">04,'!(HQ*4#$ MR($#!XN*>4 0"6,G#1D034JB"5.�@A9>CHD9D@"!NK4M+LI.-22IDY9>38 M*4.&*Y2T;=+,F9.&)0BY(,[(">.&#EL09M[( 8%2SEDZ(%7^=<.RQ9@W;2;* M&9,FC-4Z:!/ E"ES!,9 LO@ M\2O'C640=CY6%L/F[,N8"G3S[LC$2A F(!#7*;/C=D# @N]\?#H:],>#=5L> MEVGDB90K0:00 ='\.6'?WARZ&XT?Y])%G'GKJL><<=' 8 M1D9)!Y4Q7WWW$:C?@2 \U@8<'SD8H'T#Y@>"$4P\04464!01W1MFL/$&'7G MH6%],EV'AVYAJ 0'0Q5=E-%&'9V4TDH=G4"C2C^<,!YND! A5()#$%"$Z" M($41SS&1!0A*5#$%%2 $ <*650CQH7D@./'$%2\EB=Q^ PU)!QSSR;2'3" D MR>9'9]17)P%X@M##0&R>B"JPIV%TU-&;3TXD MP<2&?5@G$!X21 26Y9)-/1CEEE5=F MN6677U(1YIA2E'EFF@2L22&H;H@:IP)S2FHGA7CJF62??RXJJ!N$&BI'I'LN MRD:CC\IQ!KA)4FII1RA(5P:GG@YT$%\XEKHCJCZN:M<)\[IAY&8*L GKHVX\ M&^V>=YK+ IXR6$L B"*2:&)P;#B<:+("G9%5=!$!EH84&&<5%=\<;(I]!LLDH] M"4G@$!?">:9CA4QN"E8'G'/,% M%6T"#/NI\J"%MEQ? N*2"^F&"5 L=;\RM(NBBBRZV+.Y*;! Q]@KMN@@PRFX MG&2GTA( LT RTTP12Q3AN7-//1,\D-#([5D56EQY_6>_8J?8MMEXQ@UCW=>I M>RE"%!DV1QT9<70&8"IRV\;)Z6:UKD]CV.&XZ"A0++E,=,?XJ>."U:OCJ3VJ M"F2KM,OQK[+NX=&[P1UZG<4^8Y_PWZ7R:*[6V66WM<-:.6H^\F@*= M-L8:=Y$5G=O0%^V3&6G@ 6?D*7!E.;N1.WPX1>:CX/A!ZZ/=O@()O(^ZZNEC M'0J,D 0LC*A$*1C>\E9'J+.=(05)DA\;$,>_18DA#&0HV]O05I_8X68@8R@# M1CQG.U/Q*%4_8M4)0CA"-YSA=S(1& O9X#GBUQC;6/+]-Q&1#NY;T MLA6HZID+703 7KG.M:&[52@BWPN?2S18/J/9+WWY>^#^^F>Z2SE0;@28WUVL M>+\W?7&+_OL) /$@0 (:4&(IF"$*%ABZ!D8N@A>;'U0ZG8GS-?N3C#(0L(P8,MJY,QLN">('=!$>&!!'EB@!X?A<'L8RPL/.^;# MDO4DB-'['!&7I[VZ*;&53O0>^$(R1?*ALG[H4]\9W==%^'$PCQ.D'QE5A+\S M@N!I>) :'5EBQU_R+RE_&E[0KJ:'Z>$H#U>K7S5[\"<8N* &3N,*T:P(B0&X M\9(I2(H)A!(4;K*3*PE(R@K^% ,7P.!JD^KE_W+9Q@*B,P^OXQ_=$B!&;<8& M!-X$ISA+5RDOIHZ?#1R@/^$(4*[ID7_Y;"B['AK B)X3CBB0IU#L"<$!.(QN MA@OF'MEPP0RZ[8^P"Z1T4M*@$MXK=RGOTQ_X)$61X7$) MP 2&03+,)P'< \$*CG2P)-4O!$@SS-*:QM;3J1&B<)4K.F$0T(QZMK#_0<$) M5G""@-)-8&W@W&,C*Q" 598 E\VLTLS%M+AUUJ%K[.=X)6N#<'8"@#R"X3D,6NZP%V8&Z2;(N=I4K MGQ.\H+O?#:] 7G D@<6A#F] +P'4JT\49+>]48 O>*]SWQ6EP93UC:1$],O? MMOJ7O:J5@H#E>UV)A($CHQD,>8,7EX(%);T5=O!_5=N&"5^GPPGFPJFV"B05BD&1N&#HS4A\=T#N !K\XM23UPO@$?)AREK><8APK&0^"H:Z/GPSA$WA! MS&= LX:1([N*L!='>:O9?T%PD[2 AR6*7=,3AN >-HW8#&-PP_Y 3(=H- M];GM1TMT%XJQH#+FD5J8OQI&>(&TT.8SL\CA&$?2!K">E M!&)34SF](BXQ4DY$"_,Z1D44L=ICKW;>4JMX/K"R[YA<28/B1$D'T,*4?Z>F MR)].D(03G+2LPD3K&XIY[*>98=G+9%U@$Q!MJ9W "-:^&$J3=-&^MM2/@74B M8I0&:Q#0Q84UBS6L71(&>[N(,K_AJ5F]ZA/,)FVS<4,V_^9PAY! Y'R)#B?_ M!$Z1[9Y !PLE ,,=CH:CO6$T$D_ GBC>JFICG'\)4/9O_K01BETM 6+0[!KP MF222G_OB\/SVRAFB\XK!,^9*FWG&![HGH(=!Z!-O5,7?>W*1)VGC='@X"J(= M\I$KO>0X1[DLTZ"'M.17Y6S@6LJM"'80A(">(7SG;Z6E/N/?\Y49'NMH'NFX" M>%"'(,@S193V<,,8A",DU#?T[H &C%!DZ@?G;=,4SI6C[IHBS=J-L!$,,*@- M$:JWOFH"KB-+*8[/14<:>[%UV>V,0UWJ5%>XVFUN\H4B --/7>!;G^UT!$3> M[X#/>O4_??L!A@B=TF=C,Q\(^;X/G2L#+>@PMZU6_2E_3\?O..I!_OZ:7YW: MVJ\3 A8?]^_#D>XYES+A-GYB=W>MDG<_9WX897]F=7--IW_<%WUV54=XY4P) MP'=!YW>4QQ7M%BY^Y5*0XTRM)Q U,@:$PCDUU3R:PSD]03'3$7SQYW'T]S3, MEW]/UW!1)W^/5G4,6'&LI0,IYS7S=!?54A$*N'SWQUU 6'8M\"?0YUW7EW$V MUUQ+Z#4JX(1%&(4+^'?WQW2#IU54P)$B#9^TDTIH'9< M44Y$XS4O@(6CQC_E)$9/(X=)PG_>%S%SYW)Q. ![$H%2\X?H](2#6(AT&$V@ M!EF$F"0&>'-74TX#54Y:B(0-&&! N'6&]W7Q4VF_48=KF"=&F(%2>'\2UHE@ M^(EC&(IE5P)V:(J9:'4-*&-+2'9]X@.B&':]*#5/>(I'AWWW5V*YZ!/0=U!@ M%Q1E-XM0>(2V6'%"!H1I]% 4&%=R1UQP\ 9W@(W^%XB6P0*(^']W9%*IV(!2 M5H6_80+.*(R2%XVM$F;J:!5\T(ZUV(.M\F;S" )>8(_0F"2C\6DL"(0M51=P MPC5[0G1)DHG9]X WR'$0IVCUQX4-^(,)P'9#&('/B(I;:'-*>)%>TX2 D87_ M2)$51X4@^1M7.)*9YH[$V(!>2'BN&('TT6FCZ(@M>8\FV2JX*'SVLXLVZ8O\ MIY$N>8X59XP^:8@\$)1!,90DR9&:*(T7EY)6\2?;V(T]QP(TN9'#F'$!&08# M"7,8%!@'J8$7HW:96'F7%UG^HX)GP8+0$X/S]RX*!X_X1XW]Q5'B!U?+"$8- MR44.9HW,!%<]=UR6%U,*4&366;R M(@:]52<&L&;LR9FP0@9D$ /H50"BZ1.DJ5JL)3GQ=1TQ,%F0 M*5VN^6&PZ62C^67<99L#)A MD)NJ>6_H%9K *9M?-@5#=F^J^1B?"0G,F4:S M>0)#,&34J9H$LYRQB0+9205#)CB0V2@<\9KAF9US<)K2>9[4J9[-*9Y?-@:G MV9V0663@.9_9*63$26%%EIQQ( >462>_B9U?)F'_>1US,*!'!EUFEF7[B:! MQ@1PIII[,3.0P6/K^65%LJ "D:%D !E'HIB&A6=55C.DR67\6"78KL )<*7D>.95@UP(M$*A78W/0B9>! MJ3K7.(X(I)R02ES+6$Z)>G_;R:B>)9AM](W$%9^3F@*5:HYM6G'DJ:G =5?> M"(C$]9VA.JJ7VH#MB:H;Y:B#N:KHA)X%\ZJN8ZE<87/V2:O[]*C9F (U\@9, MPZN645*Q6G%T,)75:*N=RJK&ZJK%"JN_>G_3")B;*JT>Y:DIH)_*&G:^6JJM M8J'"^EG$"JY*AJO_UZND.GBJ.)5;URSGLHR5. #1JJJAVJ $ZJ[@2*[Q:G-% M J>B!4?(*J)Q56JBFGALF@!?&98%>1.1D@ #M:_3UY?75C?JIVWG]O2I6'R'9SVGAUV@)LAZ>%B:C96I%3B9&,=T\/.ZA R'8B MZ78V:ZXGL*@L^R?*6;,]BZDYNVSQJ;1[VH"G>K31P1>(MZQ#*Z^RVK0[IZM7 M&W99"ZQ<6Y4>\;0.&[7..K9?\YU0>X0VMZW\IY]M"Y4VAZY4VZYSVY5$NXI? M6*5K8 ;V^K5E. #\YZ\[EK>2%[$909!C2;%<<[%YZ:V$Z3I@5'GMQD<@N$$E M*UB!= 9C8$AYH5E^$3(6@C0=85YR43N0Z;E,)B<\"J0FT@8LX 8L( >>)&K' MDYAUDUNI=P:]]8;EQ'M:A1V#X12F%!))07*UA[%[B8VPFP*D!49,&BAAX&Q@ MU!%_$G[BYDSCY!,=L90'BT"D!0+8RQ"0=H'7@9IS\ :AX1? 81DOB$JD9WH> MIUFJEW!/,[V"8KU7,SK9:U?3-V[U,SK@.VG$-;[^RQ!ML .[1X*>R;YUX+XN MF*7(<9&U@P([L -. XG7409U !I.<0+\%BB"$1)H,#JU-RE2,SIJ"&D95S^# MX4[A>\!;A(%ZJW8)[,);6+ZVBW[J=C',RSJ*]EPFRI@)PA8,,KJJ::_@L18' M>4SS><0+PE-^H5K#69/%2;YE("@DL19U"IF?^,20<*#])<5)[" GH 5#]HE? M##PXMHUTT<5E\,3A:<94C,:UB<44!L)[+X-H7D> 0*?W&JZPRJ+ M):/0P2:E;#\1=Z.E!AB)MJ-UTZ./][K#U8NW2Z2Y:Z1(-7NR=C'Z&U5(]$I6 ME6JAU'M(JC/#UE6SADO&!K+\\Z7:2X!7<[(228-)2*C+AH:_,:=ZZK;WI\8& MVXQN&+9\RLT[Y\U6P8NDALT[&U88(%W^:;+#L# +V'!1G ME\]9J[ATP+@+XKA7HY;8=E;VDU99A+\A"VX3>*MBBH-21Z;:W( ?.<\N2]!+ MVX#D'(3KO'CG'-(^J,YD^[4@X,[Z?,,&C=!D6;$,S;$J54$?"&\BB%7-Z9:; MDQ'O&QH4#,3]579UZBX@@*>9LBF I+N\!QD8 A+KBU..":.0O"ASH6;S:2%1 MC<8\,&1+"9G%$0=:78U0G2&J9:$@&AM_DI]QP 9EG9=G;1BJU0-#UM9N/! : M0]:5&9ASC<9',&0^@->!C&-G@!AQ[=<7@M8GX ."7:(?Q-49@B.E:Q>2;1B- MN3NI3&BK3"&7[2 V*BDX*LLZ+&FP>Q=C<"&79FF*6,N>*LNJG94:63RXZS"Q M'&W(['J_YFHA(WJH-,Q..J7V]LN]9C3-P]NPEJ3!O+M?Q:5:I'S4#,#-.VZ3 M6&T;FU)FA4L0;4S>1M'-=HW4_7'2=H#I5C>6>]/N]E=V%N M$'K*_:"%>,$E<2%20P524 5%X%WY?2,FL$ZZA7 OFS0=Q1.R8;1,H+,]FNQ ME]S,K*1< =RPQ#_"Z[>^Y\S)UMP1S8,:A]'REWQ/8Y?-MX#/)X#2O;V;6WTZ MV9#.9XA_$JK53+)BIY,;R#\=^]#L]^$3*90X[L,ZCMX>^&Z M=,-7"%0'<&9\Y9 [6O- M\]DP*.(R2)<;77$GKG8!#HPA68I^A\T@;G-?O82I?2,S7N?@G+5V:;=U'NA_ MSM8@/>4-:-=^KM^(#NDGS>@5%]B/#NC(F.B#O>@E:7..?>F'6.ASDW%H M2]X.N7:)'DUW/MM;J.<3R>>$NNH0I]\O^\X/6^BS#NFU?B,\T$TD1>H[>0*. MGG*T[LJ2CE#!GNOX> *6;NR\CNPWLNG>A.N4WBJ?#NV8+NTMK>S67I(*20!I M^<.ZBWEMV3$K"-2HE$9U?M1R\()*K2E$_$%KXSA4U!"/X09K0:"C3$-S<",3 M?"*C7$8DM(VQ+#K>-+*M<_(; M.UA4^CUA.$B4/;R!4;Q]L<4:C[IT81=BD!2?>"2>*(9D>*,&C.>NR]S(B"UN MN%*?AA$H( )*SRI-#P*?* +SGN% ;Z]#K^%%;V_W-=F#M")\9C3]QL1R3+XL M,VOD6+TO6) M/_H=,?9E?_8__[=JC^]$7SN+W_B/3_=:S,5^C/=5H_<*0'B!J_JB;W+OML0/M?'_R8'?<] ?G%/_G([RV6CYAU-K&C4A$8A*-(/QA]YJ*H+&B< MC?X)?9!7[X'8+P(MI?X:P_XM^F=N,/Z[*.7/2O'$#(LW:DV$^A@1A9B.(.F[DN*7#$>-@-WM;C'FC M$NZ8-&&XUGF;X&;.G"-8CF%3A\Q$$00?1BSC HV(SSH%EL$#4HZ;S"#LA.$8 M1@P;MS9Q*IA=FR\3*T&8#/SMQ@X+/&QTL]F1DSA0 M,R (-F_&X-;-VS=PSPJZAZ&#%<3QY"^Y;S7#8LT7OVZ4<<=X\M>'W*C18& M7BQ4=)%XL)G'DGQNC#$1>YBY!X(;=;0A!EQK%28'"'1 !(*">(%PPA!L+#C' M"<&!9IH9+$W41!%33!'$$3@F($,"YK'A5TUOF &"1'B%<<9[PHTP8XT@)(&< M%%,DD, ,0 HD9'<4&3DA'8%9F-MN&?ZV84I,RE@&C0&",,24529 0Y8@>&3' MB7N!R1)++J&X%H:]_;86?$ZN">4454!1A!1#,!%$C@G40.=,+-5&XALDF@@3 M'):UF"*A3[8I91",.D&%E3;0R:&'<'5YHJ=K?1GFA60&FJ8"A;(YT:A24/$$ M%K?CABD7VY0:&8@+HWJ'#E"91LJ\S*6B&M[0E*F&$E3N2G MBBRZ"".HAK;9Z*.0#)"$%D4D8$.$ HEXQVXBF:8@2O3M-6U.1CPAQ16D$F%? M=G4*)D<;6&R(Q]+%(81SIUAQ*3E0L M"(%1=-"#,2H W<@H5,3"''FTD4).(%2LG,TXMS'>'CQ#0@""1S;,PFASL ' MQPJ 8'20;[RQQKVTTCJBBCCN:8PLX*)* V"G#L#?=7?N\&. LWYK@C MCG8_/9+C8Y A!^.'BX5V&D:B@ +#+KVMWN=P' Z""2:<*#GJ1_7P=M!'$9UX M G!LA@;=:MB]P@K0[7;&&'E+Z"Q<-9WP%AMFP&A\AQ[5!)^5T$G'N>>G-VSW MU +%_;7));XATO4)%"\3&WELG(#4!2AOA]4JFRA1^><+9Z5B=-1AVWCO,UH? M8(,V\R )95V#3$T*@YC\%8T T(%+23XG LB0#PWFPUJF_+(U!)9!!#?+&<1R M,D#RQ*8A'B$#V4;$$#'4(0ULR A+"(,8C.B%+\Y+80M6>"[A$"2%*WQ83G2' M-J0!+6 ,;-O; M!YJ'32+16@ZA!R,'821F:%M<1;C('#ODK2)W/,CV/E>1T"6.=&O[2!XX513) M];%V;WN"$)10A"%0 7$!), 9C(4I-'[A?A@DPWC0%D$Y3! %%326UTJ&2?.! M$'=0LV0IR: #,T*Q)EJ;8M?&%9@TFFB-T7.91=Z81:,QS7%]^UOJEU-;;$\&15GJ+5Q&6:% M?CJ;T1:7-Z:ULVW A-S?F,8":!+N45/PH^(,P[AXTF>>3*RM@%]&'(O(E(@2![JS4NSG\KH]Y&U[QY'"\Y ED0LQ3 MT?-R.;UB6D]_Z8L.;A+Z.=KE#7R/@Z7]OI+)F&&O1>MK'\0"&+^3-H=^4N1I M!M''/_^Y 8!H*R$W93D1!7ZK@7 T6B<_&A&.I Q:EHMRX+ M1-+#HJVIMEG;2D>H@+.:QR#C8HCXRADV9K6LL'=%&&9AM=>^'@UA@'V@8-_6 MQ3 4UK&)]11C'4;9QW[%J6N+V]PF2UG+"L0@'GW#'=@:W.%J35O0JI6T7/79 ME_%2.'@M;FD?^-?]L, ,<&#,$IMV&R1ILU)'"@,>TL""-#@1I^(3;"W'1R,S M44IA627 :I=#6.<:MK;KS.Z(WG:ZC93!>'-X& A^0%_7SD0.]P6!#G(JG3J4 M 07;Z[(GB"??NR%A'@-\8J=D,,(&S=&\OAQ]"9<7<^9V06@-!- M8>.@CRTL8XX(>7)&1G(,X:)B&^L7Q8@E@'F"K-.)>#A6S@+3ML;4+742H+O MH2D*@BDY>O(JGS]N@WC3X$^_C<&8=IZ2KX#%A!2L( ;:7!R?WR:#O/&9!V_3 M\WA#NH(TY$XL20[/DKV,XYY-&=-59LF05X<".,^!F5D&8*9IS&3].MEQGTY< MDJT\9#I_;J7E1?675;UE.70YU6(Q]1Y+C:93:_.L3P0!9/G"XAW#>-F2/;%9 MZ?6J V7(6-0S'PF4C)KZQ)FR)T(?$9C[>F&N;K0.Z^8!9+M_X*$91M:*VAA M/-_6OE;+VGN;M5^+ZV#^V;"XYM6@DU-A N)T9.,[P5SK*LZNP7AF*41!]C+3 MG__,P=J]I?9HYLK6/=$G,VG0 [?C/=P70Q=A&[^X@,Q=1-1:-W)R:-H8V-.T M%7[W(QM2MWG2:]WQP;QI)Z(YRT#VDIB4[5/"T>)^!NM:^\*6 #]G>L:>/O/= MN&UM;? O@ 5,X-9._2@+=D(2"AU8H^\7ZUHG:8"/TG4VU'>7"5YP8;6,X<:" M.=GMWO;XQA4M,\'Y/$,2<4=_-QEG29PYM0%E"4H@S2GX>&D^R4/& ESUF+- M[(5NES:YF?=WX-+X3YXJ^!60&E$ADSO*4W I9\"92Y9,% M&6/.&4IT>.D8.@8_?@M(?N/28_8^,\R$@=-\\K#@?X68U3-^ZID9@YM)^X&# M/SX;[G[P8BG&YVF>U=!%PG?EFFGRXQ\?.L-&[]C?VKIWACS&AA1@6T/8["RX M,S-_7O P"Q_F1 8]M _&%/C7+ JIF,$28 %5) % MBI(";M!_:,,7*T!B__1O]\" !AP14AH+.B",(@",DB#-E@$ M.-A_W 1M6N-MYN1L26,,#8&V5=X 19A109@5AAFYF$=1/=Y*1)Z"4,5 MI7=Z=Y &)0)^S\(M&?@O899ZCF-MK8"[R> M4%?284_J"=3JK<<@%@A@OA0+% L!LA,LE@& MSZ&1/^9K+=(YI^-J,[=*VI>0"8AK_YA/FO= GL-\P*>+6-AA7/A 7SA9TR:& M O&,9 !S;(6,(](R%XB.\,$$3S $^&&4 $A/[($X/8,T[G0B:+ ;-L$>0_.) M_#@Y\<>-AZ>4*'"5,CF6@<:0-UE9U&:4IL@01@EOD+@R)6-R.0&54JD<@2= F-=NF:> EB2+>748D?2*.4H1F8WL,SA>F<9_"8+8^@1(QN>9U_0Y[GE1M",Z M7GA;D=62C&&:15D6Z:%WW;96D%@]<@ 5@+07$W$O%W<""[2!#A1FVN@[1>$O M((EY#2E?"5B>.#)0. )YAB>2#[.651E0'7J>NSD /*F?S*8I8"1&&]*)K\FB M:S,3(QF&'>-O.*=9492%':(LKM*4Y@<<;&B<],B7^ %>.FI8] 1SA*F5;>-H M. =SU.E7*/<1W^50_]9G -4T3GI1F <"?, '(! "+FB _Z9/6[41H"0&SS@F MI#$1:B.D;88GB$$'()2FVO2%*% I*1 W3M@A1?$1_=>;%R-Y@<<0>L:+\':H MS*6)+X6.1N6. MF"$D(B=X%(JA>2-;CH-YJ8IWD<=>I,J#U1" M:,--82 3*:1^%[$7(M&K#_2KW"BLH$JLH&JL]XJL":"LG-.LDJ.IS"2K8D&M MBV6M<+"29'"II2JN -2MF/D5X;JM $2N\6:N88:N^=D_^VFC!TA"U :"+?&. M#(%&XZ-[[^A9D'I7R:DTJCE^H1.(I68H"*8K06#.%QK1IRF/FB\ 0?P*6U:R>J MJNJ;6>.3<*=L6[%M(B&U6\N9W@@]/1.*:"D"4U $3& $L88V_L%Q<$N:(I $ M4^ $17 %L;9A/6HB.E:VZU4N*:*V<.I@](@VH.6#M7F6?*M(C.1(/A:+8>-/ MDWN;>2@"C9>Y0]DQT/$&'L=6H-61-K07S<*J(*<'\W%#R@8>]-$F\%&Z'J>' MIX4?07.K.-5Y%:@BA_L@;?23_IB >:Y%+1XH3NPT?J]?Q.^O**"5-"$:?""@@J% M,UB#-^A,[(M-<">^O6*$3""_]-L&,7B_4Y@"^JM-?^DPX=NW?QNX("0");"\ MCM0"?@NX@OMC"PP\#^)DH>MD$[Q(S-L"Z:O T!B:#3P%2/ $@@O"%$P%+:#" M+.R\VQ2VP)MPBOLBW_9YMXH%LXCJ>Y(1:]TSMVUHB3B9P #QE=(*4US(B-A!?5 E05-RW*6@J6"PA[+$A/]HJ->#%4@S& M#"*WB1)-0CQE9NR56PP"-,#&1^G&30.Z<%+&)W7&=SP#>CS%;WQG@-P7@IS& M(R(#A!)7(6LS(2!%?_P?)96FAYJMXC#?'S$2>L.*_-JFB8FG(3?.^ M*SAS@4K ]BN%-RA-U\O$^XM,HVS%3,C*\_N$48B_5"C+2TR%M $4W % MBP+-VSS.Y7S._CD2\_$0>Q=E'X$I)^!AZ7<"?M)#8CDWX0O%)3@W?K)$+A*& M&@ :"%A34%))3E0N0P!+ %T7# (Q(;N1ZS=AH PO5(# ,P>.G#1NZ+@8 M Z+%P#ECT)1I4P:$081T0,AY4X<.PHHJ7C10$##!D#=P\AP\@R8CBC$I0,3( M@0,'"Q!B\H @$L9.&C(@FJ2)&*8,&Q!"RM#1,S)!$#9'I:1A26<.""EEYI21 M8Z<,F:90MK9),V=.FC=N0) %<49.F(1>09AY(P=$'3=RLM(Y.(9.7#=H6XQY MTX:BG#%IPARMHS5!R)$C1R !G.[MZ_@RL8&1!$Z3&H5;-V M#5OV'#IA/#(D6E=,'3-;9," T44Y:(-Q(: ,314&VUO@9">05F9A18(=Z1Q7!QUO.&1&V?$)I(" M>*QXD!LQH#"C'"Q8^%H*(X$ PGWYR8B'04VF\9IR>T0)"0$"TH&"D_XMR0(5 M4E11! LPI*!<'Z$U5Z2 ##D4)@@Q+EGC66GEN!M'&?'H(T)!RC;GD6,H>263 M9$*I@)14ZF:18I+)@IE&Y#?%FFV^&:= 1:YWD8OKC=6>7_M)!,(8 M=4BH'!TA"<(UQU9Z)#8ANOK7O_M%>R4PS*[UPZOHK%:;.$:"\*7 M=Z"A944HJ!"NHPE@NVRS_NZUP@K3*E#M>;5FY!!&$:)VYT8=X2H;$T\,4668 MYS)I1[-9C>%A&&>P4-QNZT9*++H?OZL6K2&/7/+):-C[)6VWE9';;O^EH8=_ M:2AW+P$JN]&L&_2A.'1S=[JA9:['$I"&&2"@T')=/?CF1!),Q-2E @&OV)&Y M[C(I @HIB)!P GG1$:L;0G^Y<-3-;3;&&JDIUM]^>< !TI!#S^%G1%4GU'<9 M5O^:@M>6-@C"%%4((84.C8>A%0A80"XYY6 /W6U5==S6,0LB3!&Z'"*P[8+D R0]MH)N%Y\YW+?CJS8 M= R,[@DH2!O\\#KKQIOU^_O27.J" J-IRS=7@YMA3WL;W,W!.EB;$**A@LTC0+GVLCOT#4!MP4NA^V)8K>8A M@&-E8P%TY%! Q6T*(C(SF?1$& /V8;" ]$'.&,C PP4NKBDI/.)@W% 0)%(0 M8.D3V.A. +]07%H1KGCSP]%Q@:2"7%Z M*RAB\-(WPR_&#WX$J.'0M)A#:7D1D'V,FN.L4(0A4.$)M@/D"GF80Q&, 5M M!.0 JY8&Y,#@)F;Y&7+.H)10(@YX:@$!#\#E,P>!X&!I0.$1.]E $+1)19^S M'Y.X>$@+PA%=I/3+:RB2D,2A*Y9S#"+-\LBZ/Z:0D,TR9#,)D,BA.>X)0E!" M(ZG /-QAAPYMV-T3Q*"&,O3E=XH+(#6)%SO'32$+31#"$YC0S2^1+P_AS&$P MPT4H% 03#NVAB#&!E8)DUO$,TZSFEQP'!2D\H0E)^%0]I?:\?QKD#8E:'0AJ MN;6N0?%SVSRRI1OZNLL2K5?">YC'D1>5;!'B]Y5.AM%8*0W^3%]:65 M+ )$PN"WFFYDIF1XJNK2>=[Z+C2M17""%?X;W@"[P2<;<0,QR[O@E#:XLMHU MPE#7"TCPBA2-1L@+3CNLTP]G-VJ7,4,8ZL &.E#XQ&:+Z1OF*T,'!Y):H[*( M2\&YK8Y\#D]IR0YAH(8QC>G'Q*/#3LE4PX:4M:M8\9J7"J0,+Y51V68$* BF MS( "[YB!="/@00FL,H+42=E-N#PN)9MEYH0%+DQD-C,+@F"$)E!!=8J!\W1S M6.?8P7:7/CCDW)C67BIBAU8.X9:WPO JM%SG+1FY6,8VUNA+%S.'4OX//@TZ MW"BQJTIE@Q=W8A-J?^$37K01[AG /.AFO3EV]\2QJ-M :H2*REJ,KBZ0BDR' M(U.:G\/6M).%+.PSC.Y?IE99JK-=,)2V+@AI5460/2Y+Y6M?52.<;ZQ],$[E#4>I][VA=L'G$6Z5,*#!]?C AWCUQC?/X@(7.>[QK'6Q MW15,=RZWR 613U-P.B+<2TX(@C':MR+/@L$,9G "YCU3W5LL0R][#&) .NY9 MT?*YRI6UQ6BQCW\O3N'1N2"'GOM1A4 O9-6?_J5$2CVMSZ*#U<6W]/IM4>Q< M7V?1OWZYD(^=[3AOM]+GM_(<1B3M7A]:C&=Q)@P P)CJ)L3E<%G\]&EZRMC&HLK]K:L(89$ ^*;5II.S1+$XC= M\+;),)7>3V*5]X#])A_ .:]J(=A]S9M2:W3]*WAM>UOLYI9\$'A;1O;F#>6W M K6A'3&85.X/"@ 4I@;%Q.0'2M""[+]]L/W[-54S<\A!< BS42#'!3 @+8BE M>F11!W#@-SQT=R#P _L!<0IR5Q*H _%B9W\$1L]5$6/T?_PB@ ,7+@5G@%V$ M@ J(>777+&11&G> @31'@8#G@! XHZ'5+?Q F9 MA-4V)$UF>T@8979$9;RG']/V>UQV:OKQ92/Q-6"D'A&B5E7@!$10!$8@%W>! M'6*P!>5A*6*&$7GV'6BF9E:Q9C[@9G9D!F78&EL03&]@!D>H%%83:%W@ F9 M!E\04&7 @5A'/BQ$:-^1,#[(;)3Q!DB5%T*8$906B9.(>@JPA$_&59+H5:#V MA($6;5?F,E1(,ETV+%BH %IH3^VU6J%8,L%$6W]898[8>J]8$9$6;Y98:9=A M?N1D3IFFA)O6B?7C7DXX9:/X*%:X,M=&;:R&BLVXBJU(-,-BB+%S1(8X2DIA M%)Q13%3& D5406N8$&UX9I8$AR @AW0HBZ6$7$#B3TH!4&$@4(:8 ND3/-W' M)(7&@Y9R>:$U9+H6:E#X:PSS.7QE5W6QBXW7BPG)?K5GC \Y9^CB!E'HC/"R M5EA !5D !47P>& F;1K"C700?XA3(1<"(HA8CG1PCBPP?_!X!G P)AH2$Q0X M)6(9.;7%ZB1$ZQB MDDQ6C,P6>*-CD:38>RY#&W"3A6J(9V7FAB)0 CJW8RQ0E*EWE!3)CTH)9,#V M@XI5&GSUE)0&671UE"-)G4/CYV=%W$/*EI22TW!7!@;SBU-CRU=S1F8TUAF66)CL[) M!24P!JFS@V"3FJMIG44W-#TX$AH &@A84U)%040N0P 2P!=91 ",2J[/+ ME]8D ,+U2 P#-'3IDP9%R, =%BX)PQ:,JT*0,BC1LX=>B D/,FH\4R-% 0< $0][ R2,GS1DT&E&,20$B1@X<.%B $),'!)$P=M*0 =$D#<0P9=B M$%*&CIZ2"8*P42K%)2,'1!TW!N?0:3D&[E W:%N,>=-FHIPQ:<(HK3.G3(*1)4N.L#B&31TR%$40 MA"BQC LT(B*;%%@&#UPY;A2#L!.F91@Q;$"*)*F@].FT3*P$80)B;YTR.T0' M!&%[:VJE'#VZD0VYMFGC(,ATA$TQ#)TW9E"D".[\-H@D5+) *<*]Y/"Y;"#(T'T( M@> 6<7C D9=9:,U6DD4:P8@@"F; L1<+<+#&1@HE@0 "AG(9*0<+*B2I&'=[ M- D) 4"" %%Y"H"PY7"D8830&P@DH MG* #5&(24*62@=*8WWYZ&;K7=J1N:1 ==:#6)Q525%$$K)MV2M$)*8@:*P$P MFA'&GBB(,!:*;(0Q1EPMO:01'*V5X88(O"; J:JIJ@FHX8(%E MN#JE"%%4\00516#+70*ESEIK6BC@JFNVV_X*!KCT;CFN4N4Z>*Z!11[);A5! M3)%$N^_&FVV]3=U[:ZZ[SMOOIRP +*Z5!*OZA8)M,)BP'!/+6K&M^6+,KZ^? MBN"QP""GJJ&(%I5X=T=08ZK* Z=,T MHYKTB1%.V/2A>&\=-;Y 9]M'V#[C:\1N4P2MP.$*F">0AJQJU)",88!0N9U, M/#&$?5!2SI^ZCSH)Y:<: M";H[$[#CJ2>??EHJ**%ND)[HHHT^&NFDE0+Z9Z9"5WUUVUIKV/5;I =.]D%F M9\]ML-Q#;3$*<*BD7;9HAZ$VV\/"3>+<==\];!IF]!F"D/BIFPF4A"BH)*!8 MQZJ0".Y2FJ7Y!02,,H*\]M<_%.A-4##RVE:2Y0)L80]2">!?GU@7/.'Q3GI: M0R"RE$46.#3K6>PIT 1!Z#TRR*%N),Q6 A+7I_;!X7V!@YS6DN(I324@ 7KS M$EKF8$'%L&!X.A0A"G*X$10D)[(QV'!&,J)#FOQ8%^S8*#H%>B"U MTE 7^GC./C6\X L TGD(/\8P-W M%!\[Q:Z"_XM1 " R1^#OF]F%R'.&X8BB'WLQR: M./)S&>(:0-%Y*$N>3DJ7]*%8SD5BGG@:"=$02!"4S T9.& MDPMN&">D2"E%=D+/40.QS/U*.DG]/"U\PVKC&[55-?0-*XG+ MN4-4;[A5GJ%GA,!+E0_]4Y%4P8"M:0 !#S1G+;:N8 5IT,D9!45(8=*A@" $ M8U(Z SXEA=5NK7$MH@+'PR8NZ6QE2-O:TOTRZ'T,G!)'(Q\?/O$$P9.BE24 S"Q2,(M_G987AQ44\3H6YZM=C57&M9I MMRJ^LLTKCL65)QVI>T=>-DJ/0"ULR01:H\S=Y6 46>:!"027%C#+*#G#D8Y MPJ-I+O61O F=1!DJ0%*%# D%@R,PA>"BKI' K'PJZJCX985)B 83:4+H/ M6U4.;)632.:,54]6U:Q9A24 $2) Z$)%NKKLKW7_Z\LMV8XQN=,N$VT+Q483 M (SLE30*,OB6#&UNRD#F;8PA1PU80@8&$% M,>C"6/\,<(B]O6$YFA^EA&%E[[^H;E M-@,+:KDD$/P ODK104XUB&]S\S/ K=Y+A!OBY>H,2N'V9'.&W9SP$>FLHAZ^ MZ%67W4D]YUO:U+8VMK4=-E&&%4RE&@Y)!U5LI:0&U]3^QF"'MY3\ M>;.E)48I#(]U==)B'<(\O#5TB##U $6T$W .PW;NNXK^?FP[*UL!(W9TL^OR M<:MC?>0LR+<,0'YUD<^ Y*'<:-BWQ-?JX1SLR.2YS^^:>0(,+00 DV*X6UXW MO!/]E7T2T1C:\,-\LT $0,-6H&R.PM[ZI@P\2Z\4A4]\%!A?!(MC0N.4WV(8 M-%_&?5HK>MG@J>GO9?C%A_;QG5 %)C"!^\PW8&_%[S8"(-F *!H1';(C^N./ M( 0E, 5#_IMD+LUA?NUG(V8@:G\2G_ M%W39HEBD-#1]9W" 14'!=W[5=WU. M4 17 &19"'\@X'T&Q'3=$E.!(WT51'WIIV\BX&-!, 02LWQ?B$)B^"EE2'X4 M87YRL%4*: 8TX0,U$5VQ(0<<<4/358$/]&YAH(%U0C0C&'1V4W<0=W<&=U]0 MX44)0&K#H1YS$%,]R')$R 8ZL7)@%H-SLH'-H34F&'M/AUB0TEMT)R?78VE# M$RK'Q4X(5@2$/1 M^'S19X<5<896F(;')T'?%'\,"8[T-T1V:$ 9)(A258AV1"=#@8B*6!>--X!T M9W=[V( 0V)'U]Y&#F$O\19*DZ"P;F(@;F)*/"(LCM8^O0FKS H)7IFH(1XP( MX2$$-A2[UFMB4"<6X79^9P9I "U)B0>/)VP4AY0=4HUQ1HUUIG%X5A$;18U] M9@1)@ 7A,1X 1U.JUU%[MW9"V(+O]G(4$7,$,'-)A )HJ9;BL2LWEV(_R5.' M\CQY900JQ5)D,6?7,W0#*28(($5D\8-WL$&80A-,=QUU !.),B8!%*(A31X1*4HI)V (N763P(D$2H,CE7"0(K,)=T M,)JEZ5-BIW9C(A!S !1AEB:*=9,SZ$K%%3= .24^94IL9S&C:&]/28.=Y(IV M0)5X8&_M=7![-QRA>97":3E-=R8'U1AWV#^9(R(@,Z$&/@:"D^$$YHEY@MQ0/A% / MLHN>@@,/ZHJ ,J&?4J$K=:'A= ,;6CLP4XX?&HT22J&.5Z*6@J&?D@,IVG$K M:@,M"HXA):(G0*(L-:/A9*.E PD5P =\\'H^&@0Q&J2 0J,G8 3 8FE8!E0D M=9\-H5U=(0<]2'@/D0:A-1B8T1M+:)^RJ1$21Y8:<:5G>CT#^I9]!J*B-:2. M]V^6TA _ZG@"=Z>?PJ2^61/>QQVK!ISOUA K-VL8:)?[R1M=\H_C-B5X1U7V M@3JD*!+YUF6MW&79VU:1W;0M@5=MP)F-W5S0)F6J5S^1J:;V9E_M:?*14IEERK= M@G8H=YR#HIPNV)SR^9QXJ8^$>23$J3+@^'$P\'5 QP5H1YY\5&].62=9&GL1 MB29D\7 6IQ:'I)UUDJ;]N8GI>D,B@B0$9$EZI@(BPE90,C"8NE%D (K200A&C9PD"H!&QTAD["I\DS MYA(65G(55"5P> (KX'A(^K OVP(P!@>G1;("<8(GZW:12&;]DY[S(:H$(%? M"J!5P8K"RE;N[%=&[.!FZ2&^RDVFZMC M*QJ0>[>Z!J\19DA"RX1I2Q9LZ[8$ +?1(;(IY!Y@16@ (&+)1%V9W16#B""E3,,R,S?%FC M2)5RX%: X08M\"9N$">;-Y_^&K7>AK_9J\;]:IMX*8>)DIQ>K[\ M42?_"K&'_&V+&<;I8(G_1 MF+V. Z'K \,M+'=]XLSDJ0$:"%A34UE-+D, !+ %V&! ZQ"(4X/QY@< M PO5(# ,V=.GC8NQH!H <)@&S%OV(! $\8-&39IW)P!(>=-'3H9R\P!H>)% M P4!$PQY R>/G#1GT- !@6),"A QB"(F9I[-SX448=TO $"'6AH!IQP80!%G8UACHD"D1(J0*&% M=JE 9(Q'VDAG'BPXE".-+*X%WI''G?'4FW%66(<<>GGX6W"8UNF>191J1M$< M:'28&1[(V04G6PY!)!%U.A)P:(]M/:5D'4S.V6D>7,::!JVCHK&GA@3;&&FN9D::K:XVTF%YAD %41F_&-EMM1])E5Y-MT"II7+,=YB$* MA[*0QG=I"&C.1!M!+FQAPU17F0J\,>EL+ 3S'UF9GL[NKNQT="Z+2Z M=$0]G+N)>KSHS^72ZS"^(,=Z',8:API"RBNWNB:L-**M&DUDG^1E>*7]J#!W M"]7Z8:6WRBGM>]NQU!6!/>/)QMXLD+1Z8;,#Q4>E]ZSX3X=P=#E3@ MOWF(1AIR?+TO37!\;Y>/ MHVL7_>F7YZM I>S$<8888!N/@M*]DHC4XY)!2$]-E"/>S3:W-?$ M13YS/06 9LD:V2HDG>ZXS@0FH.'0NE.O*44.7J&CE[UJ,L3(06( ^N(7_7QX MDQ[X:(3ON]A3TD9$)NJ/ )ZCB>QHY\ O320,I.I;L-#D-HD0J2$&TTC/&A6L M?LF!!4"27(4H$JB"A>\D,O)9H]*PPKK0Y%<3XY *[,BAB@'RCR#@ 0] ((.; D> %#?%G!"L0'@A+X"$A?RR(*?K5(&*AN(;^"W;NZJ - !H end  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Aug 89 22:50:26 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa23743; 30 Aug 89 22:46 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 30 Aug 89 17:23:55 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: 30 Aug 89 03:03:19 GMT From: jdm Organization: Hodge Computer Research Corporation Subject: Xschsrc.arc (Part 1 of 3) Message-Id: <21725@hodge.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu begin 666 xschsrc.arc M&@A-04M%1DE,10 1="P$ ",2/B MC1@U( R26=BFX<.(<\S0"2/&(D2#:=J$.2J:Q&BFCIL8/HNZD>%3)!TT+F&V^4FGCADS'F'"#*A$ M1D&4;M+<'&IPS!NA%T':S*H YA C3((,G#1AQ+ A"<(D M2JY>P3:U$H1)Q2]UW(CYZ(8,"SIRZI39\;;K5S<@C"1A,E4%'3-P""N >QB$ M2#I;Y8!](QFE5C9OQH@E:Q:M6K9N%1@,$Y)A4+,@V(A!N,4I5*E=)*]N;=D- M9C9P)M9^&K5(;I2[.?;^+1(F'MUT6"N_''L,7SK0I3.D#GQBFI!OW&3G#=K- M&1!RYI0I0P9$#Q QF'3.*M"[F^\->W]'RR:-GIBIV?<="F*$X<9(^)5D>RP("0%PG.6;&2B(4,(<7+@A @L1(IB"9"!C GU@I=5$2Z4Q!QKYM52&@2#4 0<(8I1AQAMR MQ%3E06")=!X=;X! AU @O'&1'-*95U$>!@W5UDD*$"F2D6B@H* "%0(I9'WJ M:49E?AE2Q^17'CU(5$%AG $@FQ,!2B4*!)TQ)X,.MM4HA3CVN6&'BLJA P@? MACABHR>B%&1*](4Y!YE]Y7=E'7*%@9Z!$K4!@AMUM!'E@U'2<<=ZB,$ JRS MMA##FBA1-Q&J9*#@QJ/+S4JI BGF&-YY:\0P7[1:M1'&&C'-P6I,NX(@D1LG M8&8H9@;5,<8:OV+VGT?$0GNA1B"@D-YZ[?7@(Q,IH*<>>R_&=^V%6HEU!I7? MH2%K=-PB9H9'LA(AAPL@$/&&&&)0I,1'8(G% @A.O&''4+?"EP,.-7P,1Z$Q MY3!L:M%6^^*] +\ GPPW0#+ #/+A2"\*]OZ;+WPVX ###78)%#2^^J010N2C>H;G7JOGM_FO4(ID5AZBIT%Z:J8W-A'SF ]?!NRR M&[]@@VC 9KOKW^<>/N\71BI&\5O$ ,-Q\A)@D!QCP)$'@<6#/_L.%0&,:.C MO_"Q0 1B$$'D>HR0JWO$DD[Q23:0EB4H2:-0#O=$=JEB^,14&U8," MR# K>VV!#/L(4+AZF6&$92@A'"8HJCN9RBML&(M#SN4E,(V!554*H0=!$!P6 M@0<#&-42%*ZL3 W[D0AVQP(O)L.)%_LD) PLN .0G'#&,0'K<1 ,861BE&.=#2#'1.I1^-M<7)X8AD=&++#O4'/06$80UQ$![&__>IS MH1MB:MRHR3$X<7PH5($4Z82C1I[+E2:\I/),%08X@(231 3))\M')E'FC4NF M]%Q&4FF]#RJ E;[<) J"P@(3CH\Z00%@+&=)Q0LU,IJNI&8N*UR(G1 9RE!$D6(&;X",':.$F;S,D/C=N2;%K1@3F +J.%D0YO^](4K*UA!%R*' M(ZVH$S$BB69L1.+,:#UUJ]>Q$0 !"-8YW.$[0:E78-^#AZ'VJTX)$ T'3\ % M.9Q !U]+ %G-L 4=72>M77@18\DEF00D \;9:QC3P0"T*ITLR<@[8K6J-?( M_NPQ'U6 9^VZ)Q28U3EZG>M9\< UR_((@&F]+5? JK/4;72RE:41'KKP%Q-V M5K+*S:UON]J"YS82N<+% V8CEUC/Q82Q,)#?8[^FV.]R(08WN,%X99N GTV7 M#H>-;+3>Z]7G1@N/S6R<&H\( A_$IHB5Y2H=U@H"Q.K,M-($KWA)BV!7G@ $ MJ05@@U&@8!A$^&LZ6^T1ZRO?"XW*LQ].@!BJM*W.EA?"7(#!#&2P7L_BP0PN M.9*A7A"4;@KE+"4 &Q;U:5[!XB<\'(Q!V M1 J,X0%$:\(/OK!L==8'$."7="@([G[1C!@IWX"["8@6$SEHX %,."BJ'71X MTJIF H1XO@*F=&1#O.B8(#;1%WIQC..$Z&CY%;!(XFB69]L^[Z+8*C-X[&=] M+*:UC"R+)TK 4L,#F#>PH04,20VK"7!B\!Y-UGC0T5H,Y*09ZUH@UO&-1WY] M'F&#FMBN!F]5D&U9WXA$,,[>M;1]W8(G63M:Q4[QBF7=R!OG> ?/;A"OI]T" M/<1KV#ON\8\]VTA(5SK$'QY5!2E'!X4Z1*XU+29$NS1&+WVEIV'Y*:(,LE%( M@Q0S83[IV\C75-'M*=J]'HM5OU(2-D7K@D)9UXRQLO&/%%R8#1_Y@[!J5*UR MM,TH)M>J\=S8")" QOQB=0"OM:9LC:M2:L)6EQ:< XSK<*3\S+WN M#>>I3WLC5RY/=>83OSNI_UF_[)I9P&8F>FM=&G>FKBM)*7?JQ^?M:_+9M)T4 M(0.KM+05/& $)(2.%\J;*B?"1^NH1Q[VNGWF2J(;WT[BXVQ3!@ ML0[B#7)ZB^'>=Q;\RF5[9]F0.(XB$((4BA"$)8QH#GC1"U_(P-UHC7A):S!Q MMG$?Z]V+.^3 !GZHA5_]4-,:#K9FXO"O??T2DW?[N:>!K+]/;\P(^\XBF=+Z MK7]\[=\^]]W'>Y3W:R7W-?>%!OF% GC0>G(" B'@9KD7 ZD569W%?]C760)G M0WB0?UT"1FCP!G?0&T^E+?SE(KU';O;')LG!$!OH!OI'5,J3=(8A%]3A@E7R M/6X*27@ M%R!P!$/0(&+!!G- A59(!6\PA%3(!NW1!2-B@!=B@^O! CFX@USX%V$H%@MT M(8 23??3A&80.:DQ< (A:G2') XA>#T4$W$E3&85$WZ7-\"R&G) 4[-2!B%X MB/&R@J5%?J9W(40R:L-W0J'4Z64=P^W=W_U)2ZW M%4'1):E!B=0ABM($@RA58P1"$RAP RP [_8+U)694;P;@:U2PVV4(XHI=( &+ BS; M0$ Z#8AZT'>1UW5PEW4X"''-0X M'2&T@)%7>AKG3;JXC1.! MU(C$80C% &(WA0C.%86B(A!GG@%:JR).TA40,9 M$SEE2H6(&<'1B/'"!'1A%RTHD%X!CT5%'0])!V[ &3@BD75!&D2((V4Q%H3% M!F<0!AN!!W^! HAS+BO9DB4YAP20;&S@.=$A!V>PB?+80()E M!S=9*T"C&%A !5D !460 G&% AO9D2F@,^1T4'C@I&;DY*[52,L#2C9W+BSR'X)I!_WR@""0 X\" M"0B0;)G2(2Q!)54B2F2!$1@:&YAS!E\R(JZIDS_#HOX10RX'HP[X'C3Z-3BJ M)QDJ CMJ1CY*H@]BHD2*!B/2I&Q5/Y_Q!F'0'DL26,AIGZ@(3^CI!G*EI8-S M(?P) N?"1$-Q1B\:C*GG!LWI GC@ F' 6S.YDG!@F7(( C] H(-9F(>)H(>Z M*>"HF"9)IWMCIT3A&WD: TC*I]=9$W\J!H+J0H99J#F)J(H*7XR*DX\*(SHY MIW6Z%I=*0-LI YO:IW\Z!J%:0J-JJ&S0+XDJF*A*F0?*J_T"J:VZF)2*0W>* MJ=LY [7:J7[J F20JX1*K*8*K(0IK(UJK<8JJ2_RJLLJJV[@G33PK,D9K2P2 MF-5:JK]:H)59JMU*DL@*KK&:IS5@KIXJK:$SJ+O*KJ>:K0:ZK?#*JM[Z'O2* MI]MI SIIG>?*%OP*6M;:KHNJK:K:JR 0K_LYKY4*JP@[KBQP:$?'L#5!!A3Q ML*1ZJ!(;K %;L<5*L/(ZJ0?+K!Z+ _@:K6, 8X6BKOV*LO^:JHBYJI'*<@0C M$'/6<+.9)K;I&[A)=G%J5+YI W@ K*%I B+1G"Q@ BYGM28@LF&Z<09!)3'1 M<%7B+3Y&$2+AC&4I3'!*&* G ; W);F76;!$O9E$^IM^?ZJ7C@MQ?2MAR+J7 K X5+MW:KN'G+G'N[ M$(^[L(!;KW [ Y>[K8>;N'C+N/DZK9!K/Z'[MA/* C10NBUYNG>[N)S;N"[ M(JTKN8$+MRDS!G-KNIF;NKF[NFG0NZ]+N;';C<)KN,7[E"+K B2AO,HJNK'K MB\^+N8A[NRDPO21KO6[+O-W) CA NTAINYJKNC:+LXZBDR!*GT0IMB2A;W,E MGS372&!ZE;MT+B/1%>ETGF#ROV77J*0$3ZX2G[JI&NNX'2'DOW AE0K,++RI M NAGGRO$F^"IH#87;1:! A8\P5F6(@@PIZ*1H2%LG]R5PO()9F2 PA=L$-SU M,R&PKG((5L67HR+ %1"M/+6!MJ2*JG!FS]!FT,!G.A&3&TQ!FU !CT@ D/P!$W0 M!$'@!$0@ JEG<[%#8D Y!W("5F@\-!QE/@![/UJB@ TJR.:QQT>7F8S(F4?7 M2%,\QGW<+_KB-XD*&()QL0TRO+4;O2D *%2)FN?"+=0S4] CR@>L4S$ARGMA M%NWQQ6EIBZ),QN;7DXNLH?VFR>G+R;;H2E4Y /P;=[-I*[Y&$0YQ1GDS$171 MPQJA',&\%UPH>@61!\+,A< Y*AH &@A53DE84U151BY# 1=6 < # 24*S8 M#@ . ,+U2 J.,F#9XY=.J8,>-B#(@6 POB 3$'3IDQ:5!!U:E6A5H(PH?B%H!B/;LBP MH".G3ID=*,M2=0/"2!(F2%70,0,'+UFI>T&$I -53M4WAE$^9?-FS-6L6[M^ M#6L2)<(P(!W6W J"C1B%6X86/=K%\.?0BMTP9@/GS9S41(T6:>V9#NB-L6>' MA(G'M6_8BTN/@4O'^&^'E-V< 2%G3IDR9$#T !ĆG FV'3,,8XGB05]/H MB=E9@?B"=%"(">-&I)P4*$& &"VGY/SZ5!FV1WZ0$ '5[*9@8(()$9:YUB.+QZ8G(Q4==0?3G/,$<89[(UE6YDYHM#&'&=8J1]_)=D2-Y:&CJ&[%\F=&1ID3(X0((1+PAAA@D*>%155>Q ((3;]AQTZ?< MY8!##0;#L69,.:S:7JZ]6P.VN**I@U>0J M5 [3K;FNS2V.CT<^N>=EI'"WEI(U^M;C?L->J1@A;96'X6D@WI[B@=GV^MBF MET&YY:GGMQ\:I&DNN?"=$P^ZVF7TR#;IP&\N/.JJ&\8ZE[:U].:+WEMW*NZZ MC^7JX)19AP)AM/)>$F'/$R#Z^N&7L3X_]OTE,/!#"99"%[U)36^";*C@ZO)F&W-1"R+6 M80R18D) QXR-,8=+H'A XD!6G<^$]V/!&Q:20A;9PTY9&(/HQC$U(UP?XV:&!T< L#HC8\_81B# M60QWK[*=:G!I*%P,;7C QCUK#!4TGOM4D,$K]6E^=Q2A]DBH)CA\A(P@,"1C M*H5&-5)E2$(*'!SEF+LVH>1\85 D'FO" O89+SDU>>(>^[A!Z$F/6YI$ 2?9 M]\76=4D,=WQ1 !F)O"0YLC_VZMKL:B>'V\VQ/>>#9?3PZ$DBCK(P&OQC!\^" M@D"R(I".C/%=*E>)OT\>,)1%7!P?D>E' M7)G2@Z@\I"K1T$G\M9)["(EE&1=YO*U@\Y&YE%>1S-*&VF$%F'7,YS"KE$QW M$@"4:% 7 9Y2DXM0"T?]F9U"S$"5@"%L@A577:(5%-'?J4.W!E*HI1H9!6.*1'#8XK M<("A54/Z4#-P:S#E5,!0P714#4V$1$]\*7&&IASF/%&F@HU*2G/5N%0B=0N) MQ4,7YL*^#^G*KQSR4&%%=%*)/D5T;-5(=1CST4?2=7Z/C:Q,:0I-5]J&#M.$ MR$YIZ<];0E* ,2&H05GUVG&B@580C1]%;3(MPX%I.;+I"%9*6YVT$:![Q,7B M6*]FI(_LE*W,=:XF:SG/Z:XK/-:M)G:O:5MMLI4N]'EK&N+Z3;J:#*\I;:P\ M.0G?UN+3#"YIT8OP6P?]GI4P[2 MI*EH"B)123%:*S6'&C]I.6T0%J3:PX2TK(7&3FH#C!VR4M!4>GR(Q3@@0UG$!R9I5.EJ!;HS&Q0"!4TI&@5^P0(4L0*$(*2B3&]Z0/[Q% MLX1Y\-2'28)CV3S2-A2Q"$8TXI >:YH-)&D/ID^]Y89J20, @(04 !H(6%-" M0T]$12Y( $79($ !T$=.F*7=W" #"]4@, S1\R8-V3*N$ #HL7 .6/0 ME&E3!L3!-G#2L"DC!X28/'0J'DP((J&9-&[2T$GSQLT<$"I>-% 0,,&0-W#R MR$ES!@T=$"C&I 1(P<.'"P\Y@%!)(R=-&1 -$D3,4P9-B"$E*&C9V:"(&RP M2N'I\Z64,G,XVBE#QBL4CFW2S)G#T@T(N2#.R GC)F14,V\ZUG$C!RV=G6/\ M@G#3LL5%BG+&I F#M4[:!#%GSAQA$F7%)U"^")%")4$"&'A@Q$@0T.->-Q%! MM 1QN$[%S HXESGIYG/HT49,HX8A@[5 ,:]CSS9#.2U,F;D[]P8!6K04X:EG M&'?--_;@@V[(J*Q+F;9]2%=L041;PWG W;I?43@F\H MB!6##D((@H1L4(B>?QE^442 PZ7PW9EN/&4'"U1U->*8>P4AA@; =GB;="E MAV%U17#H86I!A+@5"#GNV&../TDH))$5L>ABDC!6-T405A2!'0Q"A.A416%8 MU-)*;M01QDJSO7CA=-4-$0033)PYQ'9CE ="FV9\1Z===JH78X!45"&%$P02 ML5UA=-0AAUUF\-C&H" 4"MNA%2J)9VA/PF!F:_39!\()+)X PATJ,?13HDN& MYD02?1(8'*KU1<4J9:["2@=#*6%%ZZA?0%'%%$A@%P,,V\%AF:P2K=HJ"(6= M(5=('1V[WA!,/,$A?#&LUMH8A>F M&Q*GO=U!I8YI:(IEIWM1%&J8H35A11!2'$&N=JVU\<9:V)811QT%LS6H'&?4 MX>-/=+R!N9[#3T LL;[R57QQ13@=NE^0(8],F\F9HER1RF^P MW)_+,3IL;\3D&MB:&!RS$55A<_S$L\@'\Q65Q1B7?'+**R^,='5!$"$%:.3> MV!H9/,)!6[54__2&&6^S"3+6?;WD;8Q[!C%%:?I&67$8:PS];MV%?5P18R!8 MG/C5(^O=\KRA$5$$$T%D06Z:_9:A+J=P:"H7O H<3?D7$ OH[)^MA3'&&&B] MU*:6DW%YEUU\#6RE&S[O3;:3SDK:FHB5!5_Y(VZFUXHZ%4\T MX>RI LWYQJ:ALT75Y[Z'5D04SNXJD,8_@-"]>('^&_X73E3!)W8R0-M:G&&E MCT)@BQ4]U/K?<]_DI#>$)SAA"O0SET# ([GH(4M/UX&/#/BUP"")[71#,!O] M*+9 MEU0>DZ"H 1K)A 1.29((?@@LD*H0=3(P&DEW(ICV)9"Z,E+>F63%'QH M8+_LD2$J=+B#R>($&:I0"0_=FTM=&GC#%58A33M4( C<)8;#N(YD0EP,UA!S MQ"32I25,%-7+Y(<=&E"P<75@PTK@8![:9)&('#%B&9!(M2^Z1(7KB4(5GE!& M#I8D#4\A21!-AI*0G($C7:SC$O$8(R9, 8$[)"$(-C*7M^7N?>/+%6IH $,J M;6P_7GO?$:@0P4V"J#5Z\1RW+(DHZ&@ &@A84T-(14U%+D, 1=,0< $42 MYI['T_@, ,+U2 P#-G#)HR;>2D.8.&#@@48U* B)$#!PX6(,3D 4$DC)TT9$ T26,P3!DV M((24H:-'9((@;)!*6=ER#@@I9>:4D6.G#!FG4+:V23-G3IHW%\F".",GC!LZ M7D&8>2,'1!TW=,FH9PQ:<(@K:,U 4B1(D=8',.F#AF/ M(@@:1*@0C0C((P72.0@"3D:V8=KD=.MFZ\>0"D9<-M,Q:1 G3HI(22 "RY3- M$AU:V6H6+0@8+F+<^*Q 9,"U;-Z(40S"3AB58<2PR?I:I)HV<+Z(J6,&!)V3 M7[9W9;,#]/.]8<9XI+V]]!N+<.L^5F D"9,B']%A!AP].%$%$TRTUUQH()2! M1WYN4&<==MIQMY^#$(+ A!5!,#$0&V;V[EAQXAL6,>>2!AN==&&'8(P MQQ=ST$&&12S,6",9&M&1(XTV;B7'CW>)H9$;9"CHG$ MRA$A4AEMU)%5%S[H M(@C]_??1&V;15P8**2C)($46-60>:61>%"5'K76G0)I@BK2'2"! 0@",'@YV MF8)U$D"GG<]9E 9'BJ6AAT?[]7BAD!A%G+MQAJ@@II. 4L6X,>L<<*-0 R0#3+K@I0+Q>*9'C";& MAJ&TGG61GO,56Z.;?;(+0@\?EO'65LFJD(0325"11(=):%&$"M#R::>\]*)@ MY%UDP '3&Y?)],-:2ZE8QY?LRJ0#"/PRX2VE[[4%1X-R9"0'E;[:">Q+6M'Q MG4=&",*<""2!<[[URY$O%$U#\9T413!#L;Y3PPD@ZG#$($Y]1 ML6(7/QPQ"!MW?#2)(5Y$+XGVVC'OARJ.W;&""9!XZMAJT[%&S 83T =HX#:( M1QEC;,0IFA5=%-U)\*HWC.AABSKL'Y'A_&/#,;8.X @NF4E>'6Y*M;OF3K)[UN M9EYTU.&D>6^,2_S(ON]'HNMEK!>G C?WN2,<&]78LPA;K#;&&L0?#X+O77#A M1L&41N?&&2^C$'-ZS1_%0@R5NR<0UQ4AY5!><-#EDELDF^PF_6F 71OF< 9I M60H$1='/ ,^@H.C9"6PEHPL*%D@D-S"-#/%;T',@Z+_[E2%_# AC#LI%/]*V%"RA(&J06. M $*B'AVLEZPBH'!CY+.4G9)8O;U,D("/FV+)E,A$$8@OBGW*86E4\A;CK; . M"2FC<6ZE%52UI5;G:E.B!/>2%8*@<#+Z0I&.A$&;.86*2[2B"$ @B@F((ED M;-0*LR@W2HG1-/@Q7M?ZHBX0W.$@>3$>">ORAC'DK61QF2,2MUC%Z[T0#G"P M5UPL D5&(A(_*.#:73XF10(\9PR*00H07XBD$QX1EU'9)"_)<,+8B41W# +F M"4TV3%\Z1)F:1"$(FNF:_2A3F&XA)KX,Z$ D6FEX+Q,/>7(RAB_@E-3I8[$M@XUF^=".%)TBA!4BX#1'^ M(P6C<)U4% M(7.#/312",T$R3+R;YY#G$,1/9)-6\G5)A9+&N>16XAE$3GI2 M>'D)"F4_V\53IK(U06%E(3TKA[HV*J>TK)M773*=[74/B&1-7LH((-&6JBY, M%A4(1E&IO[L,RJ,Y2=VN-G+$M"YUK69MZS'E]R$ST(HZ#O&MK>1R7J1 EHA& M[*N#!F5"\])!,80U("$/JP(9XK"67-ID?C6+AT&A 'YN):]%YF(FQOH0!)<9 MSQG.8)$S@&#!=*$(1XRS'PRCP QM\%$88L"",,B@Q#,H,0WTZT(8J@#$=%!L M+0\['C-L(08P@$$76* ".,3M5(DT@\+(PP(8EYC$)D:QBADYE[J@8&3TJK'L M>GQ'>IV "S X@>P,F NT4&)8T!!CU>P@@SN+G)#G9R9:L<_-:@10MR$9NI1[K^_"I: X,!EB49'*^H;$".Y1)MJR?2H?9IOHV!@ M9@5H !H(6%-#2$5-12Y( $7;L6 !.$G*DJ),;- #"]4@, S9PR:,FW* MN$ #HL7 @@<3@B!3QDP:-VGHI'GC9@X(%2\:* B88,@;.'GDI#F#A@X(%&-2 M@(B1 P<.%B#$Y %!)(R=-&1 -$EC,$P9-B"$E*&C1V2"(&R02EG9TJ.4,G/* MR+%3AHQ3*%K;I)DS9Z,;$&-!G)$3Q@V=KB#,O)$#HHX;.5CIJ!SS-J@;CBW& MO&F34,Z8-&&0ULF: *1(D0%!S,DSYVT;R7#*'+8X9F+%BQG->G2L8 1%BV[* M@/A"I8H4(4^&?'E<^N(8-G4H@N!1F2+D21 J1!'22JWYC!D28N'/OA)$3E.+M]6$T@Q M7GEMF3=BB1ZA6&G7ARM&>?9_T9:&HOQ;?HHR D,6&%%V9( MQX9S>>@2AUS&"<*Z:9 DNQ%"#FL+2%AFM/JK& M!%5TS)$97$. (-AT:;#!HT--A'&86V_,P1!IPYEQ&@A,3#&$<*<)"H*$W":0 M(ALK4OP9J3#*2*.-"1SJ,6JJ.9'$?@F@8$>80:F0 @PG6]Q$$$,DX0053TR! MA'!EN.&;&?(*1.^/5:B,!0A34&89"%: T.^_< 3,(\-I.%P1"$E'";3061>] M9;T7Z_%69U,/5K7 =#D4A%AGG(>UUN4%H0451<@61!-)'!%$S:1BS.K&'9=6 M,<@Q'ELR1V=\/;381ZM6L!QK@'!%P&P@UH9':0/,=D,7T[%>&DQ3$6]M= MU MQ<2&?ZR:X!82+@+@JH6LN,FE!?VX=4Y&+A11?\Y!GDO]UN "#/ZJ;35= MODP^^#"3#3+UT,-+*,!?H_SK T'][NK-KW??\1[+N21!\XB.?^:B /O6Q#P7NXZ'\W$ _^\4 ?R#0'_^4B(( M#O")!=0A A4X!<=]T$5E$9)_RE,&@S&$4&,$04+:,)>=9.4,"'&2#2LF?H:@G^A-4S\6 M6I!&QO!,YIBAF(*KX?1N:+U9>K.8/(P>#RVTI&Y2\F%0DM+(E!FEVS'.G=%\ M6)OFJ452[9-*BX.6J1B5 GP24Y^2LD+T(C6I^5EHH/,SZ#?UN:J%CG-CP))H M,8OU!#^8"71;0$&70 !%T0" M DA8P 0F> D3=P,"$+AU?7&=:UW#<->\KD!!<)7K'+X0QC(4-'>2%-MB*E(' MI/Q2/ATYW0%)-=4J>%*9^A%? F@VT_*HC E[7%G+3*F?F;G311AZPUK"<)G, MB25?HOWA%*9Z,Z0FX),PL%!D/(0'7>8H0$$[@X_2>)[*9 A1>5J0'%WX0R1T M,JDYR(%R!3(9'2T*!&@(@\)Z% :2-C)(JF&8P;1S!HTE">K M;- 7Z-;*@X&$F YK$(-Z+6OBRJSA#7MJU Y T(?HC<%."G,9^SJ*,G.6T[SF-V,O*W2(LXZUO.8HO@3+=OX> MB4[BT);U>05@9N)E7;2>,^0(E@$:BTO@L)ZR0(O"%I8O]GY\AJ4T^LPH>,N" MY' &])4!#Z(C=:/<%[T?1WC4I=YQCT'LXG+ M7"(ZG'D/A][?CVN]@V##.2^?MFS+V(B71L^A42#XP4M8K ,3\]H,9;A#HP)M M,4)]F@YP."*ZZ0QDF6@[-:C^M$RZ_6,5DX%0[-97%H4-[U3'NF5<7C:IQX 3 M-0.YS>0F%;7+2.IK;S7" Q=RKL6&Z83U*(6==DFC'^T6C_SG/)26PS8[NQYE M:4G3W^.TP8():E'[.]3B^71VT\UJ*JL\7A02 MM&4N/W?,55WT1=%\ *UF0]RL>Y%_AWKGI>YYJ:F>IJ='/6YO$(,:-&-L=6,= MYIGY=-C'SA>OVUSJ88 3F70.:[0SO-1P;[T4D-^+HU/.=S!)/+)9[WR*. \T(5>>+BG0?2> MM_NG3\_+S%M,Y2?A9>H!'WN1NYY4AA?0'$Q8AMF#_C8)X_WM5:/RH-G!]XHO MM?'=[B)&FOQ$*+>8$:10!)*Q5MA#>$+XDIK3+#0!-BR3 3VQX(0J-,%",_BH M]LUO(1KD=*HZ.X*%FDKE)PA!"7EC%5&I# 7ML.H&FY1_VF$A.%!5^#$%KD$R M.1 ]Y4,%2/ $WW%&3T"&8U@A'JB#8"@$.M,=69 *MA\X38F2:@:!C,&6.$1%>>$5.86 MXI%51]0_VO,_A&A8,Y%M3Q(EY=<$(-!MA)A87T HB^8D%7=QGO$6'6(Q/78> M?^$&+8 12&$'B5$'JE%!T;(D+10]8W$N6D&([?,^AU@$\J-5BA@#^8-KEQ@9 M:(0A74$4\0%]+Y [M-7!Q ]IM(&LJA6N"A%KP4"?, '8X)ON'AK4J-]4Y!P MJH$C4=&,*)"(T+@RW!AIE6%F6N6,NP@"T3B-U3B(S[@_V1<^Y4A(Z%B(N A8 M[Y@9XK@_\?2(TDB-@LB/\?@D^/&(Y8A"=D$&]]@R&6>*N-%[U[@_DV47"BDT MY+H==ZB:B/*)!Q<+"$3?B1(/"%8>@$:R@3V#AQ5%9[ZY:.';F1^1A8 M(;D4([F%UY:/)XF&:DB&+,F+8E-D1/%\MX(7OD$@HB8LQC@ R&ACP=20X5B3 M^RB1ZSB/VQ@]7'<&4OF1@3605AE%^S-<4A!_Y=AT;-"55 F6_<@TW@=^Y2AZ M:BD3^LB6!=E_4D %Y;AV9#>7AO65UKB.]H=_0Z"7T9-WX.B55=F6_VA^Y7@M M\>&7=1F88FF0Z]<$Y7AY$C2?B:E"E%#?B 1'"6=2 &F\F1B@F;E7F"Y4@0OQF<,CF< MN;D_(*B!HFECZ:6<^$B7G4F05VF#T4EEN24668&;GEF9.]B#22 ^Y;A\B;F6 MS0D"0YB0;[ H9;0IPEF0[2B0ZPD;3V!?0> $O2@0V64>8\"'9*%&!I-IW(5A MZY&>D>4&7T @+82I72OJC,J"E6HF3:8H'+&"D:\J@5\I8;UJFY3@%WO== M"4""+J*9,-J'!%IA-'J@WY-QE36?5EI9Y9AQ1X$0L*2A:="A;)JG6Y &<$IE M>#:ICV2I=2H32"JF3,JI?"HV?,D7A3J@?]B%%I-Q[T$6CFJJ6-JIPH9GL[J3 MHXJBF3JF>05F3TIE&9<&IBAY='JIOHJG/\JI6VJL"9JLO5JJOWJJP?IG681; M?^*=>AB@AOJJ-:H:(IE;8U"K;.J@6PH'Y/JER]J@'XJMD8J30YJCU,J@%/J@ M<8IN\\JN]=J@*BJLV>HDI,E[K2JCB J(PB:K>6BN]KH>\?H6>L*P_HJO1Y@\ MNK&'WSJC"'NF2R$&@D$1$EJM=H576^JQ"TNG1MJNFHI7J4JL2S$&79JC*@NL M6PJS4\JN,\ND9 JP#VL',;N3.:S4\JK*=NOFKJG/$M/4C!< M3- FZ (C$NNX\#6X&DD' M+P"3KWNPL2NN8VLU$FL&Z9:O%B$P_/JW7T"]+9NPL^L3FI%D=IND L9*:+"E MY1N^V7NWE 6^!M&]'(MN) FT[9J33+@^^6J_)8FRF,J@^NL13UNQNP>":QY '!2S&X/X>'NA&N8^*N?B\&[PD+.S",-Q< M;F'":=#";@$Y:/))O$;7 C1AS"(YRW)FP&V^O$8L.U *;#&;RXI *X M?0O%0#S"_F7"8]"@@9N'+JH758?!\>7%W4A9>O'#;B#%,6Q=)EP96K+09S+N$Q75^*BR2G+3$Q9R0G,@YR<>:S,P-G'$XQGIQS$"_S, MT[P48N-\UE4'?$&PI$$H#]/-K.I\>\!7D$ N\N@A+(#^85&AK3#I-%7ZCR= M&SR_[BQ*6LB$.9$1@$C/=I$@&!'((-!A^36OIY, Y.P2,NP2>Y!?%^Q\,!%, M3:*CZ;S0R'S"#NK.OO@C#KJ*;M&*"F#1!(#12ZS1),+1 D$V]PK27DL:"= ' M&]S0.^ 4&"W$#IU?.,PC2_P@)$VZ(S,01;PD^1P9.TT7" W3,CW"1&W3>N'- M#)VW!:W/4MW33D'/'.4F V'%>5O41N/$()#4/KW4J>S$-3W2-[V[#ZW/6NRU M5CW2]"PF>'#&?)N'7NTOT]FU/-*W"4W6FQ=*BT9B8THC=S7,^W93BT'4+W5 M<* 74TW55N/2/"W/E9W.4&)?'T')F'S79'.]9"8M(DW2"I.%N"W*=RT@;[ & M87 0(J+9_^6UM%(G=\(E @.(P(T&PFW%_WO7HK?/7*C4,_W)@7W3D-?:D4&H MBQW7F3+,E777A%I9"4W/)BW/:K;+B_79A+I8I#W"D!?>@\W0"TS>Y)6<6?O? MYWW1_8W,=#99"RP_44;5!P):L,T\LTT C?T%V4P'=WWAFJ(H!N(6[97?=YR< M9TW/9.W"9RW33B";+* "DGO6+K)&;60>43$@ID(7GR4:"8:)L,OA5',G@_(C M[OUQDE$&< 1I3/Q&C3I8501?Y($"9"5$.Y,"*Q".3.13*: "E=7D\4T1GOL] MCDOD24ZJ66X&*'!)935$4D[E<*6+6,[D9"ZYK"L0F8!@[LWA MYW$'^DQ*\8Q(FC)":1'KIW/JG#XM.ZQ8.ML%GRWL^$T:* Y60^3B3M+>JIXI M"PW.#P+JY8'17U[DI#[KW"[L*N"X7]#JNWYJ+D'MWB[KII[.DOL1Y&X&>%$& M=_WJ\EX&JB$@2ID@%P'L'B'N#T+/[S[NDQ5GNGT2:23LH8<;'I<:32+PI\0$ M83U9P!K9U>X2S?X@,FWF4$X%TCXO#YX@-SX?U^[IX2P>XWS@I4[/NZL"#E/N M4_K99A#R\Q&SP^[N$?\2+D\&T/R@,N;@;H @\P%+)$I&H04I.$B:5\@HE(NJN$>$"=AH27XG*CV^J%?#G?7$QU: MF,NA=1_Z>#_Z/P9+L=C@^@S[(2(9>6!>E/\@:=_Z$L]I./DGJW_W[]ZX:"EC(,#6=2YR .*Z?&[[N+_\A-_\CAO:T"_]>F+GU1_: MVB_Z$M^XD!MET1\9>;(G=\ZVY<_[_F('>0O]D' X._^ "+5H,_\.=^XAZ?^ M^=7^XG\>;2W2N\_] XL7/\_^T]\I%RLTYG$6QJ>)YS&P)J_[@V_^\U^;UEVB MLL_^T]\I%RLTYG$6QJ>)YU&;UATSNC_XYC__"_SS^2_^YS'S00_A2Y)"U77, M_;_]_V\'J"?[[#_][__:H\WG9P'=DY:%_;_]_V\'W3D6O=?@[#_]=TZN74&P MU]^=8_'("K#[[YX:=T"[#<[^U89@H'B'KMO_VY_SJ>'GL,P7/\_^U89@H'B' MJ\KNN__NJ7$'FOGS[%]M" :*=TBH_;_].9\:=]"W/\_6U89@H'B'?+VJ[+[[ M[YX:=Y GY5('GO_S[%]M" :*=Y@GY5('GN\?L,RJ_;_].9\:=R#O-RO[[%]M M" :*=VA\:? G;J#I\CZE\?_NJ7$'C/3S;%UM" :*=_C6N__NN_:>X"9NLA\9 MIIF%(L!K<7&'B0]+08I$^S%DF8T$#2)4R- AQ)!U!A8\F'!APX=:4D6.G#!FK4,:V23,'XALW(-B".",GC!N/2R4UF7#BS0="@P]&6&$>*."10@(HE+A3#SU\N,87,&7GAF,@\,$'3B:"P**+ M7_PU!QTI] ="&7AX),>,4-D1QDQAB$&15QL2:21<3%@1!!,\QIC&6XZQP,:+ M/M+!0F!UE+&#D&R\,0:-2C+IY'<;_H@=4R!4>65<;NBU@W[2C01'2;]=IA=X M"JS4YQN<"O4%T1GS)=7426,HVML6R"G7Q9[2B1&&6"#<-EVB MB_[F**1XWI3IJ&8F\%RHL":X5VYUR/'770GV-=B6<*U:G4*7N0I'8'O.*I!N MFC(* AQO%*MJ<(8*I. =2R854F9+SOD6E,$5"P(9;WS181DHI, "N5^(14>Z MZY8;1QUO> 0ONR!"&,:]Y1KD1EN!E>$@O^8^%0:)*9RI@+CX3D4P10&/\?!4 MZ"C-<;AIF$"Q&&6=<1O =: "J\1ACA#4'R"O9B>5_ M%7[A&HQBJ/'1NPD+*2U=35+4*V8R;E=T11MRYQUQ#Y$Y& A[Y(;&DBC=]<6, M&NW0:F%TZ(QH&2QHO>09P;+L-=];'RE'VHV)LT86. M5%LE0A!4/-&$""S(.L 34'Q!N.&)Q\""X$5$\0/BBC/^1>6))R##Y HD(((3 M53#!Q.6=:TZZZ9&#+KH33U"!^7.JE\Y$ZX(/\8034\R^>..Z\Y[XY[D'(87O MF@]A?.>2YT[$\8G3#OSSS+LNPA3HM:"\%"%@GH#FV%.Q_?#6AZ_]\]VGWGCX M0U#ON?4K(-]X$$00T7D+Q(%*H0NR04 MH6W>T]P"GY! P?&@?TR8PA0JJ+\>]*]RM],/_JSG@_X=@0I2X& "8+"2/BBL M6@_Q#F-HI* V*.U-A'*:6>(3-3G486I5NQ1*S! VKIGI:RA0 1&_8(8QN"$% M( /!VHQ@M[BM9&YTHN+;C##$O+& B$WR&^#V(+@)4J$(F&/7O.I%-L$Q(0A- M$ (1@I#&"-2@/UF,">KS7,#&Y$3T%[%PA*Q9(])QG"'V$ MV%_&D$>X)<$^?3Q7^="3/OVPRUW62X(1"#DR,U@O>$0@I=C<0 ;K":$(1[AD M'T^6,C=LD%P0BH56:Z-6>\)T/-DN?9BO2L@(0F"["/+ M 7,(>A2@WT$4,S:XCH6*L"%0L(#&_P$J(5,AR1&L\N0\ ''[DE6,&QV4#& M>9 _400%1&HG"P93!C?8(4@* $&=K(2E?.J-G_Y4&!D#"@D"2.JBD9QXQ)\LB$$*<%I2G?)T#!G[J4I1\%*7 M0G.I+\RI=-Q5!SA8=".U,A4=+JH;!5E4+F;P5=)(VM!7D2JE>0,<#++:U*U. MI:M?[6A@\G JI@6GJ3.E0Z8Z@B[-&4$*<"P"4QL:V,':2ZET;>BAT*G1BQI4 M9L B5%/995!\LE-OY3E/>M:#TY7452"**DE2QBJ2L96J9S_3;$/=10>8H !G M91!;2'CFL\%0]:J+U>E=CX03:,$A73CM0SC9D%:D998AY$SGT7ZEG0W)4YS- MI:X;4-#<+YYM#BP0 Z( B=!_FG:@=^JN&;X;WO'N\ZAV4*AI)2L0B$J4#12M M;&LINYV(5*2?1P&I2&_"5@*<%'!3K>I+8SJ&FI6U0@DK;F!0SBM/ M@WI-7)J6;T[EV5P)FQ0W.?G6<0VZU,"%KKD(7A*FY<#4!) ,)R&80QX>] 8V M'%?/-;H1"D)PF:WQ;=8FOLM.3& "$!#;#4P\MD&3#:3G6&6S_7(,&Y"MZ> 6 MNJE/(=6M4:!K7OMZUDNU"KN0TL_J%& MZWE@6N #K9D4K:A$,=K+0!&![:TLB MT=*M'C;74'WH10\;>Z?=;85YO:%]_C-.4%@%Q;K]VW ?+J"-<"7L)=??T0XX M= >.(+,ZI,F933@8Q4 H)C0<2P^']N(G#E"!=AKC7]NX CK>T(]3RBPB;Q3- MS13BT0-.YG1X^LMC/G,CYD36.!^ SF_%79\GB&]>,T/5?;#$HR==]X$!J*U1 M_?0Q1'WT7]Q][[&N(ZUS_=H-32+PY4#T)3;QB3DAP\T_JZZV0U^X?B8N"NAN M=ZO@'?QR1P'?,UC^;PJ)7>@3@UY&7Q81PQ\'H6\X+[I'T6* <8F(#]9FC2<2XQ M(']/X1TG(2!U4!T>8E;P%X,>PG"4-BY,6 8SB%\_TEY0EH"<1E ?,B%6F <. M.!UW$8$-16K?=7+B.2(I!8(IH M(Q3CE8I6(6?'-56P"(HP-8L)(!TI8HNXZ!5X1#E M5H*$,GRX5H^]EH<3DH%O1P ;J"L?\X'L%()N< 8-,8+FACB?F%7%N"R$5W ) MV4YJ8A;O6(Z1UG2HAHD5(LB8,MN8LY]WU'>Q\9 85607I22:\5^?A5G:<2L4&8[O&)242&_?]V6U5))76![V M@1_!M8X"$7\PUB:-@4-:62;W.&[R009C0)=+\Y15: )HZ(])209?4 9^^28H MH#E%$#XL ,L,)AN9Y9(V5:&F9CWI#E'X)@-:6]89B3ZIH<\J(TM]'[EXBZ+ M1F3U=U$H$#XAL'_]]W]="6G5)6E/^$D.@X#=EH7I=8%?J'F<9V"H1H%MD(,8 M*'P!V8$H0) RA(0(J8\F>!)!8$V-.04,Z((7.&]L(&[$1X+[^(PO:&VA@YMT MT";&.9KHN)T5<8>J!I[9*9X)0)[:)#/GZ7WI*196D9P#"8*_G.15MDIK\97^N"0(->I=E()OMY)7P5#,#2)[FJ9ORQIM8 M4D._"8$<9X>\0A%V$)F]<7+R5&YJ*!"HEU>861%&)%L$4&ZQ5H/9^:)7N9H5 M0:'K=*&TF:$Y54-"J:,':H;#65O%^8+(:1+*R9P&B9! "H# 8J 8>'*6UD[N M>:!C5A_W005H1E\/,14RNB1U:31 6F!Z>1ED,*/DMFLL8 (H.J>#*7Q*B9AH M^I>,R9F(J:)FH)WXV8>7N:>*J9F.66Y>UB_481W>LEWV66@PI$;TXA$.ZHWV M9T;ZQW\#X']!ZDX9J0".=YOR4JD'>(%86'&DYIN91Z*;9X=+6H%.FI]0NI\% MV9\(N4:$8:5O@:6+^IGYMFTD:8.1:II6YB#Z1")N=:J&@6IL: M2JK'&B+[XJ'*!J(,.*)A6*(Y-8%,:IS^J)\>R)_.B8MU,&!;^".^>G)*V5Q- MN5U5-:S9>8-(>IQ:RJAWX:@R HA TH,P%*],R81SJ!W0I9KZ=7"A.JIW0K"L M9+#_JEY;MHO<2K$XV85B:&"\TFM\*2IBP:. 431L@08).1]WT%$!]A;L.E0J M9Z,>RV. $P9D8)@H^A0T8VAIQFAY=63M>A,;PV0YIAUD^5>,166Y=65ZJ&49 MNXS[^@6^M%UB1F:C=68\FEILL%IDY5IW%EL[YF U16<[T[6^I6=OR6(@$"9[ ML; 7>A1O !DJ^U$LVVXV^A=M\ 9E866(B;,Q"[(5RJ,\JQNUE1M_@1V-EAMI M,@?O6&#X@F]UL6V"IBYL&:;!U5@<82_)XWA^)["'-F5R4&5*.R'FY+FD F,U M1"-GLZYTJX<"^(2DF[3(&B%8]B-,*Y4>J:I:&)7@Q64;*T]GPP)A\KLHZR6C M0@=FR"LNJQ$L, =I0@=N<'+Z(65'Z%B%U3B'E5C!E;PK M9[F$A0);QZ/VU1CX55$PEKKL6J.L&[3,6R^%L:XGTRA&*UP5@Y MTB!)UB(O M=7+SZ[R $P/0B[9L:#0"_]EW+UFPH<#8Y M6KMST&HA&0)'-B(=?(JMME!P"0+MJ+A_D5<2S"MR08_>"164.&ZY5L/'=3:$ MV5#FNIPSRL*0<1,GDY#0B3@\[)#20;-:VVBGJ+J\4J.#"V/P*[J4B+((=F*_ MNV!N-V[^"R1IRXK06+P:AE,)D([N\A2A<1?/2)(WI2Z0B;)F_,6 @[)*#*/] ME&^6JDZ7\70_E#2#>[=E <-/S*[%,B"FRV'W2+Z8VSA-8"52< 1FS,CH,L!N MD'1FO,*"O+"G"Q4Q?!.L"RW2LB 80;/WJ+M'"L+>%AL[&Y%F!6,G, (AH"5< MP@8GH*[LRJ8;V9ZZN\$K68,:W'Q9XH?W,OA7,(6 MDCF\_J*-7I7"'N^,+MF]4R#,_0 M&=3"F8\ZC-G[ZX_[7*L>*,MA(J$!71$#G61%3,,+";R9?08K]H]+7+,[_;XO M.\43_;*L:]$-A=%@.#.1?08<;<8?7=)@/-(9\\4R_7TJ[1$4T=(DZ<88ME0Q M?=+?5].%<=,*3:;M"&.P#1C4?*)6'-9"+5A$O9B.; 6(%')IW$\2@E8:/CUMS"_%+;W&S0V=BH6),LWB*ZR\P,'=H. M+=P<1=PT:MSO;17*/57-_=Q=C&HA'<8C)MW7'3K9S=+MYM(6 ]-Q'%1S7+QU M;-Z&9I7I?5'KC=@%_K.+/-3EJSF/?-]*;15,; '0( ?%6TRH$#*2I)L>>BB^)LX()FS??([17>.!#E-J3N:-[#AO- 5BZG;1:Q'J M!&-!:5:C/,WS2NJSY=1(9^-N^@6W[A@%F+XG)F8A#>MH6QQX@%>)_+)]+#5K ME;^9LBA;P&,K(+Y_TR*6S+G2L9? WM5(,NQN<+#_8DY[V2IC@>L22X>MZW#( M^^O!S@;B3NXS8^S%JX#R9.\_TKM:J$GEIF''"]$],%>./M5I\@8BWA!9@1/G MPJD[44.Z3@ [%W\MLH%=O9SXATD,UIY.JXM0ELHNJ9%UW9X]"64BW&S=790F M*HRPL=Q,P)A9.K[A0[_-2?\TCS]A"OU1] MXLJWXA!A:9$O/*_W^(]43Y)6;Q7X*/0E>%R*6I/_..0G]N]<3/?1G>34S>3B M'3K_^.3;'>4I/^7?#<=-KA]-1=YV#/@-E73/2_<2WE02?GYQ)WY/Q.T*ZD<' MHZR&?7]%L$?0ZJF\2J0.6VGE$A)_5)\?BKN]J8/>:KS@*H$=F[4\!K@1B>@5 MW>>QVJ39^:2$?JZWFJZP/_JK_ZX%+QTCZR0E>[)!%;<"1K= 76!]6RLMPL1Z M6Q;;-J93S574^U_6B[VNI;WR7>;>BUA-T'Z I>KHDHUR/M4\:^>S&8",FVB7 M9J]>2K5F)OZA4@=K1F-<^V8$)NU@>UOJ7&>\]3,HMF=-%>MJ"]H7U;9; K< M)K(^P;L;*.-"YJ0.XU?VI:O7GKR M3]]?H$=!D 6_JFG^"BP BZ"3:D=FFK /RIJ"1 6I+ZT8VNZNK[=YAJJ[2?LA MRJJ@YJK!2=CT]^,:D100H^*[3/8O^.+Q?&[^CX'PR2Y&9+.YB:KVV52Q[LP@ MT!=&E!008Z.465((H)00@V)?A*K%FJ $:$0V:Z8)^Z"L*4A44!@ORZFJG_\- MNZ'E8D0VFYNHNINT'Z*L"FJN&IQGR/M^6S9%PJ-S8!2'JVG^&JK1K6G.UB)4 M:V8UR=3@$P16T'X)X 9% CB-A2%RD#'G&^=-%>O13X4FZQ!8#&!R&U+8K\C: MS_M^.[,U^_TX&UQIG/ALO/@7IA?@#9E3Y?\[R(C/+[W,7KU[U5UOJ M7&>\]3,HMF=-%>MJ"]H7U;9; K< )K(^P;L;*.-"YJ0.XU?VI:O7GKR3]]?, 2:VWZQ'@:;S@:=?E$H2*3QO_ZK M3FD=77KRCP+T'^N/_*&OA"1T:Z-K+>>'^ M*09N*H)ZZ/SUOU5&<;B:YJ^A&MV:YFPM0K5F5I-,#3Y!8 7MEP!N4"2 TU@8 M(@<9<[YQWE2Q#K9YE;X3I0>/^JD8&O%PT2)@^^T1=9CY3X==JJ_/+Q#13X4F MZQ!8#&!R&U+8K\C:S_M^.[,U^_TX*_[=N*Q"X:8BR.>EA[1Z&S8S.C/^OX,/ M7OR J[!Y%90Y_R%3\0*2]!$VBI8J\^#W2K5F)OZA4@=K1F-<^V8$)NU@>UOJ M7&>\]3,HMF=-%>MJ"]H7U;9; K< )K(^P;L;*.-"YJ0.XU?VI:O7GKR3]]?, 2:VWZQ_B-KFU=K+XXO3-<\][(A MN9=P.G5T^J>"V1O^F*=PVJ?HX25_*IG/+Q!AL.ELT.D7A8)$&O_KO^J4UM&E M)_\\)_XV?S9F^LI;VZ]NPBA/$2:[!YFQZ^(NR%I[0H8&NO9P7[I]BX*8BJ(?.7_]; M912'JVG^&JK1K6G.UB)4:V8UR=3@$P16T'X)X 9% CB-A2%RD#'G&^=-%>M@ MFU?I.U%Z\*B?BJ$1#Q,;BH2>MONV0S&O'N K5ORTI?,*,SX__Z&F*Q?O\7%90Y_R%3\0*2]!$V MBI8J\^#W2K5F)OZA4@=K1F-<^V8$)NU@>UOJ7&>\]3,HMF=-%>MJ"]H7U;9; M K< )K(^P;L;*.-"YJ0.XU?VI:O M7GKR3]]?, 2:VWZQ'@:;S@:=?E$H2*3QO_ZK3FD=77KRSW/B;_-G8Z:OO+7] MZ@;7$>VP.O8W >CD81YE1EI6H>Q=Q7-%@J"3:DGL_%5+#\]BX*8BR.>PBA/$ M2:[!YFQZ^(NR%I[0H8&NO9P7[I]BX*8BJ(?.7_^$37\+NR:DPC)CH5\OO"0; MX:8O%_% _XNR%IZ=&IPK/ =&<;B:YJ^A6O>:YFPM0K5FYO+Z/=_@$P16T'Y[ M7R2 TU@8(@<9<[[F%V(KC+5-7-YPF!0^N_KGF 04S$SZ/\[^.#%?\!6^2BG M:*:OO+7]Z@;7$>TB#[#.UB)4:V;")]9IL.S'Y09%LLHY%>O.S&:UPC)CH5\O MO"0T.B!BX*8O%_&4&9_E$K79EZ_4&+"EF: ?TG)+$H0,@1&^]AM&B(0_?2L0 M(Q!.>"<04S$S*/U5>+N6IX727X6\F_LFM?L?"RMEPZ-@FU?S421X,H<3I0>/ M^JD8&O%^^& 7_(S2_R/"N&<7#3A@^^T1=9CY3X>O.(WB#_UR(OT/1OTI"V!R M&U+8K\C:S_M^.[,U^_TX*_Z$37\+NR:DPC)CH5\OO"2TO;9"X:8O%_% _XLX M*/T_D@+]UW6OJ[=A,Z,S$XQ&;A404S$SZ(K2_R/JXK1QWE2Q[LP]B^5BX*8B M6&#IV'6OJ[=A,Z,S$XQ3Z9E1JY: 1+5FMLJA$^M8V\1]]5IX9J.^>%OJ7&>\ M]3,HMF=-%>MJ"]H7U;9; K< )K( M^P;L;*.-"YJ0.XU?VI:O7GKR3]]?, 2:VWZQ'@:;S@:=?E$H2*3QO_ZK3FD= M77KRSW,("D-@:R[KV@9Y\ 44ZA4, ;;CLJYMP%<4ZA6&!P(G($D?<O1GM> MPY'2_R,Q)?W_2]86(_T_HBY(IW3"%__KO^I04 53@ 2KS&=ZAQ.?7YH)^BPT M]>T1=9CYS^X, ;9X$E&?BJ%>87@@< (0<\NKW^Z0QRM@^^T1=9CY3X<=^8G< M*OW[GOLF%<5*.O9!+_T_DL)"#CA@^^T1=9CY3X?99S'2_R-[5OI609G_R-2JP1"OFU=BX*8BR.?5>B>O MJ[=A,Z/U+IJW:WE:*/U5R+NY/X9:*+Q!1;S[;J(W(;[+Z]0'G&;DGU?M=KU] M9:-,;5CN#_\-!=0MPM3G^_SU->[WE5_!3;<4#;1+-L#U^R#3$F+D#>AA3L$M8\$<*?T_\M@>K),6(_T_D@+]I\*A<_21'MQT MR_2E?<_=W,,$P/>!N,57-9GJ&1>[3/8\_.+Q?&XDR

='5G]&!2)(\ M;.1609G_R,^7H95((11N^G)(C,(X#MPZSM,1G5<436"*C>3WKN272/A6/IGJ M6:;:O<;OLO@7IA?@7>5W<.7_6]YWP,PR-Q]UL<=P\>P^I%T$0M6#K.,\?!)QM5&HN!??8_2_[]D;3'2_R.K MG%-,K3E7$@2N+OY;M29P0>OC)9'Q#H7R0>\V:LF]GB#P#N["GNMJ"4C';A6Q MKNS,?E% _>P^I%TV.NV;8NW8#CC;7IH)6J9A(UY,^04SZA4,@9KBQ92R[29/ M@B<)>0*2]!&WO/KMCB7N K5ORTI?,*/U_HG<*OW[GOLF=:)_BH:S=Q(HX#4< M*?T_$E/2_[]D;3'2_R,I+/(7_(M%^8F^/))$:3'2_R,IT%"N]H];*O,[*?-% M^8G/\:5M^>K?UZ:L!*>+WY&?J"YT^J>"V1NLG:=PVJ?HX25_*IG83>&&S\^, M=A+'OQ#091>8GB!NBCB+WY&?>)0)<'Z%EM9'7V>\%5L,@;6'WE>OA6?MCB7R M)+9CPUL_PUU]@>^YVQ<;ZWDA)T0JT& LJH5F!P 6[A[W%>OA6NH7Y)( 6NS@1)0 5(]R']= 9CU<8X>%,-Y35^^&"I%A+!Y2ZM,3:I%A(: MIGH'F1-Q!5U^NVSV'^0< !>U^U#"QHZQ;A QT;..ZQA><I9,RCX-O[#4<"0Q;A QD5=$W5<1OW-I@&!^&Q0-=GHM-Q,'R7ITT!ICDVHA@55Q 0(\ M(%/(XG]6H0(-EG0(UBQ;D 9)]RG/+Q"=#Q=47/UM]F8$EK^=#VB1BZ"3RJ]) MD; /RIJHE/K2BJ'M[OJKE#':2G&6E[NL"FJN&ISBX@9%P@)WKJ1C'_1.ZFH) ML'-W#F3+_6L[RH"!7?RN]H_B6H'^CX'PV=K'OYP7[I\.X?3<,NG.+]5;*O,L M*6M.^J5M^>K?Q]2:(P128 3Y30!N4"2 TU@8(@<9<[[?=X=$F:\I )_Q62Y1 MFWTR+VM.BIZ'3^&&SRZ:YJ_ K#Y?=H *\R3ZY:NIA],K3E"( 5F?,9+UB*- MA2%RD#%WGM\$D/D-I>Q=Q7-%8L82KNQ=A4^LM,KW66^AP]2J&&OZ4R+VO$*F]GG0#*WE7XQ$JK?)_U M%CI,K3FO'F+LHFG^"BP BZ"3NDPGD; /RIK(E/K2BJ'M[OHPDJ^I:GFYRZJ@ MYJK!*2YWKJ1C'_1.ZFH)L'-W#F3+_6L[RH"!7?RN]H]WJ,S%[VK*=)C]+VLV M.+ENZ78)P-2:(P12\.IT?^> TU@8(@<9<^?Y30"9G](4;OA;*O.R1JSR=M8) MH.Q=A4^LM,KW66^AP]2J J[!YY1%)MOHJ/OSD:OP"B?S-B>'LW?Q? MM*,AMJ4R+VLV.+ENR:-SL 9IX%5+\K9+!LNL=>F(&P:3'AL5[J M::-,K3E"( 5&$%QN4"2 TU@8(@<9<[[//QMKD 8OYM,@@.D8<>F(&P:3;J-& M&O/DJJ0X09SD:OP"B?S-B>$8 1?<,NG.7__=N*P@@.D8<>E*EA0G0&^WS"V3 M'O% _XO*_)Z=VG6+?1,[,KENZ6K_N*4R+VLV.+ENN=3R3]]?( 12D-\$<.> MTU@8(@<9<[[F9Q7IV'5?UUG^OX/V>?A+UB+N<=8)H.Q=Q7-%8L9;*O,[F:_@ M;9\)X 9% CAW[N'//V3\I08$[1"8CA&7CKAA,.DV2IGQR?]>E,F,7-3=K3&#"CQ-N4"0@X /.YVH)H.Q=Q7-%8L;LHFG^"BP N\KNEZ $ M&+6DO[ H\$JQY 2I+ZT8VNZN#[5@MEW:2G&6E[NL"FJN&IQ _VO%;Q4[YS79 MO*,,&-C%_WU _XO*_)[08?A;*O.R9H.3ZY8S39G*=)C]+VO$*F\GEXY=Q]2J M'LW?Q?M*// M/QMKD 9>M21ONV2PS&6W[./;P=ZK;Z-,K3E"( 7!Y09% CB-A2%RD#'G^_Q# M]J 7=?!>5;0A=O!>Y6,G 5U^^[11FWWY*KE@ZI8\VB G Q6O?%'%\;DWX;B/ M:J/*WE4\5R3BWXW+NAWLO?HVZ@9%@F!Q!5U^^[2=Y?\[.+ENR:-SL 9IX%5+ M\K9+!LM<=LNWAO]"&H!HY1BDHO[[K3E"( 6O7GK;BR%R4-UO !/BWXW+"H9( M>!W1'F+LHFG^"BP BZ"36DPP(S.DO[ H(*#5*=LG 6#2BJ'M[OI?,)]M(?O; M2OLARJJ@YJK!V:*[QJ,Q.I>S71@O2]<=/*XO&&S.%N-=BH'P:>')+X('_8(" MO&N3O:///V0/6KTK&U)TN_HV:J0Q3ZY*BA/$2:[&+Y#(WYPB"&!R&U)TV_Q? MM*,AMJ4R+VLV.+ENR:,Q.I>S+=M;::-*":>:8SQPL[R[]JN:YJ_ K (.JD+ M^B@P(S.DO["MR4DX(:#5*=LG 6 [0:'2BJ'M[OKM,A7SV1:ROZVT'Z*L"FJN M&IR^BX N^OS^ >GL?%9>,<-P,9]MP8 V&@9&JI/Y&ESB6H%A\(+!]LUA\(+. M5O&#:"3+*:#529.#+I#(WYPBJ$X"6IW7B= OR*,Q.I>S71@O6V!A8*0QW\$O MJ*0X09P=_(+!YFPQ_HQA$)[0H8&NO9P7[I\''08O*,"[]L%A\(* J[!Y!6!R M&U)TN_HV&@9&&O,=_()*BA/$V<&SJH&NO9P7[I\ )KS+=M;::-*":>:$P2)NFN_JFG^"BP MBZ"3FFT+G[#\=7A#"Q=KLO!.>"?LLB99(?O;2OLARJJ@YJK!*2YN4"1E<\!I M-@=&<;B:YJ^A&MV:YFPM0K5F5I-,#3Y!8 7MEP!N4"2 TU@8(@<9<[YQWE2Q MSK,+;++NO/HV"AVP.O8W >CD M81YE1EI6H>Q=Q7-%@J P!+9? -@)^Z!Z7N!>87@,JQUKLO!.Z.XW ;9?\%WD M>K&^F?LF%<5*.O9![Z2NE@!PT2)@^P7?E7WYNF?QR?]!*K?XZM3X S MLZJVWZK?^JKABFIPP0,@ ,OCA-PT2(HT )/ MM!. _B']= 9CE7WYF@+PR2YKDA6R7XWW61%=![9@AY/9EZ_J\OFIOO[V A-F MS"Z:YJ_ K"K['X)^BPT!78X2?KM7.!>87AP<1GXE81#"Q=KLO!.Z.XW ;9@ MAY/G^407RZKBDL;!>B7N!SX/RA,VY@ M"W8XF7WYJBYNX!X]C'+R3]]? 55, 5(8,9;*O.R9H.3ZY9NU_F 1GZK'*ZH M]D2#+I >Z.D)4OVC[OQ\IG2>-"YK; MAE]BLINTCR7X9;RM^JVOFE-*B5^@N6WX%; AQBZ:YJ_ K (.JDC$Q+]^FXG MD;#\Q<B?K%A+]^FX6\^^[2?M8XJ*M^JVO&JXG^J=HJ*0X ?,M M0B85FNKKO^JO'F+IV*:L!*?_3J=_*IB]X8]Y"J>,>1Y&X"5_*IDA1ID)H)1P MJIGG803+NVN_JFG^"BP BZ"3RJ](>!U)D[#\Y1":YJ\-NZ'\BH37\:^[67&@ MYJK!.0=W$%$,#+!\F)2U0K5FI@.IOOZK+EIF9L9B4+AK *^U,KGXH0-6(0:% MNP8>7IH)VA U^_U/84X,[1!OF*XW:\.VZ>Y 6[/?C[, %9QGR/M^>\!I%OU4 M:+(.@<4 )KE M,F-;RQFOW#)>@8)$VE3;_U:YX;?PZK<(EC<\VOEP 6,>VUK,V;)MW8K=5_?U\R_M^JX!GR/M^N['2H;:@ M?5%MNR5P"V!R&U+5'&(C[5,EYHK>K1=?V\$L1.Z.XW ML9=P^N\3\:?0TAOXKH4N^C4D5ZS;>YNJF36/[>\$L0)1V.YLBLWD?VVZ>XWL9=] M.=M"SP+0TAOXKH4N^C4DAX8;>X8K&F*^>W(.T2*H!^5LO/@7IA?@?;XAMG-H M6,!>PY%A$%,.$?,=K"Y(MP*#*?)"+\PD&08I_'TDAX: @X8SW?F 1GYFS/EZ MAQ/KM[FEF: )XJ;X!9I0P1#G+B&@"14)9V2.2T.*[(3N?A-[B5^@N6WX17&6 MIX7XA?NO&JX="SA&D 12X.I,D 14P*):*"9PH*0X<1,Z*?,X>%/]UW4[YU6G M[C4<&;#/ CABLAVI#"1!D71O('S1[<#7L6WX)28D66W08?B=#VAO8,:##P?) M-C/X)2:,&.?@1N&A,]+[XHHWE6PS@U]BPH@AUOF ]@8(.K"%ZB9&D[#\Y1!! M_!>,TD\QT^Y8HI1P"A/+NVL*>(9PX#4MNFL;R]0P4;GRSUUNBE^@N6UY#_ID M?9A!G+#\Y6@>=?V\$L1_P2C]%#/MCB5Y"J'%'"3"85FNKKO^JO'F+I MV'5,K3E,D 2OGNKK;R][B5^@N6WXM8<>7IH)^BSR/[I'F)#,0E@]/2[808]3 M%C/M#GF\PM1BH(#B(@8;*RXT*P=*6M=QY0,MTBE8\*1-LA?O(@)]O"A,D09T MJQL8#"!ET.$A1K,GT2(Y$5?0Y;?!->V;TF"!D739+A0GU_F 1K.T!OK/LKT8 M(@=)P1"!E9"Z@2%RD!2'/"[808]3%C/M#GF\TE@8(@<9Q(MPM0IZP,^ (X4+GRCP)W$%R=#V@T2VN@GR!IL.Q>Q1#*CE<.\1>, MTD\Q(W()YX3IE0;+_HMH\$3G!6IH@P9:"3A:"0(^X ,@@ .S=Q(HX#47 M\;Q6 Q<_5R0UZ09% C@YT2S5[K7IH)^B']= 9C9>YNVK/] M= 9C52JX@60$%BXGVD]G,%: 27&6IX5ZN+'B,HBS=Q+0V$] MMS\^",QQ;HQ M#YA[:!5)-X@GU_F -H@("D//[D/:52I'&%@,B!WG.!Q1" )&T 144!^[4P0K M!!\&" )&T 14\ 5"D 5GE #OP2%1" )&T 14\ 6.9P1&X#GP88 @8 1-0 5? M< 7(1 0), /P88 @8 1-0 6;\P1&8 3,$1LZ!#5^#$1?4R]UYC5"I +U G9= M\S7UPD1M8+Q2! *QLT4*$SM;5"I\(T8MLE![\#V-(P120 6=(P)"( 6RTSE& MT 14\ 57@$Q$D !] #I[\#V-(P128 2=(P)"( 6CU#E&T 14\ 57@$Q$D !] M #I[\#V-(P0II!\B( 3)E !&T 14\ 57@$Q$D !] #I[\#V-PP1)0 6=8XA) M(#N=8P1-0 5?X'A&8 0)T >@LP??TSA'@LP??TSB;B1Z)(P*;.4B=8P1-0 5?X'A&8 0)T >@LP??TSA%@LP??TSB-B1Z)(P*-.4B=8P1-0 6; M\P1&8 0)T >@LP??LSY!8 5%D#C7$P16L$OZ801-0 5?< 7(1 0)T >@LP?? M SQ7$D(B0&E,X#U&T 14\ 5"D 5GE !] #I[\#V-(UIFEC@B(%IFACE&T 14 M4!^[4P0)T >@LP??TSA4T#DB(#N=8P1-0 7UL3M%D !] #I[\#V-4U7Z,3K0 MY#U&T 144!^[4P0)T >@LP??TSA04 53@ 2)(P)04 53@ 3>8P1-0 7UL3M% MD !] #I[\#W H[E%D#@B, 2:NTL)8 1-0 7UL3M%D !] #I[\#V-HT=!D 6) M(P)Z% 1\E#A&T 144!^[4P0)T >@PW'?T_Z)E3@B\+WOCSE&T 14\ 5"D 5G ME !] #I[\#WUG=2)(P*/G-288P1-0 5?( 19<$8)T >@LP??4]]('@LP??4]]HGC@B<.9)C3E&T 14\ 5"D 5GE !] M #I[\#WS\SR,DSB#\SR,@SE&T 144!^[4P0)T >@LP??,S^M3@6),SBM+CN) M8P1-0 7UL3M%D !] #H<]SWSU%QA?U!?XGKM>5&JY;U(G MVD]>0DF7/VI::'8 !J^NU2*HYQK'H4,XAG,%:L M1P>M,3:I%A)[)M:T-TY ]B$*P0,?TD]>,TZ]7AC"!Q0DD AJ"3^A%C\^U^K%WFM"VN18\O9S1$K1O/[D/:12@,\Q%C\^U^K%VU M%Q@F%A)>0DD AN^YZT6N\87CY#6=EE"YWWG_ G*@)T0JT&#P>C4GH2E;$ ,P M .?$F*QLT4H 1,GUS9;A# M\=P0*HIWH'R7IT,'JO*!'@/4XLH (-)J@5T748/!-W43*:P@)!8 1- M0 4F%A(Q)4Z!]72U%QCAQ1O!-?7M5"PEHRDL( (Z4 (P0 -X (E ,R@ >= MX264I (-MLHY)4Z!]72U%QCAQ1OB#Q"!]72U%QCAQ1LO5( @DV8.'#9A\H"@ M@Z8,B#=PRL@)XX;,'! J7C10 (2 3-OY(! 1%$CX=TPHC9\1!."Q]OZ'QQ M$Z9-&98K5D!,L3%!&C,C58R!8_(DQ)G8D,.=.&CICT(P\ M"E.FF39TGD95D&#JF#!S'!II0N6+DR=.BNCHF<"@G#1NZ)A!(::.&18B.AHH M,8>+&Q$LN":E:3/%#KIXV,"I0V<.'3DHS,"YS**O&<=TQ<@I$V;-8[)FT:IE M^T5(%BIRZ=K%JY>O7\ E8,C ,Y4PB-R[#2,>NB5&E\0NN\ZL688%<>.@R2:( M/+GRY/6 MS=NC;^"\L30<',4=IYA,C#7W7!?=32<9999AIAEGGC5(W5UNQ(#"&670408; M9=B4%PI+->4<@="Q,*$<%K+AH1QPW(7=90V")QX(Y(4V6FGEI=;>>U]<\804 M1-3GW7VUZ2<"@+_Q]]M% (HW(D%4BG#<3U!,L"!R]E$I7%6,EB>@]5%.*-V M%8YIXTDRC'D>C^H1P-YJ;14A'WUT_302"FF8!,*"3_5P$@P\23<5'6T0=1*' M=-B1X!PD,N74F!^V-Y9W4X$D$@J(*@I"&6[8P5*?/N#(4@LMI/%4IWZ.009F MG39X:*)^,OIAB*#206(8L":: @N$CMD'79J.U.=)Q%TY*@BED@<"JJHN1"NR MKW+JZYA(YG?;DDXR^5^W3@KXY7')8DF6EEPF.&Z8+99YW8K;?3;FA7AI>%:O M1Q1X5&[&G>:G$DAO)Y=7E3>&M@'.A M/@&%@E"*GH3S2SJ7Z!14<69KVU^!03)888>Q<+0/.B?8W5340?AN=O%N[1'# M#D,L<7D)PTP QBBOX<8;=X 'D=(8:<211TXK*1@/53BQQ%M7..&#<-%Q_:!U M$H*=IMID/SS2V1LEK $:"%A31$U%32Y# $Y+ %TD&@ JQ)B/\(-6ST PO M5(# ,X=,FS)M7(P!T6+@G#%H$)8!02:/FS!MTBP\V.:-G#P@VH2Y>$:B&SH@ MY+RI0R>-FS)S0*AXT4!!P 1#WL#)(R?-&30H48Q) 2)&#APX6( 0 Y)(&#MI MR(!HHA%-F#)L0 @I0T=/S01!V&25XA-H3"DPR\BQ4X;,5RAJ,\Z9D^:-&Q!I M8IZ1,Y).6Q!F/(*HXT8.3#H]Q_B5ZL9NBS%OVAR4,R9-F*QUYI1),+-FS1$N MQ["I0V:B"((0);I (\*S38%0Y="IOG)B=%3"Q$H3)0#9F M".](D" @B#%UY!@^"9BPXKIW@P\O?KR,&SO+FPN$+MT[2N^Q[1ZDKIVX<3QL M[%P.[US^Z(EOS(1\,P>EX3'FX>5&?W+4<9U=,M$DG'LRP3<''/3!=ED=$_5W MVQH@P/&&2[XEZ)IS%HZ!(1MI9$0'< IN9YP*#M*QAAAA:+:<=RRRT=\:=.@4(0A%PG&C?CI62,>%(*!PVVR7L9&'4G9-)$89>=A% M!E'!U51?&#V%(08;,/%HE6%2W9$&'6@X5&(8)2GDH0)&)($%%5E 4022;SS) MQI%%"@J"&W6TL:4<2RZ5AU\QX6Y9Y]_GC'&&%7.,:- B"JJ M5J.@BA53D4A&!,(99,)8TG-OB%6&8H*%^=JA;Y3&(QRW312<$U,4<40313A! MA4P#EG'&>B>."@*)_37:F*^:/6L>BC41:RRRRC([!QLQTB$MN=5>6Z&ST-[) MX:$/K732D:4N:FVOZVI[$K=XZLFGGX>J*RISSA5:6[VGXBCPG9K^^Z<;9AA6 M!KV)VJLPOC%9&G$9$U&+TH_&F2'PD1XWNO%$"^M:WZU%,BJE&U(1Z-(91#T8 M[)U6%'MLLLNJ8$>VT [L7,DXLH4KHT!OB[/.X/;\,WG3F2O><]%%G2/+@B7- MGH+O/BVOU%,CS&C16"/-KM(@RV3'R?26@0=*)T_[!J@M(6BIT2W_>G/:/B=) MJ$Z-XITUL #>*:9 ;OMV45;RE7EFFL$EKM9=*O+X!6%BR$O&D2I4X8003WA. MA$!SY*%HK7=*+@?E#+X!HW1AY,'Y$T($(844061!NNF99Q7YVY.#4'EI9H11 M!QMT?.&Z&BQ+2[SQR-\H!O.*I0[\ZL(S6$9^RD_?/,&(X[@\R]8KGCUWB%%( M:(%PYCBAL H>#H+JBZ>T4DLO\4O_8 /Z]))4$"&33%+%AKFA( 4[^)! B.' M.Y!)*J41#9G"4+P)4KB"[8AP/N-4:6[J.F "\81!#4J!@Y7[X!@$)P<1 M*I!6%FP(9 :4ONJ%X5!EN ,,8Z*N.U5NAG- 1Y8D(<4U 0$'1P($4>XAR-" M@@"5) !\S.01.J! !"Z90QW,8,C*!*B'-@.0"/R8 #*H! YV M]&,F^^":3#J',"1R X;@A+(R1BPRK9I(W$K6Q2=*LC0Q.>,87/E(?,GRB2UH M <0D1D4%V%(@+GF394BDAXGP$H)G'$(3R#6 M"#,I!SB0"U3-+ T+\/!, M3SGF3(9QF(Z,-U\2SC(6TY]M>U0A4Q-N4?7<[PO^>L228$8F(5*VR@8[0@M*K^T\@YU,K3+6[/(H[[2  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Aug 89 17:41:39 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20277; 30 Aug 89 17:39 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 30 Aug 89 16:29:36 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: 30 Aug 89 02:56:44 GMT From: jdm Organization: Hodge Computer Research Corporation Subject: Xscheme is a-commin'! Message-Id: <21721@hodge.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I have had numerous requests for a copy of Xscheme 0.17. I am therefore posting the entire thing (executable and source) on this wall rather than comp.binaries.ibm.pc because 1) the majority of people who want it read comp.lang.scheme, and 2) files submitted to comp.binaries can take weeks to be posted. I am not in contact with Dave Betz and I have no idea when the next version of Xscheme will be out. I only started in scheme several weeks ago, so contact him via BITNET if you need to. The files xscheme.arc and xschsrc.arc are uuencoded and seperated into three postings each. Have fun and keep your nose clean, -- "I'm an anthropologist, not a computer systems architect, damit!" jdm@hodge.cts.com [uunet zardoz crash]!hodge!jdm James D. Murray, Ethnounixologist TEL: (714) 998-7750 Ext. 129 Hodge Computer Research Corporation FAX: (714) 921-8038 1588 North Batavia Street Orange, California 92667 USA  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Aug 89 14:22:24 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa14802; 30 Aug 89 8:38 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 30 Aug 89 08:11:16 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: 30 Aug 89 03:35:37 GMT From: Ozan Yigit Organization: York U. Communications Research & Development Subject: umb scheme ?? Message-Id: <3477@yunexus.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Somebody from Univ. of Mass. had posted a message about the availability of a portable/small scheme interpreter (umb scheme ??). Whatever happened to it ?? I heard nothing from the author, and lost the address after mailing to him. oz -- The king: If there's no meaning Usenet: oz@nexus.yorku.ca in it, that saves a world of trouble ......!uunet!utai!yunexus!oz you know, as we needn't try to find any. Bitnet: oz@[yulibra|yuyetti] Lewis Carroll (Alice in Wonderland) Phonet: +1 416 736-5257x3976  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Aug 89 05:47:16 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa13771; 30 Aug 89 5:38 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 30 Aug 89 05:18:30 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: 29 Aug 89 15:03:24 GMT From: Richard M Emberson Subject: MultiProcesing Scheme Message-Id: <3950001@wdl1.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Do people really use engines to get a multiprocessing capability in scheme? What are some alternate approaches? rme@wdl1@fac.ford.com  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Aug 89 11:12:55 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa09687; 29 Aug 89 11:08 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 29 Aug 89 10:45:42 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: 29 Aug 89 14:25:49 GMT From: Robert Steven Glickstein Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA Subject: R^3.99RS? Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu What is the status of the promised Revised^3.99 Report on Scheme? Thanks in advance. _______________________________ Bob Glickstein, System Designer Information Technology Center room 220 Carnegie Mellon University Pittsburgh, PA 15213-3890 (412) 268-6743 Internet: bobg+@andrew.cmu.edu UUCP: ...!harvard!andrew.cmu.edu!bobg Bacchus, n.: A convenient deity invented by the ancients as an excuse for getting drunk. -- Ambrose Bierce, "The Devil's Dictionary"  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Aug 89 22:06:57 EDT Received: from relay.cs.net by mintaka.lcs.mit.edu id aa29915; 28 Aug 89 22:05 EDT Received: from carleton.edu by RELAY.CS.NET id aa11625; 28 Aug 89 22:05 EDT Date: Mon, 28 Aug 89 21:08 CST From: RKIRCHNE@carleton.edu Subject: RE: Scheme Digest #169 To: Scheme%mc.lcs.mit.edu@relay.cs.net X-VMS-To: IN%"Scheme%mc.lcs.mit.edu@RELAY.CS.NET" Message-ID: <8908282205.aa29915@mintaka.lcs.mit.edu> This is the last Scheme Digest I have. Our network has been down for a couple of weeks. Could you have my name reactivated and send me Digests 170- ? Thanks. Roger Kirchner  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Aug 89 12:58:33 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07947; 27 Aug 89 5:07 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 27 Aug 89 04:56:52 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: 27 Aug 89 03:36:54 GMT From: "Roger R. Espinosa" Organization: The Rabbit Corps Subject: How Good Is Xscheme? Message-Id: <772@cbnewse.ATT.COM> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu Hi. I'm doing a project in scheme (Hi, Cordy!), and in the course of trying to keep down the long-distance-modeming (since I'm in Naperthrill, IL right now, and the *official* scheme is back in Ann Arbor, MI...), I ftp'ed my way around and found two scheme systems: xscheme v.0.16, and mit-scheme, version 7.0. NOW ... the problem is that the copy of mit-scheme which I ftp'ed onto the sun then onto the Macintosh and then onto the UTS feels that the *.Z file is corrupted (I couldn't uncompress them on the sun before putting them on the Mac for transportation because the system kept running out of disk space). The Apollo felt the same way when I tried to uncompress the original ftp'ed stuff from UM, which makes me wonder whether I'd ever get mit-scheme running on the UTS to begin with. BUT, xscheme transferred over and is presently running on the UTS here in Naperville. It claims to be consistent with the Reivison^3 report, which is fine by me. How bugfree for *regular* schemeing is it? (I, at the moment, am not interested in its object-oriented extensions.) Please email all comments, advice, and guidelines to here, or to att!ihlpn!rre (or rre@ihlpn.uucp). Thanks! Roger Espinosa  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Aug 89 17:58:10 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20457; 25 Aug 89 17:56 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 25 Aug 89 17:25:54 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: 25 Aug 89 03:04:06 GMT From: jdm Organization: Hodge Computer Research Corporation Subject: Re: X Scheme availability Message-Id: <21650@hodge.UUCP> References: , <387@maytag.waterloo.edu> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu > > Is there a newer version? I'd like a copy too. > Not to long ago I downloaded Xscheme 0.17 from the Video 7 BBS (yes, the VGA board people) at 415-656-0503 (12|2400,8,N,1). -- "I'm an anthropologist, not a computer systems architect, damit!" jdm@hodge.cts.com [uunet zardoz crash]!hodge!jdm James D. Murray, Ethnounixologist TEL: (714) 998-7750 Ext. 129 Hodge Computer Research Corporation FAX: (714) 921-8038 1588 North Batavia Street Orange, California 92667 USA  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Aug 89 15:47:12 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18965; 25 Aug 89 15:45 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 25 Aug 89 15:24:41 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: 25 Aug 89 17:32:22 GMT From: Mark Biggers Organization: Data General Corp., Research Triangle Park, NC Subject: OOPS system for Scheme - where? Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Howdy, I would be very interested in public-domain or freely available sources for an object system for Scheme, such as SCOOPS, or some analog of CLOS for Scheme. Pointers, please? thanks much, mark (news mail header is bogus; mail addresses below...) -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ biggers@dg-rtp.dg.com USMail: Data General OR: rti!dg-rtp!biggers 62 Alexander Drive Research Triangle Park, NC 27709 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Aug 89 07:12:36 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa13252; 25 Aug 89 5:43 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 25 Aug 89 05:37:40 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: 24 Aug 89 16:37:55 GMT From: "Luiz H. deFigueiredo" Organization: Computer Systems Group, University of Waterloo Subject: Is there a version of xscheme later than 0.16? Message-Id: <413@maytag.waterloo.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anyone know about this? Dave Betz, maybe? ------------------------------------------------------------------------------- Luiz Henrique de Figueiredo internet: lhf@aries5.waterloo.edu Computer Systems Group bitnet: lhf@watcsg University of Waterloo (possible domains are waterloo.edu and uwaterloo.ca) -------------------------------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Aug 89 16:21:45 EDT Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa03837; 24 Aug 89 16:20 EDT Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06832; Thu, 24 Aug 89 16:20:56 EDT Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Thu, 24 Aug 89 16:17:35 edt Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C) id AA00474; Thu, 24 Aug 89 13:20:00 PDT Date: Thu, 24 Aug 89 13:20:00 PDT From: Morris Katz Message-Id: <8908242020.AA00474@sesame.Stanford.EDU> To: scheme@zurich.ai.mit.edu Subject: Multiple values In my mind, Kent has not really pointed out a defect in accepts, but rather one in the parameter specification mechanism in Scheme. His example should really be written using some form of optional argument specification mechanism. His code would go from (lambda (a b . rest) (if (> (length rest) 2) (error ...) (let ((c (car rest)) (d (cadr rest))) .... c .... d ....))) to (lambda (a b #optional c d) .... c .... d ....))) In the past, the Scheme community has refused to agree on a manner for specifying optional arguments. Maybe it is time to reinitiate a discussion on this topic. OK everyone, you can start flaming at me now!!! ------------------------------------------------------------------------------- Morry Katz katz@polya.stanford.edu -------------------------------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Aug 89 18:47:04 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa17920; 23 Aug 89 18:43 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 23 Aug 89 17:44:15 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: 23 Aug 89 21:12:18 GMT From: Brian of ASTD-CP Organization: Jet Propulsion Laboratory, Pasadena, CA Subject: Problem with XScheme 0.16 Message-Id: <1639@jato.Jpl.Nasa.Gov> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I have been using XScheme 0.16 for about 6 months, now, and find it to be quite useful. I have been running it on Silicon Graphics workstations, specifically, the IRIS 3130 and the Personal Iris. In all the time I have been using the program, I have found only one non-trivial bug. The author of XScheme, David Betz, deserves considerable praise for the robustness and performance of XScheme. Having been inside the source, I have found it to be some of the cleanest, easiest-to-understand C code I have ever seen. However, I have determined that I will be unable to debug the problem without spending several days instrumenting the code. I have written to David to ask his help, and I thought I might query the network, too, in case someone out there has already solved the problem and can save me those few days' work. The following operations cause a "segmentation violation" on the Personal Iris XScheme version 0.16 (with IRIS graphics primitives) > (save "foo") #t > (restore "foo") [ returning to the top level ] > (* 3 4) Segmentation violation (core dumped) A traceback shows putnumber / xsprint / xlprint / xwrite / xlapply / xlexecute / main with the program dying at line 278 in xsprint.c at the statement LVAL fmt = getvalue(s_fixfmt) ; The following sequence may also be instructive. XScheme version 0.16 (with IRIS graphics primitives) > (save "foo") #t > (restore "foo") [ returning to top level ] > (save "bar") #t > (exit) UNIX% cmp foo bar foo bar differ: char 94, line 1 My intuition tells me that the two files should be identical. To give some context, the Personal Iris is a MIPS processor, running Silicon Graphics' own UNIX, part system V, part BSD 4.2. In this test, I am running XScheme as "clean" as possible, without the file "xscheme.ini", without syntax extensions, etc. Bringing up XScheme with my usual environment, which contains hundreds of graphics definitions, R. K. Dybvig's syntax extender, etc., etc., causes XScheme to crash deep in the restore statement itself. I have not modified the XScheme core, that is, David Betz's code. I have only added graphics routines in new files. My hunch is that information about the contents of memory is either not getting saved correctly or not getting restored correctly, and the next step seems to be to collect information about the save and restore processes. I spent a couple of hours desk-checking the code in xsimage.c for "xlsave" and "xlrestore". There is nothing obviously wrong. I decided that my next step would be to create versions of save and restore that deal with a printable format, so I could see what is being saved and restored, and I prepared myself to build a memory analyzer that would print out the contents of memory so I could verify that restore is doing the right thing. I'd like to avoid doing all this if someone out there has already fixed the problem. By the way, save and restore are necessary in my graphics work because I need to be able to load complex graphics models very quickly, in compiled form, without going through recompilation. Please e-mail or phone me if you have a solution, and thanks in advance. . . . Dr. Brian Beckman . . . . . . . . . . . . 4800 Oak Grove Drive . . . . . . . . Computer Graphics Laboratory. . . . . . . Pasadena, CA 91109 . . . . . . . . . MS 510-202, Jet Propulsion Laboratory . . (818) 397-9207 . . . . . . . . . . . California Institute of Technology. . . . brian@topaz.jpl.nasa.gov . . .  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Aug 89 11:48:37 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa24991; 22 Aug 89 11:43 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 22 Aug 89 11:03:59 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: 18 Aug 89 11:11:26 GMT From: Gary M Pratt Organization: Worcester Polytechnic Institute, Worcester, Mass. Subject: Texts & Dialects Message-Id: <3569@wpi.wpi.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Here's the list of Scheme language texts that I have found doing some research for a project...these are not articles in journals, such as SIGPLAN. An Introduction to Scheme Jerry Smith Prentice-Hall 1988 ISBN 0-13-496712-7 The Scheme Programming Language (good) Dybvig, R.K. Prentice-Hall 1987 ISBN 0-13-7918864-X and, of course: Structure and Interpretation of Computer Programs Abelson, H. & Sussman G.J. MIT Press 1985 ISBN 0-07-000426-9 which is really a programming text with Scheme as the language used by the authors to implement the programming techniques they introduce. The dialects used in each book are: PC-Scheme for Smith (i believe) Chez for Dybvig MIT for Abelson & Sussman and there are other dialects running around also, such as X-Scheme C Scheme, and MacIntosh Scheme. Plus there are probably others that I ignore because they run on machines which, as a WPI student, I do not have access. Dybvig has a summary of forms (for Chez), and also states whether or not the form is essential or optional in the "Revised^3 Report on the Algorithmic Language Scheme". Which can be found also in: SigPlan Notices 21, 12, December 1986 Jonathan Rees, and William Clinger, eds. Enjoy! the GiMP.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Aug 89 22:49:36 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa17482; 21 Aug 89 22:44 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 21 Aug 89 22:12:28 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: 22 Aug 89 01:46:47 GMT From: Eric Raible Organization: NASA Ames Research Center, Moffett Field, CA Subject: bug in interrupting xscheme read (for unix) Message-Id: <2927@amelia.nas.nasa.gov> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Hopefully my previous post didn't get out... but I have fixed the bug in xscheme 0.16 whereby interrupting read could cause an uninterruptable infinite loop. To fix it simply call osflush from unixstuff.c:osinterrupts. - Eric (raible@orville.nas.nasa.gov)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Aug 89 00:49:36 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa09300; 19 Aug 89 0:43 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 19 Aug 89 00:35:06 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: 19 Aug 89 02:58:33 GMT From: "Jack J. Woehr" Organization: Whole Earth 'Lectronic Link, Sausalito, CA Subject: Don't Read This If You Get Tired Easily At Whiney Requests Message-Id: <13213@well.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu blah, blah, blah, latest version on Amiga? blah blah blah ...  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Aug 89 14:48:10 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa28821; 18 Aug 89 14:43 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 18 Aug 89 13:52:18 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: 18 Aug 89 17:34:34 GMT From: Bob Sutterfield Organization: The Ohio State University Dept of Computer & Information Science Subject: Re: Cscheme posting Message-Id: References: <6592@cognos.UUCP>, <8907241613.AA01903@zurich.ai.mit.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <8907241613.AA01903@zurich.ai.mit.edu> cph@ZURICH.AI.MIT.EDU (Chris Hanson) writes: In article <6592@cognos.UUCP> rossj@cognos.UUCP (Ross Judson) writes: A month or two ago I read that somebody planned on posting the most recent version... Unfortunately, I am unable to ftp... So posting is the only way I'll see it. There is no chance that anyone will post CScheme -- the current distribution is 6 megabytes in size, over 2 megabytes when compressed. You will have to find someone who has a copy and can get it to you. I have updated the C Scheme on osu-cis to 7.0, available for anonymous UUCP. Though it's pretty huge, we now have a TB+ and a V.32 that should help keep your costs down when you call for it. Write to osu-cis!uucp (same as uucp@cis.ohio-state.edu) for instructions if you don't already know how to get the current set. (BTW, it's not at all safe to say that "there's no chance" of something stupid happening in the Usenet - someone, somewhere, will gladly prove you wrong. :-)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Aug 89 17:34:58 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa11131; 17 Aug 89 17:29 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 17 Aug 89 16:40:51 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: 17 Aug 89 19:48:15 GMT From: Ulf Dahlen Organization: CIS Dept, Univ of Linkoping, Sweden Subject: Re: "Scheme has data types and Lisp doesn't." Message-Id: <1334@majestix.ida.liu.se> References: <711@skye.ed.ac.uk>, <13120@well.UUCP>, <737@skye.ed.ac.uk> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <737@skye.ed.ac.uk> jeff@aiai.uucp (Jeff Dalton) writes: >In article <13120@well.UUCP> nagle@well.UUCP (John Nagle) writes: >>Common LISP has lots of declarations. But the programmer isn't required >>to provide them and the compiler implementor isn't required to make them >>do much. CLTL: [...] Not that SCHEME is really all that different. > >I knew about all of the things you cite in CLtL. I still don't see >how it explains the claim that "Scheme has data types and Lisp doesn't." > >-- Jeff Well, the claim is false! __________ Ulf Dahlen Dept of Computer & Info Science, University of Linkoping, Sweden Troskaregatan 51:23 | uda@ida.liu.se S-583 30 LINKOPING | uda@majestix.liu.se, uda@liuida.UUCP SWEDEN | {mcvax,munnari,seismo}!enea!liuida!uda "The beginning is a very delicate time."  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Aug 89 10:13:52 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05381; 17 Aug 89 9:42 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 17 Aug 89 08:56:53 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: 17 Aug 89 04:31:22 GMT From: "Luiz H. deFigueiredo" Organization: Computer Systems Group, University of Waterloo Subject: Re: X Scheme availability Message-Id: <387@maytag.waterloo.edu> References: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article talvola@janus.berkeley.edu (Erik Talvola) writes: > > I have a rather old version of X-Scheme on my IBM PC (version 0.16) and >was wondering where I could obtain the most recent version, in both source >and object form. Availability by FTP would be nice, but if not, then a >BBS source would be fine. Thanks in advance. > Is there a newer version? I'd like a copy too. ------------------------------------------------------------------------------- Luiz Henrique de Figueiredo internet: lhf@aries5.waterloo.edu Computer Systems Group bitnet: lhf@watcsg University of Waterloo (possible domains are waterloo.edu and uwaterloo.ca) -------------------------------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Aug 89 09:58:31 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa29781; 16 Aug 89 22:43 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 16 Aug 89 22:24:47 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: 17 Aug 89 00:57:04 GMT From: jdm Organization: Hodge Computer Research Corporation Subject: New to scheme Message-Id: <21508@hodge.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I am a C programmer new to scheme and I'd like to know what are the major texts/documents and interpreter packages used in the scheme world. I use a PC and a Sun 386i. Thanks, -- "I'm an anthropologist, not a computer systems architect, damit!" jdm@hodge.cts.com [uunet zardoz crash]!hodge!jdm James D. Murray, Ethnounixologist TEL: (714) 998-7750 Ext. 129 Hodge Computer Research Corporation FAX: (714) 921-8038 1588 North Batavia Street Orange, California 92667 USA  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Aug 89 21:23:06 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa29101; 16 Aug 89 21:16 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 16 Aug 89 19:13:07 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: 15 Aug 89 14:52:37 GMT From: Jeff Dalton Organization: AIAI, University of Edinburgh, Scotland Subject: Re: "Scheme has data types and Lisp doesn't." Message-Id: <737@skye.ed.ac.uk> References: <13046@well.UUCP>, <711@skye.ed.ac.uk>, <13120@well.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <13120@well.UUCP> nagle@well.UUCP (John Nagle) writes: >Common LISP has lots of declarations. But the programmer isn't required >to provide them and the compiler implementor isn't required to make them >do much. CLTL: [...] Not that SCHEME is really all that different. I knew about all of the things you cite in CLtL. I still don't see how it explains the claim that "Scheme has data types and Lisp doesn't." -- Jeff  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Aug 89 19:50:07 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa28181; 16 Aug 89 19:45 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 16 Aug 89 17:11:22 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: 16 Aug 89 20:29:17 GMT From: Erik Talvola Organization: U.C. Berkeley Subject: X Scheme availability Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I have a rather old version of X-Scheme on my IBM PC (version 0.16) and was wondering where I could obtain the most recent version, in both source and object form. Availability by FTP would be nice, but if not, then a BBS source would be fine. Thanks in advance. -- +----------------------------+ ! Erik Talvola | "It's just what we need... a colossal negative ! talvola@janus.berkeley.edu | space wedgie of great power coming right at us ! ...!ucbvax!janus!talvola | at warp speed." -- Star Drek  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Aug 89 14:53:55 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21825; 16 Aug 89 12:13 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 16 Aug 89 11:41:32 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: 16 Aug 89 15:28:04 GMT From: Kevin Spier Organization: RPI CS Dept. Subject: Additional function libraries for PC-Scheme... Message-Id: <6802@rpi.edu> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu I am looking for any public domain function libraries (in source form only) available for PC Scheme v3.0 (which is R^3 compatible). I guess any library which requires only R^3 compatibility would also be fine. Please mail directly to me and I will post a summary if others are interested. Thanks, Kevin L. Spier spierk@turing.cs.rpi.edu Kevin L. Spier spierk@turing.cs.rpi.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Aug 89 14:53:49 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21820; 16 Aug 89 12:13 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 16 Aug 89 11:25:22 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: 16 Aug 89 14:58:49 GMT From: Adam Glass Organization: MIT Media Lab, Cambridge, MA Subject: Re: Books on Scheme Message-Id: <493@mit-amt.MEDIA.MIT.EDU> References: <261@his.UUCP> Sender: scheme-request@MC.lcs.mit.edu To: scheme@MC.lcs.mit.edu jonas@his.UUCP (Jonas 'Gamemaster' Mellin) writes: > Does anyone know a good book about Scheme? > > Please answer via E-mail. Please answer via a public message in this newsgroup. I am quite interested also. Adam -- "Offer me anything I ask for..." "Anything you want." "I want my father back, you son of a bitch." - The Princess Bride  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Aug 89 12:42:36 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18433; 16 Aug 89 6:12 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 16 Aug 89 06:00:58 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: 15 Aug 89 17:43:18 GMT From: Jonas 'Gamemaster' Mellin Organization: Hogskolan i Skovde, Skovde, Sweden Subject: Books on Scheme Message-Id: <261@his.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anyone know a good book about Scheme? Please answer via E-mail.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Aug 89 10:35:24 EDT Received: from A.GP.CS.CMU.EDU by mintaka.lcs.mit.edu id aa18074; 16 Aug 89 5:17 EDT Date: Wed, 16 Aug 89 05:16:39 EDT From: Olin.Shivers@a.gp.cs.cmu.edu To: scheme%mc.lcs.mit.edu@lcs.mit.edu Subject: Lisp shells Message-ID: <8908160517.aa18074@mintaka.lcs.mit.edu> John Lacey requested information on Lisp shells. John Ellis implemented a shell for a PDP-11/45 running Unix in Harvard Lisp in 1979. "A LISP SHELL" John R. Ellis ACM SIGPLAN Notices, Vol. 15 #5, May 1980 John Levine has a paper about using Lisp for a command language in the same issue of SIGPLAN Notices ("Why a Lisp-Based Command Language?"). Of course, you might do well to look into the Lisp Machine interface, both before and after the fancy Symbolics interface that allowed non-Lisp-syntax commands. Any you might consider gnu-emacs plus all the extensions (like monkey mode) to be a fairly reasonable shell, with lisp as an extension language. -Olin  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Aug 89 17:17:33 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa27854; 14 Aug 89 17:12 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 14 Aug 89 17:08:21 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: 14 Aug 89 19:14:43 GMT From: Eric Raible Organization: NASA Ames Research Center, Moffett Field, CA Subject: xscheme code wanted/offered Message-Id: <2855@amelia.nas.nasa.gov> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I'm looking for a bytecode dumper/loader for xscheme. I written some low-level stuff for 1) calling C functions 2) dynamically loading C functions (on an Iris 4D, but pretty generic) 3) accessing and setting C variables 4) some support for accessing and setting elements of C structures (by parsing the structure definitions) In addition, I've got some simple error-handling stuff, fluid-let, a break macro, with-input-from-file, with-output-to-file, and some other stuff. All of this stuff is public domain - mail to me for more info or code. Eric Raible (raible@orville.nas.nasa.gobv)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Aug 89 04:15:48 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa22028; 14 Aug 89 4:12 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 14 Aug 89 03:48:24 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: 13 Aug 89 18:31:49 GMT From: John Nagle Subject: Re: "Scheme has data types and Lisp doesn't." Message-Id: <13120@well.UUCP> References: <9085@thorin.cs.unc.edu>, <13046@well.UUCP>, <711@skye.ed.ac.uk> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <711@skye.ed.ac.uk> jeff@aiai.uucp (Jeff Dalton) writes: >In article <13046@well.UUCP> nagle@well.UUCP (John Nagle) writes: >> It's more of an MIT vs the rest of the LISP world tradition. I think of MIT as favoring strong typing and efficient implementation of math, following the Maclisp tradition. >>Although Common LISP has data type declarations of a sort, they tend >>not to be taken all that seriously by compilers. CLTL is very weak >>on this subject [...] >I find this explanation rather strange. For one thing, Common Lisp >has more in the way of declarations than does Scheme, so I don't see >how Common Lisp's weakness explains why someone would say "Scheme >has data types and Lisp doesn't". Common LISP has lots of declarations. But the programmer isn't required to provide them and the compiler implementor isn't required to make them do much. CLTL: "Declarations allow you to specify extra information about your program to the LISP system. With one exception, declarations are completely optional and correct declarations do not affect the meaning of a correct program." [CLTL, intro to chapt. 9]. Not that SCHEME is really all that different. >Neither Lisp nor Scheme (if we're going to pretend for the moment that >Scheme isn't a kind of Lisp) are strongly typed. Both use dynamic >typing. This is not something introduced by Common Lisp, nor is it >something that's changed in Scheme. Common LISP implementations typically use dynamic typing, and it is mandatory that dynamic typing be supported. The syntax is defined for strong, static typing. But it isn't necessarily connected to anything. In theory, one could have a Common LISP system with typing as strong as Ada's, while retaining the dynamic typing facilities for the occasions on which they are needed. This is consistent with the language definition, although not with LISP history. >> What people tend to actually implement are systems in which all objects >>are "LISP objects", and are still individually allocated and pointed to. >>Defining an array of "short-float" is likely to generate an array of pointers >>to LISP objects. > >That varies from implementation to implementation. Yes. KCL does it the slow, general way. Lucid did until at least late 1987, I think. I happened to be doing a number-crunching implementation in LISP in 1987, and was irked that I couldn't get efficient matrix math in any available LISP for Sun 3 iron. John Nagle  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 10 Aug 89 08:15:38 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa29942; 10 Aug 89 8:12 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 10 Aug 89 07:20:34 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: 10 Aug 89 03:03:58 GMT From: John Gateley Organization: TI Computer Science Center, Dallas Subject: Re: "Scheme has data types and Lisp doesn't." Message-Id: <87107@ti-csl.csc.ti.com> References: <9085@thorin.cs.unc.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <9085@thorin.cs.unc.edu> bts@evergreen.cs.unc.edu (Bruce Smith) writes: >I hope someone here can explain the origin of this notion that >"Scheme has data types and Lisp doesn't". Probably this statement refers to older dialects of Lisp which used dynamic scoping, making static type inference difficult. Also, older lisp dialects tended to do everything with cons, as opposed to vectors etc. As for Scheme vs. Common Lisp, the main differences are Common Lisp has more available data types (such as displaced arrays) and CL also gives the user some tools for manipulating/enforcing types (declare, typep, subtypep etc.) >Most recently, in a discussion of which functional programming >language should be taught to students (not at UNC, by the way) >I heard that Scheme was to be preferred because compiled Scheme >executes much faster than compiled Common Lisp. The reason for >that difference? Because, of course, "Scheme has data types >and Lisp doesn't." I don't believe this (and I currently maintain both Scheme and CL compilers). CL could potentially execute slower than Scheme because it has more features (like keyword arguments, sequence functions, etc). However, if you compare CL programs with these feature to Scheme programs which "are the same", then usually the CL programs are more efficient. This is because the compiler knows about the extra features and most of the time has efficient ways of doing them. Hope this helps, John gateley@m2.csc.ti.com  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 10 Aug 89 06:17:26 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa29234; 10 Aug 89 6:11 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 10 Aug 89 06:04:37 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: 9 Aug 89 16:52:53 GMT From: Jeff Dalton Organization: AIAI, University of Edinburgh, Scotland Subject: Re: "Scheme has data types and Lisp doesn't." Message-Id: <711@skye.ed.ac.uk> References: <9085@thorin.cs.unc.edu>, <13046@well.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <13046@well.UUCP> nagle@well.UUCP (John Nagle) writes: > It's more of an MIT vs the rest of the LISP world tradition. >Although Common LISP has data type declarations of a sort, they tend >not to be taken all that seriously by compilers. CLTL is very weak >on this subject [...] There's a faction in the LISP world that feels that >floating point is unimportant. The strongest expression of this feeling >was in the early Symbolics machines, which lacked floating point hardware. >Much of the weakness on typing in Common Lisp reflects lobbying from the >Symbolics faction, which generally supported the idea that everything >possible should be dynamic. I find this explanation rather strange. For one thing, Common Lisp has more in the way of declarations than does Scheme, so I don't see how Common Lisp's weakness explains why someone would say "Scheme has data types and Lisp doesn't". Neither Lisp nor Scheme (if we're going to pretend for the moment that Scheme isn't a kind of Lisp) are strongly typed. Both use dynamic typing. This is not something introduced by Common Lisp, nor is it something that's changed in Scheme. You might say this is Lisp (and Scheme) vs the rest of the world, except that there are other languages that work in the same way. But I don't think it's MIT vs the rest of the world. MacLisp was known for the efficient numeric code generated by its compiler, for example. CLtL certainly seems to take floating point seriously and describes a reather elaborate set of floating point facilities in detail. There are a number of reason why Symbolics may not have had floating point initially. But floating point is hardly the only case where type information can lead to more efficient code on "conventional machines". Because Symbolics machines have a hardware (microcode?) type dispatch, type declarations don't help on their machines. It could be argued that this is truer to the spirit of Lisp. But in any case, Lisp has never been a strongly typed language, so I don't see how that can be due to Symbolics. > Reading section 4.5 of CLTL (Common Lisp, the Language) will give >you a good feeling of the weakness of the commitment to strong typing >in Common Lisp. It's stronger than in most other Lisps and stronger than in Scheme. > What people tend to actually implement are systems in which all objects >are "LISP objects", and are still individually allocated and pointed to. >Defining an array of "short-float" is likely to generate an array of pointers >to LISP objects. That varies from implementation to implementation. >Declaring an argument to a function to be of a specific >type may turn off some checking. That varies too. But these things also vary in Scheme.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 9 Aug 89 22:14:41 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa24308; 9 Aug 89 22:11 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 9 Aug 89 21:09:06 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: 10 Aug 89 00:05:06 GMT From: "Peter R. Ham" Organization: Stanford University Subject: functional command shells? Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Are any of these shells, like fsh, available? -- Peter Ham PO Box 3430 (h)(415) 324-9645 MS Computer Science Student Stanford, CA ham@polya.stanford.edu Stanford University 94309 (o)(415) 723-2067  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 9 Aug 89 12:33:31 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa16693; 9 Aug 89 12:29 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 9 Aug 89 12:22:56 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: 9 Aug 89 16:00:44 GMT From: Dan Weinreb Subject: Re: "Scheme has data types and Lisp doesn't." Message-Id: <410@odi.ODI.COM> References: <9085@thorin.cs.unc.edu>, <13046@well.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <13046@well.UUCP> nagle@well.UUCP (John Nagle) writes: This is very confused. It's hard to know where to begin. It's more of an MIT vs the rest of the LISP world tradition. If you are contrasting Lisp and Scheme, it's hard to see how this can be a conflict between MIT and the rest of the Lisp world. Scheme is from MIT. Traditionally, the Lisps with the best numeric support, compared to other Lisps, are *also* from MIT (particularly the NCOMPLR for Maclisp). Although Common LISP has data type declarations of a sort, they tend not to be taken all that seriously by compilers. This is not the case. Many major Lisp compilers for standard hardware, such as Lucid and Franz, pay close attention to numeric declarations, and produce far better numeric code when the declarations are present. CLTL is very weak on this subject: Yes; this is intentional. The idea is to accomodate both standard hardware, for which the declarations are needed, and Lisp machines, for which they are superfluous. There's a faction in the LISP world that feels that floating point is unimportant. The strongest expression of this feeling was in the early Symbolics machines, which lacked floating point hardware. What? The reason that the Symbolics LM-2 lacked floating point hardware had nothing to do with a "strong expression of a feeling"; it was due to marketing timing and economics. The LM-2 was just a repackaged MIT prototype, and the idea was to get it shipped as fast as possible, reserving improvements for later hardware platforms. Machines that were actually designed by Symbolics all had floating point accelerators, generally based on Weitek floating point chips. Symbolics typically did very well in Lisp floating point benchmarks. Furthermore, I know of no "faction" anywhere in the Lisp world that claims that floating point is unimportant. Much of the weakness on typing in Common Lisp reflects lobbying from the Symbolics faction, which generally supported the idea that everything possible should be dynamic. That the language should not REQUIRE declarations. And it didn't require any lobbying; the conventional-hardware faction agreed with the philosophy that declarations should be optional hints from the user to the compiler. Guy Steele, Richard Gabriel, and Scott Fahlman never have advocated mandatory declarations of the types of variables in Lisp. There was plenty of lobbying during the design of Common Lisp, but not about this point. Reading section 4.5 of CLTL (Common Lisp, the Language) will give you a good feeling of the weakness of the commitment to strong typing in Common Lisp. You bet. There is no committment to "strong typing" (typed variables) in Common Lisp. This is very much intentional. What people tend to actually implement are systems in which all objects are "LISP objects", and are still individually allocated and pointed to. Yes, in the general case. Defining an array of "short-float" is likely to generate an array of pointers to LISP objects. Nope. Not on Symbolics machines and not on the conventional-machine implementations that I'm aware of. Lisp objects are not always implemented as pointers; they can be stored "immediately". The technique of doing this for numbers is nicknamed "inums" and has been around for at least 15 years. And none of this has anything to do with the original query, since Lisp and Scheme are essentially the same in these regards. Scheme doesn't have typed variables, either.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 09:04:57 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa28862; 8 Aug 89 8:56 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 8 Aug 89 08:44:17 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: 7 Aug 89 15:47:06 GMT From: John Nagle Subject: Re: "Scheme has data types and Lisp doesn't." Message-Id: <13046@well.UUCP> References: <9085@thorin.cs.unc.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu It's more of an MIT vs the rest of the LISP world tradition. Although Common LISP has data type declarations of a sort, they tend not to be taken all that seriously by compilers. CLTL is very weak on this subject: "As an example, consider the type (array short-float). Implementation A may choose to provide a specialized representation for arrays of short floating-point numbers, and implementation B may choose not to." Serious number crunching with implementation B will probably be rather slow. There's a faction in the LISP world that feels that floating point is unimportant. The strongest expression of this feeling was in the early Symbolics machines, which lacked floating point hardware. Much of the weakness on typing in Common Lisp reflects lobbying from the Symbolics faction, which generally supported the idea that everything possible should be dynamic. Reading section 4.5 of CLTL (Common Lisp, the Language) will give you a good feeling of the weakness of the commitment to strong typing in Common Lisp. What people tend to actually implement are systems in which all objects are "LISP objects", and are still individually allocated and pointed to. Defining an array of "short-float" is likely to generate an array of pointers to LISP objects. Declaring an argument to a function to be of a specific type may turn off some checking. John Nagle  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 07:35:25 EDT Received: from BU-IT.BU.EDU by mintaka.lcs.mit.edu id aa28208; 8 Aug 89 7:28 EDT Received: from BUCSF.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA04158; Tue, 8 Aug 89 07:28:20 EDT Received: by bucsf (4.12/4.7) id AA27496; Tue, 8 Aug 89 07:30:20 edt Date: Tue, 8 Aug 89 07:30:20 edt From: "George J. Carrette" Message-Id: <8908081130.AA27496@bucsf> To: scheme@mc.lcs.mit.edu Subject: opinions wanted: scheme book. A scheme programming course should not require a book on scheme. You just give a good definition of the language during the first 15 minutes of the first lecture, then give a couple examples of how to construct a procedure or two, then assign the first home work.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 06:34:52 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa27879; 8 Aug 89 6:28 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 8 Aug 89 06:23:26 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: 7 Aug 89 11:00:26 GMT From: Jeff Dalton Organization: AIAI, University of Edinburgh, Scotland Subject: Re: "Scheme has data types and Lisp doesn't." Message-Id: <690@skye.ed.ac.uk> References: <9085@thorin.cs.unc.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <9085@thorin.cs.unc.edu> bts@evergreen.cs.unc.edu (Bruce Smith) writes: >I heard that Scheme was to be preferred because compiled Scheme >executes much faster than compiled Common Lisp. The reason for >that difference? Because, of course, "Scheme has data types >and Lisp doesn't." Some people out there still think "everything in Lisp is a list". Maybe that's it. Of course, it's not true that everything _is_ a list, in Common Lisp or Scheme. Jeff Dalton, JANET: J.Dalton@uk.ac.ed AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Aug 89 15:33:52 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa17808; 7 Aug 89 15:26 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 7 Aug 89 14:57:27 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: 7 Aug 89 13:35:43 GMT From: "Mark W. Bailey" Organization: University of Virginia, Charlottesville, VA 22903 Subject: Opinions wanted. Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu We looking for a good book on Scheme to use in a graduate programming languages course. I've found "The SCHEME programming language" by Dybvig, but I don't have access to a copy. I'd like information on this or any other books that are available. Please send e-mail. Mark W. Bailey mwb5y@virginia.edu Computer Science University of Virginia  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Aug 89 15:57:56 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07152; 6 Aug 89 15:56 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 6 Aug 89 15:37:08 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: 6 Aug 89 18:55:51 GMT From: Bruce Smith Subject: Re: "Scheme has data types and Lisp doesn't." Message-Id: <9085@thorin.cs.unc.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I hope someone here can explain the origin of this notion that "Scheme has data types and Lisp doesn't". I have heard several people make this claim over the past couple of years, but never with any concrete evidence nor even a clear explanation of what it's supposed to mean. (It was usually in almost exactly those words, however.) I know a modest amount about these languages and have access to references on them. I have not been able figure out what it is supposed to mean. Most recently, in a discussion of which functional programming language should be taught to students (not at UNC, by the way) I heard that Scheme was to be preferred because compiled Scheme executes much faster than compiled Common Lisp. The reason for that difference? Because, of course, "Scheme has data types and Lisp doesn't."  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Aug 89 13:08:17 EDT Received: from A.GP.CS.CMU.EDU by mintaka.lcs.mit.edu id aa08112; 2 Aug 89 21:22 EDT Date: Wed, 2 Aug 89 21:22:14 EDT From: Olin.Shivers@a.gp.cs.cmu.edu To: scheme%mc.lcs.mit.edu@lcs.mit.edu Subject: Lisp shells Message-ID: <8908022122.aa08112@mintaka.lcs.mit.edu> John Lacey requested information on Lisp shells. John Ellis implemented a shell for a PDP-11/45 running Unix in Harvard Lisp in 1979. "A LISP SHELL" John R. Ellis ACM SIGPLAN Notices, Vol. 15 #5, May 1980 John Levine has a paper about using Lisp for a command language in the same issue of SIGPLAN Notices ("Why a Lisp-Based Command Language?"). Of course, you might do well to look into the Lisp Machine interface, both before and after the fancy Symbolics interface that allowed non-Lisp-syntax commands. -Olin  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 31 Jul 89 16:34:51 EDT Received: from inria.inria.fr by mintaka.lcs.mit.edu id aa26746; 31 Jul 89 4:48 EDT Received: by inria.inria.fr (5.61+/89.0.8) via Fnet-EUnet id AA06460; Mon, 31 Jul 89 09:40:22 +0200 (MET) From: adams@daisy.cge.fr Received: by crcge1.cge.fr, Mon, 31 Jul 89 09:39:43 +0200 Date: Mon, 31 Jul 89 09:39:42 +0200 Received: by zephir.cge.fr, Mon, 31 Jul 89 09:39:42 +0200 Message-Id: <8907310739.AA06479@zephir.cge.fr> To: Scheme@mc.lcs.mit.edu Subject: Re: Scheme Digest #171 Cc: adams@zephir I would be quite interested in your project to write a shell etc. based on a functional framework. I would also be interested in more info on FSH (I remember reading the Software: Pract. & Exp. paper when it came out). Would you please keep me posted. Regards, Drew ADAMS, Laboratoires de Marcoussis, Centre de Recherches de la Compagnie Generale d'Electricite, Route de Nozay, 91460 MARCOUSSIS, FRANCE Tel. +33 (1) 64.49.11.54, adams@crcge1.cge.fr ["one", not "ell"]  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jul 89 21:35:42 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa26135; 28 Jul 89 15:16 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 28 Jul 89 14:45:13 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: 28 Jul 89 18:15:47 GMT From: John Lacey Organization: Cornell Theory Center, Cornell University, Ithaca NY Subject: Inquiry about functional command shells Message-Id: <8512@batcomputer.tn.cornell.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu This coming fall I am going to embark on a programming project to build a UNIX shell based on a functional programming paradigm. My initial inclination is to build the shell from a Lisp interpreter/compiler---options so far include MIT Scheme, Yale T, and perhaps XScheme or the recently mentioned ELK embedded Scheme. The main purpose is to combine the command and programming languages of the environment into a single system. That is, the shell language would not only be similar to the programming language, it would _be_ the programming language. So far, I have found several references to similar projects, and I would like to find further references, as well as any comments about the project or the language that anyone might have. The most promising reference that I have is _fsh - A Functional UNIX Command Interpreter_, by Chris S. McDonald Univ. of Western Australia It appeared in Software: Practice and Experience, 17 (10) 685-700 (1987). If anyone knows more about this project, or has used a similar shell, I would greatly appreciate hearing from you. Thanks, -- John Lacey | cornell!batcomputer!lacey lacey@tcgould.tn.cornell.edu | lacey@crnlthry.bitnet  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jul 89 21:31:06 EDT Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa24801; 28 Jul 89 13:36 EDT Received: from unido.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA12511; Fri, 28 Jul 89 13:35:24 -0400 Received: from tub.uucp by unido.informatik.uni-dortmund.de with uucp via EUnet for uunet id AO21115; Fri, 28 Jul 89 14:14:38 +0100 Received: by tub.UUCP; Fri, 28 Jul 89 15:09:46 +0200; AA26250 Date: Fri, 28 Jul 89 15:09:46 +0200 From: Oliver Laumann Message-Id: <8907281309.AA26250@tub.UUCP> To: uunet!mc.lcs.mit.edu!scheme@uunet.uu.net Subject: Equivalence predicates The Revised^n Report on Scheme does not specify the result of eq?, eqv?, and equal? applied to ports and end-of-file objects. Is this intentional? E.g. what is the result of (equal? (read) (read)) provided that both reads return an end-of-file object? Regards, -- Oliver Laumann net@TUB.BITNET net@tub.UUCP  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 12:15:22 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa10357; 27 Jul 89 12:11 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 27 Jul 89 11:51:52 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 Jul 89 13:19:26 GMT From: Oliver Laumann Organization: Technical University of Berlin, Germany Subject: Elk (Extension Language Kit) submitted to comp.sources.unix Message-Id: <883@tub.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I would like to announce the posting of Elk (the Extension Language Kit) to comp.sources.unix. Elk is a Scheme interpreter intended to be used as a general extension language interpreter. Interfaces to the X11R3 Xlib and the Athena and HP widget sets are part of the distribution. This might also be of interest to the readers of comp.soft-sys.andrew because of the recent discussion about extension languages. Attached to this article you will find a copy of the release notes. Regards, -- Oliver Laumann net@TUB.BITNET net@tub.UUCP ----------------------------------------------------------------------- Elk Release Notes ----------------- This is release 1.0 of Elk (The Extension Language Kit). This is a production release. Elk is a Scheme interpreter intended to be used as a general extension language; it is also useful as a stand-alone implementation of Scheme. One purpose of the Elk project is to end the recent proliferation of mutually incompatible Lisp-like extension languages. Instead of inventing and implementing yet another extension language, application programmers can link the Scheme interpreter into their application in order to make it extensible and highly customizable. The Elk project was started in 1987 to support ISOTEXT, an ODA-based document system (a WYSIWYG editor) that is being developed at the Technical University of Berlin. Elk has been successfully demonstrated as the extension language kernel of ISOTEXT, e.g. at the Hanover Fair 1989. We feel that Scheme is better suited as a general extension language than other Lisp dialects: it is sufficiently small to not dwarf the application it serves and to be fully understood with acceptable effort; it is orthogonal and well-defined. In addition, Scheme has been recognized to be mature enough for national and international standardization (IEEE P1178, ISO/IEC JTC1/SC22/WG16). The Elk Scheme interpreter is R^3RS compatible (with some minor exceptions listed in a separate document); future releases will conform to the R^4RS and/or P1178 as soon as the respective standards become available. Non-standard features of the Scheme implementation include: o dynamic loading of object files o creation of an executable image from the running interpreter (``unexec'') o a macro facility o environments as first-class objects o dynamic-wind, fluid-let o autoloading, provide/require The Scheme interpreter can easily be extended by application-specific new types and primitive procedures. Such extensions are typically written in C or C++ and dynamically loaded into the running interpreter. The current release of Elk includes several such extensions, e.g. interfaces to the X11 Xlib and to the application programmer interface of the Xt intrinsics, and interfaces to the Athena widget set and the HP widget set. The software currently runs on Sun-3s with SunOS, ISI 680x0 with 4.2BSD or 4.3BSD, Vax with 4.3BSD or Ultrix, and Intel 80386 with System V Release 3. Porting instructions are included. Dynamic loading of object modules is not supported under System V. -- Oliver Laumann, Technical University of Berlin, Germany Communications and Operating Systems Research Group net@tub.BITNET Europe: unido!tub!net World: pyramid!tub!net  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 01:40:06 EDT Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa02837; 27 Jul 89 1:36 EDT Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA05610; Thu, 27 Jul 89 01:32:29 EDT Received: from localhost by zurich.ai.mit.edu; Thu, 27 Jul 89 01:29:10 edt Date: Thu, 27 Jul 89 01:29:10 edt From: Chris Hanson Message-Id: <8907270529.AA26430@zurich.ai.mit.edu> To: info-cscheme@zurich.ai.mit.edu, scheme@zurich.ai.mit.edu, knish@hpcllld.hp.com, gball%arizrvax.bitnet@mitvma.mit.edu, wisdom@zurich.ai.mit.edu Cc: randy@zurich.ai.mit.edu Subject: Scheme Release 7 Beta Test The secondary host for distribution of Scheme Release 7 is the host "prep.ai.mit.edu" (internet address 18.71.0.38). Use anonymous ftp and look in the directory "pub/gnu/scheme-7.0/". At present, due to space restrictions, this secondary site carries only the minimum required installation files. None of the optional files for source, documentation, etc. will fit there. If feasible, we will make the rest of the distribution available there in the future.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 01:04:40 EDT Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa02436; 27 Jul 89 0:59 EDT Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA05442; Thu, 27 Jul 89 00:55:52 EDT Received: from localhost by zurich.ai.mit.edu; Thu, 27 Jul 89 00:52:27 edt Date: Thu, 27 Jul 89 00:52:27 edt From: Chris Hanson Message-Id: <8907270452.AA26278@zurich.ai.mit.edu> To: info-cscheme@zurich.ai.mit.edu, scheme@zurich.ai.mit.edu, knish@hpcllld.hp.com, gball%arizrvax.bitnet@mitvma.mit.edu, wisdom@zurich.ai.mit.edu Subject: Scheme Release 7 Beta Test MIT Scheme release 7 is now available for beta test. This release contains many notable changes: * Liar, the native code compiler, is supported for 68020 and Vax computers. Rough performance measurements indicate that it produces code that is competitive with Orbit and Lucid Common Lisp (although there's still some work left to beat them consistently). High-quality debugging support is standard -- the debugger provides nearly the same information for compiled and interpreted code. * Edwin, the Emacs-like text editor, is supported under curses and X version 11. Unlike the stripped-down version supplied with TI PC-Scheme, this is a fully-extensible editor with most of the GNU Emacs features. Due to performance considerations it is likely to be useful only on machines that have compiler support. * A reference manual, written in Texinfo, is supplied. The manual is still incomplete but even so documents a substantial part of the system. Because it is written in Texinfo, it can be either printed or browsed on-line with the Edwin (or GNU Emacs) info subsystem. * Two-dimensional line and point graphics support for X version 11 is standard. Color, border, size, and position controls are provided. Because this is a beta test, users should expect the installation to be less than completely smooth. Although we have done extensive debugging here at MIT, you should expect bugs as well. We solicit your bug reports, criticisms, and any other comments about the release. A few important things are still missing, including: (1) detailed documentation for using the compiler and editor, and (2) a compatibility mode for S&ICP classes. We hope to remedy these, and many other defects, by the end of August when the full release will occur. We've tested installation on the following machines, and would greatly appreciate any efforts that you could make getting things running on any other machines: HP 9000 series 300 and 800 running HP-UX Sun3 running SunOS Vax running Ultrix DS3100 running Ultrix This release may be obtained by anonymous ftp to "zurich.ai.mit.edu" (internet address 18.26.0.176), from the directory "pub/scheme-7.0/". See the README file in that directory for further directions. Because a number of people have had trouble using ftp to that machine, we plan to distribute from a second host. When we have an alternate host, it will be announced. We will not be mailing tapes of this release until the beta test has finished and the full release is out; however if you show up at MIT with a 9-track magtape we'll be happy to put the software on it. As usual, report bugs to bug-cscheme@zurich.ai.mit.edu If you receive this message from another source, and would like to be included on the MIT Scheme mailing list, please send a request to info-cscheme-request@zurich.ai.mit.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jul 89 23:31:30 EDT Received: from relay.cs.net by mintaka.lcs.mit.edu id aa17270; 25 Jul 89 23:27 EDT Received: from relay2.cs.net by RELAY.CS.NET id ae27477; 25 Jul 89 23:27 EDT Received: from zix.gmd.dbp.de by RELAY.CS.NET id el02619; 25 Jul 89 23:22 EDT Received: from zix.gmd.dbp.de by .zix.gmd.dbp.de id a004392; 25 Jul 89 20:14 MET Date: 25 Jul 89 19:10 GMT+0100 From: Guenther Goerz To: scheme@mc.lcs.mit.edu Message-ID: <44:goerz@rz.informatik.uni-hamburg.dbp.de> Subject: equal? Bug in PC Scheme There seems to be a bug in PC Scheme's (ver. 3.03) EQUAL?: If you ask whether the empty vector equals the empty vector, it says false. (equal? #() #()) => () Vector is the only datatype where this happens. ---Guenther  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Jul 89 12:18:37 EDT Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22516; 24 Jul 89 12:16 EDT Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA29698; Mon, 24 Jul 89 12:16:45 EDT Received: from localhost by zurich.ai.mit.edu; Mon, 24 Jul 89 12:13:33 edt Date: Mon, 24 Jul 89 12:13:33 edt From: Chris Hanson Message-Id: <8907241613.AA01903@zurich.ai.mit.edu> To: jarvis.csri.toronto.edu!utgpu!utzoo!dciem!nrcaer!sce!cognos!rossj@rutgers.edu Cc: scheme@zurich.ai.mit.edu In-Reply-To: Ross Judson's message of 19 Jul 89 13:54:30 GMT <6592@cognos.UUCP> Subject: Cscheme posting Date: 19 Jul 89 13:54:30 GMT From: Ross Judson As I understand it, Cscheme is a free (I hope!) implementation of the scheme language. A month or two ago I read that somebody planned on posting the most recent version. Has this been done? What's the status? Unfortunately, I am unable to ftp, and, due to mailer screwups, unable to mail out of this site at all. So posting is the only way I'll see it. Does anybody from Ottawa or the region have it? I'd like to get in touch if you do. -- uucp - uunet!mitel!sce!cognos!rossj |people hate the generator arpa/internet - rossj%cognos.uucp@uunet.uu.net |but love to light up the sky There is no chance that anyone will post CScheme -- the current distribution is 6 megabytes in size, over 2 megabytes when compressed. You will have to find someone who has a copy and can get it to you. A useful piece of information: GNU Emacs tapes ordered from the Free Software Foundation contain the current release of CScheme. If you have a copy of GNU Emacs that was obtained from such a tape, then you should also have CScheme. (Note that CScheme is not included in the FTP distribution of Emacs.)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jul 89 07:04:54 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa29728; 22 Jul 89 6:57 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 22 Jul 89 06:50:10 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: 19 Jul 89 13:54:30 GMT From: Ross Judson Organization: Cognos Inc., Ottawa, Canada Subject: Cscheme posting Message-Id: <6592@cognos.UUCP> References: <9447@phoenix.Princeton.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu As I understand it, Cscheme is a free (I hope!) implementation of the scheme language. A month or two ago I read that somebody planned on posting the most recent version. Has this been done? What's the status? Unfortunately, I am unable to ftp, and, due to mailer screwups, unable to mail out of this site at all. So posting is the only way I'll see it. Does anybody from Ottawa or the region have it? I'd like to get in touch if you do. -- uucp - uunet!mitel!sce!cognos!rossj |people hate the generator arpa/internet - rossj%cognos.uucp@uunet.uu.net |but love to light up the sky  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 17:46:50 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21662; 21 Jul 89 17:42 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 21 Jul 89 17:03:51 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: 21 Jul 89 17:01:30 GMT From: Suresh Jagannathan Organization: Yale University Computer Science Dept, New Haven CT 06520-2158 Subject: Re: WANTED: information on first class environments Message-Id: <67151@yale-celray.yale.UUCP> References: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article ham@Polya.Stanford.EDU (Peter R. Ham) writes: >I'm interested in first class environments in programming languages >like Scheme. Symmetric Lisp is a programming language whose fundamental program and data structure is a first-class parallel environment. In the symmetric programming model, the representation of programs is identical to the representation of data structures. To specify a computation, the programmer specifies a data structure. The specified data structure can be examined, parameterized, composed with other structures, and projected yet it has the semantics of a naming environment -- it defines a scope and the bindings within it implicitly affect the evaluation of expressions as the program executes. A program in this model is an environment containing reducible expressions; the object returned as the result of evaluating a program is the same environment with each reducible expression replaced by its value. Parallelism is an important part of this model. Whenever two elements of a Symmetric Lisp program occur as separate elements of the same structure, they may evaluate simultaneously (subject only to basic data dependencies). A first-class environment is a non-strict object: a program's components may be examined (since a program is a data structure) even as its other elements continue to evaluate. Non-strictness and first-class environments combine to form an interesting symbiosis; much of the Symmetric Lisp effort has focussed on investigating their interaction. ----- You may be interested in the following references for more information: [1] A Symmetric Language. Yale University TR, DCS-RR/568, May 1989. (I'll be glad to send you a copy if you're interested.) [2] A Programming Language Supporting First-Class Parallel Environments. MIT Laboratory for Computer Science TR-434. December, 1988. (A slightly revised version of my Ph.D thesis of the same title.) [3] Environments as First-Class Object. 14th ACM Symposium on Principles of Programming Languages, Jan. 1987. [4] Parallelism, Persistence and Meta-Cleanliness in the Symmetric Lisp Interpreter. SIGPLAN '87 Conf. on Interpreters and Interpretative Techniques. 1987.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jul 89 14:57:10 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa04128; 20 Jul 89 14:54 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 20 Jul 89 14:28:33 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: 20 Jul 89 17:44:54 GMT From: Duke Briscoe Organization: The Internet Subject: re: Scheme for unix systems Message-Id: <8907201745.AA11540@ATHENA.CS.YALE.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Several people have asked me about the Lisp Pointers publication which I mentioned in my previous posting. It is a free publication which is unrefereed, but usually contains interesting articles. It is sponsored by various generous companies and organizations. It comes out quarterly. According to the information I have, you can get a subscription by sending a note with your name, address, and whether or not your name can be released to a commercial mailing list, to: Lisp Pointers Mary S. Van Deusen, Editor IBM Watson Research PO Box 704 Yorktown Heights, NY 10598 As for getting versions of T by anonymous FTP, I have found out that they are on trix.ai.mit.edu (128.52.32.6), in the directory pub/t3.1. -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jul 89 14:57:05 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa04111; 20 Jul 89 14:53 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 20 Jul 89 14:26:59 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: 20 Jul 89 16:55:00 GMT From: CARLETON.EDU!RKIRCHNE@bloom-beacon.mit.edu Organization: The Internet Subject: emacs and Scheme Message-Id: <8907201548.AA05690@nic.MR.NET> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Is there away to set up emacs so Scheme code can be compiled from within emacs? Franz supplied some files to do this for our Allegro CommonLisp. What about for Scheme?  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jul 89 14:03:43 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03309; 20 Jul 89 13:55 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 20 Jul 89 13:45:28 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: 20 Jul 89 17:06:07 GMT From: "Peter R. Ham" Organization: Stanford University Subject: WANTED: information on first class environments Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I'm interested in first class environments in programming languages like Scheme. I heard something about XScheme including this. Can anyone give me any pointers to XScheme or its documentation or any other systems or papers concerning first class environments? -- Peter Ham PO Box 3430 (h)(415) 324-9645 MS Computer Science Student Stanford, CA ham@polya.stanford.edu Stanford University 94309 (o)(415) 723-2513  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jul 89 14:03:37 EDT Received: from ATHENA.CS.YALE.EDU by mintaka.lcs.mit.edu id aa03254; 20 Jul 89 13:52 EDT Received: by ATHENA.CS.YALE.EDU; Thu, 20 Jul 89 13:45:58 EDT From: Duke Briscoe Full-Name: Duke Briscoe Message-Id: <8907201745.AA11540@ATHENA.CS.YALE.EDU> Received: by yale-hp-crown (leons) via WIMP-MAIL (Version 1.3/1.5) ; Thu Jul 20 13:44:55 Date: Thu, 20 Jul 89 13:44:54 EDT Subject: re: Scheme for unix systems To: Scheme@mc.lcs.mit.edu Several people have asked me about the Lisp Pointers publication which I mentioned in my previous posting. It is a free publication which is unrefereed, but usually contains interesting articles. It is sponsored by various generous companies and organizations. It comes out quarterly. According to the information I have, you can get a subscription by sending a note with your name, address, and whether or not your name can be released to a commercial mailing list, to: Lisp Pointers Mary S. Van Deusen, Editor IBM Watson Research PO Box 704 Yorktown Heights, NY 10598 As for getting versions of T by anonymous FTP, I have found out that they are on trix.ai.mit.edu (128.52.32.6), in the directory pub/t3.1. -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jul 89 13:56:55 EDT Received: from nic.mr.net by mintaka.lcs.mit.edu id aa01909; 20 Jul 89 12:00 EDT Received: from carleton.edu by nic.MR.NET (4.0/SMI-DDN/MRNET-881216) id AA05690; Thu, 20 Jul 89 10:48:16 CDT Message-Id: <8907201548.AA05690@nic.MR.NET> Date: Thu, 20 Jul 89 10:55 CST From: RKIRCHNE@carleton.edu Subject: emacs and Scheme To: Scheme@mc.lcs.mit.edu X-Vms-To: IN%"Scheme%mc.lcs.mit.edu" Is there away to set up emacs so Scheme code can be compiled from within emacs? Franz supplied some files to do this for our Allegro CommonLisp. What about for Scheme?  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Jul 89 11:55:12 EDT Received: from CS-GW.CS.YALE.EDU by mintaka.lcs.mit.edu id aa16364; 19 Jul 89 11:51 EDT Received: by ELI.CS.YALE.EDU; Wed, 19 Jul 89 11:38:59 EDT From: Duke Briscoe Full-Name: Duke Briscoe Message-Id: <8907191538.AA13269@ELI.CS.YALE.EDU> Received: by yale-hp-crown (leons) via WIMP-MAIL (Version 1.3/1.5) ; Wed Jul 19 11:41:25 Date: Wed, 19 Jul 89 11:41:23 EDT Subject: re: Scheme for unix systems To: Scheme@MC.lcs.mit.edu The T language has a Scheme environment which is about 99% compatible with the Scheme standard, based on my recent experience porting several thousand lines of Scheme code to the T system. The quality of the T compiler is very good, producing code which is comparable in speed to Pascal and C. It also adds some useful extensions to Scheme, including multiple return values, a simple object system, debugger and inspector, macros, structures, hash tables. It is available for VAXes, Sun 3, Apollo, HPs, and both parallel and sequential versions for Encore Multimax. According to the information I have from Lisp Pointers Vol. 1, #6, it is available by FTP from some sites at MIT, but I just tried there, and I couldn't find it. Maybe someone else can give the latest info on how to get it. -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Jul 89 18:12:43 EDT Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa06517; 18 Jul 89 18:09 EDT Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA19607; Tue, 18 Jul 89 18:09:30 EDT Received: from localhost by zurich.ai.mit.edu; Tue, 18 Jul 89 18:06:27 edt Date: Tue, 18 Jul 89 18:06:27 edt From: Chris Hanson Message-Id: <8907182206.AA16993@zurich.ai.mit.edu> To: scheme@ai.mit.edu Subject: test message This is a test message, please ignore.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Jul 89 17:08:05 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05844; 18 Jul 89 17:05 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 18 Jul 89 16:37:32 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: 18 Jul 89 20:06:55 GMT From: gwusun!bleen.gwu.edu!stoler@uunet.uu.net Organization: The George Washington University, Washington, D.C. Subject: scheme for unix systems Message-Id: <1418@bleen.gwusun.gwu.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu We are in the process of installing an HP 9000/835se and need to know of an implementation of scheme that runs on said machine. We also need to know of implementations that run on a SUN 3/180 and similar machines. Public domain implementations that can be ftp'd would be nice but commercial products are okay too. Thanks all.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jul 89 17:31:34 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18447; 17 Jul 89 15:04 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 17 Jul 89 15:02:20 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: 17 Jul 89 18:03:02 GMT From: Brian of ASTD-CP Organization: Jet Propulsion Laboratory, Pasadena, CA Subject: Question: "Records" in scheme? Message-Id: <1455@jato.Jpl.Nasa.Gov> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Is there a way to create contiguous-memory aggregate variables in scheme? I'd like to be able to read in some arrays of structs created by a C program (equivalent to arrays of records in Pascal) into scheme, parse & plot them, and translate parts of them into scheme lists / vectors. I guess I could print the data out and read them into scheme data structures, using ASCII as the communication medium, but they're on the big side (several megs) and I'd prefer to read them in "binary format" if possible.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Jul 89 13:18:54 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa01058; 16 Jul 89 11:13 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 16 Jul 89 03:52:21 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: 16 Jul 89 04:18:26 GMT From: "Mario O. Bourgoin" Organization: MIT Media Lab, Cambridge MA Subject: The defintion of TRUE and FALSE in Scheme. Message-Id: <152@mit-amt.MEDIA.MIT.EDU> References: <8907141728.aa02609@mintaka.lcs.mit.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I've been wanting to replace the usual LISP definitions of TRUE and FALSE by functions because that seems more in the spirit of Scheme. Furthermore, with functions we can eliminate ``if'' and ``cond'' from the essential syntax of Scheme which simplifies the analysis of extensions to Scheme such as Zabih, McAllester, and Chapman's non-deterministic operator, ``amb''. I would like to get the Scheme community's reaction to the specification of particular objects for TRUE and FALSE, namely the functions: (define true (lambda (iftrue iffalse) iftrue)) (define false (lambda (iftrue iffalse) iffalse)) Naturally, the constants #t and #f would always denote the appropriate one of these two functions. Given the above definitions for TRUE and FALSE, ``if'' statements can be replaced according to the following pattern: (if predicate iftrue iffalse) => ((predicate (lambda () iftrue) (lambda () iffalse))) And ``cond'' may be replaced thus: (cond (predicate1 body1) (predicate2 body2) (predicate3 body3) (else bodyelse)) becomes: ((predicate1 (lambda () body1) (lambda () ((predicate2 (lambda () body2) (lambda () ((predicate3 (lambda () body3) (lambda () bodyelse))))))))) The logical connectives ``not'', ``and'', and ``or'' could be defined as follows. (not predicate) => (predicate false true) (or predicate1 predicate2) => (predicate1 true predicate2) (and predicate1 predicate2) => (predicate1 predicate2 false) Naturally, the definitions for ``or'' and ``and'' can be extended to handle a variable number of parameters. Please tell me of any problems you see with such a definition. --Mario O. Bourgoin  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Jul 89 13:18:45 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa01049; 16 Jul 89 11:12 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 16 Jul 89 11:04:58 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: 16 Jul 89 14:12:44 GMT From: David W Crabb Organization: Princeton University, NJ Subject: Xscheme object context diffs & sample (425 lines) Message-Id: <9447@phoenix.Princeton.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Since, as far as I know, no solution to the bad behavior of the objects in Xscheme has yet appeared here, I am posting one. Two files are appended to this posting: xschemen.dif tryit.xs The former consists of context diffs for the program PATCH . These must be compiled in order to make the object/class capability of Xscheme, vers. 0.16, work in a manner similar to Xlisp (especially the versions of Xlisp prior to the introduction of "send"). The second file is for trying out some of those capabilities, and is designed to illustrate how close the modification comes to implementing what was presumably the original design idea. Note that very few lines of code need to be added or modified: xscomn.c 1 line added xsintn.c 3 lines added 1 line deleted xsobjn.c 8 lines added 4 lines deleted 4 lines modified ---------------- xschemen.dif ---------------------------------------- *** xscom.c Thu Jul 13 14:50:58 1989 --- xscomn.c Thu Jul 13 15:19:04 1989 *************** *** 1,3 /* xscom.c - a simple scheme bytecode compiler */ /* Copyright (c) 1988, by David Michael Betz All Rights Reserved --- 1,8 ----- + /** modified xlfunction + David W. Crabb (crabb@phoenix.princeton.edu) + July, 1989 + **/ + /* xscom.c - a simple scheme bytecode compiler */ /* Copyright (c) 1988, by David Michael Betz All Rights Reserved *************** *** 101,107 return (pop()); } ! /* xlfunction - compile a function */ LVAL xlfunction(fun,fargs,body,ctenv) LVAL fun,fargs,body,ctenv; { --- 106,112 ----- return (pop()); } ! /* xlfunction - compile a function */ /* used only by clanswer() **/ LVAL xlfunction(fun,fargs,body,ctenv) LVAL fun,fargs,body,ctenv; { *************** *** 110,115 rplaca(info,newframe(ctenv,1)); rplacd(info,cons(NIL,NIL)); /* setup the base of the code for this function */ cbase = cptr = 0; --- 115,122 ----- rplaca(info,newframe(ctenv,1)); rplacd(info,cons(NIL,NIL)); + rplacd (car(info), ctenv); /** DWC: 7/5/89 */ + /* setup the base of the code for this function */ cbase = cptr = 0; *************** *** 316,322 /* initialize the argument name list and slot number */ restarg = last = NIL; slotn = 1; ! /* handle each required argument */ while (consp(fargs) && (arg = car(fargs)) && !lambdakey(arg)) { --- 323,329 ----- /* initialize the argument name list and slot number */ restarg = last = NIL; slotn = 1; ! /* handle each required argument */ while (consp(fargs) && (arg = car(fargs)) && !lambdakey(arg)) { *** xsint.c Thu Jul 13 14:50:59 1989 --- xsintn.c Thu Jul 13 14:50:59 1989 *************** *** 1,3 /* xsint.c - xscheme bytecode interpreter */ /* Copyright (c) 1988, by David Michael Betz All Rights Reserved --- 1,8 ----- + /** modified METHOD case of xlapply() + David W. Crabb (crabb@phoenix.princeton.edu) + July, 1989 + **/ + /* xsint.c - xscheme bytecode interpreter */ /* Copyright (c) 1988, by David Michael Betz All Rights Reserved *************** *** 6,11 #include "xscheme.h" #include "xsbcode.h" /* sample rate (instructions per sample) */ #define SRATE 1000 --- 11,19 ----- #include "xscheme.h" #include "xsbcode.h" + /** from xsobj.c : */ + #define IVENV 1 + /* sample rate (instructions per sample) */ #define SRATE 1000 *************** *** 356,362 break; case METHOD: xlfun = getcode(xlval); ! xlenv = cons(top(),getenv(xlval)); base = pc = getcodestr(xlfun); break; case CONTINUATION: --- 364,374 ----- break; case METHOD: xlfun = getcode(xlval); ! ! xlenv = getenv(xlval); /** DWC 7/5/89 */ ! tmp = getivar(top(),IVENV); /** DWC 7/11 */ ! rplacd(xlenv, tmp); ! base = pc = getcodestr(xlfun); break; case CONTINUATION: *** xsobj.c Thu Jul 13 14:50:59 1989 --- xsobjn.c Thu Jul 13 15:10:12 1989 *************** *** 1,3 /* xsobj.c - xscheme object-oriented programming support */ /* Copyright (c) 1988, by David Michael Betz All Rights Reserved --- 1,8 ----- + /** Modifications to clanswer(), clisnew(), and clnew() . + David W. Crabb (crabb@phoenix.princeton.edu) + July, 1989 + **/ + /* xsobj.c - xscheme object-oriented programming support */ /* Copyright (c) 1988, by David Michael Betz All Rights Reserved *************** *** 13,18 static LVAL s_self,k_isnew; static LVAL class,object; /* instance variable numbers for the class 'Class' */ #define MESSAGES 1 /* list of messages */ #define IVARS 2 /* list of instance variable names */ --- 18,28 ----- static LVAL s_self,k_isnew; static LVAL class,object; + /** DWC: instance variable numbers for objects */ + #define IVENV 1 /** ivars now passed as an environment */ + /** number of instance variables for objects */ + #define IVTOT 2 + /* instance variable numbers for the class 'Class' */ #define MESSAGES 1 /* list of messages */ #define IVARS 2 /* list of instance variable names */ *************** *** 140,146 /* clnew - create a new object instance */ clnew() { ! LVAL self; /* create a new object */ self = xlgaobject(); --- 150,157 ----- /* clnew - create a new object instance */ clnew() { ! int i; ! LVAL self, ivframe,ivars,c ; /* create a new object */ self = xlgaobject(); *************** *** 144,150 /* create a new object */ self = xlgaobject(); ! xlval = newobject(self,getivcnt(self,IVARTOTAL)); /* send the 'isnew' message */ xlsend(xlval,k_isnew); --- 155,161 ----- /* create a new object */ self = xlgaobject(); ! xlval = newobject(self,IVTOT); ivars = getivar(self,IVARS); ivframe = newframe(NIL,listlength(ivars) + 1); *************** *** 146,151 self = xlgaobject(); xlval = newobject(self,getivcnt(self,IVARTOTAL)); /* send the 'isnew' message */ xlsend(xlval,k_isnew); } --- 157,167 ----- self = xlgaobject(); xlval = newobject(self,IVTOT); + ivars = getivar(self,IVARS); + ivframe = newframe(NIL,listlength(ivars) + 1); + setelement(car(ivframe),0,ivars); + setivar(xlval,IVENV, ivframe); + /* send the 'isnew' message */ xlsend(xlval,k_isnew); } *************** *** 153,159 /* clisnew - initialize a new class */ LVAL clisnew() { ! LVAL self,ivars,cvars,super; int n; /* get self, the ivars, cvars and superclass */ --- 169,175 ----- /* clisnew - initialize a new class */ LVAL clisnew() { ! LVAL self,ivars,cvars,super, tmp; int n; /* get self, the ivars, cvars and superclass */ *************** *** 163,172 super = (moreargs() ? xlgaobject() : object); xllastarg(); - /* create the class variable compile-time environment */ - xlval = cons(xlenter("%%CLASS"),copylists(cvars,NIL)); - cpush(cons(xlval,getivar(super,CVARS))); - /* create the class variable environment */ xlval = newvector(listlength(xlval)); setelement(xlval,0,self); cpush(cons(xlval,getivar(super,CVALS))); --- 179,184 ----- super = (moreargs() ? xlgaobject() : object); xllastarg(); /* create the class variable environment */ xlval = newvector(listlength(xlval)); setelement(xlval,0,self); cpush(cons(xlval,getivar(super,CVALS))); *************** *** 172,178 cpush(cons(xlval,getivar(super,CVALS))); /* store the instance and class variable lists and the superclass */ ! setivar(self,IVARS,copylists(getivar(super,IVARS),ivars)); setivar(self,CVALS,pop()); setivar(self,CVARS,pop()); setivar(self,SUPERCLASS,super); --- 184,191 ----- cpush(cons(xlval,getivar(super,CVALS))); /* store the instance and class variable lists and the superclass */ ! setivar(self,IVARS,ivars); /* to be retrieved in clnew() **/ ! setivar(self,CVALS,pop()); tmp = newframe(NIL,listlength(cvars) + 1); *************** *** 174,180 /* store the instance and class variable lists and the superclass */ setivar(self,IVARS,copylists(getivar(super,IVARS),ivars)); setivar(self,CVALS,pop()); ! setivar(self,CVARS,pop()); setivar(self,SUPERCLASS,super); /* compute the instance variable count */ --- 187,197 ----- setivar(self,IVARS,ivars); /* to be retrieved in clnew() **/ setivar(self,CVALS,pop()); ! ! tmp = newframe(NIL,listlength(cvars) + 1); ! setelement(car(tmp),0,cvars); ! setivar(self,CVARS,tmp); ! setivar(self,SUPERCLASS,super); /* compute the instance variable count */ *************** *** 191,197 LVAL clanswer() { extern LVAL xlfunction(); ! LVAL self,msg,fargs,code,mptr; /* message symbol, formal argument list and code */ self = xlgaobject(); --- 208,214 ----- LVAL clanswer() { extern LVAL xlfunction(); ! LVAL self,msg,fargs,code,mptr, tmp; /* message symbol, formal argument list and code */ self = xlgaobject(); *************** *** 206,214 /* add 'self' to the argument list */ cpush(cons(s_self,fargs)); ! /* extend the class variable environment with the instance variables */ ! xlval = cons(getivar(self,IVARS),getivar(self,CVARS)); ! /* compile and store the method */ xlval = xlfunction(msg,top(),code,xlval); rplacd(mptr,cvmethod(xlval,getivar(self,CVALS))); --- 223,230 ----- /* add 'self' to the argument list */ cpush(cons(s_self,fargs)); ! tmp = getivar (self,CVARS) ; /** now an env from clisnew() */ ! /* compile and store the method */ xlval = xlfunction(msg,top(),code,tmp); rplacd(mptr,cvmethod(xlval, tmp)); *************** *** 210,217 xlval = cons(getivar(self,IVARS),getivar(self,CVARS)); /* compile and store the method */ ! xlval = xlfunction(msg,top(),code,xlval); ! rplacd(mptr,cvmethod(xlval,getivar(self,CVALS))); drop(1); /* return the object */ --- 226,233 ----- tmp = getivar (self,CVARS) ; /** now an env from clisnew() */ /* compile and store the method */ ! xlval = xlfunction(msg,top(),code,tmp); ! rplacd(mptr,cvmethod(xlval, tmp)); drop(1); /* return the object */ ----------------------- tryit.xs ------------------------------------ ; "tryit.xs" for loading into xscheme - modified version . ; David W. Crabb crabb@phoenix.princeton.edu (define aClass (Class 'new '(ivar1 ivar2) '(cvar1 cvar2))) (define anInst (aClass 'new)) (aClass 'answer 'set-cvar1 '(value) '( (set! cvar1 value))) (aClass 'answer 'cvar1? '() '( (print cvar1))) (aClass 'show) (anInst 'set-cvar1 592) (anInst 'cvar1?) ; >> 592 (aClass 'answer 'set-ivar1 '() '( (set! ivar1 5505))) (anInst 'set-ivar1) (aClass 'answer 'ivar1? '() '( (print ivar1))) (anInst 'ivar1?) ; >> 5505 (define subClass (Class 'new '(ivar1 ivar2) '(cvar1 cvar2) aClass )) (define subInst (subClass 'new)) (subInst 'cvar1?) ; >> 592 (subInst 'ivar1?) ; >> () (aClass 'answer 'reset-ivar1 '() '( (set! ivar1 -66))) (subInst 'reset-ivar1) (subInst 'ivar1?) ; >> -66 (anInst 'ivar1?) ; >> 5505 ;; -------------------- eof ----------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 12:55:16 EDT Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa02609; 14 Jul 89 17:28 EDT Received: by iuvax.cs.indiana.edu Date: Fri, 14 Jul 89 16:23:53 -0500 From: Chris Haynes To: rrrs-authors@mc.lcs.mit.edu, scheme@mc.lcs.mit.edu, scheme-standard@wheaties.ai.mit.edu Subject: Minutes of the 3rd IEEE Scheme Working Group meeting Message-ID: <8907141728.aa02609@mintaka.lcs.mit.edu> IEEE/MSC/P1178 Working Group on Scheme Unapproved Minutes of the Third Meeting 7 July 1989 MIT, Cambridge, MA SUMMARY R4RS numbers accepted. Group believes all major technical issues have been resolved in preparation for submission of draft. Next meeting at POPL '90. ACTIONS The meeting was called to order by Chris Haynes at about 9:45AM. The following attendance list was collected: Hal Abelson MIT Bill Campbell University of Mass at Boston William Clinger University of Oregon Ken Dickey Tektronix Dan Friedman Indiana University Dick Gabriel Stanford University Chris Hanson MIT Chris Haynes Indiana University Sidney Marshal Xerox Tim McNerney ILA James S. Miller Brandeis University Eric Ost Indiana University John D. Ramsdell The MITRE Corporation Guillerimo J. Rozas MIT Gerald Jay Sussman MIT Mitchell Wand Northeastern University 1. The agenda was amended; the changes are reflected by the minutes. 2. John D. Ramsdell was elected secretary. 3. Minutes of the second meeting were accepted with no changes. 4. Differences from the last draft. Chris Hanson described the changes to the draft introduce since the last meeting. Changes agreed on at last meeting: * "User Interface" appendix removed. * Restore `substring'. * Delete `with-input-from-port' and `with-output-to-port'. Changes from R3.95RS: * Many small editorial changes. * Characters added to "extended alphabet" set: + - . * Added number section (pending outcome of third meeting). * Added description of "implementation error" in support of numbers section. * New description of: number->string string->number integer->char char->integer peek-char 5. Discuss the number section of the standard. A long discussion followed, which continued until about 2:00PM (with a lunch break). This resulted in a much wider understanding and appreciation of the exact/inexact distinction. (In the process it was clarified that non-numeric operations on numbers, such as storing and retrieving them, are not allowed to affect their exactness.) 5.1 Moved and accepted: The editors will change wording in section 1.3.1 to clarify the notion of an implementation error. Specific directions include, dropping the word "arbitrary" in paragraph 3 and changing the following two sentences to read something like: "When an implementation error is reported, the report must make clear that an implementation restriction was violated. Implementation restrictions are of course discouraged, but reporting their violation is encouraged." 5.2 Moved and unanimously accepted: We accept the number section of R4RS with some editorial changes. 5.3 Moved and accepted: We recommend that the R4RS authors rename the procedure max to sup, and procedure min to inf. 5.4 Moved and rejected: If R4RS does not change the names of max and min, P1178 should eliminate max and min. 5.5 Moved and accepted: Add expt to the list of procedures which must return an exact result when given exact arguments (section 6.5.3). 5.6 Moved and accepted: Add an example showing the use of explicit coercion of an inexact argument as an index of vector-ref. 5.7 Moved and unanimously accepted: The editors will add to the body of the text the requirement that implementations must support a minimal subset of numeric procedures and request that the R4RS authors change the status to essential of any unessential procedure required to support the minimal subset. It was noted that the proscriptive wording (e.g., "shall", "must") in appendix B.3) should be softened (e.g., "should"). The editors reaffirmed their intention to substantially extend appendix B.3, including, for instance, a discussion of the transitivity requirements for the numeric order and equality predicates. 6. R4RS status report Will Clinger described the changes he expected between R3.95RS and R4RS. He promised a R3.99RS (R4RS without macro appendices) within a month. * Add ... as a . * Change the branch cuts of some trig functions to be like Common Lisp's. * Make char->integer and integer->char one-to-one. * Return char-upper-case? to R4RS, which was dropped due to an editing error. * Leave it unspecified as to whether the empty list counts as false. * Change number->string description. 7. Moved and accepted: We request that the R4RS authors add a sentence encouraging that implementations support an international character set, most likely ISO Latin 1 (ISO8859-1). 8. A move that ":" be change to not be an extended alphanumeric character was not seconded. 9. Moved and accepted: We request that the R4RS authors consider making just list-ref (and not list-tail) essential. 10. A move to discuss changing the semantics of internal definitions was not seconded. 11. Moved and accepted: It is suggested that the next meeting of the IEEE Scheme Working Group be on January 19, 1989, following the Principles of Programming Languages conference in San Francisco, CA. There was general consensus that at the next meeting the Working Group could probably approve the draft standard for submission to the MSC for public comment and balloting. Therefore the draft to be considered at the next meeting should be mailed to all those on the Working Group mailing list no later than mid-November. 12. Moved and unanimously accepted: The draft standard distributed at the meeting (reflecting the changes detailed under item 4 above) should be submitted to ISO WG-16 for consideration, with a brief cover statement to be drafted by Chris Haynes. Dick Gabriel reported that ANSII asked X3J13 whether Scheme and Common Lisp were distinct enough to justify two standards. Bob Mathis provided technical arguments convincing ANSII that they were distinct. Meeting adjourned at about 3:30PM. -- Minutes by John D. Ramsdell, edited by Chris Haynes  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 12:47:19 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa01334; 14 Jul 89 15:42 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 14 Jul 89 15:39:26 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: 14 Jul 89 17:53:22 GMT From: unicads!les@boulder.colorado.edu (Les Milash) Organization: Unicad Boulder, CO Subject: Re: Opening files with Cscheme Message-Id: <557@unicads.UUCP> References: <553@unicads.UUCP>, <8907141438.AA01871@altdorf.ai.mit.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu thanks, everyhody, for telling me about the function `file-exists?'. you can stop now :-) you've been overwhelmingly helpful. ya know, i've never gotten more code working faster than with this wierd Scheme stuff! i guess that's what it's all about, huh?  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jul 89 10:45:48 EDT Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa06346; 14 Jul 89 10:40 EDT Received: from altdorf.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05454; Fri, 14 Jul 89 10:40:17 EDT Received: from localhost by altdorf.ai.mit.edu; Fri, 14 Jul 89 10:38:49 edt Date: Fri, 14 Jul 89 10:38:49 edt From: Chris Hanson Message-Id: <8907141438.AA01871@altdorf.ai.mit.edu> To: unicads!les@boulder.colorado.edu Cc: Scheme@mc.lcs.mit.edu In-Reply-To: Les Milash's message of 13 Jul 89 18:36:08 GMT <553@unicads.UUCP> Subject: Opening files with Cscheme Date: 13 Jul 89 18:36:08 GMT From: Les Milash i have a thing called CScheme, which i love. i have a manual called RRRS. i have a problem. is there a way to figure out if some file exists without crashing? The procedure `file-exists?' does what you want. It takes a single argument which is a filename.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 16:18:20 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa14326; 13 Jul 89 16:12 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 13 Jul 89 15:49:26 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: 13 Jul 89 18:36:08 GMT From: Les Milash Organization: Unicad Boulder, CO Subject: Opening files with Cscheme Message-Id: <553@unicads.UUCP> References: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu i have a thing called CScheme, which i love. i have a manual called RRRS. i have a problem. i'm trying to write a program that's c-preprocessor compatable, in that it takes a -I/parameter -I/that/lists/a/bunch -I/of/directories/that include files might be in. so when the code includes foo.h i have to find the first one of /parameter/foo.h /that/lists/a/bunch/foo.h /of/directories/that/foo.h that exists. RRRS talks about (open-input-file "filename") but if the file doesn't exist i get an "out of range with "filename"" error and the program stops. is there a way to figure out if some file exists without crashing? or some way to substitute some better error behaviour (i'd just as soon have it return '() or #!the-you-screwed-up-object or something). i have the CScheme source and am not adverse to making myself un-scheme- compatable (but i imagine that scheme can do what i want somehow (else what good is it?)) thanks in advance for the assistance! Les Milash wow! with a language like this, i might even be able to handle a shared-memory multiprocessor!  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 19:57:44 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa23422; 12 Jul 89 18:12 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 12 Jul 89 17:32:32 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: 12 Jul 89 21:19:40 GMT From: Shawn McLean Organization: Thinking Machines Corporation, Cambridge MA, USA Subject: re: do loop for 1.6 XScheme Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Help yourself. Also included is a defsetf clone. -shawn ;;; (c) Copyright 1989, Shawn Mclean ;;; All rights reserved ;;; Permission is granted for unrestricted non-commercial use ;;; created: Tue 3-28-1989 22:32 ;;; XScheme - Version 0.16 ;;; commonlisp compatibility macros and functions ;;; ;;; macros ;;; (macro defmacro (lambda (form) (let* ((name (cadr form)) (form (cddr form)) (arglist (car form)) (form (cdr form)) (body (car form))) (put name '%arglist arglist) `(macro ,name (lambda (form) (apply (lambda ,arglist ,body) (cdr form))))))) ;;; ;;; lists ;;; (macro first (lambda (form) `(car ,(cadr form)))) (macro second (lambda (form) `(cadr ,(cadr form)))) (macro third (lambda (form) `(caddr ,(cadr form)))) (macro fourth (lambda (form) `(cadddr ,(cadr form)))) (macro fifth (lambda (form) `(caddddr ,(cadr form)))) (macro nth (lambda (form) `(list-ref ,(cadr form) ,(caddr form)))) (macro push (lambda (form) (let ((item (cadr form)) (list (caddr form))) `(set! ,list (cons ,item ,list))))) (macro pop (lambda (form) (let ((list (cadr form)) (item (gensym 'item))) `(let ((,item (car ,list))) (set! ,list (cdr ,list)) ,item)))) ;;; ;;; loops ;;; (macro do (lambda (form) (let (locals test body exits inits updates) (set! locals (reverse (cadr form))) (set! form (cddr form)) (set! test (car form)) (set! form (cdr form)) (set! body form) (set! exits (cdr test)) (set! test (list 'not (car test))) (while locals (let* ((local (car locals)) (var (if (list? local) (car local) local)) (init (cadr local)) (update (caddr local))) (push (list var init) inits) (if update (push `(set! ,var ,update) updates)) (set! locals (cdr locals)))) `(let ,inits (while ,test ,@body ,@updates) ,@exits)))) (macro do* (lambda (form) (let (locals test body exits inits updates) (set! locals (reverse (cadr form))) (set! form (cddr form)) (set! test (car form)) (set! form (cdr form)) (set! body form) (set! exits (cdr test)) (set! test (list 'not (car test))) (while locals (let* ((local (car locals)) (var (if (list? local) (car local) local)) (init (cadr local)) (update (caddr local))) (push (list var init) inits) (if update (push `(set! ,var ,update) updates)) (set! locals (cdr locals)))) `(let* ,inits (while ,test ,@body ,@updates) ,@exits)))) (macro dotimes (lambda (form) (let* ((control (cadr form)) (body (cddr form)) (var (car control)) (limit (cadr control))) `(let ((,var 0)) (while (< ,var ,limit) ,@body (set! ,var (1+ ,var))))))) (macro dolist (lambda (form) (let* ((control (cadr form)) (body (cddr form)) (item (car control)) (list (cadr control)) (items (gensym 'items))) `(let ((,items ,list)) (while (not (null? ,items)) (set! ,item (car ,items)) ,@body (set! ,items (cdr ,items))))))) ;;; ;;; debugger ;;; ;;; Is this the way to do this? (define break (lambda args (display "break: ") (dolist (arg (cdr args)) (display arg)) (let ((env (environment-bindings (the-environment)))) (dolist (binding env) (map display (car binding) ": " (cdr binding)) (newline)) (read)))) ;;; ;;; string conversions ;;; not common lisp (define integer->string (lambda (integer) (let ((done nil) (integer-string nil)) (while (not done) (push (integer->char (+ (char->integer #\0) (remainder integer 10))) integer-string) (set! integer (quotient integer 10)) (set! done (= integer 0))) (list->string integer-string)))) ;;; ;;; general accessor ;;; ;;; This is a defsetf clone that works on global functions. A modifier ;;; function is first defined with defset, and following set will invert a ;;; reference. For example: ;;; ;;; (set (car foo) 'bar) => (set-car! foo 'bar) ;;; ;;; If anything, this saves you from typing !'s all over the place. set ;;; will accept one or pairs of auguments. (macro set (lambda (pairs) (if (odd? (length (cdr pairs))) (error "odd number of arguments to set") (do* ((place (cdr pairs) (cdr place)) (value (cdr place) (cdr place)) (assignments nil)) ((null? place) (if (cdr assignments) `(begin ,@(reverse assignments)) (car assignments))) (set! assignments (cons (general-set (car place) (car value)) assignments)) (set! place (cdr place)))))) (define general-set (lambda (place value) (if (list? place) ((get (car place) 'set) (cadr place) value) `(set! ,place ,value)))) (defmacro defset (function lambda-list values form) (let ((set-function `(lambda (,@lambda-list ,@values) ,form))) `(begin (put ',function 'set ,set-function) ',function))) (defset car (list) (value) `(set-car! ,list ,value)) (defset cdr (list) (value) `(set-cdr! ,list ,value))  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 11:02:30 EDT Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa12607; 12 Jul 89 10:59 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 3744; Wed, 12 Jul 89 10:58:11 EDT Received: from FRSAC11.BITNET (NETWORK) by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 6599; Wed, 12 Jul 89 10:58:10 EDT Date: Wed, 12 Jul 89 16:46:56 GMT To: scheme@mc.lcs.mit.edu From: NETWORK%FRSAC11.BITNET@mitvma.mit.edu Comment: CROSSNET mail via MAILER@MITVMA Comment: File TT NOTEBOOK A Subject: DO syntax in XScheme Message-ID: <8907121059.aa12607@mintaka.lcs.mit.edu> I am looking deseparatly for a do construct for XSCHEME, 0.15 or 0.16. The change in macros.s between 0.15 and 0.16 break my syntax for named-lambda. Any comments or working named-lambda in 0.16 ? The benchmarks give a noticeable slowdown from 0.15 to 0.16, any comments ? Any understandable documentation on the macro.s package welcome. I need the ststuff.c for the atari ST, using MWC, by the way. I made up something to work with Lattice 3.04, but it may be less than ideal. Regards, Jean-Pierre H. Dumas network@frsac11 (bitnet) network%frsac11.bitnet@cunyvm.cuny.edu (arpanet) dumas@sumex-aim.stanford.edu (arpanet)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jul 89 11:43:08 EDT Received: from potomac.ads.com by mintaka.lcs.mit.edu id aa10974; 11 Jul 89 11:42 EDT Received: by potomac.ads.com (5.59/1.18) id AA25882; Tue, 11 Jul 89 10:21:15 EST Date: Tue, 11 Jul 89 10:21:15 EST From: "John T. Nelson" Message-Id: <8907111521.AA25882@potomac.ads.com> To: Scheme@mc.lcs.mit.edu Subject: Re: Scheme Digest #147 In-Reply-To: your article <8906280053.aa29437@mintaka.lcs.mit.edu> News-Path: zodiac!MC.lcs.mit.edu!Scheme-Request If you have a pointer to the FTP'able Scheme report and/or public domain Scheme I'd appreciate hearing about it.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 9 Jul 89 09:16:38 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa09296; 9 Jul 89 9:10 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 9 Jul 89 08:25:10 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: 7 Jul 89 15:59:06 GMT From: Dave McKellar Organization: Inter\Access, Toronto Subject: Learning/teaching Scheme as a first language - Summary Message-Id: <1989Jul7.115906.7544@intacc.uucp> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Many thanks to the 16 kind people who replied to my query about an easy reading book on Scheme. Here is what they said... Easy Reading Books on Scheme ============================ The Little Lisper by Daniel P. Friedman and Matthias Felleisan ----------------- of Indiana University Programming in Scheme by Mike Eisenberg --------------------- published by Scientific Press The Scheme Programming Language by Kent Dybvig ------------------------------- published by Prentice Hall Introduction to Scheme by Jerry Smith ---------------------- published by Prentice Hall The 'World's biggest bookstore', here in Toronto, has a shelf of Lisp books but none of these.... shocking! -- ---------- {uunet,watmath,utzoo}!mnetor!intacc!mckellar "Taste is a matter of taste." ----------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 19:14:27 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa10428; 6 Jul 89 19:10 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 6 Jul 89 18:25:40 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: 6 Jul 89 21:33:25 GMT From: Brian of ASTD-CP Organization: Jet Propulsion Laboratory, Pasadena, CA Subject: Looking for MIT C-scheme manual Message-Id: <1415@jato.Jpl.Nasa.Gov> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu We here in the Computer Graphics Lab have MIT cscheme running and we have the R3RS to look at. But cscheme has a tremendous number of features, extensions, and goodies that we haven't figured out. Is there a reference manual? A user's manual? If someone has it, would s/he be so kind as to e-mail (or even US snail) it to us? We're limping along with MacScheme and various installations of Betz's Xscheme, which, while very nice indeed, doesn't seem to have the power, backing, (nor size) of cscheme by an order of magnitude or so. ;================================================================ ;| Brian Beckman | brian@topaz.jpl.nasa.gov | ;| Computer Graphics Laboratory | (818) 397-9207 | ;| Mail Stop 510-202 | (818) 397-9344 | ;| Jet Propulsion Laboratory | | ;| Pasadena, CA 91109 | 6 July 1989 | ;================================================================  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 00:29:39 EDT Received: from DSAC.DLA.MIL by mintaka.lcs.mit.edu id aa26961; 6 Jul 89 0:24 EDT Received: from daitc.UUCP by dsacg1.dla.mil (5.61++/1.34) id AA24764; Mon, 3 Jul 89 22:14:38 -0400 Received: from MINTAKA.LCS.MIT.EDU by daitc.mil (5.61++/29-June-89) with SMTP id AA22383; Mon, 3 Jul 89 01:22:00 -0400 Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21379; 3 Jul 89 1:01 EDT Date: 3 JUL 89 00:09:16 EDT From: Automatic Scheme Digestifier Subject: Scheme Digest #151 To: Scheme@mc.lcs.mit.edu Reply-To: daitc!mc.lcs.mit.edu!Scheme@dsac.dla.mil Message-Id: <8907030101.aa21379@mintaka.lcs.mit.edu> Scheme Digest #151 3 JUL 89 00:09:16 EDT Today's Topics: OOP in Scheme ---------------------------------------------------------------------- Date: 2 Jul 89 07:31:07 GMT From: Brian of ASTD-CP Subject: OOP in Scheme Message-Id: <1404@jato.Jpl.Nasa.Gov> ; methods2.scm ; ; =============================================================== ; Brian Beckman | brian@topaz.jpl.nasa.gov ; Mail Stop 510-202 | (818) 397-9207 ; Jet Propulsion Laboratory | ; Pasadena, CA 91109 | 30 June 1989 ; =============================================================== ; INTRODUCTION ; ; This is a tiny object-oriented programming system with multiple ; inheritance and error handling. It is modeled after the message ; passing modules in Chapter 3 of Abelson & Sussman. It is ; implemented in ``pure'' Scheme, without macros or syntax ; extensions. ; ; This programming system is implemented as a technique, or ; programming convention, with some helper routines. The programming ; convention is not enforced, as we choose to avoid syntax-extensions ; for portability's sake. The technique is illustrated in this file ; with a few examples. In example one, a parent class, named ; ``parent,'' passes its attributes to a child named ``child.'' In ; example two, two parents, ``mother'' ``fater'', pass their attributes ; to a child class, ``daughter.'' The reader will perceive the technique ; by generalization from these examples and will be able to apply it ; to his or her own problems. ; ; Every class is represented by its constructor procedure. This ; procedure returns a message dispatching procedure. The message ; dispatching procedure should be named ``self'' so that an object can ; conveniently send messages to itself. However, ``self'' is an ; internal name not known outside the constructor. ; ; In summary, classes are represented by constructor procedures, and ; objects, or instances of classes, are represented by message ; dispatching procedures. The present version of ``methods'' does not ; support code sharing, so every instance of a class has its own ; private copies of the method code. We expect to implement code ; sharing in a later version of ``methods''. ; ; The message dispatching procedure walks the multiple inheritance ; hierarchy upwards until it finds an object that can understand a ; message, starting with itself. If no object that can understand the ; message is found, a global error procedure is called. ; ; IMPLEMENTATION ; ; Error processing is challenging. We should like to have two modes. ; In ``normal mode'', an error is reported only by the first receiver ; of a message. In ``debug mode'', an inheritance traceback should be ; given whereby every object in an inheritance hierarchy will report ; when it fails to recognize a given message. The following variable ; represents that mode. (For simplicity, this object is hidden only ; by its name, which is unusual enough that it is unlikely to be ; trammeled by an application. This is not the recommended technique ; for data hiding. Data hiding ought to be implemented through the ; techniques shown in this file! However, since this error handling ; part of the methods package is considered system programming, ; certain liberties in style are justifiable. There are in fact, good ; technical reasons for the error handling code to be implemented with ; global variables, which the perceptive reader will be able to ; deduce.) (define **method-mode** 'normal-method-mode) ; The user can set these modes as follows. (define (set-debug-method-mode) (set! **method-mode** 'debug-method-mode)) (define (set-normal-method-mode) (set! **method-mode** 'normal-method-mode)) (define (reset-debug-method-mode) ;;; synonym (set! **method-mode** 'normal-method-mode)) ; and test them with the following routine: (define (test-debug-method-mode) (eq? **method-mode** 'debug-method-mode)) ; Before presenting the examples of classes and objects, some helper ; routines are needed. ; ; When an object cannot recognize a message, and none of its ancestor ; objects can recognize it, the object creates an error procedure and ; returns it as the result of the message dispatcher. (define **method-error-class-name** "No class name.") (define **method-error-message** 'no-message) (define (error-method . junk-args) (display **method-error-class-name**) (display ": uknown message: '") (display **method-error-message**) (newline) ()) (define (make-error-method class-name msg) (set! **method-error-class-name** class-name) (set! **method-error-message** msg) error-method) ; The procedure that walks the inheritance hierarchy must cooperate ; in the error handling. (define (search-supertypes supers msg) (define method ()) (if (test-debug-method-mode) (begin (display "Searching...") (newline))) (cond ( (null? supers) () ) ( (begin (set! method ((car supers) msg)) (eq? method error-method)) (if (test-debug-method-mode) (error-method)) (search-supertypes (cdr supers) msg) ) ( else method ))) ; This procedure implements the inheritance of methods. It is greatly ; complicated by proper error handling. Without error handling, the ; routine would resemble the following, which is much easier to ; understand (without error handling, the programming convention is ; that an object that does not understand a message returns the ; unexecutable method ``()''). ; ; (define (search-supertypes supers msg) ; (cond ; ( (null? supers) () ) ; ( ((car supers) msg) ) ; ( else (search-supertypes (cdr supers) msg) ))) ; ; The actual routine, with proper error handling, works as follows. A ; local variable, ``method'', is defined. Its value is not important ; to begin with. If debugging is on, we print a message telling the ; user that the inheritance hierarchy is being searched. Then, the ; list of supertypes is investigated. If the list is empty, we return ; nil, which signals the caller to create and return the error-method, ; as we shall see in the examples later. If the list is not empty, we ; pass the message to the first supertype in the list. The return ; value is assigned to the local variable ``method''. If the returned ; method is the one and only global error-method, then the supertype, ; and, recursively, all its supertypes, did not know the message. ; If debugging is on, we execute the returned error-method, contributing ; to the aforementioned inheritance traceback. Finally, we return ; the value of a recursive call of search-supertypes on the remainder ; of the list of supertypes. If the returned method is not the ; error-method, then the supertype did understand the message after ; all somewhere in the hierarchy, and the returned method is the ; return value of this procedure. ; ; Note that the list of supertypes is searched in order from front ; to back. The first match of a message results in the successful ; finding of a method. The order of supertypes in the list is ; significant only when more than one supertype can understand ; a given message. The earlier members of the list will shadow ; the later ones. In some object-oriented programming systems, one ; refers to the ``overriding'' of methods. The shadowing in ; ``methods'' is our form of method overriding, and it is under ; explicit control of the programmer who sets the order of supertypes ; in the list of supertypes. ; ; In summary, search-supertypes passes the message to the ancestors, ; in pre-order, returning the first method found. ; ; The next helper routine passes a message, and a variable number of ; arguments, to all the parents of an object. For side effects, it ; executes any methods found. Parents are defined as ; first level ancestors. (define (for-all-parents supers msg . args) (let ( (method-list (map (lambda (supertype) (supertype msg)) supers)) (for-proc (lambda (method) (apply method args))) ) (for-each for-proc method-list))) ; With the current programming convention, it is not possible to pass ; a message to all ancestors and execute the methods for side-effect ; without explicit cooperation on the part of the objects involved. In ; other words, the procedure ``for-all-ancestors'', analogous to ; ``for-all-parents'', cannot be implemented in the current version of ; the methods package. The reason is that the convention calls for ; every class to call ``search-supertypes'', which stops when it finds ; a method. The convention would have to be augmented so that objects ; would call ``find-all-methods'' (defined below) on an appropriate ; message. Since we expect the need for ``for-all-ancestors'' to be ; fairly rare, the necessary changes to the methods package will be ; reserved for a future version. (define (find-all-methods supers msg) (cond ( (null? supers) () ) ( else (cons ((car supers) msg) (find-all-methods (cdr supers) msg)) ))) ; EXAMPLES (cut here to end of file to throw examples away) ; ; Our first example class, or object type, is ``parent'', represented ; by the following constructor procedure. (define (new-parent arg) (let ((state-var (* arg arg)) (supers ())) (define (report-state-var) (display state-var) (newline) state-var) (define (update-state-var arg) (set! state-var (* arg arg))) (define (echo arg) (display arg) (newline)) (define (self msg) (cond ( (eq? msg 'report) report-state-var ) ( (eq? msg 'update) update-state-var ) ( (eq? msg 'echo) echo ) ( (search-supertypes supers msg) ) ( else (make-error-method "Parent" msg) ))) self)) ; This class, or constructor procedure, completely illustrates, by ; example, the programming convention of the ``methods'' technique. ; The constructor takes a single argument, whose square it stores in a ; local state variable. Another state variable, the list of ; supertypes, is set to nil, since this class is at the root of an ; inheritance hierarchy. Three methods are defined, one that reports ; and returns the current value of the state variable, one that sets ; the state variable equal to a new square, and one that merely echoes ; its argument. A method dispatching procedure, conventionally named ; ``self'', tests a given message against three symbols and returns ; the corresponding method if a match is found. If no match is found, ; the list of supertypes is searched for a match. In the case of this ; class, ``parent'', the search is purely formal, to illustrate how it ; should be done, since ``parent'' has no ancestors. However, if a ; match were found among the list of supertypes, the method would be ; returned. Note how the search relys on the fact that any non-nil ; result is treated as a successful ``cond'' clause, terminating the ; ``cond'' statement. Search-supertypes returns nil only when a match ; is not found. Finally, if no match is found locally or among the ; supertypes, an appropriate error-method is pseudo-created and ; returned. ; ; We now test this class by making an instance and passing it ; messages. (define p (new-parent 42)) ((p 'report)) ((p 'update) 69) ((p 'report)) ((p 'echo) (list 1 2 3)) ; We test error handling: ((p 'bogus)) (set-debug-method-mode) ((p 'bogus)) (reset-debug-method-mode) ((p 'bogus) 'here 'are 'some 'junk 'arguments) ; Continuing this example, let us define a child class inheriting ; all attributes and methods of the parent. Note the attributes of ; the parent are only accessible through the parent's method ; discipline. This is a strict form of inheritance, and the default ; in C++, for example. (C++ allows the programmer to override ; ancestors' access discipline, at his own peril.) (define (new-child arg1 arg2) (let* ( (leg1 (* arg1 arg1)) (leg2 (* arg2 arg2)) (hypotenuse (+ leg1 leg2)) (supers (list (new-parent hypotenuse))) ) (define (report) (for-all-parents supers 'report) (display "Leg1 = ") (display (sqrt leg1)) (newline) (display "Leg2 = ") (display (sqrt leg2)) (newline) (display "Hypo = ") (display (sqrt hypotenuse)) (newline)) (define (update-leg1 val) (set! leg1 (* val val)) (set! hypotenuse (+ leg1 leg2))) (define (update-leg2 val) (set! leg2 (* val val)) (set! hypotenuse (+ leg1 leg2))) (define (self msg) (cond ( (eq? msg 'report) report ) ( (eq? msg 'update-leg1) update-leg1 ) ( (eq? msg 'update-leg2) update-leg2 ) ( (search-supertypes supers msg) ) ( else (make-error-method "Child" msg) ))) self)) ; We now test the child type. (define c (new-child 3 4)) ((c 'report)) ;;; passes message to all parents ((c 'update-leg1) 5) ((c 'update-leg2) 12) ((c 'report)) ((c 'echo) '(foo bar)) ;;; msg known only in the parent ((c 'bogus) 'baz 'rat) (set-debug-method-mode) ((c 'bogus) 'baz 'rat) (reset-debug-method-mode) ((c 'bogus) 'baz 'rat) ; The last example, presented without detailed narrative, shows a ; slightly deeper inheritance hierarchy. The leaf is a type named ; ``daughter''. Its two parent classes are ``mother'' and ``father''. ; In turn, every mother has an ``estate'' and a ``religion'' (please ; excuse the somewhat strained metaphor of inheritance; this is just ; a little example). (define (new-estate value) (let ((value value) (supers ())) (define (report) (display "Estate = $") (display value) (newline)) (define (what-value) value) (define (increase amount) (set! value (+ value amount))) (define (decrease amount) (set! value (- value amount))) (define (self msg) (cond ( (eq? msg 'report) report ) ( (eq? msg 'what-estate) what-value ) ( (eq? msg 'increase) increase ) ( (eq? msg 'decrease) decrease ) ( (search-supertypes supers msg) ) ( else (make-error-method "Estate" msg) ))) self)) (define (new-religion theReligion) (let ((religion theReligion) (supers ())) (define (report) (display "Religion = ") (display religion) (newline)) (define (what-religion) religion) (define (convert theNewReligion) (set! religion theNewReligion)) (define (self msg) (cond ( (eq? msg 'report) report ) ( (eq? msg 'convert) convert ) ( (eq? msg 'what-religion) what-religion ) ( (search-supertypes supers msg) ) ( else (make-error-method "Religion" msg) ))) self)) (define (new-father eye-color) (let ((eye-color eye-color) (supers ())) (define (report) (display "Father's eye color = ") (display eye-color) (newline)) (define (what-eye-color) eye-color) (define (self msg) (cond ( (eq? msg 'report) report ) ( (eq? msg 'what-eye-color) what-eye-color ) ( (search-supertypes supers msg) ) ( else (make-error-method "Father" msg) ))) self)) (define (new-mother eye-color estate religion) (let ((eye-color eye-color) (supers (list (new-estate estate) (new-religion religion)))) (define (report) (for-all-parents supers 'report) (display "Mother's eye color = ") (display eye-color) (newline)) (define (what-eye-color) eye-color) (define (self msg) (cond ( (eq? msg 'report) report ) ( (eq? msg 'what-eye-color) what-eye-color ) ( (search-supertypes supers msg) ) ( else (make-error-method "Mother" msg) ))) self)) (define (new-daughter eye-color) (let* ((eye-color eye-color) (parents-eye-color (if (eq? eye-color 'blue) 'blue 'brown)) (supers (list (new-father parents-eye-color) (new-mother parents-eye-color 500000 'Jewish)))) (define (report) (for-all-parents supers 'report) (display "Daughter's eye color = ") (display eye-color) (newline)) (define (what-eye-color) eye-color) (define (self msg) (cond ( (eq? msg 'report) report ) ( (eq? msg 'what-eye-color) what-eye-color ) ( (search-supertypes supers msg) ) ( else (make-error-method "Daughter" msg) ))) self)) (define dbl (new-daughter 'blue)) ((dbl 'report)) ((dbl 'convert) 'muslim) ((dbl 'report)) ((dbl 'increase) 50000) ((dbl 'report)) (define dbr (new-daughter 'brown)) ((dbr 'report)) ((dbr 'decrease) 250000) ((dbr 'report)) ((dbr 'bogus)) (set-debug-method-mode) ((dbr 'bogus)) (reset-debug-method-mode) ------------------------------ End of Scheme Digest ********************  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Jul 89 19:18:36 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa23852; 5 Jul 89 19:10 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 5 Jul 89 18:17:11 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: 5 Jul 89 21:47:32 GMT From: Brian of ASTD-CP Organization: Jet Propulsion Laboratory, Pasadena, CA Subject: OOP in Scheme (serious example) Message-Id: <1412@jato.Jpl.Nasa.Gov> References: <1404@jato.Jpl.Nasa.Gov>, <1406@jato.Jpl.Nasa.Gov> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu ; This'll be my last submission on this topic, so I promise I won't ; be burning up the wires with any more. I thought a serious ; example would be of some interest, however, so here is a FIFO ; queue data type. I'll be building classes for priority queues, ; heaps, splay trees, and assorted others, as well as a data flow ; executive. Anyone interested further in this topic may feel ; free to e-mail me. Again, sorry for the length of these sub- ; missions. BCB. ;================================================================ ;| Brian Beckman | brian@topaz.jpl.nasa.gov | ;| Mail Stop 510-202 | (818) 397-9207 | ;| Jet Propulsion Laboratory | | ;| Pasadena, CA 91109 | 3 July 1989 | ;================================================================ ;;; Adapted from Abelson & Sussman, Ch. 3, Pg 208 ff. ;;; Uses the ``methods'' OOP package. This is an expanded, ;;; industrial-strength solution to Exercise 3.22 of A & S. (define (new-queue . initial-list) (let ( (q (cons () ())) (dummy (if (not (null? initial-list)) (set! initial-list (car initial-list)))) (supers ()) ) (define (head) (car q)) (define (tail) (cdr q)) (define (set-head! item) (set-car! q item)) (define (set-tail! item) (set-cdr! q item)) (define (empty-queue?) (null? (head))) (define (front) (if (send self 'empty?) (error "FRONT called on empty queue") (car (head)))) (define (insert-queue! item) (let ((elt (cons item ()))) ; could be (list item) (cond ( (send self 'empty?) (set-head! elt) (set-tail! elt) self ) ( else (set-cdr! (tail) elt) (set-tail! elt) self )))) (define (insert-list! lyst) (cond ( (null? lyst) self ) ( else (send self 'insert! (car lyst)) (insert-list! (cdr lyst)) ))) (define (remove-queue!) (cond ( (send self 'empty?) (error "REMOVE called on empty queue") ) ( else (set-head! (cdr (head))) self))) (define (clear-queue!) (set! q (cons () ())) self) (define (print) (display (head)) (newline)) (define (self msg) (cond ( (eq? msg 'insert!) insert-queue! ) ( (eq? msg 'empty?) empty-queue? ) ( (eq? msg 'remove!) remove-queue! ) ( (eq? msg 'clear!) clear-queue! ) ( (eq? msg 'front) front ) ( (eq? msg 'print) print ) ( (eq? msg 'list) (lambda () (head)) ) ( (eq? msg 'insert-list!) insert-list! ) ( (search-supertypes supers msg) ) ( else (make-error-method "Queue" msg) ))) (insert-list! initial-list) ;;; returns ``self'' )) ;;; end of new-queue ; Test suite for queues. (define q (new-queue '(a b c d e))) (send q 'print) (send q 'list) (send (send q 'remove!) 'print) (send q 'empty?) (send (send q 'clear!) 'empty?) (send q 'print) (define q (new-queue)) (send q 'empty?)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Jul 89 14:04:14 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa27488; 3 Jul 89 14:00 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 3 Jul 89 13:46:55 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: 3 Jul 89 17:21:18 GMT From: John Lacey Organization: Cornell Theory Center, Cornell University, Ithaca NY Subject: Calculuses (sp?) for Scheme, and R*RS (again) Message-Id: <8313@batcomputer.tn.cornell.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anyone have references to calculus bases for Scheme (such as the lambda calculus, and the one by Matthias Felleisen)? That is, references that deal with these directly in terms of Scheme (of course those for the latter will, as it was designed for Scheme). Also, I am *still* looking for the text of the Revised * Report on Scheme. Where can I find it? Is there an E-mailable copy someplace? Sorry about posting these types of questions, but the libraries here are staffed with completely inadequate electronic searching systems, and summer help. -- John Lacey | Internet: lacey@tcgould.tn.cornell.edu running unattached | BITnet: lacey@crnlthry | UUCP: cornell!batcomputer!lacey "Whereof one cannot speak, thereof one must remain silent." ---Wittgenstein  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Jul 89 07:53:40 EDT Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa24699; 3 Jul 89 7:52 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 9370; Mon, 03 Jul 89 07:51:39 EDT Received: from NCCIBM1.BITNET (MAILER) by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 2544; Mon, 03 Jul 89 07:51:38 EDT Date: Mon, 03 Jul 89 07:49 EDT To: scheme@mc.lcs.mit.edu From: DYU%NCCIBM1.BITNET@mitvma.mit.edu Subject: AI NEWS FROM IEEE COMPUTER SOCIETY Message-ID: <8907030752.aa24699@mintaka.lcs.mit.edu> WHAT IS THE TASK FORCE ON EXPERT SYSTEMS? The IEEE Computer Society announces the formation of a Task Force on Expert Systems Applications. The purpose of the Task Force is to support interest in the development and use of expert systems applications. The IEEE Computer Society, which has over 100,000 members worldwide, authorized the creation of the Task Force at a meeting of its Technical Activities Board (TAB) held March 2nd in San Francisco, CA. The objectives of the Task Force are to improve the abilities of organizations and individuals to work with expert systems technologies. The Task Force will sponsor activities at the national and international levels, but also support local events. The Task Force will publish a newsletter, exchange electronic mail, provide speakers for conferences, organize tutorials, symposiums, and convene meetings on standards either on its own initiative or jointly with other IEEE Computer Society functions. The Importance of Expert Systems MIS and end users are experiencing an explosion of interest and activity in expert systems applications in almost all sectors of business, government, and education. This is taking place due to the wide distribution of expert system shells on personal computers and workstations. It is a remarkable change in the field of artificial intelligence in which developers usually rely on specialized computer platforms and programming languages. Expert systems are the most mature and resilient products to emerge from the AI community, and they are being adopted by corporations and government departments to improve productivity. They are doing this because the applications of expert systems to specific knowledge intensive systems return high yields. Success stories for expert systems are more common now than two years ago. A current estimate is there are 2,000 operational expert systems and 80% of them on running on personal computers. The Value of the Task Force The greatest value which will be derived from participating in the Task Force will come from regular discussions among Task Force participants. In some ways, this will resemble the informal interactions of a user group. In other ways it will compliment many of the professional activities of the IEEE Computer Society. Within these broad themes, there are many diverse interests, including business activities such as banking and finance, manufacturing and service functions, medical practice, government functions, including the military, and education. These interests will be addressed through locally sponsored and nationally significant activities including conferences, workshops, lectures, a newsletter, and other appropriate mechanisms. Membership All meetings of the Task Force are be open to the public and will be announced ahead of time in the news media. Anyone who has an interest in the objectives of the Task Force is invited to attend its functions and participate in its activities. Membership in the IEEE Computer Society is not required to attend our meetings. Since the Task Force is oriented toward development and use of expert systems applications, we expect and encourage the interest of vendors of computer hardware, software, and services. Future activities of the Task Force will be developed consistent with the goals and objectives of the IEEE Computer Society. For additional information, call Dan Yurman, Chairman, at 202-475-6754 9-5 EST. MCI Mail: 364-1277 Mailing address: ----------------------------- Task Force on Expert Systems c/o TAB Coordinator IEEE Computer Society 1730 Massachusetts Ave., NW Washington, DC 20036. IEEE Computer Society Task Force on Expert Systems Roles & Responsibilities Chair: This role is responsible for leadership and technical direction of the Task Force. The Chair maintains the vitality of the group by coordinating activities such as speakers, seminars, conferences, workshops, tutorials, workgroups on standards, and communications with members including newsletters and electronic mail. The Chair appoints the other leadership figures of the Task Force. Dan Yurman, Chairman Information Management Staff Office of Solid Waste & Emergency Response U.S. Environmental Protection Agency 401 M St., SW; (OS-110) Washington, DC 20460 202-475-6754 Vice-Chairs: The Chair appoints Vice-Chairs for the purpose of carrying out functions of the Task Force. All Vice Chairs receive logistical support from the IEEE Computer Society's administration office which is located in Washington, DC. Vice-Chairs are responsible for recruiting volunteers to carry out their responsibilities. Vice-Chairs are delegated the authority to appoint such committee chairs as may be needed, e.g. newsletter editor, workshop convener, etc. Communications: Responsible for all communications with members, the public, and other professional societies. Develops and publishes a newsletter, establishes electronic mail exchange, and sustains publicity for Task Force Events. Keeps a record of all meetings. Serves as a point of contact with IEEE Expert magazine and IEEE Computer magazine. Sandra Hoffman, Vice Chair for Communications Systems Analyst Congressional Budget Office 2nd & D, SW; Room 450 Washington, DC 20515 202-226-2886 Meetings: Responsible for developing a program of meetings featuring speakers on topics of interest to the membership. Works with other Vice- Chairs to handle local arrangements. Establishes working groups for tutorials and seminars on significant topics. Randy Manner, Vice Chair for Meetings Manager - Expert Systems Group American Management Systems 1777 N. Kent St. Arlington, VA 22209 703-841-6849 Conferences: This Vice-Chair has a liaison role for the IEEE Computer Society "Expert Systems in Government" Conference, and for other IEEE Computer Society conferences which emphasize applications of artificial intelligence and expert systems. Also, this Vice Chair is responsible for coordinating the working relationship of the Task Force with conferences on expert systems sponsored by other professional societies. Jerry Feinstein, Vice Chair for Conferences Vice President Phase-Linear Systems/ICF 9300 Lee Highway Fairfax, VA 22031 703-934-3280 Standards: Develops working groups composed of users, industry, and academia to address issues related to hardware or software standards for expert systems applications. Captain Dave Howell, Vice Chair for Standards Artificial Intelligence Program Management Office U.S. Air Force Logistics Command HQ AFLC/MM-AI Wright Patterson AFB, Ohio 45433 513-257-2571 Industry Relations: Establishes and maintains communications with hardware and software vendors, developers, and other commercial as well as not-for-profit providers of expert systems applications. Provides for demonstration or poster sessions on the latest technological developments. Joseph Schmuller, Vice Chair for Industry Relations Senior Knowledge Engineer CDM Federal Programs Corp. 13135 Lee Jackson Highway Fairfax, VA 22033 703-968-0900 Treasurer: Responsible for keeping track of Task Force finances, for fund raising including setting up a means to cover costs, and solicitations of "in kind" contributions. Vacant Membership: Responsible for developing and implementing a membership recruitment campaign for the Task Force working at the national level. Works with other Vice-Chairs to carry out these functions. Establishes and maintains liaison with IEEE Computer Society Chapters and Area Activities Boards as well as other Task Forces and Technical Committees. Vacant Task Force on Expert Systems c/o TAB Coordinator IEEE Computer Society 1730 Massachusetts Ave. NW Washington, DC 20036 --------------------------- Membership Mailing List and Activity Preference NOTE: If you can't wait for the mail, call a Vice Chair and volunteer today! Please complete this form and return it to: Dan Yurman, Chair Task Force on Expert Systems c/o US EPA (OS-110) 401 M St., SW Washington, DC 20460 Ph: 202-475-6754 Please provide any suggestions or comments in the margins of the paper. Thank you. Name:________________________________________________________ Title:_______________________________________________________ Organization:________________________________________________ Address:_____________________________________________________ _____________________________________________________________ City:________________________________________________________ State: ______ ZIP:__________ Daytime Phone: ______ ______ ____________ Electronic mail:_____________________________________________ Please indicate the activities you would like to volunteer your time and talents. You will be contacted soon. You do not have to be a member of the IEEE Computer Society to participate in the activities of the Task Force on Expert Systems. At this time there is no charge to be placed on our mailing list. Within the next six months there may be a nominal dues charge to continue to receive these materials.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Jul 89 05:04:32 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa23401; 3 Jul 89 4:59 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 3 Jul 89 04:32:01 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: 3 Jul 89 08:16:05 GMT From: Brian of ASTD-CP Organization: Jet Propulsion Laboratory, Pasadena, CA Subject: OOP in Scheme (addendum) Message-Id: <1406@jato.Jpl.Nasa.Gov> References: <1404@jato.Jpl.Nasa.Gov> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu ; methods.scm (ADDENDUM) ; ; =============================================================== ; Brian Beckman | brian@topaz.jpl.nasa.gov ; Mail Stop 510-202 | (818) 397-9207 ; Jet Propulsion Laboratory | ; Pasadena, CA 91109 | 30 June 1989 ; =============================================================== ; There are two ways to invoke a method in an object. The ; first is to send the object a message, getting back a procedure. ; This procedure can then be invoked at will on an appropriate ; set of arguments. Such an idiom usually results in expressions ; like the following: ; ; ((foo 'do-it) arg1 arg2) ; ; This is fairly readable and a fine idiom, but it has its ; limitations. Suppose that this expression were to result in ; another object, to which we should like to send the message ; 'baz with the arguments 'rat and 'ter. Then we should write ; the following: ; ; ((((foo 'do-it) arg1 arg2) 'baz) 'rat 'ter) ; ; The number of leading parentheses is a problem. It is easy ; to devise nested message passing expressions that are ; much more difficult to write than to devise, merely because of ; the number of leading parentheses that must be presaged. Lisp ; already has a problem with closing parentheses; we don't want ; to compound the felony in this package by introducing a ; corresponding problem with opening parentheses. ; ; We need a ``send'' routine that does little more than reduce ; the need for leading parenthese. This is, admittedly, merely ; a syntactic issue. Consider the following, which is the second ; way to send a message to an object: (define (send object msg . args) (apply (object msg) args)) ; The earlier example message passing expressions can now be ; much more easly written much more nicely, as follows: ; ; (send object 'msg arg1 arg2) ; ; and ; ; (send (send object 'msg arg1 arg2) 'baz 'rat 'ter)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 2 Jul 89 05:08:21 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa13679; 2 Jul 89 4:59 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 2 Jul 89 04:38:09 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: 2 Jul 89 07:31:07 GMT From: Brian of ASTD-CP Organization: Jet Propulsion Laboratory, Pasadena, CA Subject: OOP in Scheme Message-Id: <1404@jato.Jpl.Nasa.Gov> References: in, 'pure', scheme Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu ; methods2.scm ; ; =============================================================== ; Brian Beckman | brian@topaz.jpl.nasa.gov ; Mail Stop 510-202 | (818) 397-9207 ; Jet Propulsion Laboratory | ; Pasadena, CA 91109 | 30 June 1989 ; =============================================================== ; INTRODUCTION ; ; This is a tiny object-oriented programming system with multiple ; inheritance and error handling. It is modeled after the message ; passing modules in Chapter 3 of Abelson & Sussman. It is ; implemented in ``pure'' Scheme, without macros or syntax ; extensions. ; ; This programming system is implemented as a technique, or ; programming convention, with some helper routines. The programming ; convention is not enforced, as we choose to avoid syntax-extensions ; for portability's sake. The technique is illustrated in this file ; with a few examples. In example one, a parent class, named ; ``parent,'' passes its attributes to a child named ``child.'' In ; example two, two parents, ``mother'' ``fater'', pass their attributes ; to a child class, ``daughter.'' The reader will perceive the technique ; by generalization from these examples and will be able to apply it ; to his or her own problems. ; ; Every class is represented by its constructor procedure. This ; procedure returns a message dispatching procedure. The message ; dispatching procedure should be named ``self'' so that an object can ; conveniently send messages to itself. However, ``self'' is an ; internal name not known outside the constructor. ; ; In summary, classes are represented by constructor procedures, and ; objects, or instances of classes, are represented by message ; dispatching procedures. The present version of ``methods'' does not ; support code sharing, so every instance of a class has its own ; private copies of the method code. We expect to implement code ; sharing in a later version of ``methods''. ; ; The message dispatching procedure walks the multiple inheritance ; hierarchy upwards until it finds an object that can understand a ; message, starting with itself. If no object that can understand the ; message is found, a global error procedure is called. ; ; IMPLEMENTATION ; ; Error processing is challenging. We should like to have two modes. ; In ``normal mode'', an error is reported only by the first receiver ; of a message. In ``debug mode'', an inheritance traceback should be ; given whereby every object in an inheritance hierarchy will report ; when it fails to recognize a given message. The following variable ; represents that mode. (For simplicity, this object is hidden only ; by its name, which is unusual enough that it is unlikely to be ; trammeled by an application. This is not the recommended technique ; for data hiding. Data hiding ought to be implemented through the ; techniques shown in this file! However, since this error handling ; part of the methods package is considered system programming, ; certain liberties in style are justifiable. There are in fact, good ; technical reasons for the error handling code to be implemented with ; global variables, which the perceptive reader will be able to ; deduce.) (define **method-mode** 'normal-method-mode) ; The user can set these modes as follows. (define (set-debug-method-mode) (set! **method-mode** 'debug-method-mode)) (define (set-normal-method-mode) (set! **method-mode** 'normal-method-mode)) (define (reset-debug-method-mode) ;;; synonym (set! **method-mode** 'normal-method-mode)) ; and test them with the following routine: (define (test-debug-method-mode) (eq? **method-mode** 'debug-method-mode)) ; Before presenting the examples of classes and objects, some helper ; routines are needed. ; ; When an object cannot recognize a message, and none of its ancestor ; objects can recognize it, the object creates an error procedure and ; returns it as the result of the message dispatcher. (define **method-error-class-name** "No class name.") (define **method-error-message** 'no-message) (define (error-method . junk-args) (display **method-error-class-name**) (display ": uknown message: '") (display **method-error-message**) (newline) ()) (define (make-error-method class-name msg) (set! **method-error-class-name** class-name) (set! **method-error-message** msg) error-method) ; The procedure that walks the inheritance hierarchy must cooperate ; in the error handling. (define (search-supertypes supers msg) (define method ()) (if (test-debug-method-mode) (begin (display "Searching...") (newline))) (cond ( (null? supers) () ) ( (begin (set! method ((car supers) msg)) (eq? method error-method)) (if (test-debug-method-mode) (error-method)) (search-supertypes (cdr supers) msg) ) ( else method ))) ; This procedure implements the inheritance of methods. It is greatly ; complicated by proper error handling. Without error handling, the ; routine would resemble the following, which is much easier to ; understand (without error handling, the programming convention is ; that an object that does not understand a message returns the ; unexecutable method ``()''). ; ; (define (search-supertypes supers msg) ; (cond ; ( (null? supers) () ) ; ( ((car supers) msg) ) ; ( else (search-supertypes (cdr supers) msg) ))) ; ; The actual routine, with proper error handling, works as follows. A ; local variable, ``method'', is defined. Its value is not important ; to begin with. If debugging is on, we print a message telling the ; user that the inheritance hierarchy is being searched. Then, the ; list of supertypes is investigated. If the list is empty, we return ; nil, which signals the caller to create and return the error-method, ; as we shall see in the examples later. If the list is not empty, we ; pass the message to the first supertype in the list. The return ; value is assigned to the local variable ``method''. If the returned ; method is the one and only global error-method, then the supertype, ; and, recursively, all its supertypes, did not know the message. ; If debugging is on, we execute the returned error-method, contributing ; to the aforementioned inheritance traceback. Finally, we return ; the value of a recursive call of search-supertypes on the remainder ; of the list of supertypes. If the returned method is not the ; error-method, then the supertype did understand the message after ; all somewhere in the hierarchy, and the returned method is the ; return value of this procedure. ; ; Note that the list of supertypes is searched in order from front ; to back. The first match of a message results in the successful ; finding of a method. The order of supertypes in the list is ; significant only when more than one supertype can understand ; a given message. The earlier members of the list will shadow ; the later ones. In some object-oriented programming systems, one ; refers to the ``overriding'' of methods. The shadowing in ; ``methods'' is our form of method overriding, and it is under ; explicit control of the programmer who sets the order of supertypes ; in the list of supertypes. ; ; In summary, search-supertypes passes the message to the ancestors, ; in pre-order, returning the first method found. ; ; The next helper routine passes a message, and a variable number of ; arguments, to all the parents of an object. For side effects, it ; executes any methods found. Parents are defined as ; first level ancestors. (define (for-all-parents supers msg . args) (let ( (method-list (map (lambda (supertype) (supertype msg)) supers)) (for-proc (lambda (method) (apply method args))) ) (for-each for-proc method-list))) ; With the current programming convention, it is not possible to pass ; a message to all ancestors and execute the methods for side-effect ; without explicit cooperation on the part of the objects involved. In ; other words, the procedure ``for-all-ancestors'', analogous to ; ``for-all-parents'', cannot be implemented in the current version of ; the methods package. The reason is that the convention calls for ; every class to call ``search-supertypes'', which stops when it finds ; a method. The convention would have to be augmented so that objects ; would call ``find-all-methods'' (defined below) on an appropriate ; message. Since we expect the need for ``for-all-ancestors'' to be ; fairly rare, the necessary changes to the methods package will be ; reserved for a future version. (define (find-all-methods supers msg) (cond ( (null? supers) () ) ( else (cons ((car supers) msg) (find-all-methods (cdr supers) msg)) ))) ; EXAMPLES (cut here to end of file to throw examples away) ; ; Our first example class, or object type, is ``parent'', represented ; by the following constructor procedure. (define (new-parent arg) (let ((state-var (* arg arg)) (supers ())) (define (report-state-var) (display state-var) (newline) state-var) (define (update-state-var arg) (set! state-var (* arg arg))) (define (echo arg) (display arg) (newline)) (define (self msg) (cond ( (eq? msg 'report) report-state-var ) ( (eq? msg 'update) update-state-var ) ( (eq? msg 'echo) echo ) ( (search-supertypes supers msg) ) ( else (make-error-method "Parent" msg) ))) self)) ; This class, or constructor procedure, completely illustrates, by ; example, the programming convention of the ``methods'' technique. ; The constructor takes a single argument, whose square it stores in a ; local state variable. Another state variable, the list of ; supertypes, is set to nil, since this class is at the root of an ; inheritance hierarchy. Three methods are defined, one that reports ; and returns the current value of the state variable, one that sets ; the state variable equal to a new square, and one that merely echoes ; its argument. A method dispatching procedure, conventionally named ; ``self'', tests a given message against three symbols and returns ; the corresponding method if a match is found. If no match is found, ; the list of supertypes is searched for a match. In the case of this ; class, ``parent'', the search is purely formal, to illustrate how it ; should be done, since ``parent'' has no ancestors. However, if a ; match were found among the list of supertypes, the method would be ; returned. Note how the search relys on the fact that any non-nil ; result is treated as a successful ``cond'' clause, terminating the ; ``cond'' statement. Search-supertypes returns nil only when a match ; is not found. Finally, if no match is found locally or among the ; supertypes, an appropriate error-method is pseudo-created and ; returned. ; ; We now test this class by making an instance and passing it ; messages. (define p (new-parent 42)) ((p 'report)) ((p 'update) 69) ((p 'report)) ((p 'echo) (list 1 2 3)) ; We test error handling: ((p 'bogus)) (set-debug-method-mode) ((p 'bogus)) (reset-debug-method-mode) ((p 'bogus) 'here 'are 'some 'junk 'arguments) ; Continuing this example, let us define a child class inheriting ; all attributes and methods of the parent. Note the attributes of ; the parent are only accessible through the parent's method ; discipline. This is a strict form of inheritance, and the default ; in C++, for example. (C++ allows the programmer to override ; ancestors' access discipline, at his own peril.) (define (new-child arg1 arg2) (let* ( (leg1 (* arg1 arg1)) (leg2 (* arg2 arg2)) (hypotenuse (+ leg1 leg2)) (supers (list (new-parent hypotenuse))) ) (define (report) (for-all-parents supers 'report) (display "Leg1 = ") (display (sqrt leg1)) (newline) (display "Leg2 = ") (display (sqrt leg2)) (newline) (display "Hypo = ") (display (sqrt hypotenuse)) (newline)) (define (update-leg1 val) (set! leg1 (* val val)) (set! hypotenuse (+ leg1 leg2))) (define (update-leg2 val) (set! leg2 (* val val)) (set! hypotenuse (+ leg1 leg2))) (define (self msg) (cond ( (eq? msg 'report) report ) ( (eq? msg 'update-leg1) update-leg1 ) ( (eq? msg 'update-leg2) update-leg2 ) ( (search-supertypes supers msg) ) ( else (make-error-method "Child" msg) ))) self)) ; We now test the child type. (define c (new-child 3 4)) ((c 'report)) ;;; passes message to all parents ((c 'update-leg1) 5) ((c 'update-leg2) 12) ((c 'report)) ((c 'echo) '(foo bar)) ;;; msg known only in the parent ((c 'bogus) 'baz 'rat) (set-debug-method-mode) ((c 'bogus) 'baz 'rat) (reset-debug-method-mode) ((c 'bogus) 'baz 'rat) ; The last example, presented without detailed narrative, shows a ; slightly deeper inheritance hierarchy. The leaf is a type named ; ``daughter''. Its two parent classes are ``mother'' and ``father''. ; In turn, every mother has an ``estate'' and a ``religion'' (please ; excuse the somewhat strained metaphor of inheritance; this is just ; a little example). (define (new-estate value) (let ((value value) (supers ())) (define (report) (display "Estate = $") (display value) (newline)) (define (what-value) value) (define (increase amount) (set! value (+ value amount))) (define (decrease amount) (set! value (- value amount))) (define (self msg) (cond ( (eq? msg 'report) report ) ( (eq? msg 'what-estate) what-value ) ( (eq? msg 'increase) increase ) ( (eq? msg 'decrease) decrease ) ( (search-supertypes supers msg) ) ( else (make-error-method "Estate" msg) ))) self)) (define (new-religion theReligion) (let ((religion theReligion) (supers ())) (define (report) (display "Religion = ") (display religion) (newline)) (define (what-religion) religion) (define (convert theNewReligion) (set! religion theNewReligion)) (define (self msg) (cond ( (eq? msg 'report) report ) ( (eq? msg 'convert) convert ) ( (eq? msg 'what-religion) what-religion ) ( (search-supertypes supers msg) ) ( else (make-error-method "Religion" msg) ))) self)) (define (new-father eye-color) (let ((eye-color eye-color) (supers ())) (define (report) (display "Father's eye color = ") (display eye-color) (newline)) (define (what-eye-color) eye-color) (define (self msg) (cond ( (eq? msg 'report) report ) ( (eq? msg 'what-eye-color) what-eye-color ) ( (search-supertypes supers msg) ) ( else (make-error-method "Father" msg) ))) self)) (define (new-mother eye-color estate religion) (let ((eye-color eye-color) (supers (list (new-estate estate) (new-religion religion)))) (define (report) (for-all-parents supers 'report) (display "Mother's eye color = ") (display eye-color) (newline)) (define (what-eye-color) eye-color) (define (self msg) (cond ( (eq? msg 'report) report ) ( (eq? msg 'what-eye-color) what-eye-color ) ( (search-supertypes supers msg) ) ( else (make-error-method "Mother" msg) ))) self)) (define (new-daughter eye-color) (let* ((eye-color eye-color) (parents-eye-color (if (eq? eye-color 'blue) 'blue 'brown)) (supers (list (new-father parents-eye-color) (new-mother parents-eye-color 500000 'Jewish)))) (define (report) (for-all-parents supers 'report) (display "Daughter's eye color = ") (display eye-color) (newline)) (define (what-eye-color) eye-color) (define (self msg) (cond ( (eq? msg 'report) report ) ( (eq? msg 'what-eye-color) what-eye-color ) ( (search-supertypes supers msg) ) ( else (make-error-method "Daughter" msg) ))) self)) (define dbl (new-daughter 'blue)) ((dbl 'report)) ((dbl 'convert) 'muslim) ((dbl 'report)) ((dbl 'increase) 50000) ((dbl 'report)) (define dbr (new-daughter 'brown)) ((dbr 'report)) ((dbr 'decrease) 250000) ((dbr 'report)) ((dbr 'bogus)) (set-debug-method-mode) ((dbr 'bogus)) (reset-debug-method-mode)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Jul 89 07:38:43 EDT Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa04623; 1 Jul 89 7:35 EDT Return-Path: Received: by ZURICH.AI.MIT.EDU; Sat, 1 Jul 89 07:32:26 edt Date: Sat, 1 Jul 89 07:32:26 edt From: "Guillermo J. Rozas" Message-Id: <8907011132.AA22198@ZURICH.AI.MIT.EDU> To: scheme@mc.lcs.mit.edu Subject: Location for 3rd IEEE Scheme standard meeting The room for the meeting on July 7th will be MIT room 37-252. This room is called the Marlar Lounge, but few people know this, so you should ask for 37-252 if lost. Building 37's street address is 70 Vassar st. in Cambridge.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jun 89 17:32:22 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07078; 30 Jun 89 17:29 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 30 Jun 89 17:15:30 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: 28 Jun 89 17:10:22 GMT From: Dave McKellar Organization: Inter\Access, Toronto Subject: Learning Scheme as a first language Message-Id: <1989Jun28.131023.1031@intacc.uucp> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anyone know of an easy-reading book about scheme. If there is one I hope to use it as a text for a course teaching scheme as a first computer language. Please e-mail any reply to me as I dont read the news regularly. I will post a summary if there is any response. Thanks alot. -- ---------- {uunet,watmath,utzoo}!mnetor!intacc!mckellar "Taste is a matter of taste." ----------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jun 89 13:39:08 EDT Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa04323; 30 Jun 89 13:35 EDT Received: by iuvax.cs.indiana.edu Date: Fri, 30 Jun 89 12:35:31 -0500 From: Chris Haynes To: scheme-standard@wheaties.ai.mit.edu, scheme-rrrs@iuvax.cs.indiana.edu, scheme@mc.lcs.mit.edu Subject: Draft agenda for 3rd IEEE Scheme standard meeting Message-ID: <8906301335.aa04323@mintaka.lcs.mit.edu> A draft agenda follows for third meeting of the Scheme Working Group, July 7th, 9:30am-5pm, Cambridge, MIT (room to be announced soon). Suggestions for other agenda items are welcome. 1. Approve agenda. 2. Elect secretary. 3. Approve minutes of second meeting. 4. Discuss the numbers section of the standard draft. 5. Discuss proposals for differences between R4RS and the standard. 6. Discuss liaison with ISO WG-16. The question is whether we want to formally submit a draft of our standard to the International Standards Organization Lisp Working Group so that they may consider the possibility of adopting our standard as an ISO standard. If we decide to to submit, we must also draft an accompanying statement. 7. Establish time and place of next meeting.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jun 89 09:40:58 EDT Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa01822; 30 Jun 89 9:40 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 6543; Fri, 30 Jun 89 09:39:23 EDT Received: from TREARN.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 2163; Fri, 30 Jun 89 09:39:22 EDT Received: by TREARN (Mailer R2.03B) id 0340; Fri, 30 Jun 89 08:56:07 TUR Date: Friday, 30 June 1989 08:55:44 TUR From: Oguz ALGAN Subject: PC-Scheme To: SCHEME@mc.lcs.mit.edu Message-ID: <8906300940.aa01822@mintaka.lcs.mit.edu> Hello, I want to learn the current version of the Texas Instrument's PC-Scheme Lisp. And Do you know how can obtain the PC-Scheme's REFERANCE MANUAL or a book that tells me about PC-SCHEME's language features. Thanks in advance. Oguz ALGAN, ETIFIZ02@TREARN  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 14:11:22 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa26382; 28 Jun 89 14:06 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 28 Jun 89 13:49:09 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: 28 Jun 89 10:54:44 GMT From: Oliver Laumann Organization: Technical University of Berlin, Germany Subject: Re: Looking for R*RS and XScheme source by ftp Message-Id: <867@tub.UUCP> References: <8271@batcomputer.tn.cornell.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <8271@batcomputer.tn.cornell.edu> lacey@tcgould.tn.cornell.edu (John Lacey) writes: > if anyone knows of another free Scheme implementation, I would like > to hear about it. I'm going to send the sources of a Scheme interpreter to comp.sources.unix next week. You can expect it to be posted by Rich Salz in about 4 weeks. The interpreter is R^3RS compatible, includes interfaces to the Xlib, to Xt, and to the Athena and HP widget libraries of X11R3. It was written to be used as an general extension language interpreter (to be linked into an application); it is also useful as a stand-alone implementation of Scheme. Regards, -- Oliver Laumann net@TUB.BITNET net@tub.UUCP  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jun 89 13:48:14 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa12247; 27 Jun 89 13:44 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 27 Jun 89 13:42:27 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: 27 Jun 89 17:16:32 GMT From: John Lacey Organization: Cornell Theory Center, Cornell University, Ithaca NY Subject: Looking for R*RS and XScheme source by ftp Message-Id: <8271@batcomputer.tn.cornell.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I'm looking for the Revised Report, as well as the source to XScheme (by David Betz), preferably by ftp. Actually, if anyone knows of another free Scheme implementation, I would like to hear about it. I'll take the report in any form I can get it, but I would prefer a [La]TeX format. -- John Lacey | Internet: lacey@tcgould.tn.cornell.edu running unattached | BITnet: lacey@crnlthry | UUCP: cornell!batcomputer!lacey  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jun 89 11:02:50 EDT Received: from CU-ARPA.CS.CORNELL.EDU by mintaka.lcs.mit.edu id aa26688; 26 Jun 89 10:58 EDT Received: from LOKI.CS.CORNELL.EDU by cu-arpa.cs.cornell.edu (5.61+2/1.91d) id AA13626; Mon, 26 Jun 89 10:58:07 -0400 Received: from lakshmi.cs.cornell.edu by loki.cs.cornell.edu (4.0/I-1.91f) id AA29819; Mon, 26 Jun 89 10:58:03 EDT From: Chet Murthy Message-Id: <8906261457.AA02518@lakshmi.cs.cornell.edu> Received: by lakshmi.cs.cornell.edu (4.0/N-0.08) id AA02518; Mon, 26 Jun 89 10:57:58 EDT To: Scheme@mc.lcs.mit.edu Subject: Re: Scheme Digest #145 In-Reply-To: Your message of 26 Jun 89 00:07:06 -0400. <8906260045.aa06648@mintaka.lcs.mit.edu> Date: Mon, 26 Jun 89 10:57:57 -0400 Please remove me from the Scheme mailing list. My addresses are: murthy@cs.cornell.edu murthy@svax.cs.cornell.edu Thanks, --chet--  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jun 89 18:48:48 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa04054; 25 Jun 89 18:43 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 25 Jun 89 18:36:39 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: 25 Jun 89 22:17:45 GMT From: Dorai Sitaram Organization: Rice University, Houston Subject: Re: "unspecified" and SET! Message-Id: <4011@kalliope.rice.edu> References: <3902@kalliope.rice.edu>, <19890619192610.2.ALAN@PIGPEN.AI.MIT.EDU>, <2281@ubc-cs.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <2281@ubc-cs.UUCP> manis@grads.cs.ubc.ca (Vincent Manis) writes: >Going to the trouble to develop a calculus of unspecified values >strikes me as almost as silly as some of the things I did when I was >involved in writing an Algol 68 compiler. If this is in response to my posting(s) entitled "unspecified and set!" (and I'm not sure it is -- Vincent doesn't say), I request permission to shriek, "No! This is not what I meant!" ;-) I was drawing attention to side-effecting constructs in the literature (that they appeared in a calculus-definition is of secondary importance) that give all the "power" of current Schemes WITHOUT having to mess with (returning) unspecified values at all. I do, of course, concur with Vincent that having an unspecified object like #!unspecified is close to being the all-time great oxymoron of our troubled times (though he might not use the selfsame words ;-]). Second, the comparison that Vincent draws between "(#!)unspecified" and "bottom" is not correct. "Bottom" stands for divergence (non-termination) and occasionally, errors; "(#!)unspecified" is a stopgap value concocted to stand for a meaningless value returned in a TERMINATING computation. --dorai ------------------------------------------------------------------------------- It may be that the gulfs will wash us down; It may be we shall touch the Happy Isles. -------------------------------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jun 89 04:06:30 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa14756; 25 Jun 89 4:04 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 25 Jun 89 03:47:40 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: 23 Jun 89 02:01:05 GMT From: Vincent Manis Organization: The Invisible City of Kitezh Subject: Re: "unspecified" and SET! Message-Id: <2322@ubc-cs.UUCP> References: <19890619192610.2.ALAN@PIGPEN.AI.MIT.EDU>, <2281@ubc-cs.UUCP>, <81872@ti-csl.csc.ti.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <81872@ti-csl.csc.ti.com> gateley@m2.UUCP (John Gateley) writes: >Do you mean Matthias Felleisen's calculus for Scheme? It is neither a >calculus of unspecified values nor silly. It is a better theoretical >basis for Scheme than the lambda value calculus: it includes both >set! style side effects and continuations in its equations. To clarify, let me say emphatically that I *don't* mean Felleisen's calculus. As John says, Felleisen's work is not at all silly. I was instead referring to the proposals for #!unspecified, which, is either the same as `bottom' in denotational semantics or it is not. In the former case, #!unspecified should be returned, also, in both a division by 0 and a non-terminating recursion. In the latter case, #!unspecified is somewhat pointless (set! could just as easily return `()), unless one has some reason for distinguishing the two. While I do not care for William of Ockham's metaphysics, there is much to say for his Razor. ____________ Vincent Manis | manis@cs.ubc.ca ___ \ _____ The Invisible City of Kitezh | manis@cs.ubc.cdn ____ \ ____ Department of Computer Science | manis%cs.ubc@relay.cs.net ___ /\ ___ University of British Columbia | uunet!ubc-cs!manis __ / \ __ Vancouver, BC, Canada V6T 1W5 | (604) 228-2394 _ / __ \ _ "Theoretical computer science helps me convince people that ____________ my indecisiveness is really Nondeterminism, which sounds like a much more positive characteristic." -- a student  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jun 89 09:34:33 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa26458; 22 Jun 89 9:30 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 22 Jun 89 07:56:52 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: 22 Jun 89 03:27:48 GMT From: John Gateley Organization: TI Computer Science Center, Dallas Subject: Re: "unspecified" and SET! Message-Id: <81872@ti-csl.csc.ti.com> References: <3902@kalliope.rice.edu>, <19890619192610.2.ALAN@PIGPEN.AI.MIT.EDU>, <2281@ubc-cs.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <2281@ubc-cs.UUCP> manis@grads.cs.ubc.ca (Vincent Manis) writes: >Going to the trouble to develop a calculus of unspecified values >strikes me as almost as silly as some of the things I did when I was >involved in writing an Algol 68 compiler. ... >____________ Vincent Manis | manis@cs.ubc.ca ... Do you mean Matthias Felleisen's calculus for Scheme? It is neither a calculus of unspecified values nor silly. It is a better theoretical basis for Scheme than the lambda value calculus: it includes both set! style side effects and continuations in its equations. John gateley@m2.csc.ti.com  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jun 89 19:57:13 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa08284; 21 Jun 89 19:51 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 21 Jun 89 19:38:58 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: 21 Jun 89 22:47:44 GMT From: Chris Haynes Organization: Indiana University Subject: Re: "unspecified" and SET! Message-Id: References: <10160.890620.ALAN@ML.AI.MIT.EDU>, <8906212117.AA20117@sesame.Stanford.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu From: mkatz@SESAME.STANFORD.EDU (Morris Katz) Newsgroups: comp.lang.scheme Date: 21 Jun 89 21:17:54 GMT ... P.S. After the meeting at Snowbird, Guy Steele and I came to an agreement as to the correct of the two conflicting semantics for multiple values to continuations that we proposed. At that time, we believed that this solution would probably be acceptable to the great majority of the community. Is there interest in having the proposal written up for future consideration? I would be willing to strain my memory in an attempt to creat such a proposal if there is genuine interest. I'm interested.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jun 89 17:24:43 EDT Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa12352; 21 Jun 89 17:18 EDT Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C) id AA20117; Wed, 21 Jun 89 14:17:54 PDT Date: Wed, 21 Jun 89 14:17:54 PDT From: Morris Katz Message-Id: <8906212117.AA20117@sesame.Stanford.EDU> To: Scheme@mc.lcs.mit.edu In-Reply-To: Alan Bawden's message of Tue, 20 Jun 89 18:15:21 EDT <10160.890620.ALAN@ML.AI.MIT.EDU> Subject: "unspecified" and SET! At the R*RS meeting in Snowbird we discussed the possibility of adding some form of multiple values to Scheme and allowing continuations to accept multiple values. I wonder if the solution to the problem of what should be returned by side effecting procedures like SET! is to just have them return no values (i.e. a zero arity multiple value). As long as continuations can handle multiple values appropriately, it seems to me that this solution would have many, if not all, of the advantages of #!UNSPECIFIED without introducing many of the undesirable side effects. Morry Katz katz@polya.stanford.edu P.S. After the meeting at Snowbird, Guy Steele and I came to an agreement as to the correct of the two conflicting semantics for multiple values to continuations that we proposed. At that time, we believed that this solution would probably be acceptable to the great majority of the community. Is there interest in having the proposal written up for future consideration? I would be willing to strain my memory in an attempt to creat such a proposal if there is genuine interest.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jun 89 16:39:24 EDT Received: from [128.81.41.45] by mintaka.lcs.mit.edu id aa15560; 21 Jun 89 16:20 EDT Received: from PERTA.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 143800; Wed 21-Jun-89 15:49:05 EDT Date: Wed, 21 Jun 89 15:48 EDT From: Andre van Meulebrouck Subject: Scheme Digest #125 To: shap@polya.stanford.edu, Scheme@mc.lcs.mit.edu cc: vanmeule@allegheny.scrc.symbolics.com In-Reply-To: <8905250927.AA29776@polya.Stanford.EDU> Message-ID: <19890621194848.5.VANMEULE@PERTA.SCRC.Symbolics.COM> Date: Thu, 25 May 89 02:27:13 -0700 From: "Jonathan S. Shapiro" Very well. I hereby specify an object whose name is #UNSPECIFIED Any association between this name and some meaning in your mind is coincidental. I propose that all functions/forms that under some conditions currently return an unspecified value should now return a value which is EQ? to the value named by #UNSPECIFIED under those same conditions. Note that you are only in violation of R3RS if you *tell* me that that is what you do... Seriously: It's a non-damaging change, and there seems to be concensus that it is valuable to some part of the community and has no impact to speak of on anyone else. Let's do it. Jon [Disclaimer: my opinions are purely my own.] An off-the-cuff comment after seeing the argument posed that way (^^) is: "Why not? After all there is canonical truth!". I see a lot of parallels between canonical unspecified and canonical truth. I'm not taking sides however, because my jury's still out and/or I don't care enough to get really religious one way or the other about it. BTW: I think the whole thing with nil vs. () vs. #f got a lot of mental energy spent on it, and even after all that mind power being focused on that issue, I'm still not convinced that things are now consistent or appreciably cleaner than before: the net outcome seems to have hypocrisies of its own such that I'm not convinced Scheme is truly better off than Common Lisp (on the nil issue) for all the hubbub and hoopla.  Received: from ML.AI.MIT.EDU (CHAOS 3133) by MC.LCS.MIT.EDU 20 Jun 89 18:16:40 EDT Date: Tue, 20 Jun 89 18:15:21 EDT From: Alan Bawden Subject: "unspecified" and SET! To: titan!dorai@RICE.EDU, Scheme@MC.LCS.MIT.EDU Message-ID: <10160.890620.ALAN@ML.AI.MIT.EDU> Date: 19 Jun 89 23:24:37 GMT From: Dorai Sitaram How do you deal with the other "commands" of Scheme? (E.g., READ, SET-CAR!, PRINTF.) Easier than SET!. SIGMA-like counterparts need _not_ be made for these, as that would lead to a plethora of special forms (as opposed to 'procedures'). All of these "command" procedures now take an additional argument for "the body" (thunk actually) whose value is returned. So we would write (NEWLINE (CURRENT-OUTPUT-PORT) (LAMBDA () (WRITE X (CURRENT-OUTPUT-PORT) (LAMBDA () X)))) to newline, and then output and return the current value of X. (Or perhaps the continuations are passed as the first argument -- it doesn't matter in the current discussion.) Now it would seem to me that the most uniform way to include assignment in this scheme, is to have SET! take a continuation as well. So (SET! X (+ X 1) (LAMBDA () X)) would increment the value of X and return the new value. SET! is still a keyword, so this isn't -exactly- parallel with the side-effecting procedures. But I'll bet that once people start writing programs using this scheme, the thing that will impress them the most is that whenever they perform a side-effect they have to create an explicit continuation to wait for the side-effect to happen. And I'll bet they will be most comfortable if they have to make exactly the same kind of continuation for SET!. I'm currently working on a language where users really -must- control sequencing by explicitly using thunks, so I'm very interested in linguistic constructs that support this style. Actually, in my case its worse than in plain Scheme, because users must also exert control over when variables are -read- as well as written. Thus users have to write something like (LOOK! X (LAMBDA (VALUE) (SET! X (+ 1 VALUE) (LAMBDA () )))) to increment the value of X, because if they wrote (SET! X (+ 1 X) (LAMBDA () )) the occurrence of X in (+ 1 X) might be taken to refer to the value of X -after- the SET! happens (so that the value of X would become the fixed point of (lambda (n) (+ 1 n))!).  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jun 89 14:25:15 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa01965; 20 Jun 89 14:20 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 20 Jun 89 13:45:07 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: 20 Jun 89 16:29:44 GMT From: Brad Pierce Organization: UCLA Computer Science Department Subject: Re: "unspecified" and SET! Message-Id: <25058@shemp.CS.UCLA.EDU> References: <3902@kalliope.rice.edu>, <19890619192610.2.ALAN@PIGPEN.AI.MIT.EDU>, <2281@ubc-cs.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <2281@ubc-cs.UUCP> manis@grads.cs.ubc.ca (Vincent Manis) writes: << Stuff omitted. >> >I regard `returns an unspecified result' as an injunction not to place >a call to a procedure in a value-returning position, e.g., the last >step in a lambda or begin. If I wrote a Scheme compiler, fascist that >I am, I would probably generate an error message for such a usage. << Stuff omitted. >> This is really not a criticsm, only a question. How does one go about building a compiler that can detect when a procedure is going to return an unspecified result, especially those which sometime return unspecified values and sometimes return specified values? For example, in an object-oriented program most objects will respond to some messages with actual information and to some messages with unspecified values. On the face of it, it sounds very difficult to determine such things syntactically. And wouldn't runtime checking amount to introducing the unspecified object? It doesn't seem right to me that a user should have to know the full specifications of an object before being able to confidently send messages to that object. It would seem preferable to me to be able to check whether the result returned has any information content. Also in this discussion I haven't heard any mention of my suggestion to see the unspecified object as being analogous to NaN in the IEEE numeric standard. Is that a bad analogy? Is NaN a bad idea? Just wondering. -- Brad  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jun 89 09:53:26 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa28668; 20 Jun 89 9:47 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 20 Jun 89 09:15:57 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: 20 Jun 89 01:48:58 GMT From: Vincent Manis Organization: The Invisible City of Kitezh Subject: Re: "unspecified" and SET! Message-Id: <2281@ubc-cs.UUCP> References: <3902@kalliope.rice.edu>, <19890619192610.2.ALAN@PIGPEN.AI.MIT.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I've bitten my tongue on this, but I really can't see the point of #!unspecified. Perhaps it would be nice in theory (especially if (define loop (lambda (x) (loop (1+ x)))) returned #!unspecified, which would then be equivalent to `bottom' in the Scott-Strachey world), but it seems pointless. One can argue, as somebody has, that the existing behaviour distinguishes between expressions and commands; however, Scheme already has a strong notion of side effects (unlike, say, Miranda), and whether a side-effecting procedure yields (), #f, an unspecified result, or #!unspecified really makes no difference to anybody, except in one place, which I'll mention in a moment. I regard `returns an unspecified result' as an injunction not to place a call to a procedure in a value-returning position, e.g., the last step in a lambda or begin. If I wrote a Scheme compiler, fascist that I am, I would probably generate an error message for such a usage. Going to the trouble to develop a calculus of unspecified values strikes me as almost as silly as some of the things I did when I was involved in writing an Algol 68 compiler. The one place where #!unspecified makes some sense is in Read-Eval-Print loops. One can use #!unspecified as a trigger that the result is not to be printed. But then one does not need to change the language: PC Scheme, for example, has *the-non-printing-object*. If it ain't broke, don't fix it. ____________ Vincent Manis | manis@cs.ubc.ca ___ \ _____ The Invisible City of Kitezh | manis@cs.ubc.cdn ____ \ ____ Department of Computer Science | manis%cs.ubc@relay.cs.net ___ /\ ___ University of British Columbia | uunet!ubc-cs!manis __ / \ __ Vancouver, BC, Canada V6T 1W5 | (604) 228-2394 _ / __ \ _ "Theoretical computer science helps me convince people that ____________ my indecisiveness is really Nondeterminism, which sounds like a much more positive characteristic." -- a student  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Jun 89 21:20:18 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa26725; 19 Jun 89 21:17 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 19 Jun 89 20:37:01 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: 19 Jun 89 23:24:37 GMT From: Dorai Sitaram Organization: Rice University, Houston Subject: Re: "unspecified" and SET! Message-Id: <3904@kalliope.rice.edu> References: <3902@kalliope.rice.edu>, <19890619192610.2.ALAN@PIGPEN.AI.MIT.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In response to my posting suggesting SIGMA and SIGMA-based SET! (a la LAMBDA and LET) instead of traditional SET!, I received email which basically states that SIGMA violates the orthogonality of Scheme constructs, viz., SIGMA does "two" things: it "side-effects the environment" _and_ "returns a value". In other words, it is felt that any side-effecting construct should just perform the job it was made for, viz., side-effecting, and not do something else too, like returning values. SIGMA allegedly "fails" in the latter detail. But then, we should remember that our goal was to preserve the syntactic uniformity of Scheme. Scheme is (and very deliberately too) an expression-oriented language. In spite of our best efforts, traditional SET! does return a value. Given that whichever primitive side-effecting construct we pick will inevitably return a value, which construct should we choose? I would prefer one where the returned value is not only meaningful but _necessary_. The value that SET! returns is totally arbitrary. What SIGMA returns is crucial to its correctness. Recall that SIGMA does not perform a side-effect immediately; it returns a closure, which needs to be applied to value(s) before any side-effecting can take place. (Incidentally, LAMBDA, the cornerstone of Scheme, also has "two" purposes _if_ we take "returning a value" as a distinguishing property in assessing the orthogonality of Scheme. LAMBDA introduces fresh lexical variables _and_ returns a closure. I don't think anyone seriously wants to reject LAMBDA for lack of orthogonality!) --dorai ps: Other questions: * Why was SIGMA created? Felleisen & Friedman (POPL 1987) devised a calculus for a lambda-calculus-like language with assignments. SIGMA kind of falls out naturally. * Why is it "superior" to SET!? "Superior" is a tough word. However, I did mention the naturalness of parallel assignment in my orig. posting. Using SIGMA-capabilities as arguments to control-reifiers like call/cc is also delicious. * There is also another reason why the SIGMA-model of assignment, viz., (sigma (x ...) e ...) or (set! ([x a] ...) e ...), makes sense. In any program, one always performs some operation _after_ the side-effecting (of variable-bindings(see + below)) has been done. If the side-effecting were the last thing done in the program, there is no way it could be detected, hence no way it could be meaningful. Thus the application of a SIGMA-capability returns the value of the body of the SIGMA-expression, something (and such a something invariably exists) that is evaluated _after_ the side-effecting has taken place. +{PRINTF is the only side-effect which can meaningfully be the last thing in a program.} * [Alan Bawden's question about NEWLINE...] How do you deal with the other "commands" of Scheme? (E.g., READ, SET-CAR!, PRINTF.) Easier than SET!. SIGMA-like counterparts need _not_ be made for these, as that would lead to a plethora of special forms (as opposed to 'procedures'). All of these "command" procedures now take an additional argument for "the body" (thunk actually) whose value is returned. {* SIGMA of course is necessarily a special form (i.e., it cannot be substituted by a procedure as for READ, SET-CAR!, PRINTF above). The reason is variable names can't be passed as procedure arguments.} --dorai ------------------------------------------------------------------------------- It may be that the gulfs will wash us down; It may be we shall touch the Happy Isles. -------------------------------------------------------------------------------  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 19 Jun 89 15:28:27 EDT Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 225389; Mon 19-Jun-89 15:26:22 EDT Date: Mon, 19 Jun 89 15:26 EDT From: Alan Bawden Subject: "unspecified" and SET! To: titan!dorai@rice.edu cc: Scheme@MC.LCS.MIT.EDU In-Reply-To: <3902@kalliope.rice.edu> Message-ID: <19890619192610.2.ALAN@PIGPEN.AI.MIT.EDU> Date: 18 Jun 89 23:17:50 GMT From: Dorai Sitaram ... Perhaps, SET! is not the ideal side-effecting construct for an expression-oriented language. Felleisen and Friedman [1] propose a side-effecting construct called a SIGMA-capability. This looks just like a LAMBDA-expression, but whereas LAMBDA introduces new bound variables, SIGMA modifies the binding of existing lexical variables. In other words, on applying a SIGMA-capability to arguments, the variables corresponding to the SIGMA-parameters are side-effected. Problems about "unspecified" return values disappear.... I'm having a hard time applying this idea to the NEWLINE procedure -- which is specified in R3RS to return an unspecified value. Is the idea to introduce a side-effecting construct that looks like LAMBDA, but performs a newline when applied to an output port? ((NULINE () ) (CURRENT-OUTPUT-PORT))  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Jun 89 19:54:19 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05037; 18 Jun 89 19:48 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 18 Jun 89 19:35:04 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: 18 Jun 89 23:17:50 GMT From: Dorai Sitaram Organization: Rice University, Houston Subject: "unspecified" and SET! Message-Id: <3902@kalliope.rice.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu The recent discussion of "unspecified" values reveals that Scheme is not as syntactically uniform as it is claimed to be. Some Scheme syntactic forms return meaningful values, others don't: the former are "expressions" and the latter "commands". "Commands" are usually used to represent side-effects, e.g., assignment in the form of set!. In an expression-oriented language, a "command" is awkwardly "expressed" by an expression returning an arbitrary "unspecified" value. Perhaps, SET! is not the ideal side-effecting construct for an expression-oriented language. Felleisen and Friedman [1] propose a side-effecting construct called a SIGMA-capability. This looks just like a LAMBDA-expression, but whereas LAMBDA introduces new bound variables, SIGMA modifies the binding of existing lexical variables. In other words, on applying a SIGMA-capability to arguments, the variables corresponding to the SIGMA-parameters are side-effected. Problems about "unspecified" return values disappear. The application of a SIGMA-capability side-effects the SIGMA-parameters and returns the result of evaluating the SIGMA-body (the parallel being the application of a LAMBDA-expression). In addition, SIGMA gives a very natural method for parallel assignment, since the arguments to a SIGMA-capability are all evaluated before the application performs the side-effects. We can retrieve the old SET! from SIGMA as follows: (set! x a) == ((sigma (x) ) a) where is the "unspecified" value of your choice. Thus, there is no dependence on a system-chosen unspecified value. Even better, we need not fall back on a command with its necessarily arbitrary choice of unspecified return value. We can define a _generalized_ SET! in terms of SIGMA that is more along the lines of LET in terms of LAMBDA: (set! ([x a] ...) e ...) == ((sigma (x ...) e ...) a ...) The upshot of all this is that while we have side-effects, we still have a syntactically uniform language. --dorai [1] Felleisen & Friedman, A calculus for assigments ..., POPL 1987, 314 - 325. ps: In terms of SET!, SIGMA's effect is as follows: (sigma (x ...) e ...) == (lambda (x^ ...) (set! x x^) ... e ...) where x^ ... are new variables, used only to show what's going on. A native implementation of SIGMA is simply got by mimicking LAMBDA, except for the following: where LAMBDA has extend-environment, SIGMA has update-environment. ------------------------------------------------------------------------------- It may be that the gulfs will wash us down; It may be we shall touch the Happy Isles. -------------------------------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jun 89 08:26:06 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa15016; 17 Jun 89 8:23 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 17 Jun 89 07:51:10 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: 16 Jun 89 21:43:25 GMT From: Brian Leverich Organization: RAND Corp., Santa Monica, CA Subject: BUG IN EXPANDED MEMORY TI PC-SCHEME? Message-Id: <2102@randvax.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu On "long" simulation runs (20+ minutes on a 12mHz 286 with LIM 4.0 EMS...) using PCSEXP, the _expanded memory_ version of Texas Instrument's PC-Scheme, I apparently run low on space, the gc starts thrashing around, and finally I get a Scheme reset because the system is out of space. Problem is, I can't find anywhere near enough current structures to fill memory. Moreover, (freesp) returns 400K + of memory, then if I invoke (freesp) again (or anything else...) it triggers another gc and sometimes another Scheme reset. I don't have the problem when I use PCSEXT and jumper my expanded memory to act like extended. Looks like (freesp) can see a big chunk of free space, but the gc isn't adding it to the free list. Anyone else had this problem with PCSEXP? Anyone have any workaround suggestions? Tnx. -B -- "Simulate it in ROSS" Brian Leverich | U.S. Snail: 1700 Main St. ARPAnet: leverich@rand.org | Santa Monica, CA 90406 UUCP: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jun 89 08:52:53 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03139; 11 Jun 89 8:45 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 11 Jun 89 07:46:19 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: 10 Jun 89 19:36:03 GMT From: Brian Leverich Organization: RAND Corp., Santa Monica, CA Subject: SCREEN GRABBER AND MOUSE INTERFACE FOR TI'S PC-SCHEME Message-Id: <2074@randvax.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Before I do it myself, has anyone built a screen grabber for TI's PC-Scheme that will allow you to capture the graphics displayed on the monitor and save them to a file in some format that they can be manipulated, printed, or redisplayed? Also, has anyone built a mouse interface? Finally, does anyone know if there are PC-Scheme primitives for peeking and poking? I need them for several little projects. Thanks! -B -- "Simulate it in ROSS" Brian Leverich | U.S. Snail: 1700 Main St. ARPAnet: leverich@rand-unix | Santa Monica, CA 90406 UUCP/usenet: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jun 89 08:52:47 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03131; 11 Jun 89 8:44 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 11 Jun 89 07:45:55 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: 10 Jun 89 17:45:28 GMT From: Brian Leverich Organization: RAND Corp., Santa Monica, CA Subject: PASSING DATA FROM TI-SCHEME TO EDWIN Message-Id: <2073@randvax.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anyone know an elegant way to pass data (generally S-expressions) _from_ TI's PC-SCHEME _to_ EDWIN? As a crude hack Scheme can write the data to a temp file and then edwin can visit that file, but I'd like something nicer. More generally, does anyone know how to fudge with the edwin buffer and ring data structures from inside Scheme? I'm not prissy. Thanks! -B -- "Simulate it in ROSS" Brian Leverich | U.S. Snail: 1700 Main St. ARPAnet: leverich@rand-unix | Santa Monica, CA 90406 UUCP/usenet: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 9 Jun 89 16:37:23 EDT Date: Fri, 9 Jun 89 16:38:12 EDT From: Alan Bawden Subject: Algorithm for RATIONALIZE To: Scheme@MC.LCS.MIT.EDU Message-ID: <607195.890609.ALAN@AI.AI.MIT.EDU> ; This code assumes -perfect- arithmetic, so it wont get the ; exactness correct in any particular implementation. ; To really understand how this works, you should go learn about continued ; fractions. (define (rationalize x e) (simplest-rational (- x e) (+ x e))) ; Produces the simplest rational between X and Y inclusive. ; (In the comments that follow, [x] means floor(x).) (define (simplest-rational x y) (define (simplest-rational-internal x y) ; assumes 0 < X < Y (let ((fx (floor x)) ; [X] <= X < [X]+1 (fy (floor y))) ; [Y] <= Y < [Y]+1, also [X] <= [Y] (cond ((not (< fx x)) ;; X is an integer so X is the answer: fx) ((= fx fy) ;; [Y] = [X] < X < Y so expand the next term in the continued ;; fraction: (+ fx (/ (simplest-rational-internal (/ (- y fy)) (/ (- x fx)))))) (else ;; [X] < X < [X]+1 <= [Y] <= Y so [X]+1 is the answer: (+ 1 fx))))) (cond ((< y x) ;; Y < X so swap and try again: (simplest-rational y x)) ((not (< x y)) ;; X = Y so if that is a rational that is the answer, otherwise ;; there is nothing we can return at all. (if (rational? x) x (error))) ((positive? x) ;; 0 < X < Y which is what SIMPLEST-RATIONAL-INTERNAL expects: (simplest-rational-internal x y)) ((negative? y) ;; X < Y < 0 so 0 < -Y < -X and we negate the answer: (- (simplest-rational-internal (- y) (- x)))) (else ;; X <= 0 <= Y so zero is the answer: 0)))  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Jun 89 17:52:43 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa22646; 8 Jun 89 17:46 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 8 Jun 89 17:25:39 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: 8 Jun 89 19:34:07 GMT From: Robert Steven Glickstein Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA Subject: Algorithm needed for "rationalize" Message-Id: <4YXgcjO00Vsn0Jl0t=@andrew.cmu.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I am writing a Scheme interpreter based in the Revised^3.95 Report on Scheme. I am unable to find or devise an algorithm for the "rationalize" procedure. Rationalize operates on two real, rational or integral numbers. To quote the report: (rationalize x y) Rationalize returns the *simplest* rational number differing from x by no more than y. A rational number r1 is *simpler* than another rational number r2 if r1 = p1/q1 and r2 = p2/q2 (in lowest terms) and |p1| <= |p2| and |q1| <= |q2|. Thus 3/5 is simpler than 4/7. Although not all rationals are comparable in this ordering (consider 2/7 and 3/5) any interval contains a rational number that is simpler than every other rational number in that interval (the simpler 2/5 lies between 2/7 and 3/5). Note that 0 = 0/1 is the simplest rational of all. Thanks in advance. Bob Glickstein, ITC Database Group Information Technology Center Carnegie Mellon University Pittsburgh, PA  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Jun 89 21:49:19 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa00508; 7 Jun 89 21:45 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 7 Jun 89 21:07:13 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: 7 Jun 89 22:22:57 GMT From: Robert Steven Glickstein Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA Subject: Error in R^3.95RS? Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I have a copy of the Revised^3.95 Report on Scheme. In the lexical structure section (7.1.1, page 31), the second rule for is . #* Should this not be . + #* (note the "+" after )? -Bob Glickstein  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Jun 89 21:02:11 EDT Received: from F.GP.CS.CMU.EDU by mintaka.lcs.mit.edu id aa19864; 5 Jun 89 20:57 EDT Date: 5 Jun 1989 20:42-EDT From: Barak.Pearlmutter@cs.cmu.edu To: Scheme%mc.lcs.mit.edu@lcs.mit.edu Cc: Kevin.Lang@cs.cmu.edu Subject: Re: SCOOP problems Message-Id: In-Reply-To: Scheme's mail message of 2 JUN 89 00:12:18 EDT > Date: 1 Jun 89 12:05:26 GMT > From: "Donal O'Mahony - OMAHONY@cs.tcd.ie" > Subject: SCOOPS problems > Message-Id: <46261@csvax1.cs.tcd.ie> > > Having used X-Lisp for a while, I moved over to TI-Scoops. There are > two very annoying defects in that implementation of OOP. > > 1) SCOOPS objects don't have a SELF instance variable. I had to get > around this by redefininng SEND to do a FLUID-LET on the symbol > SELF before sending the message, but this is both ugly and slow. > > 2) There is no SEND-SUPER primitive - this means that super-classes > methods must be completely overridden, rather than extended which > removes a lot of the benefits of having inheritance in the first > place. > > > A slightly less annoying feature is that the arguments to SEND > are evaluated in the environment of the object begin sent-to > rather than in the calling environment i.e. > (let ((a 1)) > (send an-object (+ a 1))) > will bomb-out due to 'a' not being defined in an-object's environment. > > Has anybody got good solutions to the above? If simple generic dispatch would suffice, you could use a non object oriented dialect which supports generic procedures, like ADA or T. On the other hand, Oaklisp purports to be a solution. As you may have heard, Oaklisp claims to retain Scheme's lexical scoping while incorporating so-called object-oriented facilities, allegedly including the apparently desirable ``features'' described above.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 2 Jun 89 21:48:53 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05759; 2 Jun 89 21:43 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 2 Jun 89 20:52:11 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: 2 Jun 89 23:32:12 GMT From: William Clinger Organization: University of Oregon, Computer Science, Eugene OR Subject: OOP without EVAL Message-Id: <4807@uoregon.uoregon.edu> References: <8905302120.aa01439@mintaka.lcs.mit.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <8905302120.aa01439@mintaka.lcs.mit.edu> V4110DAA@AWIUNI11.BITNET (Gerhard Eckel) writes: > Is it possible to design an object-oriented layer which implements the >concepts of classes, inheritance and polymorphism in pure Scheme? Yes. For it to be convenient, though, you probably need some kind of macro facility. For it to be efficient, you probably need a little help from your compiler. See the paper by Adams & Rees in LFP '88. > ... Something >like Scoops seems to be impossible to build without functions like EVAL and >THE-ENVIRONMENT. I don't know whether that's true or not, but it is certainly true that you can design an object system in such a way that it can't reasonably be implemented without something resembling EVAL. The fact that you can design such a system doesn't mean that it's a good idea to do it. Object systems that don't require EVAL have some substantial advantages over those that do; one of the main advantages is that you can write object-oriented programs that can run without a complete run-time library and an interpreter or compiler. I don't know of any reasons why an object system that requires EVAL would have an inherent advantage over one that does not. Peace, Will  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 2 Jun 89 09:32:09 EDT Received: from BU-IT.BU.EDU by mintaka.lcs.mit.edu id aa19666; 2 Jun 89 21:24 EDT Received: from BUCSF.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA18755; Fri, 2 Jun 89 21:24:08 EDT Received: by bucsf (4.12/4.7) id AA03373; Fri, 2 Jun 89 21:23:18 edt Date: Fri, 2 Jun 89 21:23:18 edt From: "George J. Carrette" Message-Id: <8906030123.AA03373@bucsf> To: tektronix!tekcrl!tekchips!kend@bloom-beacon.mit.edu Cc: Scheme@mc.lcs.mit.edu In-Reply-To: Ken Dickey's message of 1 Jun 89 19:44:26 GMT <4066@tekcrl.LABS.TEK.COM> Subject: Scheme on a Mac I sent "house@cs.williams.edu" a copy of siod, Scheme in one Defun, but actually a mere 25Kbytes of C source code. It is extremely easy to write new SUBR's for this scheme implementation. Depending on the application the over-simplified storage-management may or may not be a problem. -gjc  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 2 Jun 89 02:54:21 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa00683; 2 Jun 89 14:43 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 2 Jun 89 13:50:31 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: 2 Jun 89 14:39:28 GMT From: Alex Colvin Organization: University of Virginia Subject: unspecification Message-Id: <143@uvacs.cs.Virginia.EDU> References: <8905250045.aa22349@mintaka.lcs.mit.edu>, <8905250927.AA29776@polya.Stanford.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu If you must always return the same unspecified object, then it's been specified. If you really want #unspecified, then you should also permit (not (eq? #unspecified #unspecified)). As for unit domains, isn't () one?  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Jun 89 20:52:31 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa06750; 2 Jun 89 8:46 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 2 Jun 89 08:00:26 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: 1 Jun 89 12:05:26 GMT From: "Donal O'Mahony - OMAHONY@cs.tcd.ie" Organization: Computer Science Department, Trinity College Dublin Subject: SCOOPS problems Message-Id: <46261@csvax1.cs.tcd.ie> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Having used X-Lisp for a while, I moved over to TI-Scoops. There are two very annoying defects in that implementation of OOP. 1) SCOOPS objects don't have a SELF instance variable. I had to get around this by redefininng SEND to do a FLUID-LET on the symbol SELF before sending the message, but this is both ugly and slow. 2) There is no SEND-SUPER primitive - this means that super-classes methods must be completely overridden, rather than extended which removes a lot of the benefits of having inheritance in the first place. A slightly less annoying feature is that the arguments to SEND are evaluated in the environment of the object begin sent-to rather than in the calling environment i.e. (let ((a 1)) (send an-object (+ a 1))) will bomb-out due to 'a' not being defined in an-object's environment. Has anybody got good solutions to the above? -- _______________________________________________________________________ Donal O'Mahony omahony@cs.tcd.ie Computer Science Dept., Trinity College, Dublin 2, Ireland _______________________________________________________________________  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Jun 89 17:47:23 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05041; 2 Jun 89 5:44 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 2 Jun 89 05:12:11 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: 1 Jun 89 19:44:26 GMT From: Ken Dickey Organization: Tektronix, Inc., Beaverton, OR. Subject: Re: Scheme on a Mac Message-Id: <4066@tekcrl.LABS.TEK.COM> References: <"19890531223839.8.schreq@MC"@MICKEY-MOUSE.LCS.MIT.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <"19890531223839.8.schreq@MC"@MICKEY-MOUSE.LCS.MIT.EDU> house@CS.WILLIAMS.EDU writes: >I am interested in building a scheme or lisp based interactive >shell for interfacing with 3-d graphics routines. The graphics >stuff is coded in C, so I will need hooks to call C routines >from scheme. Any clues/pointers will be much appreciated. >Don House >house@cs.williams.edu You might look at MacScheme+ToolSmith. You can do applications in ~100K. There is an assembler-level interface, I don't know if they directly support high-level assemblers such as C. I believe that they have an inexpensive (~$10) demo disk. }} Lightship Software (formerly Semantic MicroSystems) }} PO 1636 Blvd, Beaverton, OR 97075 }} (503) 643-6909 -Ken Dickey kend@mrloog.LA.TEK.COM  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 31 May 89 19:14:26 EDT Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16098; 31 May 89 19:12 EDT Received: from zohar ([18.43.0.174]) by life.ai.mit.edu (4.1/AI-4.10) id AA27767; Wed, 31 May 89 19:13:02 EDT Received: by ZOHAR.AI.MIT.EDU; Wed, 31 May 89 19:17:11 edt Date: Wed, 31 May 89 19:17:11 edt From: Jonathan Rees Message-Id: <8905312317.AA09064@zohar> To: Scheme@mc.lcs.mit.edu Subject: please use meaningful subject lines and M-x undigestify Reply-To: scheme-request@mc.lcs.mit.edu I would like to remind people sending messages to the Internet Scheme mailing list to please use meaningful subject lines. If you are a user of Gnu Emacs's rmail, an easy way to do this is to give the meta-X command "undigestify" before replying to a message you see in the digest. Thanks.  Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 31 May 89 18:38:45 EDT Received: from MICKEY-MOUSE.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 262241; Wed 31-May-89 18:38:53 EDT Date: Wed, 31 May 89 18:38 EDT From: house@cs.williams.edu Sender: SCHREQ@MC.LCS.MIT.EDU Subject: Scheme on a Mac To: scheme@MC.LCS.MIT.EDU Message-ID: <"19890531223839.8.schreq@MC"@MICKEY-MOUSE.LCS.MIT.EDU> I am interested in building a scheme or lisp based interactive shell for interfacing with 3-d graphics routines. The graphics stuff is coded in C, so I will need hooks to call C routines from scheme. Any clues/pointers will be much appreciated. Don House house@cs.williams.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 31 May 89 00:49:10 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03523; 31 May 89 0:42 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 30 May 89 23:53: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: 30 May 89 18:54:42 GMT From: jdm Organization: Hodge Computer Research Corporation Subject: Rete matcher wanted Message-Id: <18068@hodge.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I am resarching a class of problems called "expert-guided relaxation processes". Progress in this area could produce a new type of pattern recognizer, a sort of "structured neural network". In order to control it, I am using currently using CLIPS. A better way would be a home-grown rete matcher written in SCHEME or XLISP. Anybody have one I can study?....... -- jdm@hodge.cts.com [uunet zardoz]!hodge!jdm James D. Murray, Ethnounixologist Hodge Computer Research Corporation 1588 North Batavia Street Orange, California 92667 USA TEL: (714) 998-7750 Ask for James FAX: (714) 921-8038 Wait for the carrier  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 May 89 22:44:14 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02203; 30 May 89 22:43 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 30 May 89 21:52:21 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: 31 May 89 01:00:35 GMT From: William Clinger Organization: University of Oregon, Computer Science, Eugene OR Subject: Re: Scheme Digest #125 Message-Id: <4797@uoregon.uoregon.edu> References: , <8905301538.AA06079@sesame.Stanford.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu For the sake of portability, I would like to plead with anyone who is inventing a syntax for random values as part of a new Scheme system to use the #! syntactic convention instead of grabbing yet another #X syntax, where X is a character. For example, I plead with you to say #!unspecified instead of #unspecified. Two reasons: 1. #!unspecified is already supported by several implementations. More generally, there is a tradition of using similar #! syntaxes for miscellaneous constants. 2. Within the Lisp world, most #X syntaxes are traditionally reserved for user-defined extensions to the syntax accepted by the read procedure. The syntax of Scheme reflects this tradition, in which the first character following the # indicates the nature of the syntactic extension. Note that there are only 26 (or 52) possible #X syntaxes where X is a letter, and that Scheme has already taken 8 (or 16) of these: #t, #f, #e, #i, #b, #o, #d, and #x. This causes no problem for Scheme systems that don't support user-defined #X syntaxes, but the existence of systems that do support user-defined #X syntaxes makes it less likely that syntaxes like #unspecified will ever become standard. Peace, William Clinger  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 May 89 21:24:16 EDT Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa01439; 30 May 89 21:20 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 5992; Tue, 30 May 89 21:20:54 EDT Received: from EDVZ.Uni-Wien.AC.AT by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 8294; Tue, 30 May 89 21:20:53 EDT Received: by AWIUNI11 (Mailer R2.01) id 4570; Wed, 31 May 89 03:21:34 MEZ Date: Wed, 31 May 89 03:20:07 MEZ From: Gerhard Eckel Subject: incremental definitions To: Scheme mailing list Message-ID: <8905302120.aa01439@mintaka.lcs.mit.edu> In Digest #123 William Clinger writes: > Neither EVAL nor THE-ENVIRONMENT are part of Scheme, so the fact that XScheme > happens to define procedures with those names that happen not to work the way > someone expects has no bearing on whether it is a real Scheme system. > Most people think it is better to think of incremental definitions as part > of a programming environment instead of a language, since they are primarily > used for debugging. The programming environment obviously differs from one > implementation to another, so code that depends on the programming environment > is not portable. Is it possible to design an object-oriented layer which implements the concepts of classes, inheritance and polymorphism in pure Scheme? Something like Scoops seems to be impossible to build without functions like EVAL and THE-ENVIRONMENT. In the case of Scoops incremental definitons are used for much more than debugging. What could I do if I would like to make Scoops portable? Am I completely missing the point? Gerhard Eckel, v4110daa@awiuni11.bitnet  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 May 89 18:47:02 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa12566; 30 May 89 18:44 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 30 May 89 18:22:18 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: 30 May 89 21:39:23 GMT From: "Rene G. Rodriguez" Organization: Rice University, Houston Subject: Help wanted! (Lisp - Scheme environments) Message-Id: <3346@kalliope.rice.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I am interested in learning about the different environments for Scheme/Lisp systems. In particular, I'd like to know about editors and tracer-debuggers. Any pointers to manuals and where to get them will be deeply appreciated. --rene  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 May 89 11:44:14 EDT Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa26886; 30 May 89 11:38 EDT Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C) id AA06079; Tue, 30 May 89 08:38:17 PDT Date: Tue, 30 May 89 08:38:17 PDT From: Morris Katz Message-Id: <8905301538.AA06079@sesame.Stanford.EDU> To: bobg+@andrew.cmu.edu Cc: Scheme@mc.lcs.mit.edu In-Reply-To: Robert Steven Glickstein's message of 27 May 89 01:47:09 GMT Subject: Scheme Digest #125 Date: 27 May 89 01:47:09 GMT From: Robert Steven Glickstein > Excerpts from ext.nn.comp.lang.scheme: 25-May-89 Scheme Digest #125 > Jonathan Shapiro@POLYA.S (631) > Very well. I hereby specify an object whose name is > #UNSPECIFIED I second the motion. I am currently designing ELSIE (the "Embedded Lisp [Scheme] Interpreter, `ELSIE'"), and I'd rather not have to make arbitrary decisions about what SET! returns (for instance). (Actually, set! is a bad example, since I believe it should return the new value, which I guess I'm proposing for R4RS, but you get the idea.) -Bob Glickstein Since the return value is left unspecified, you don't have to make an arbitrary decision. Simply created #UNSPECIFIED in your implementations and return it. This is completely consistent with the current standard. Just don't force #UNSPECIFIED on the rest of our implementations. Morry Katz katz@polya.stanford.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 May 89 15:46:32 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa17202; 29 May 89 15:42 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 29 May 89 14:46:08 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: 29 May 89 18:18:38 GMT From: Mike Shaff Organization: Stanford University Subject: Re: semantics of DEFINE (and nesting) Message-Id: <9540@polya.Stanford.EDU> References: <59021@yale-celray.yale.UUCP>, <8905262124.AA04820@zohar>, <1030@syma.sussex.ac.uk> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu ciao, In article <1030@syma.sussex.ac.uk>, aarons@syma (Aaron Sloman) writes: >jar@ZOHAR.AI.MIT.EDU (Jonathan Rees) writes: >> >> It *was* an explicit decision on the part of the designers, made in >> 1981. It was an attempt to have something similar to the MIT Scheme >> define but without coupling it to the syntax or semantics of lambda. >> We never properly implemented the feature (LOCALE, for those of you >> who have seen the T manual) that would have made it coherent, however. >> Personally, I now would like to see T changed either to implement R3RS >> define or to allow defines only at "top level" (given a suitable >> non-global definition of "top level"). >> > >In Pop-11 you can use define locally and it is frequently and very >effectively used for two main purposes, and less importantly for >a third: > >(a) Temporarily alter the error handler, standard character >output consumer, interrupt handler, or other procedures that define >the current environment, need to be changed in a particular >procedure, and need to be re-set when that procedure is exitted >whether normally or abnormally (e.g. via exitto, or by temporarily >suspending a lightweight process using that procedure - in the >latter case the temporary value is re-set if the procedure is >resumed.) Typical example, redefining -interrupt locally-: > Though Scheme has no standard for speaking about interrupt handlers and presuming that the code that was handling the interrupt dispatch did so using the current environment (an admittedly complex issue with interrupts), I see no reason why the standard LET & LETREC could not supply the functionality you are seeking. As I understand your comment you wish to have local definitions, as Scheme believes in first class functions, functions can be introduced any place that a Scheme object can be introduced. What is at issue here is the meaning of the define "command." > define foo(...,....); > lvars oldinterrupt=interrupt; ;;; save previous value in local var. > > define interrupt(); > pr('Message about being in foo'); > popready(); ;;; interactive break > oldinterrupt(); ;;; if it exits normally do previous interrupt > enddefine; > > ...body of foo... > > enddefine (define foo (lambda (...) (let ((interrupt (lambda () (newline) (display Message about being in foo) (break) ;!Not standard! push a break loop (interrupt)))) ;This reference to interrupt refers to ;the binding of interrupt outside this ;environment body of foo))) Please note that I do not agree that this is the best way to shadow an interrupt handler, however I am showing how to transliterate the above code segment. > >(b) Define a local procedure that is required ONLY within the >nesting procedure. Again, the functionality of LET & LETREC allow this. (e.g., ;; BLORF alpha beta [FUNCTION] ;; ;; PURPOSE: Stupid example of how to get notification in a given context. ;; (define blorf (lambda (alpha beta) (let ((cons ;Define a new cons to give notice (lambda (obj-1 obj-2) (newline) (display "Cons was called from blorf") (cons obj-1 obj-2)))) ;Refer to the cons outside (if (eq? alpha beta) (cons alpha beta) (vector alpha beta))))) > >My suspicion is that people who don't appreciate the usefulness of >such nested procedure definitions must be people who have not been >using a language that allows these constructs. Here at Sussex there >was a gradual conversion among programmers using Pop-11, especially >after we introduced lexical scoping as an option. > Having the ability to nest functions is, of course, a wonderful thing, but I do not believe that anyone in the Scheme community contests that. The questions related to first class incremental environments, WELL there you will get discussion. >(c) If you simply want to change the global value of a procedure >identifier you can do things like: > > define foo ....; > > define foo_interrupt; > .... > enddefine; > > foo_interrupt -> interrupt; ;;; sets the value outside foo. > enddefine; (define foo (lambda (...) (let ((foo-interrupt (lambda () ...))) (set! interrupt foo-interrupt) ;Sets the value outside foo. ...))) > >or to ensure that it is set in all current contexts > > set_global_valof(foo_interrupt, "interrupt"); > I have no idea what this would mean in Scheme, so... > >I would say that a lisp-like language that doesn't allow nested >procedure definitions with these capabilities was seriously >impoverished. One can of course achieve similar effects by other >means, but they are bound to be more clumsy and also by not using >the syntactic nesting you risk hiding an important relationship, >and thereby confusing people responsible for maintaining code they >did not write. > I could not agree more, however Scheme *DOES* allow nested procedure definitions, that properly capture the environment in which it was created, passed around, etc. (peace chance) mas --  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 May 89 05:48:31 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa13507; 29 May 89 5:42 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 29 May 89 05:36:48 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: 28 May 89 09:54:28 GMT From: Aaron Sloman Organization: School of Cognitive & Computing Sciences, Sussex Univ. UK Subject: Re: semantics of DEFINE (and nesting) Message-Id: <1030@syma.sussex.ac.uk> References: <59021@yale-celray.yale.UUCP>, <8905262124.AA04820@zohar> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu jar@ZOHAR.AI.MIT.EDU (Jonathan Rees) writes: > From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich) > > A while ago I posted the suggestion that non-top-level DEFINEs do > the same thing as top-level DEFINEs, ie, side effect the top level. > ... This interpretation is the one adopted by the current version > of T (although it's not an explicit decision on the part of the T > designers) and I believe is the interpretation used by most LISP > dialects. ... > > Most of the responses that I got said either like "well, Abelson > and Sussman used the 'local' interpretation, so we really should > stick to it" or "well, local non-top-level DEFINEs add fewer > parentheses than nesting LETRECs." Does anyone have other > (theoretical or functional) reasons for this decision?? > > It *was* an explicit decision on the part of the designers, made in > 1981. It was an attempt to have something similar to the MIT Scheme > define but without coupling it to the syntax or semantics of lambda. > We never properly implemented the feature (LOCALE, for those of you > who have seen the T manual) that would have made it coherent, however. > Personally, I now would like to see T changed either to implement R3RS > define or to allow defines only at "top level" (given a suitable > non-global definition of "top level"). > In Pop-11 you can use define locally and it is frequently and very effectively used for two main purposes, and less importantly for a third: (a) Temporarily alter the error handler, standard character output consumer, interrupt handler, or other procedures that define the current environment, need to be changed in a particular procedure, and need to be re-set when that procedure is exitted whether normally or abnormally (e.g. via exitto, or by temporarily suspending a lightweight process using that procedure - in the latter case the temporary value is re-set if the procedure is resumed.) Typical example, redefining -interrupt locally-: define foo(...,....); lvars oldinterrupt=interrupt; ;;; save previous value in local var. define interrupt(); pr('Message about being in foo'); popready(); ;;; interactive break oldinterrupt(); ;;; if it exits normally do previous interrupt enddefine; ...body of foo... enddefine The interrupt procedure (whatever its current value) is called when the user hits the interrupt key, or after the error handler has printed its message, or if some procedure explicitly calls it. The use described in (a) depends on the procedure name being a dynamically scoped identifier. (b) Define a local procedure that is required ONLY within the nesting procedure. Sometimes this can be done by having a procedure defined at top level with either a unique name, or via file-local lexically scoped name, or in a section (Pop-11 sections are a bit like Packages in Common Lisp, but can be nested). But the local NESTED procedure definition is most useful when it needs to access one of the lexically scoped locals of the enclosing procedure. E.g. define foo(x, y, z); lvars x, y, z; define baz(w); lvars w; if w == x then .... elseif w == y then .... elseif w == z then ... .... enddefine; ...body of foo may either call baz or hand it as an argument ... to some other procedure or else may return baz as a new ... lexical closure enddefine; (Some of these cases can be handled slightly more efficiently, and slightly more messily using 'partial application', in Pop-11). My suspicion is that people who don't appreciate the usefulness of such nested procedure definitions must be people who have not been using a language that allows these constructs. Here at Sussex there was a gradual conversion among programmers using Pop-11, especially after we introduced lexical scoping as an option. (c) If you simply want to change the global value of a procedure identifier you can do things like: define foo ....; define foo_interrupt; .... enddefine; foo_interrupt -> interrupt; ;;; sets the value outside foo. enddefine; or to ensure that it is set in all current contexts set_global_valof(foo_interrupt, "interrupt"); -------------------------------- I would say that a lisp-like language that doesn't allow nested procedure definitions with these capabilities was seriously impoverished. One can of course achieve similar effects by other means, but they are bound to be more clumsy and also by not using the syntactic nesting you risk hiding an important relationship, and thereby confusing people responsible for maintaining code they did not write. The impoverishment in case (a) is reduced if your language does not provide a "process" mechanism, which not all Lisps do. Aaron Sloman, School of Cognitive and Computing Sciences, Univ of Sussex, Brighton, BN1 9QN, England INTERNET: aarons%uk.ac.sussex.cogs@nsfnet-relay.ac.uk aarons%uk.ac.sussex.cogs%nsfnet-relay.ac.uk@relay.cs.net JANET aarons@cogs.sussex.ac.uk BITNET: aarons%uk.ac.sussex.cogs@uk.ac or aarons%uk.ac.sussex.cogs%ukacrl.bitnet@cunyvm.cuny.edu UUCP: ...mcvax!ukc!cogs!aarons or aarons@cogs.uucp  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 May 89 11:56:59 EDT Received: from loke.idt.unit.no by mintaka.lcs.mit.edu id aa06433; 28 May 89 11:54 EDT Received: from hufsa.imf.unit.no by loke.idt.unit.no; Sun, 28 May 89 17:54:50 +0200 Date: Sun, 28 May 89 17:52:47 +0200 Received: by vifsla.imf.unit.no (5.51.2/imf-C-1.4) id AA00166; Sun, 28 May 89 17:54:01 MED From: hanche@imf.unit.no Message-Id: <8905281554.AA00166@vifsla.imf.unit.no> To: Scheme@mc.lcs.mit.edu Subject: XScheme and the whereabouts of David Betz A number of people have been asking a number of questions about David Betz and XScheme lately. I will try to answer a few of them. As far as I know, the only reliable way to contact David Betz is on Bix, the BYTE Information eXchange. He hosts his own XLISP conference there, with a separate XScheme topic in it. This is also where you can always expet to find the latest releases of XLisp and XScheme. I don't think he reads this list/newsgroup or any other service avaiable in the academic community. Bix is a commercial service, and so not the place where you see most of us academic types :-) However, is not outrageously expensive if you can avoid telecommunications charges from Europe (as I have to put up with) and refrain from joining too many conferences. Look in any recent issue of BYTE to find information on pricing and how to join. Apparently, David has spent more time on XLisp than on XScheme lately, with XLisp 2.1 just recently released. We can only hope that he will now turn his attention back to XScheme. As far as I know, XScheme 0.16 (10 Jan 1989) is still the current release, though 0.17 may be close. I sure hope so, since the object oriented features in 0.16 are broken (this happened after he added first class environments to the language). And I have asked him (politely I hope) to release 0.17 soon... Why did he not document the object oriented features of XScheme? Well, I think it is because he has been more interested in just getting a working Scheme up and going than in adding support for objects yet. You should bear in mind that as long as the version number stays below 1.0 the author probably does not consider his program as finished or really ready for general consumption. At least, here is what he said about it last year: ========== xlisp/xscheme #82, from dbetz, 136 chars, Sat Nov 19 11:32:25 1988 Comment to 81. ---------- I'm not going to increase the version number to 1.0 until I add some decent debugging support. I'd also like to add a built-in editor. - Harald Hanche-Olsen Division of Mathematical Sciences hanche@imf.unit.no The Norwegian Institute of Technology hanche@norunit.bitnet N-7034 Trondheim-NTH NORWAY  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 May 89 23:54:58 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa11910; 26 May 89 23:42 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 26 May 89 23:09:14 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: 27 May 89 01:47:09 GMT From: Robert Steven Glickstein Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA Subject: Re: Scheme Digest #125 Message-Id: References: <8905250045.aa22349@mintaka.lcs.mit.edu>, Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu > Excerpts from ext.nn.comp.lang.scheme: 25-May-89 Scheme Digest #125 > Jonathan Shapiro@POLYA.S (631) > Very well. I hereby specify an object whose name is > #UNSPECIFIED I second the motion. I am currently designing ELSIE (the "Embedded Lisp [Scheme] Interpreter, `ELSIE'"), and I'd rather not have to make arbitrary decisions about what SET! returns (for instance). (Actually, set! is a bad example, since I believe it should return the new value, which I guess I'm proposing for R4RS, but you get the idea.) -Bob Glickstein  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 May 89 17:24:18 EDT Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07240; 26 May 89 17:20 EDT Received: from zohar ([18.43.0.174]) by life.ai.mit.edu (4.1/AI-4.10) id AA07838; Fri, 26 May 89 17:20:08 EDT Received: by ZOHAR.AI.MIT.EDU; Fri, 26 May 89 17:24:13 edt Date: Fri, 26 May 89 17:24:13 edt From: Jonathan Rees Message-Id: <8905262124.AA04820@zohar> To: Krulwich-Bruce@yale-zoo.arpa Cc: Scheme@mc.lcs.mit.edu In-Reply-To: (Bruce Krulwich's message of 30 Apr 89 20:39:25 GMT <59021@yale-celray.yale.UUCP> Subject: semantics of DEFINE Reply-To: jar@zurich.ai.mit.edu Date: 30 Apr 89 20:39:25 GMT From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich) A while ago I posted the suggestion that non-top-level DEFINEs do the same thing as top-level DEFINEs, ie, side effect the top level. ... This interpretation is the one adopted by the current version of T (although it's not an explicit decision on the part of the T designers) and I believe is the interpretation used by most LISP dialects. ... Most of the responses that I got said either like "well, Abelson and Sussman used the 'local' interpretation, so we really should stick to it" or "well, local non-top-level DEFINEs add fewer parentheses than nesting LETRECs." Does anyone have other (theoretical or functional) reasons for this decision?? It *was* an explicit decision on the part of the designers, made in 1981. It was an attempt to have something similar to the MIT Scheme define but without coupling it to the syntax or semantics of lambda. We never properly implemented the feature (LOCALE, for those of you who have seen the T manual) that would have made it coherent, however. Personally, I now would like to see T changed either to implement R3RS define or to allow defines only at "top level" (given a suitable non-global definition of "top level"). I would prefer to see the desired functionality achieved not by a mechanism like T's but by either (a) a new construct implemented as a macro or (b) some kind of module system. I think a number of people are working on this design problem now.  Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 MAY 89 14:35:40 EDT Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ; Fri, 26 May 89 14:35:40 EDT Received: by spt.entity.com (smail2.5); 26 May 89 13:00:51 EDT (Fri) To: Scheme@mc.lcs.mit.edu Subject: Sunspecified object Message-Id: <8905261300.AA18650@spt.entity.com> Date: 26 May 89 13:00:51 EDT (Fri) From: alms@spt.entity.com (andrew lm shalit) I see two reasons for having a function return an unspecified result: 1) discourage programmers from using this result. 2) give implementions flexibility, so they can operate efficiently. Both of these goals are lost if #unspecified is introduced. As examples, Common Lisp SETQ (and most all setting functions) are defined to return the new value. This is often useful, but sometimes leads to very ugly code, for example: (setq temp (if (listp (setq temp (get-value))) (car temp) (get-another-value)) I don't think the efficiency concerns are really dramatic enough to be a real argument against #unspecified. On the other hand, the stylistic issue of people using "unspecified" results programmatically is a pretty valid argument. Do you want things like: (if (eq (get-value) #unspecified) (get-value-again)) I have problems with this because it doesn't scale. What if you want to specify the value #unspecified? It's an object that's likely to mess you up when you try to use it in a first-class way. On the other hand, #unspecified may be useful in the programming environment, read-loop, etc, so users don't get confused and -think- they have a real value. But I feel this should be left up to implementations, as the rest of the programming environment is. One question to those who favor #unspecified: what would (if #unspecified 10 20) return? I assume 10. Or should it signal an error?  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 May 89 12:09:43 EDT Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa02820; 26 May 89 12:05 EDT Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C) id AA17472; Fri, 26 May 89 09:04:34 PDT Date: Fri, 26 May 89 09:04:34 PDT From: Morris Katz Message-Id: <8905261604.AA17472@sesame.Stanford.EDU> To: shap@polya.stanford.edu Cc: Scheme@mc.lcs.mit.edu In-Reply-To: "Jonathan S. Shapiro"'s message of Thu, 25 May 89 02:27:13 -0700 <8905250927.AA29776@polya.Stanford.EDU> Subject: Scheme Digest #125 Date: Thu, 25 May 89 02:27:13 -0700 From: "Jonathan S. Shapiro" Very well. I hereby specify an object whose name is #UNSPECIFIED Any association between this name and some meaning in your mind is coincidental. I propose that all functions/forms that under some conditions currently return an unspecified value should now return a value which is EQ? to the value named by #UNSPECIFIED under those same conditions. Note that you are only in violation of R3RS if you *tell* me that that is what you do... Seriously: It's a non-damaging change, and there seems to be concensus that it is valuable to some part of the community and has no impact to speak of on anyone else. Let's do it. Jon It is evident from the recent discussion on unspecified values that many of the participants have not been present for previous discussions on this subject (e.g., at Snowbird). Leaving values unspecified is done for many different reasons and achieves a series of different goals. Some of these are as follows: 1) Not specifying a return value allows different implementations to experiment with different return values. Specifying return of the unspecified object would prevent such experimentation from falling within the Scheme standard. 2) When the group could not agree on what a function should return, the return value has sometimes been left unspecified until such time as we could all agree what the correct return value should be. Specifying the return value as unspecified would mean that eventually specifying some specific return value would require a substantive change in the standard. 3) Some functions are performed for side effect only and it has been generally agreed that no sensible return value can be specified for them. To specify that such functions return a specific unspecified object would not be a problem for such functions subject to 4). 4) Some things have been left unspecified in Scheme in order to allow clever implementors to build more efficient implementations. Greater specification of even return values for some functions could limit the ability to create such clever implementations. In such cases, the burden of proof is on those who want to specify the unspecified object to demonstrate that its advantages outway its costs in these cases. There have probably been other reasons for unspecification, but I can't think of any off the top of my head. Morry Katz katz@polya.stanford.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 May 89 11:31:02 EDT Received: from CHAMARTIN.AI.MIT.EDU by mintaka.lcs.mit.edu id aa27070; 26 May 89 11:23 EDT Received: by chamartin.AI.MIT.EDU (5.61/1.2) id ; Fri, 26 May 89 10:13:26 -0400 Date: Fri, 26 May 89 10:13:26 -0400 From: "Guillermo J. Rozas" Message-Id: <8905261413.AA11811@chamartin.AI.MIT.EDU> To: Scheme@mc.lcs.mit.edu In-Reply-To: Automatic Scheme Digestifier's message of 26 MAY 89 00:08:55 EDT <8905260044.aa16473@mintaka.lcs.mit.edu> Subject: Unspecified values Reply-To: jinx@zurich.ai.mit.edu There are good reasons not to specify (in the Standard) the value returned by mutators. Individual dialects/implementations can specify the value(s) returned if they wish. Besides the already mentioned ontological reasons for not returning a "canonical unspecified object" (there is no uninteresting positive integer), there are other reasons that have not been posted recently: Semantic reasons: Some people believe that the "right" thing for mutators is to return no values. Assuming that we adopt some multiple values mechanism in the future, this may be the "natural" thing to do. Specifying the value in the meantime will only make people depend on it, and will make it hard to make this change. Leaving the value unspecified, any "portable" program that depends on the value is "in error", and thus we don't have to support it. Correct programs won't depend on the value, and thus the change from one value to no values won't affect portable programs at all. Some dialects have consistent values to return for mutating operations, but there is no agreement among the various dialects. For example, some dialects specify that the return value is the new value being stored (since it has to be computed anyway). Some specify that the return value is the previous contents (so that mutators can be used as atomic "swapping" operations). Specifying the value in the standard will force these dialects into non compliance or into introducing a parallel set of operations which differ only in the returned value. Leaving the return value unspecified allows dialects/implementations to experiment with minor language design changes. Implementation reasons: For implementations of many dialects, in which the value returned is in fact not specified, specifying the return value (even if it is specified to be an arbitrary, otherwise useless, value) would cause compilers to generate more/worse code in many cases. The compiler must issue code to return the "canonical unspecified value" whenever it can't prove that the value won't be used. In my experience this happens in a large fraction (if not most) of the cases when side effecting operations are used. Since the return value should not be used anyway, why not leave what is returned to the compiler's convenience? Why go to extra work to return some canonical object which is not meant to be used? The only guarantee that the compiler must make is that the return value has to be a valid object (so that your garbage collector won't become confused if the value is "saved"). For debugging reasons, the "right" value to be returned would be some context object specifying which procedure/expression was producing this object, what the environment of the procedure (parameters and free variables) was like at the time of the construction of this context object, and what the continuation was at this time as well. Thus if such an object was ever found while debugging, the "culprit" could be pinpointed easily. Clearly this is too expensive to do, and I doubt that returning a canonical object would provide nearly as much information (think of the case where the result is consed into a data structure, and is only found to be "unspecified" ten years later when the structure is accessed).  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 May 89 06:47:05 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa19980; 26 May 89 6:42 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 26 May 89 05:49:03 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 89 01:38:15 GMT From: "Stephen G. Simpson" Organization: Penn State University - Center for Academic Computing Subject: Object,systems,for,LISP,and,Scheme Message-Id: <89145.213815T20@PSUVM> References: HAM.89May18105220@polya.Stanford.EDU Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu You asked about object oriented programming systems for LISP and Scheme. Texas Instruments PC Scheme has SCOOPS. The reference manual describes it as "an object oriented programming system for TI Scheme based on first-class environments and on multiple and dynamic inheritance. Although it is similar in concept and syntax to the object-oriented paradigms of LOOPS and Flavors, the implementation of SCOOPS relies heavily on the features of the Scheme language." Chapter 5 of the reference manual is devoted to SCOOPS. In addition, PC Scheme comes with a SCOOPS tutorial program which you can load into PC Scheme. ----------------------------------------------------------- | Stephen G. Simpson T20 at PSUVM . BITNET | | Department of Mathematics (814)865-7527 | | Pennsylvania State University | | University Park, PA 16802 | -----------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 May 89 19:20:04 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa17840; 25 May 89 19:02 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 25 May 89 18:26:20 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: 25 May 89 21:57:55 GMT From: Dorai Sitaram Organization: Rice University, Houston Subject: Re: unspecified-object Message-Id: <3323@kalliope.rice.edu> References: <24169@shemp.CS.UCLA.EDU>, <8905241845.AA02829@zohar>, <24244@shemp.CS.UCLA.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <24244@shemp.CS.UCLA.EDU> pierce@cs.ucla.edu (Brad Pierce) writes: $In article <8905241845.AA02829@zohar> jar@zurich.ai.mit.edu writes: $ $>It doesn't make sense to specify that the object to be returned should $>be unspecified. It seems to me that if some specific object is to be $>specified, then it should be a specific object, not an unspecific one. $>Besides, if we specify what object should be returned, then that $>object will no longer be unspecified. $ $When a procedure is applied to valid input and the result is unspecified, $valuable information is lost. I am suggesting removing the possibility of $leaving unspecified the result of valid procedure applications. I am also $suggesting that there be a special object which represents the important $information which is currently discarded. Practical benefits aside, I $simply find it aesthetically unpleasant to pass around values which have no $information content, when an alternative approach is possible. The above (Brad's posting, not jar's) goes against the principle of orthogonality in Scheme's choice of primitives and core syntax. Let me see if I can explain the violation in a "few" words. Each expression in Scheme returns a value, since Scheme is an expression-oriented language. However the reason behind a primitive procedure or a core syntax may not always be manifested in the value produced by an expression using this primitive procedure or core syntax. Some of these primitives may be there for producing side-effects, e.g., set! or print. (Expressions using these primitives are usually called "commands" in other languages.) The main point of these primitives being the side-effect, it is not fair to burden them with any responsibility other than their main goal. Ergo, they are free to return an unspecified object. The reason why Standards specify "unspecifiedness" (this is not necessarily oxymoronic) is that they don't want someone to write programs making use of the value returned by these command-type primitives. Such a program is making use of a coincidental and totally ad hoc (i.e., one with no semantic(s) underpinning) piece of information, and as such, very likely requires rewriting. (BTW, I don't understand how "specifying" the "unspecified-object" facilitates debugging, as has been claimed by two posters.) --dorai ------------------------------------------------------------------------------- It may be that the gulfs will wash us down; It may be we shall touch the Happy Isles. -------------------------------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 May 89 07:54:05 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa09818; 25 May 89 7:52 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 25 May 89 07:41:43 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: 25 May 89 06:20:05 GMT From: Brad Pierce Organization: UCLA Computer Science Department Subject: Re: unspecified-object Message-Id: <24244@shemp.CS.UCLA.EDU> References: <24169@shemp.CS.UCLA.EDU>, <8905241845.AA02829@zohar> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <8905241845.AA02829@zohar> jar@zurich.ai.mit.edu writes: >It doesn't make sense to specify that the object to be returned should >be unspecified. It seems to me that if some specific object is to be >specified, then it should be a specific object, not an unspecific one. >Besides, if we specify what object should be returned, then that >object will no longer be unspecified. When a procedure is applied to valid input and the result is unspecified, valuable information is lost. I am suggesting removing the possibility of leaving unspecified the result of valid procedure applications. I am also suggesting that there be a special object which represents the important information which is currently discarded. Practical benefits aside, I simply find it aesthetically unpleasant to pass around values which have no information content, when an alternative approach is possible. -- Brad  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 May 89 06:50:38 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa22486; 25 May 89 6:47 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 25 May 89 06:44:19 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: 25 May 89 02:05:18 GMT From: jdm Organization: Hodge Computer Research Corporation Subject: Re: Location of Scheme -- Again... Message-Id: <17089@hodge.UUCP> References: <1515@cunixc.cc.columbia.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu The XBBS site !alphacom at (714) 898-8634 does quite a good job archiving a lot to stuff that comes across USENET. I have a current listing of the files on alphacom and both scheme and xscheme are there. All the files are: XSCHEME.ARC - Executables and docs XSCHSRC.ARC - Sources in C schdoc.tar - Documentation for scheme schsrc.tar.Z-a - Piece 1 of schsrc.tar.Z (source) schsrc.tar.Z-b - Piece 2 of schsrc.tar.Z (source) schsrc.tar.Z-c - Piece 3 of schsrc.tar.Z (source) schsrc.tar.Z-d - Piece 4 of schsrc.tar.Z (source) schsrc.tar.Z-e - Piece 5 of schsrc.tar.Z (source) schsrc.tar.Z-f - Piece 6 of schsrc.tar.Z (source) ckecksum.all.Z - The CHECKSUM for all the scheme files -- jdm@hodge.cts.com [uunet zardoz]!hodge!jdm James D. Murray, Ethnounixologist Hodge Computer Research Corporation 1588 North Batavia Street Orange, California 92667 USA TEL: (714) 998-7750 Ask for James FAX: (714) 921-8038 Wait for the carrier  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 May 89 05:33:30 EDT Received: from Polya.Stanford.EDU by mintaka.lcs.mit.edu id aa19225; 25 May 89 5:27 EDT Received: by polya.Stanford.EDU (5.61/25-eef) id AA29776; Thu, 25 May 89 02:27:13 -0700 Date: Thu, 25 May 89 02:27:13 -0700 From: "Jonathan S. Shapiro" Message-Id: <8905250927.AA29776@polya.Stanford.EDU> To: Scheme@mc.lcs.mit.edu In-Reply-To: Automatic Scheme Digestifier's message of 25 MAY 89 00:08:48 EDT <8905250045.aa22349@mintaka.lcs.mit.edu> Subject: Scheme Digest #125 Very well. I hereby specify an object whose name is #UNSPECIFIED Any association between this name and some meaning in your mind is coincidental. I propose that all functions/forms that under some conditions currently return an unspecified value should now return a value which is EQ? to the value named by #UNSPECIFIED under those same conditions. Note that you are only in violation of R3RS if you *tell* me that that is what you do... Seriously: It's a non-damaging change, and there seems to be concensus that it is valuable to some part of the community and has no impact to speak of on anyone else. Let's do it. Jon  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 May 89 20:23:43 EDT Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24413; 24 May 89 20:21 EDT Received: from zohar ([18.43.0.174]) by life.ai.mit.edu (4.1/AI-4.10) id AA00528; Wed, 24 May 89 20:19:18 EDT Received: by ZOHAR.AI.MIT.EDU; Wed, 24 May 89 14:45:58 edt Date: Wed, 24 May 89 14:45:58 edt From: Jonathan Rees Message-Id: <8905241845.AA02829@zohar> To: pierce@locus.ucla.edu Cc: Scheme@mc.lcs.mit.edu In-Reply-To: pierce@locus.ucla.edu's message of 23 May 89 01:51:40 GMT <24169@shemp.CS.UCLA.EDU> Subject: unspecified-object Reply-To: jar@zurich.ai.mit.edu Date: 23 May 89 01:51:40 GMT From: pierce@locus.ucla.edu I think that the specification of Scheme, as well as many Scheme programs, would be made more elegant if an "unspecified-object" analogous to NaN in the IEEE numeric standard were introduced. Functions which return unspecified values now would be required to return an "unspecified-object" instead. It doesn't make sense to specify that the object to be returned should be unspecified. It seems to me that if some specific object is to be specified, then it should be a specific object, not an unspecific one. Besides, if we specify what object should be returned, then that object will no longer be unspecified.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 May 89 19:50:56 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa00477; 24 May 89 19:46 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 24 May 89 19:03:10 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: 24 May 89 21:48:16 GMT From: Jon Greenblatt Organization: University of Maryland, College Park Subject: Re: Avalability of XScheme(V 0.16) and XLisp(V 2.0) Message-Id: <4938@umd5.umd.edu> References: <4936@umd5.umd.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Has anyone compared the performance of XScheme to XLisp. I am most intersted if XScheme does OOPS faster, XLisp had to do some ugly things to access instance variables but I have not determined if XScheme has improved on that, my work load will not give me time to study XScheme in depth for another month or two. My assumption is that XScheme does OOPS faster because the instance variables can be put into a Scheme data envoronment which is hopefuly accessed in some efficient manner. If I don't know what I'm talking about please let me know that too. I have not done any work in Scheme but am interested to find out more about it. JonnyG. (jonnyg@rover.umd.edu)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 May 89 18:51:51 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa28481; 24 May 89 18:48 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 24 May 89 18:22:08 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: 24 May 89 22:03:56 GMT From: "Mark C. Carroll " Organization: Rutgers Univ., New Brunswick, N.J. Subject: Re: unspecified-object Message-Id: References: <24169@shemp.CS.UCLA.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <24169@shemp.CS.UCLA.EDU> pierce@lanai.cs.ucla.edu writes: ] I think that the specification of Scheme, as well as many Scheme programs, ] would be made more elegant if an "unspecified-object" analogous to NaN in ] the IEEE numeric standard were introduced. Functions which return ] unspecified values now would be required to return an "unspecified-object" ] instead. ] ] -- Brad I agree quite strongly with this. The scheme that I've been hacking at lately is Ed Puckett's AmiScheme for the Amiga. In Amischeme, there is an object called #u, the sole member of the "unit" domain. Any internal function that the standard says returns an "unspecified" result returns #u. In my functions, I try to do this also - any function that exists for its side-effects returns #u. In addition to adding clarity, it has proven quite useful for debugging. -- =| Mark Craig Carroll: |= =| mccarrol@topaz.rutgers.edu,...!rutgers!topaz!mccarrol |= =| "Your only obligation in any lifetime is to be true to yourself" |= =| -Richard Bach,_Illusions_ |=  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 May 89 18:51:44 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa27969; 24 May 89 18:47 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 24 May 89 18:11:14 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: 24 May 89 21:09:32 GMT From: Jon Greenblatt Organization: University of Maryland, College Park Subject: Avalability of XScheme(V 0.16) and XLisp(V 2.0) Message-Id: <4936@umd5.umd.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu People have been asking for Xlisp2.0 and the latest version of XScheme. I have made them available via anonymous ftp from rover.umd.edu (128.8.2.73). Please don't ask me to distribute these any other way. If you do not have ftp access to my machine, please find someone who does, I'd hate to be mean but I always get flooded with request from UUCP sites. BTW the latest version I could find of XScheme is 0.16. JonnyG. (jonnyg@rover.umd.edu)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 May 89 14:04:14 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa10817; 23 May 89 14:02 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 23 May 89 13:17:51 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: 23 May 89 01:51:40 GMT From: pierce@locus.ucla.edu Organization: UCLA Computer Science Department Subject: unspecified-object Message-Id: <24169@shemp.CS.UCLA.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I think that the specification of Scheme, as well as many Scheme programs, would be made more elegant if an "unspecified-object" analogous to NaN in the IEEE numeric standard were introduced. Functions which return unspecified values now would be required to return an "unspecified-object" instead. -- Brad  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 May 89 22:56:39 EDT Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa22048; 18 May 89 14:13 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 2271; Thu, 18 May 89 14:14:19 EDT Received: from IRUCCIBM.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 2996; Thu, 18 May 89 14:14:18 EDT Received: from IRUCCVAX.UCC.IE by IRUCCIBM.BITNET (Mailer R2.03B) with BSMTP id 6195; Thu, 18 May 89 18:08:16 IST Date: Thu, 18 May 89 18:08 GMT From: Ian Murphy Subject: Xscheme sources To: scheme@mc.lcs.mit.edu X-VMS-To: IN%"scheme@mc.lcs.mit.edu" Message-ID: <8905181413.aa22048@mintaka.lcs.mit.edu> Does anybody out there have the FULL sources to David Betz Xscheme??? I have sources to version 0.15 (btw is this the latest version?) but there's a bit missing, when compiled the linker gives about 5 or so unresolved externals. Before i go and do it myself, has anybody added graphics functions to xscheme? +-----------------------------------------------------------------------------+ |Ian Murphy (^v^) | Internet : IAN@VAX1.UCC.IE | |Dept. Computer Science | ARPA : IAN@IRUCCVAX.BITNET | |University College Cork, | janet : EARN%IRL.HEA.UCC.IRUCCVAX::IAN | |Ireland. | Voice : "IAN!!!" | +-----------------------------------------------------------------------------+  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 May 89 16:16:10 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa15261; 17 May 89 21:27 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 17 May 89 20:54:18 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: 17 May 89 22:53:23 GMT From: William Clinger Organization: University of Oregon, Computer Science, Eugene OR Subject: incremental definition (was Re: scoops & xscheme) Message-Id: <4688@uoregon.uoregon.edu> References: <8905152339.AA07550@BLOOM-BEACON.MIT.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Someone posted an example of unexpected interaction, or lack thereof, between first class environments and incremental DEFINE (using EVAL) in XScheme, and asked: > When I look how environments are implemented I can understand this >behaviour but is this still Scheme? Neither EVAL nor THE-ENVIRONMENT are part of Scheme, so the fact that XScheme happens to define procedures with those names that happen not to work the way someone expects has no bearing on whether it is a real Scheme system. Most people think it is better to think of incremental definitions as part of a programming environment instead of a language, since they are primarily used for debugging. The programming environment obviously differs from one implementation to another, so code that depends on the programming environment is not portable. William Clinger  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 May 89 16:08:36 EDT Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa01459; 20 May 89 15:13 EDT Received: by iuvax.cs.indiana.edu Date: Sat, 20 May 89 14:12:23 -0500 From: Chris Haynes To: scheme-standard@wheaties.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu, scheme@mc.lcs.mit.edu Subject: next meeting of the IEEE Scheme WG Message-ID: <8905201513.aa01459@mintaka.lcs.mit.edu> The next meeting of the IEEE Scheme Standardization Working Group will be 9:30am-5pm, Friday, July 7th, at MIT. The exact location will be announced later. The numbers section will be a major agenda item, and William Clinger will attend. Let me know if you plan to attend (so local arrangements can know about how many to expect) and if you have any other suggestions for the agenda. Christopher Haynes, IEEE Scheme WG Chair Lindley Hall, Indiana University, Bloomington, IN 47405 chaynes@iuvax.cs.indiana.edu 812/855-6486  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 16 May 89 05:21:36 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 16 May 89 05:14:33 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: 16 May 89 07:31:27 GMT From: cunixc!micky@columbia.edu (Micky Liu) Organization: Columbia University Subject: Location of Scheme -- Again... Message-Id: <1515@cunixc.cc.columbia.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I wish to thank all of you who replied to my initial query and I'd like to clarify some of the information that has been sent to me... Okay, prep.ai.mit.edu isn't gone, but it certainly was not replaced completely. The scheme distribution id is no longer functioning (it wasn't such a good idea really anyway...) and there is no trace of scheme anywhere in the public directories. I was also pointed to wheaties.ai.mit.edu, and I don't see the dist there, but some scheme code for labs for a class perhaps? The one place that I did find it was at zurich.ai.mit.edu, but have so far been unsuccessful at retrieving it. The poor little HP9000 doesn't really like to have it's ftpd work that hard... Any other sites that I can try at 3:30AM? Thanx! Micky Liu arpa: micky@cunixc.cc.columbia.edu uucp: ...!rutgers!columbia!cunixc!micky bitnet: malua@cuvmc  Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 15 May 89 19:40:22 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 5548; Mon, 15 May 89 19:38:46 EDT Received: from EDVZ.Uni-Wien.AC.AT by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 6665; Mon, 15 May 89 19:38:45 EDT Received: by AWIUNI11 (Mailer R2.01) id 6702; Tue, 16 May 89 01:37:04 MEZ Date: Tue, 16 May 89 01:36:12 MEZ From: Gerhard Eckel Subject: scoops & xscheme To: Scheme mailing list Hello, I've posted a request for scoops sources to this list recently. I read a redistribution of this list from a machine in Finland which apparently missed the digests 108 - 113 and 115. Since I can't find them in the archives there I don't know if anyone answered my query and so I need to repeat my question. If there are no news about scoops maybe somebody could send the digests I missed anyway. Something else: since some weeks I use XScheme and I had similar problems as Marc Craig Carroll (Digest #118), and others: XScheme - Version 0.16 > (define env (let ((var1 1)) (the-environment))) env > (environment-bindings env) ((var1 . 1)) > (eval '(define var2 2) env) var2 > (environment-bindings env) ((var1 . 1)) > var2 2 > (environment-bindings (the-environment)) () When I look how environments are implemented I can understand this behaviour but is this still Scheme? Nevertheless I find XScheme an interesting implementation which is particulary useful for me because I can easily entend it (I use it for controlling a DSP to do sound processing). I would like to get in touch with other people using XScheme so that we can exchange bug fixes (I fixed some weird ones already) and communicate about and coordinate further development. I tried to reach David Betz but didn't succeed yet (is this still the address where to reach him: 'zinn!mispmag!dbetz@decvax.dec.com' ? - if you are listening David, please contact me!!!) I am ready to organize (moderate) something like a XScheme users group - who is interested and could give me some hints how to do it? Regards, Gerhard +------------------------------+---------------------------------------------+ : Gerhard ECKEL c/o Austrian Academy of Sciences, Dept. Sound : : Hernalser Haupstrasse 164/17 : Liebiggasse 5, A-1010 Vienna, AUSTRIA : : A-1170 Vienna, AUSTRIA : Tel.: +43 222 43 00 27 30 : : Tel.: +43 222 46 10 404 : E-mail: V4110DAA@AWIUNI11.BITNET : +------------------------------+---------------------------------------------+ P.S.: for scoops, remember: I've no access to ftp ...  Received: from PROOF.ERGO.CS.CMU.EDU (TCP 20000557273) by MC.LCS.MIT.EDU 14 May 89 21:02:26 EDT Received: from PROOF.ERGO.CS.CMU.EDU by PROOF.ERGO.CS.CMU.EDU; 14 May 89 20:59:56 EDT To: scheme@mc.lcs.mit.edu Subject: What's your favorite macro? Reply-to: bcp@cs.cmu.edu Date: Sun, 14 May 89 20:59:24 EDT Message-ID: <27218.611197164@PROOF.ERGO.CS.CMU.EDU> From: Benjamin.Pierce@PROOF.ERGO.CS.CMU.EDU I'm interested in examples or applications that clearly demonstrate the utility of macros as a language extension mechanism. In particular, I'd like to know about useful macros with the following properties: 1) They make "significant" use of the macro definition mechanism (this is to rule out kinds of notational extensions that could be handled just as well by a simpler mechanism). 2) They cannot be implemented as functions (this rules out uses of macros to improve efficiency of programs without increasing the expressive power of the language). 3) They provide features or constructs that would NOT be a desirable addition to the base language (this rules out macros that "should" be language features rather than macros, e.g. delayed evaluation, polymorphic types, records, exceptions, ... [I know some of these are debatable!]). Pointers to previous discussions or research papers also gratefully accepted. Benli  Received: from ATHENA (TCP 2222000047) by MC.LCS.MIT.EDU 13 May 89 20:32:07 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA21496; Sat, 13 May 89 20:30:46 EDT From: Received: by M11-111-2.MIT.EDU (5.45/4.7) id AA04228; Sat, 13 May 89 20:29:16 EDT Message-Id: <8905140029.AA04228@M11-111-2.MIT.EDU> To: Scheme@mc.lcs.mit.edu Subject: Re: Scheme Digest #118 In-Reply-To: Your message of 13 May 89 00:01:59 -0400. <8905130419.AA10469@ATHENA.MIT.EDU> Date: Sat, 13 May 89 20:29:11 EDT Please unsubscribe me from the mailing list of scheme digest. Thank you. --- Hanson(monyet@athena.mit.edu)  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 13 May 89 06:13:48 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 13 May 89 05:52:13 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: 13 May 89 05:44:21 GMT From: cunixc!micky@columbia.edu (Micky Liu) Organization: Columbia University Subject: Whereis scheme now that prep.ai.mit.edu is gone? Message-Id: <1504@cunixc.cc.columbia.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu The title says it all... I'm looking to bring scheme up on a Convex C-210 and haven't been able to locate current sources... The last that I looked it was on prep, but that was a loooong time ago... Thanx, Micky Liu arpa: micky@cunixc.cc.columbia.edu uucp: ...!rutgers!columbia!cunixc!micky bitnet: malua@cuvmc  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 13 May 89 06:12:33 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 13 May 89 05:17:00 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: 12 May 89 13:47:21 GMT From: cs.dal.ca!aucs!880716a@uunet.uu.net (Dave Astels) Organization: School of Computer Science, Acadia Univ., Nova Scotia Subject: PC Scheme Message-Id: <1871@aucs.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Hello. I a budding AI programmer/researcher (Natural Language/Cognition). I am currently using Xlisp for my work. I have used version 1.6 with success. I recently got version 2.0 (which is much better) but it doesn't leave me enough free memory to develope reasonable sized programs. I am using an IBM PC clone with 640K. I am considering buying a LISP system. PC Scheme is in my price range (I'm a student), and I am wondering if anyone has any advice in this matter. I am not familiar with Scheme. How close to Common LISP is it? Whould there be much problem porting from PC Scheme to Common LISP? How does it work on a 640K PC (I am planning to get an EMS memory card in the future). The emacs-like editor sounds nice, what is the developement environment like? Any advice and opinions would be appriciated. Also, is there any reasonable alternatives in the same price range? Thanks in advance. -Dave  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 12 May 89 19:10:53 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 12 May 89 18:50:52 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: 12 May 89 21:50:29 GMT From: mccarrol@topaz.rutgers.edu (Mark C. Carroll ) Organization: Rutgers Univ., New Brunswick, N.J. Subject: Xscheme, object functions Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I've just obtained a copy of David Betz's Xscheme system. It claims to be "An Object-oriented Scheme". The documentation completely ignores the Object Oriented features of the language. (They get less than one paragraph, describing the syntax of a message pass.) I've managed to hack out the method of describing a Class creation, by referring to the documentation of Xlisp. What I've come up with is: ] (define newclass (Class 'new '(instance vars) '(class vars))) To define the class, and ] (newclass 'answer 'msgname '(args) '(method code)) to define methods. However, no amount of hacking seems to be telling me how to access the instance variables, or the class variables. Defining a method: ] (newclass 'answer 'what '() '((environment-bindings) ] (the-environment))) yields ((self . #)), where .... is the object number, so the instance variables are not in the environment of the method. Where are they? How can I access them? If Mr. Betz is reading this, I have a question for him: Why, on earth, did you design an object oriented variant of scheme, and then totally neglect to tell anyone how to use the objects? -- =| Mark Craig Carroll: |= =| mccarrol@topaz.rutgers.edu,...!rutgers!topaz!mccarrol |= =| "Your only obligation in any lifetime is to be true to yourself" |= =| -Richard Bach,_Illusions_ |=  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 May 89 17:15:57 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 10 May 89 16:25:47 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: 10 May 89 19:31:06 GMT From: titan!dorai@rice.edu (Dorai Sitaram) Organization: Rice University, Houston Subject: Re: SCOOPS and obsolete forms Message-Id: <3246@kalliope.rice.edu> References: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article scp@raven.lanl.gov (Stephen Pope) writes: >Second, SCOOPS made use of the REC special form. This was apparently >removed from the language as of R3RS. In any case, I got runtime >errors (Unbound variable NAME). It is always used in the form: > > ((rec name (lambda ...)) args ...) > >where name needs to recursively call itself. I'm no SCHEME wizard, >but it seemed the proper equivalent was: > > (let ((name (lambda ...))) (name args ...)) > >which appears to run just fine. > >Can anybody enlighten me on the subject of REC and its demise? Your equivalent should have a LETREC rather than a LET. Any REC-expression (not just in the application-context you mention and not just for LAMBDA-forms either) can be stated with a LETREC (which in its term is based on LAMBDA and SET!) as follows: (rec name exp) == (letrec ([name exp]) name) A possible reason for not mentioning REC as "essential syntax" in R3RS could be that the corresponding LETREC-equivalent is quite as readable. LETREC, of course, has more claim to the status of "essential syntax" since, in contrast to REC, it can also introduce several mutually recursive bindings. It is probably stretching it a bit to think of REC's omission from R3RS in such tragic terms as "demise". Any basic macro facility can resurrect it for you. --dorai ------------------------------------------------------------------------------ It may be that the gulfs will wash us down; It may be we shall touch the Happy Isles. ------------------------------------------------------------------------------  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 May 89 17:13:38 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 10 May 89 16:30:04 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: 10 May 89 19:48:35 GMT From: titan!dorai@rice.edu (Dorai Sitaram) Organization: Rice University, Houston Subject: Re: SCOOPS and obsolete forms Message-Id: <3247@kalliope.rice.edu> References: , <3246@kalliope.rice.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <3246@kalliope.rice.edu> I write: >Any REC-expression (not just in the application-context you mention >and not just for LAMBDA-forms either) can be stated with a LETREC >(which in its term is based on LAMBDA and SET!) as follows: ^^^^ It could be well-nigh impossible to figure out that the above is a typo for "turn". Hence this posting. (For what it's worth, I was thinking of term-rewriting something, and psychology did the rest.) ------------------------------------------------------------------------------ It may be that the gulfs will wash us down; It may be we shall touch the Happy Isles. ------------------------------------------------------------------------------  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 May 89 14:10:14 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 10 May 89 13:18:00 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: 10 May 89 16:35:19 GMT From: lambda!scp@lanl.gov (Stephen Pope) Organization: The Santa Fe Institute, NM Subject: SCOOPS and obsolete forms Message-Id: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Thanks to folks here in netland, I recently got a copy of SCOOPS (for those still wondering where it can be found, try ftp to linc.cis.upenn.edu (130.91.6.8). sherin@linc.cis.upenn.edu seems to be the responsible party, though don't take this as *my* endorsement to hound him with mail. In any case, I found two problems in bringing scoops up under MIT-CSCHEME: Release 6.1.2 Microcode 10.2 Runtime 13.91 SF 3.13 First, the replacements of "syntax-table-define ..." with "add-syntax!" et. al were unnecessary - I didn't touch my existing runtime band. Second, SCOOPS made use of the REC special form. This was apparently removed from the language as of R3RS. In any case, I got runtime errors (Unbound variable NAME). It is always used in the form: ((rec name (lambda ...)) args ...) where name needs to recursively call itself. I'm no SCHEME wizard, but it seemed the proper equivalent was: (let ((name (lambda ...))) (name args ...)) which appears to run just fine. Can anybody enlighten me on the subject of REC and its demise? Stephen Pope Santa Fe Institute scp@sfi.santafe.edu  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 9 May 89 00:09:53 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 8 May 89 23:18:13 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: 9 May 89 01:51:12 GMT From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich) Organization: Computer Science, Yale University, New Haven, CT 06520-2158 Subject: Re: semantics of DEFINE (why use it at all on the top level?) Message-Id: <59923@yale-celray.yale.UUCP> References: <890503-103409-9762@Xerox>, <2454@ski.cs.vu.nl>, <59918@yale-celray.yale.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <59918@yale-celray.yale.UUCP>, I wrote: >In article <2454@ski.cs.vu.nl>, biep@cs (J A Biep Durieux) writes: >>In article <890503-103409-9762@Xerox> Pavel.pa@XEROX.COM writes: >> >>>-- A program is a mixed sequence of definitions and expressions. >>> >>>--The meaning of a program P is the same as that of the expression: >>> ((lambda (I*) P') ...) >... >>Then why not actually do this? >> >>-- The scheme top-level environment has each variable bound to a unique >> location. Many of these locations will be assigned the value >> #\undefined. >> >>-- The user can assign other values to variable locations using "set!". >> A "define" on top level will be an error, since the variable is >> already bound on that level. > >First, the system has to know what symbols to bind in the global LET >contour. It would be consistant to have DEFINE always specify that a >symbol be included in this binding. > >Secondly, having internal DEFINEs do local definitions is even more >redundant, since it is 100% translatable into a LETREC while DEFINE is >needed to specify what variables should be bound. Gee that last paragraph reads like gibberish. What I meant was: Secondly, having internal DEFINEs do local definitions is even more reduntant since this is 100% translatable into LETREC. On the other hand, top-level DEFINEs are not 100% translatable since some specification is needed of which variables should be in the top-level contour. Bruce  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 89 23:09:47 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 8 May 89 22:37:21 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: 9 May 89 00:41:32 GMT From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich) Organization: Computer Science, Yale University, New Haven, CT 06520-2158 Subject: Re: semantics of DEFINE (why use it at all on the top level?) Message-Id: <59918@yale-celray.yale.UUCP> References: <890503-103409-9762@Xerox>, <2454@ski.cs.vu.nl> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <2454@ski.cs.vu.nl>, biep@cs (J A Biep Durieux) writes: >In article <890503-103409-9762@Xerox> Pavel.pa@XEROX.COM writes: > >>-- A program is a mixed sequence of definitions and expressions. >> >>--The meaning of a program P is the same as that of the expression: >> ((lambda (I*) P') ...) ... >Then why not actually do this? > >-- The scheme top-level environment has each variable bound to a unique > location. Many of these locations will be assigned the value > #\undefined. > >-- The user can assign other values to variable locations using "set!". > A "define" on top level will be an error, since the variable is > already bound on that level. First, the system has to know what symbols to bind in the global LET contour. It would be consistant to have DEFINE always specify that a symbol be included in this binding. Secondly, having internal DEFINEs do local definitions is even more redundant, since it is 100% translatable into a LETREC while DEFINE is needed to specify what variables should be bound. Bruce Krulwich  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 89 20:14:27 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 8 May 89 20:06:50 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: 8 May 89 10:21:47 GMT From: mcvax!hp4nl!botter!star.cs.vu.nl!biep@uunet.uu.net (J A Biep Durieux) Organization: VU Informatica, Amsterdam Subject: Re: semantics of DEFINE (why use it at all on the top level?) Message-Id: <2454@ski.cs.vu.nl> References: <890503-103409-9762@Xerox> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <890503-103409-9762@Xerox> Pavel.pa@XEROX.COM writes: >-- A program is a mixed sequence of definitions and expressions. > >-- The meaning of a program P is the same as that of the following expression: > ((lambda (I*) P') ...) >where I* is the set of variables defined in P (i.e., appearing as the CADR >of a DEFINE form), P' is the sequence of expressions obtained by replacing >each definition in P with the corresponding assignment, and is >an expression producing some useless value. Then why not actually do this? -- The scheme top-level environment has each variable bound to a unique location. Many of these locations will be assigned the value #\undefined. -- The user can assign other values to variable locations using "set!". A "define" on top level will be an error, since the variable is already bound on that level. -- Allow the syntax "(set! (first cell) (car cell))" to mean the analogue of the comparable "define" syntax -- Biep. (biep@cs.vu.nl via mcvax) Who am I to doubt the existence of God? I am only a simple man, I already have trouble enough doubting the existence of my neighbour!  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 89 15:09:32 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 8 May 89 14:11:45 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: 8 May 89 17:02:21 GMT From: lambda!scp@lanl.gov (Stephen Pope) Organization: The Santa Fe Institute, NM Subject: Re: scoops sources Message-Id: References: <8905012306.AA13055@BLOOM-BEACON.MIT.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <8905012306.AA13055@BLOOM-BEACON.MIT.EDU> V4110DAA@AWIUNI11.BITNET (Gerhard Eckel) writes: > is there anybody in the SCHEME community who could *mail* to me >(unfortunately I don't have access on ftp) the source code of SCOOPS as it is >running on PCScheme? I received the CSCHEME version of SCOOPS via this list >recently but I use PCScheme and I don't want to convert it back. >Unfortunately PCScheme comes without the source code. I seem to have missed the distribution of the CSCHEME version of SCOOPS. Could some kind soul mail me said package, or indicate ftp access? Thanks, Stephen C. Pope Santa Fe Institute scp@sfi.santafe.edu  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 89 12:09:38 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 8 May 89 11:38:08 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: 8 May 89 14:37:04 GMT From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich) Organization: Computer Science, Yale University, New Haven, CT 06520-2158 Subject: Re: semantics of DEFINE Message-Id: <59840@yale-celray.yale.UUCP> References: <890503-103409-9762@Xerox> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <890503-103409-9762@Xerox>, Pavel.pa@XEROX writes: >Too many people are referring to DEFINE as a form that ``side-effects the >top-level environment'' for me to keep out of the fray. In the current >(unreleased) draft of the Scheme specification, R^(3.95)RS, the following >definitions appear (my wording): > >-- A program is a mixed sequence of definitions and expressions. > >-- The meaning of a program P is the same that that of the following >expression: > ((lambda (I*) P') ...) >where I* is the set of variables defined in P (i.e., appearing as the CADR >of a DEFINE form), P' is the sequence of expressions obtained by replacing >each definition in P with the corresponding assignment, and is >an expression producing some useless value. > >More informally, to execute a program, you wrap it in a big LET binding all >of the defined variables to useless values, change the DEFINEs to SET!s, >and evaluate that expression. OK, the above makes sense for "top-level" DEFINE forms. Before recasting my comments from before into the terminology used above, let me define two catagories of DEFINE forms that are not handled under the above specification: (1) non-top-level static definitions: definitions that are made at load/compile/etc time (ie, are static) but are not top-level. An example of this is a DEFINE form inside a "top-level" LET form. (2) dynamic definitions: DEFINE forms that are executed during the execution of another procedure. An example of this is a DEFINE form in the body of another DEFINE form. My claim is that both of these cases fits cleanly into the specification given above (by Pavel). In each case the symbol being DEFINEd would be bound in the global binding countour (shown above as a LAMBDA, essentially a LET) and would be SET! at the point where they were to be DEFINEd. The new specifications (using the terminology from above) would be: A program is a sequence of expressions The meaning of a program P is the same as that of the expression: ((lambda (I*) P') ...) where I* is the set of variables defined in P (ie, apearing as the CADR of a DEFINE form anywhere in the tree coresponding to P), P' is the sequence of expressions obtained by replacing all appearences of the symbol DEFINE [perhaps only those where the variable DEFINE isn't rebound] with teh symbol SET!, and is an expression producing some useless value. The next question is why I think the specifications should be extended to allow this. My answers are: (1) It adds expressive power to the language. (2) Other proposed specifications for non-top-level DEFINEs do not add expressive power to the language. (3) It is a direct and consistant extension of the semantics being proposed (according to Pavel). Bruce Krulwich  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 7 May 89 14:10:53 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 7 May 89 13:26:05 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: 5 May 89 11:41:58 GMT From: philmtl!philabs!linus!ramsdell@uunet.uu.net (John D. Ramsdell) Organization: The MITRE Corp., Bedford, MA Subject: Please make internal DEFINE's more like top-level ones. Message-Id: <52382@linus.UUCP> References: <890503-103409-9762@Xerox> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Pavel correctly gives the meaning of top-level definitions. In article <890503-103409-9762@Xerox> Pavel.pa@XEROX.COM writes: Too many people are referring to DEFINE as a form that ``side-effects the top-level environment'' for me to keep out of the fray. In the current (unreleased) draft of the Scheme specification, R^(3.95)RS, the following definitions appear (my wording): -- A program is a mixed sequence of definitions and expressions. -- The meaning of a program P is the same that that of the following expression: ((lambda (I*) P') ...) where I* is the set of variables defined in P (i.e., appearing as the CADR of a DEFINE form), P' is the sequence of expressions obtained by replacing each definition in P with the corresponding assignment, and is an expression producing some useless value. Clearly, it is not a meaning preserving transformation to replace all top-level DEFINE's by a LETREC form. At the top-level, the order in which DEFINE's are given counts. People really write code like: (define a 3) (define b (* a a)) ... code that uses b. Internal DEFINE's are currently defined to be syntactic sugar for LETREC. That is, the order in which internal DEFINE's are given does not count. It is illegal to write the following code: (let () (define a 3) (define b (* a a)) ... code that uses b). My continuing question is why treat internal DEFINE's differently from from top-level DEFINE's? Why not give internal DEFINE's same semantics as given above? Those who want LETREC like semantics can use LETREC. John  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 4 May 89 17:41:14 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 4 May 89 15:54:17 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: 4 May 89 14:05:26 GMT From: pacific.mps.ohio-state.edu!verber@ohio-state.arpa (Mark A. Verber) Organization: Ohio State University, Physics Department Subject: Re: Cscheme via ftp now? Message-Id: <189@pacific.mps.ohio-state.edu> References: <2771@cayman.COM>, <6260001@otter.hpl.hp.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu CScheme is on tut.cis.ohio-state.edu whose IP address is 128.146.8.60. I find is very strange that Tut isn't in someone's host table since he is registered with the NIC and SOA for ohio-state.edu. You should be running a name resolver.... or at least a modern host table from SRI-NIC. Mark A. Verber | There are two major products that verber@mps.ohio-state.edu | come out of Berkeley: LSD and BSD Physics, 174 W 18th, Cols, OH 43210 | UNIX. We don't believe this to 1-614-292-8002 | be a coincidence.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 4 May 89 17:08:50 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 4 May 89 15:39:37 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: 4 May 89 10:32:26 GMT From: otter!gjh@hplabs.hp.com (Graham Higgins) Organization: Hewlett-Packard Laboratories, Bristol, UK. Subject: Re: Cscheme via ftp now? Message-Id: <6260001@otter.hpl.hp.com> References: <2771@cayman.COM> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu The question came ... ++ > Now that prep is gone, where can one ftp Cscheme from? ++ Try tut.cis.ohio-state.edu. (is there an echo in here?) Thanks Chris Whatley --- could you also post the internet address, tut.cis.ohio-state.edu doesn't appear in my hosts table. Cheers, Graham ====== ------------------------------------------------------------------ Graham Higgins @ HP Labs | Phone: (0272) 799910 x 24060 Information Systems Centre | gray@hpl.hp.co.uk Bristol | gray%hplb.uucp@ukc.ac.uk U.K. | gray@hplb.hpl.hp.com  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 4 May 89 04:22:37 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 3 May 89 21:26:17 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: 3 May 89 21:21:55 GMT From: unicads!les@boulder.colorado.edu (Les Milash) Organization: Unicad Boulder, CO Subject: Re: top level definitions Message-Id: <417@unicads.UUCP> References: <8905030850.AA21221@chamartin.AI.MIT.EDU>, <8912@polya.Stanford.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <8912@polya.Stanford.EDU> mxh@sumex-aim.Stanford.EDU (Max Hailperin) writes: >[Abelson and Sussman, p. 8], which would be legal under R3RS's set!-like ^^^^^^^^^^^^^^^^^^^ sorry to be so ignorant, but what is this? I've seen R*S's but never a book on Scheme. (After reading about Screme on the 88K in ASPLOS III I'm getting tempted to write one for INMOS Transputers. Any huge interest in this out there? Imagine the potential: "the embedded symbolic computer". For a microwave that can tell you WHY weenies take 2 minutes, or a dashboard that can debate the wisdom of using seatbelts AND WIN. Can anybody point me at thoughts about Schemes on multiprocessors (i suspect Scheme is a great language for multiprocessors but I don't really know the details) or just an overview of Scheme (i suspect that it's "Lisp without X or Y or Z" which gives you "Lisp with some additional magic powers"). My goal is to have a nice language for programming a single processor, and running bunches of those, but perhaps there are some slick things permitting parallel evaluation of subexpressions by multple processors etc.) any other tips for a rank beginner? (be nice, i'm just a fresh convert from the C world, i just got sick of having to do in my programs what Scheme does for me in the language.)  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 4 May 89 00:46:50 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 3 May 89 17:47:10 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: 3 May 89 17:33:55 GMT From: XEROX.COM!Pavel.pa@bloom-beacon.mit.edu Organization: The Internet Subject: Re: semantics of DEFINE Message-Id: <890503-103409-9762@Xerox> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Too many people are referring to DEFINE as a form that ``side-effects the top-level environment'' for me to keep out of the fray. In the current (unreleased) draft of the Scheme specification, R^(3.95)RS, the following definitions appear (my wording): -- A program is a mixed sequence of definitions and expressions. -- The meaning of a program P is the same that that of the following expression: ((lambda (I*) P') ...) where I* is the set of variables defined in P (i.e., appearing as the CADR of a DEFINE form), P' is the sequence of expressions obtained by replacing each definition in P with the corresponding assignment, and is an expression producing some useless value. More informally, to execute a program, you wrap it in a big LET binding all of the defined variables to useless values, change the DEFINEs to SET!s, and evaluate that expression. Note, please: no mutation of any environment takes place. I believe that too many people base their understanding of the semantics of Scheme on a read-eval-print loop model or on the low-level details of particular (or perhaps all) implementations. It seems to me irrelevant that I might use side-effects to resolve the separate compilation (or just separate loading) of files of code with the semantics given above. The semantics of DEFINE, and therefore the most accurate way to conceptualize its meaning, has no mention of mutation. Of course, this little diatribe has no direct bearing on the meaning of internal DEFINEs. Personally, I'd rather they had the same meaning (as given above) as top-level ones. The meaning in terms of LETREC has always struck me as gratuitously incompatible, and frequently inconvenient as well. If you're going to use the same name, you should give it the same semantics... Pavel  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 3 May 89 20:32:48 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 3 May 89 19:16:57 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: 3 May 89 21:23:51 GMT From: POLYA.STANFORD.EDU!shap@bloom-beacon.mit.edu (Jonathan S. Shapiro) Organization: The Internet Subject: Common Lisp on Scheme? Message-Id: <8905032123.AA18408@polya.Stanford.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu What with the Scheme implementation that is built on Common Lisp, it occurs to me to ask if anyone has implemented a Common Lisp on Scheme? Jon  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 3 May 89 20:31:21 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 3 May 89 18:35:02 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: 3 May 89 16:17:50 GMT From: polya!max@labrea.stanford.edu (Max Hailperin) Organization: Stanford University Subject: top level definitions Message-Id: <8912@polya.Stanford.EDU> References: <8905030850.AA21221@chamartin.AI.MIT.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I like the wrap-it-all-with-a-let semantics for top-level definitions. However, note that this is not in keeping with R3RS, in that it disallows such programs as (define pi 3.14159) (define radius 10) (define circumference (* 2 pi radius)) circumference [Abelson and Sussman, p. 8], which would be legal under R3RS's set!-like semantics for top-level definitions. Of course, you could patch things up by switching from letrec to letrec*. My preference is to adopt the letrec-based version as official (making the above example not standard scheme), with the letrec*-based version as an incouraged extension for interactive implementations (note that letrec* is a legal implementation of letrec, as remarked in R3RS). There is also an issue of what to do with multiple definitions of the same variable in the same scope, which R3RS doesn't address for internal definitions and is a bigger issue for top-level interactions. Again, it's probably best to make any use of this feature non-standard, with some encouraged extension for interactive top-levels.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 3 May 89 17:48:38 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 3 May 89 14:29:30 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: 3 May 89 02:33:26 GMT From: sun-barr!cs.utexas.edu!milano!bigtex!nueces!chari@ames.arpa (Chris Whatley) Subject: Re: Cscheme via ftp now? Message-Id: <285@nueces.UUCP> References: <2771@cayman.COM> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <2771@cayman.COM>, art@cayman.COM (Art Mellor) writes: > Now that prep is gone, where can one ftp Cscheme from? Try tut.cis.ohio-state.edu. (is there an echo in here?) Chris -- Chris Whatley | "Thank you.. !bigtex!nueces!chari@cs.utexas.edu | Ah.. Thank me!" chari@walt.cc.utexas.edu | --Data 1607 Nueces,Austin TX 78723 - 512/453-4238 |  Received: from ZURICH.AI.MIT.EDU (TCP 2206400260) by MC.LCS.MIT.EDU 3 May 89 17:24:58 EDT Return-Path: Received: from polya.Stanford.EDU (polya.stanford.edu) by ZURICH.AI.MIT.EDU; Wed, 3 May 89 17:22:17 edt Received: by polya.Stanford.EDU (5.61/25-eef) id AA18408; Wed, 3 May 89 14:23:51 -0700 Date: Wed, 3 May 89 14:23:51 -0700 From: Jonathan S. Shapiro Message-Id: <8905032123.AA18408@polya.Stanford.EDU> To: scheme@ZURICH.AI.MIT.EDU Subject: Common Lisp on Scheme? What with the Scheme implementation that is built on Common Lisp, it occurs to me to ask if anyone has implemented a Common Lisp on Scheme? Jon  Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 3 May 89 13:37:32 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 03 MAY 89 10:34:09 PDT Date: Wed, 03 May 89 10:33:55 PDT From: Pavel.pa@Xerox.COM Subject: Re: semantics of DEFINE In-reply-to: "Scheme-Request@mc.lcs.mit.edu's message of 3 MAY 89 00:14:16 EDT" To: Scheme@mc.lcs.mit.edu Message-ID: <890503-103409-9762@Xerox> Too many people are referring to DEFINE as a form that ``side-effects the top-level environment'' for me to keep out of the fray. In the current (unreleased) draft of the Scheme specification, R^(3.95)RS, the following definitions appear (my wording): -- A program is a mixed sequence of definitions and expressions. -- The meaning of a program P is the same that that of the following expression: ((lambda (I*) P') ...) where I* is the set of variables defined in P (i.e., appearing as the CADR of a DEFINE form), P' is the sequence of expressions obtained by replacing each definition in P with the corresponding assignment, and is an expression producing some useless value. More informally, to execute a program, you wrap it in a big LET binding all of the defined variables to useless values, change the DEFINEs to SET!s, and evaluate that expression. Note, please: no mutation of any environment takes place. I believe that too many people base their understanding of the semantics of Scheme on a read-eval-print loop model or on the low-level details of particular (or perhaps all) implementations. It seems to me irrelevant that I might use side-effects to resolve the separate compilation (or just separate loading) of files of code with the semantics given above. The semantics of DEFINE, and therefore the most accurate way to conceptualize its meaning, has no mention of mutation. Of course, this little diatribe has no direct bearing on the meaning of internal DEFINEs. Personally, I'd rather they had the same meaning (as given above) as top-level ones. The meaning in terms of LETREC has always struck me as gratuitously incompatible, and frequently inconvenient as well. If you're going to use the same name, you should give it the same semantics... Pavel  Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 3 May 89 04:51:04 EDT Received: by chamartin.AI.MIT.EDU (5.61/1.2) id ; Wed, 3 May 89 04:50:30 -0400 Date: Wed, 3 May 89 04:50:30 -0400 From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas) Message-Id: <8905030850.AA21221@chamartin.AI.MIT.EDU> To: Ram-Ashwin@yale-zoo.arpa Cc: Scheme@mc.lcs.mit.edu In-Reply-To: Automatic Scheme Digestifier's message of 3 MAY 89 00:14:16 EDT Subject: Scheme Digest #111 Reply-To: jinx@zurich.ai.mit.edu In article <8905011321.AA03861@spt.entity.com>, alms@spt.entity.COM (andrew lm shalit) writes: > Date: 30 Apr 89 20:39:25 GMT > From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich) > > A while ago I posted the suggestion that non-top-level DEFINEs do > the same thing as top-level DEFINEs, ie, side effect the top level. > . . . > Most of the responses that I got said either like "well, Abelson > and Sussman used the 'local' interpretation, so we really should > stick to it" or "well, local non-top-level DEFINEs add fewer > parentheses than nesting LETRECs." Does anyone have other > (theoretical or functional) reasons for this decision?? > > How about a general aversion to the notion of "top-level environment"? When > you introduce first-class environments, and programming tools for using > them, the notion of "top-level" starts to change. Just how it changes > depends on how the environments and programming tools are designed. This is a good argument against DEFINE in general, not against DEFINEs within LETs in particular. A top-level DEFINE always assumes that you want to side-effect the "top-level environment". What you're really saying is that DEFINE should take an extra argument, which would explicitly specify the environment in which the definition should take place. The side effect in top level DEFINE is a debugging utility and purely a consequence of interactive development systems. There is a static way to think about top level DEFINE that eliminates this side effect: Assume that instead of having a system with a read eval print loop, a loader, and DEFINE modifying the read-eval-print environment or environment of loading, we have a static compiler which reads all modules together and then wraps a single LET around the concatenation of all of them. Top level DEFINE now has consistent semantics with internal DEFINE, since the LET with DEFINEs can be rewritten as a LETREC, and there is no side effect of environments. T does provide such a function, called *DEFINE. DEFINE is merely a convenient syntax for doing a *DEFINE in the environment that the startup REPL works in, called USER-ENV. The REPL-ENV can be changed as desired. I don't think this is quite right. I believe that top level DEFINE in T affects the loading environment, not the REPL environment. They are the same if you give load only a file name argument. This is what top level DEFINE does in MIT Scheme as well. You can explain the meaning of top level DEFINE by postulating a new special form, called THE-ENVIRONMENT, which returns the evaluation environment of the form. Top level DEFINE would then expand into (*DEFINE (THE-ENVIRONMENT) ' ) To get back to the original point, it seems perfectly reasonable to allow *DEFINEs to be nested within LETs, which would create a definition in the environment (which is explicitly specified as an argument to the *DEFINE). The definition is evaluated (and therefore closed) within the lexical environment of the LET, as any other form would be. It is perfectly reasonable, but has undesirable consequences when used pervasively. We (at MIT) found that this "unsrestricted export" style resulted in wired-in code, namely code that knew too much about the shape of the environment about where it would be loaded, and could not easily be reused. Given that DEFINE is merely a convenient syntax for *DEFINE in the REPL-ENV, it seems consistent to let a DEFINE with a LET be a convenient syntax for a *DEFINE within that LET with the REPL-ENV explicitly specified as the environment for the definition. Unfortunately your interpretation is not correct. However, we can make the interpretation that I have suggested above consistent merely by stipulating that (THE-ENVIRONMENT) should "work" in all binding contours, not merely top level environments. DEFINE would now expand consistently (both top level and internal) as suggested above. Using THE-ENVIRONMENT consistenly explains the behavior of all DEFINEs as long as you restrict your internal definitions to valid LETREC internal bindings and ignore CWCC, which also presents problems for LETREC. Local internal DEFINEs came from a variety of linguistic and functional criteria in the design of MIT Scheme. The main linguistic argument is that the notion of a top level is strange, and distingushing it from internal levels is even stranger. We can get rid of this distinction in two different ways, each accomplished by one of the models suggested above: The global static compiler model makes top level (and its definitions) behave exactly like the body of a LET (and its definitions), but does not allow for interactive development. Using THE-ENVIRONMENT makes internal contours (and definitions therein) behave exactly like top level (with its definitions), but presents some implementation and semantics problems. Your suggestion for DEFINE forces the notion of top level or read eval print loop into the language, and I think that would be a mistake. I consider read eval print loops and "top levels" to be an environment design issue, not something to be specified in the language.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 2 May 89 19:25:10 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 2 May 89 19:05:17 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: 2 May 89 21:19:42 GMT From: mailrus!jarvis.csri.toronto.edu!ephemeral.ai.toronto.edu!bradb@ohio-state.arpa (Brad Brown) Organization: Department of Computer Science, University of Toronto Subject: PC-Scheme SCOOPS source Message-Id: <89May2.171945edt.10773@ephemeral.ai.toronto.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Is there anyone out there who can tell me how to get the SCOOPS sources for PC-SCHEME? I can do ftp or mail... BTW, I'm interested in implementing my own OO shell for Scheme (for playing around and general interest, not to compete with SCOOPS :-) and I'm very curious about how to provide access to instance and class variables. I'd like to be able to have instance and class variables in their own environments, and be able to write methods that access the variables (by name) in the proper environment. I'm having a lot of trouble getting methods that can access the variables in the proper environement. Does anyone have any tips? (I'm not an expert Scheme user and working with environments is very new (and confusing) to me...) Thanks, (-: Brad Brown :-) bradb@ai.toronto.edu  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 2 May 89 15:16:04 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 2 May 89 14:46:56 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: 2 May 89 08:15:48 GMT From: mcvax!kth!draken!tut!jh@uunet.uu.net (Hein{nen Juha) Organization: Tampere Univ of Technology Subject: NeWS interface for CL and Scheme available Message-Id: References: , <1086@cantuar.UUCP>, Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu A software package that takes as input a cps source file and produces Scheme or CL interface procedures that allow NeWS procedures to be called from Scheme or CL in the same way as from C is now available for anonymous ftp from tumtum.cs.umd.edu (128.8.128.49) under the name lps.tar.Z. Our package currently supports Allegro CL and pseudoscheme (by Jonathan Rees) that runs on top of it. Adding support for other CLs or Schemes that have a foreign function interface should be quite straightforward. -- -- Juha Heinanen, Tampere Univ. of Technology, Finland jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 2 May 89 11:35:14 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 2 May 89 11:31:47 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: 2 May 89 14:06:32 GMT From: Ram-Ashwin@yale-zoo.arpa (Ashwin Ram) Organization: Computer Science, Yale University, New Haven, CT 06520-2158 Subject: Re: semantics of DEFINE Message-Id: <59114@yale-celray.yale.UUCP> References: <59021@yale-celray.yale.UUCP>, <8905011321.AA03861@spt.entity.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <8905011321.AA03861@spt.entity.com>, alms@spt.entity.COM (andrew lm shalit) writes: > Date: 30 Apr 89 20:39:25 GMT > From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich) > > A while ago I posted the suggestion that non-top-level DEFINEs do > the same thing as top-level DEFINEs, ie, side effect the top level. > . . . > Most of the responses that I got said either like "well, Abelson > and Sussman used the 'local' interpretation, so we really should > stick to it" or "well, local non-top-level DEFINEs add fewer > parentheses than nesting LETRECs." Does anyone have other > (theoretical or functional) reasons for this decision?? > > How about a general aversion to the notion of "top-level environment"? When > you introduce first-class environments, and programming tools for using > them, the notion of "top-level" starts to change. Just how it changes > depends on how the environments and programming tools are designed. This is a good argument against DEFINE in general, not against DEFINEs within LETs in particular. A top-level DEFINE always assumes that you want to side-effect the "top-level environment". What you're really saying is that DEFINE should take an extra argument, which would explicitly specify the environment in which the definition should take place. T does provide such a function, called *DEFINE. DEFINE is merely a convenient syntax for doing a *DEFINE in the environment that the startup REPL works in, called USER-ENV. The REPL-ENV can be changed as desired. To get back to the original point, it seems perfectly reasonable to allow *DEFINEs to be nested within LETs, which would create a definition in the environment (which is explicitly specified as an argument to the *DEFINE). The definition is evaluated (and therefore closed) within the lexical environment of the LET, as any other form would be. Given that DEFINE is merely a convenient syntax for *DEFINE in the REPL-ENV, it seems consistent to let a DEFINE with a LET be a convenient syntax for a *DEFINE within that LET with the REPL-ENV explicitly specified as the environment for the definition. -- Ashwin.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 2 May 89 09:36:45 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 2 May 89 08:36:20 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: 1 May 89 17:47:29 GMT From: bunny!cayman!art@husc6.harvard.edu (Art Mellor) Organization: Cayman Systems Inc., Cambridge Ma Subject: Cscheme via ftp now? Message-Id: <2771@cayman.COM> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Now that prep is gone, where can one ftp Cscheme from? art@cayman.com  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 2 May 89 09:35:26 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 2 May 89 07:50:11 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: 1 May 89 23:09:58 GMT From: unmvax!ncar!umigw!umiami!slores@bloom-beacon.mit.edu (Stanislaw L. Olejniczak) Organization: University of Miami (IR) Subject: SoftEng or CS Graduate Program Search Message-Id: <610@umiami.miami.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I would very much appreciate, on my and many other prospective graduate students' behalf, your comments on graduate software engineering programs. I have been reading brochures from various schools, collected various rankings and read a couple books about graduate programs in software engineering or computer science. What I am asking for in this message are personal opinions, observations and comments. Which school and department do you think is a good place to study Software Engineering or Computer Science with Software Engineering emphasis? Why do you think a particular department is a good place to spend a couple years getting a Master's, and later, a Ph.D.? What are its strength? What are its weaknesses? Where do the graduates go? What kind of research is being conducted? Who (if not yourself) is a good person to contact there? What are other comments you would like to make that I have not asked about? All comments you will send will be appreciated. Let me apologize for posting this message again, and for posting it this time to numerous newsgroups. When I have initially posted this request, I have offered to send summaries to any interested person. I have received several dozens of requests for the summaries. I have received a small handful of replies on the subject. After waiting now a considerable, for Newsnet, time, I have decided I did not post it to the right groups; or all the right people did not get to see this. Thus, this second, and final, attempt. To those who had previously replied, my many thanks. For those who had requested or will request summaries, I will post them to you after I feel reasonably certain I have received all replies to this second posting. To those who will reply, many, many thanks, from me and from the numerous prospective graduate students who will embark on more successful graduate studies thanks to the time you take off your busy schedules to advise. P.S. If you are so kind as to send your comments but would NOT want be identified in the summary, please let me know. -- ---- Stan Olejniczak Internet: slores@umiami.miami.edu University of Miami UUCP: {uunet!gould}!umbio!solejni Miami, Florida, USA BITNET: SLORES@UMIAMI Voice: (305)-547-6571 FAX:305-547-6412 My opinions cannot possibly represent the views of anyone else!  Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 1 May 89 18:33:20 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 5105; Mon, 01 May 89 18:34:07 EDT Received: from EDVZ.Uni-Wien.AC.AT by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 3667; Mon, 01 May 89 18:33:33 EDT Received: by AWIUNI11 (Mailer R2.01) id 1732; Tue, 02 May 89 00:31:21 MEZ Date: Tue, 02 May 89 00:30:17 MEZ From: Gerhard Eckel Subject: scoops sources To: Scheme mailing list Hello, is there anybody in the SCHEME community who could *mail* to me (unfortunately I don't have access on ftp) the source code of SCOOPS as it is running on PCScheme? I received the CSCHEME version of SCOOPS via this list recently but I use PCScheme and I don't want to convert it back. Unfortunately PCScheme comes without the source code. Thank you very much in advance! +------------------------------+---------------------------------------------+ : Gerhard ECKEL c/o Austrian Academy of Sciences, Dept. Sound : : Hernalser Haupstrasse 164/17 : Liebiggasse 5, A-1010 Vienna, AUSTRIA : : A-1170 Vienna, AUSTRIA : Tel.: +43 222 43 00 27 30 : : Tel.: +43 222 46 10 404 : E-mail: V4110DAA@AWIUNI11.BITNET : +------------------------------+---------------------------------------------+  Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 MAY 89 14:51:39 EDT Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ; Mon, 1 May 89 14:50:22 EDT Received: by spt.entity.com (smail2.5); 1 May 89 13:21:40 EDT (Mon) To: Krulwich-Bruce@yale-zoo.arpa Cc: @EDDIE.MIT.EDU:Scheme@mc.lcs.mit.edu In-Reply-To: (Bruce Krulwich's message of 30 Apr 89 20:39:25 GMT <59021@yale-celray.yale.UUCP> Subject: semantics of DEFINE Message-Id: <8905011321.AA03861@spt.entity.com> Date: 1 May 89 13:21:40 EDT (Mon) From: alms@spt.entity.com (andrew lm shalit) Date: 30 Apr 89 20:39:25 GMT From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich) In article <19890425161147.8.DEATH@MICKEY-MOUSE.LCS.MIT.EDU>, death@ZERMATT (Mark A. Sheldon) writes: . . . A while ago I posted the suggestion that non-top-level DEFINEs do the same thing as top-level DEFINEs, ie, side effect the top level. . . . Most of the responses that I got said either like "well, Abelson and Sussman used the 'local' interpretation, so we really should stick to it" or "well, local non-top-level DEFINEs add fewer parentheses than nesting LETRECs." Does anyone have other (theoretical or functional) reasons for this decision?? How about a general aversion to the notion of "top-level environment"? When you introduce first-class environments, and programming tools for using them, the notion of "top-level" starts to change. Just how it changes depends on how the environments and programming tools are designed. Do you have a problem with the following, aside from the general aversion to SET! ? (define frob nil) (let ((x (mumble1)) (y (mumble2))) (dset! frob (lambda (z) (list x y z))))  Received: from polya.Stanford.EDU (TCP 4402000240) by MC.LCS.MIT.EDU 1 May 89 11:37:35 EDT Received: from Sesame.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA29919; Mon, 1 May 89 08:36:26 -0700 Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C) id AA12423; Mon, 1 May 89 08:36:20 PDT Date: Mon, 1 May 89 08:36:20 PDT From: mkatz@sesame.Stanford.EDU (Morris Katz) Message-Id: <8905011536.AA12423@sesame.Stanford.EDU> To: Krulwich-Bruce@yale-zoo.arpa Cc: Scheme@mc.lcs.mit.edu In-Reply-To: (Bruce Krulwich's message of 30 Apr 89 20:39:25 GMT <59021@yale-celray.yale.UUCP> Subject: semantics of DEFINE Date: 30 Apr 89 20:39:25 GMT From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich) In article <19890425161147.8.DEATH@MICKEY-MOUSE.LCS.MIT.EDU>, death@ZERMATT (Mark A. Sheldon) writes: >Allowing DEFINEs everywhere gives us a weird sort of dynamic scoping. >Restricting DEFINEs to beginnings of blocks allows us to think of a block >of internal DEFINEs as a LETREC (though CALL/CC may expose implementations >that don't implement these blocks as a LETREC). If Scheme is a statically >scoped language, then this sort of DEFINE is anathema. If Scheme is to >support dynamic scoping, then I think FLUID-LET is cleaner because I don't >have to think about environment mutation. A while ago I posted the suggestion that non-top-level DEFINEs do the same thing as top-level DEFINEs, ie, side effect the top level. This allows top-level definitions to scope over lexically bound variables, which cannot be done in any other way (as of now a single procedure can scope over variables, but such variables cannot be shared by procedures); having non-top-level DEFINEs side effect the local lexical environment is the same as LETREC (perhaps nested) and thus doesn't add any functionality. This interpretation is the one adopted by the current version of T (although it's not an explicit decision on the part of the T designers) and I believe is the interpretation used by most LISP dialects. The ability to have global procedures scope over variables reduces the number of unneeded global variables, allows hiding of internal representations, and (almost definitely) adds alot to the efficiency of accessing these variables. Most of the responses that I got said either like "well, Abelson and Sussman used the 'local' interpretation, so we really should stick to it" or "well, local non-top-level DEFINEs add fewer parentheses than nesting LETRECs." Does anyone have other (theoretical or functional) reasons for this decision?? Bruce Krulwich Some systems may not have the concept of A top level environment, so this proposal restricts Scheme in an important way that should be recognized. If one has a system that has first-class environments, then a top level environment may not exist or may be a dynamic, rather than a static, property of a piece of executing code. I would far prefer to see local defined removed from Scheme than have them given the proposed semantics. Morry Katz katz@polya.stanford.edu  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 30 Apr 89 17:25:11 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 30 Apr 89 17:14:33 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: 30 Apr 89 20:39:25 GMT From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich) Organization: Computer Science, Yale University, New Haven, CT 06520-2158 Subject: semantics of DEFINE Message-Id: <59021@yale-celray.yale.UUCP> References: , <19890425161147.8.DEATH@MICKEY-MOUSE.LCS.MIT.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <19890425161147.8.DEATH@MICKEY-MOUSE.LCS.MIT.EDU>, death@ZERMATT (Mark A. Sheldon) writes: >Allowing DEFINEs everywhere gives us a weird sort of dynamic scoping. >Restricting DEFINEs to beginnings of blocks allows us to think of a block >of internal DEFINEs as a LETREC (though CALL/CC may expose implementations >that don't implement these blocks as a LETREC). If Scheme is a statically >scoped language, then this sort of DEFINE is anathema. If Scheme is to >support dynamic scoping, then I think FLUID-LET is cleaner because I don't >have to think about environment mutation. A while ago I posted the suggestion that non-top-level DEFINEs do the same thing as top-level DEFINEs, ie, side effect the top level. This allows top-level definitions to scope over lexically bound variables, which cannot be done in any other way (as of now a single procedure can scope over variables, but such variables cannot be shared by procedures); having non-top-level DEFINEs side effect the local lexical environment is the same as LETREC (perhaps nested) and thus doesn't add any functionality. This interpretation is the one adopted by the current version of T (although it's not an explicit decision on the part of the T designers) and I believe is the interpretation used by most LISP dialects. The ability to have global procedures scope over variables reduces the number of unneeded global variables, allows hiding of internal representations, and (almost definitely) adds alot to the efficiency of accessing these variables. Most of the responses that I got said either like "well, Abelson and Sussman used the 'local' interpretation, so we really should stick to it" or "well, local non-top-level DEFINEs add fewer parentheses than nesting LETRECs." Does anyone have other (theoretical or functional) reasons for this decision?? Bruce Krulwich  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 29 Apr 89 06:54:19 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 29 Apr 89 06:44:53 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: 28 Apr 89 13:47:35 GMT From: mnetor!utzoo!yunexus!oz@uunet.uu.net (Ozan Yigit) Organization: York U. Communications Research & Development Subject: Add to your copy of biblio. Message-Id: <1729@yunexus.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu %A Steven R. Vegdahl %A Uwe F. Pleban %T The Runtime Environment for Screme, a Scheme Implementation on the 88000 %J Proceedings of the Third International Conference on Architectural Support for Programming Languages and Operating Systems %C Boston, Mass. %D April 1989 %P 172-182 -- oz -- use the source, luke !! Usenet: oz@nexus.yorku.ca uh... we forgot to tell you... ......!uunet!utai!yunexus!oz it is unintelligible, but hey, you Bitnet: oz@[yulibra|yuyetti] got it, for free (!). Phonet: +1 416 736-5257x3976  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 Apr 89 13:09:17 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 25 Apr 89 12:54:26 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: 25 Apr 89 16:11:00 GMT From: ZERMATT.LCS.MIT.EDU!death@bloom-beacon.mit.edu (Mark A. Sheldon) Organization: The Internet Subject: Scheme Digest #106 Message-Id: <19890425161147.8.DEATH@MICKEY-MOUSE.LCS.MIT.EDU> References: Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu One crucial problem with DEFINEs placed willy-nilly in programs arises from DEFINE's being an environment mutator. Consider this modification to our standing example: (define (foo bool) (if bool (define (result) #t) 'do-nothing (result))) Allowing DEFINEs everywhere gives us a weird sort of dynamic scoping. Restricting DEFINEs to beginnings of blocks allows us to think of a block of internal DEFINEs as a LETREC (though CALL/CC may expose implementations that don't implement these blocks as a LETREC). If Scheme is a statically scoped language, then this sort of DEFINE is anathema. If Scheme is to support dynamic scoping, then I think FLUID-LET is cleaner because I don't have to think about environment mutation. Top level DEFINEs don't bother me so much because I think of the top level as a debugger. -Mark A. Sheldon  Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 25 Apr 89 12:12:11 EDT Received: from MICKEY-MOUSE.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 252370; Tue 25-Apr-89 12:11:56 EDT Date: Tue, 25 Apr 89 12:11 EDT From: Mark A. Sheldon Subject: Scheme Digest #106 To: Scheme@MC.LCS.MIT.EDU In-Reply-To: The message of 25 Apr 89 00:09 EDT from Automatic Scheme Digestifier Message-ID: <19890425161147.8.DEATH@MICKEY-MOUSE.LCS.MIT.EDU> One crucial problem with DEFINEs placed willy-nilly in programs arises from DEFINE's being an environment mutator. Consider this modification to our standing example: (define (foo bool) (if bool (define (result) #t) 'do-nothing (result))) Allowing DEFINEs everywhere gives us a weird sort of dynamic scoping. Restricting DEFINEs to beginnings of blocks allows us to think of a block of internal DEFINEs as a LETREC (though CALL/CC may expose implementations that don't implement these blocks as a LETREC). If Scheme is a statically scoped language, then this sort of DEFINE is anathema. If Scheme is to support dynamic scoping, then I think FLUID-LET is cleaner because I don't have to think about environment mutation. Top level DEFINEs don't bother me so much because I think of the top level as a debugger. -Mark A. Sheldon  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 Apr 89 08:52:45 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 25 Apr 89 08:50:58 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: 25 Apr 89 03:25:00 GMT From: stung@iuvax.cs.indiana.edu Organization: Indiana University CSCI, Bloomington Subject: Re: NeWS interface for CL and Scheme Message-Id: <56700004@iuvax> References: <89@ Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I am interested in your lps program. I would appreciate if you can make it available through anonymous ftp. Simon Tung stung@iuvax.cs.indiana.edu  Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 25 Apr 89 06:33:02 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 1373; Tue, 25 Apr 89 06:34:11 EDT Received: from IRUCCIBM.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 3776; Tue, 25 Apr 89 06:34:10 EDT Received: from IRUCCVAX.UCC.IE by IRUCCIBM.BITNET (Mailer R2.03B) with BSMTP id 3468; Tue, 25 Apr 89 11:19:02 IST Date: Tue, 25 Apr 89 11:17 GMT From: Ian Murphy Subject: RE: Scheme Digest #105 To: Scheme@mc.lcs.mit.EDU X-VMS-To: IN%"Scheme@mc.lcs.mit.edu" oops, made a mistake with my interpretation of the program yesterday, I thought that (define (foo bool) (if bool (define (result) #t) (define (result) #f)) (result)) meant define the procedure result as the value #t/#f. My mistake was in thinking #t/#f were values which couldn't evaluate (procedural thinking), in fact (define (result) #t) is merely syntactic sugar for (define result (lambda() #t)) Which, as most of you know only too well,is the lambda func which evaluates '#t', which of course returns #t. stupid mistake, too many years of pascal warps your way of thinking :-) +-----------------------------------------------------------------------------+ |Ian Murphy (^v^) | Internet : IAN@VAX1.UCC.IE | |Dept. Computer Science | ARPA : IAN@IRUCCVAX.BITNET | |University College Cork, | janet : EARN%IRL.HEA.UCC.IRUCCVAX::IAN | |Ireland. | Voice : "IAN!!!" | +-----------------------------------------------------------------------------+  Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 24 Apr 89 21:04:42 EDT Received: from relay2.cs.net by RELAY.CS.NET id av00264; 24 Apr 89 20:27 EDT Received: from cs.brandeis.edu by RELAY.CS.NET id am07322; 24 Apr 89 16:32 EDT Received: by cs.brandeis.edu (14.2/6.0.GT) id AA17375; Mon, 24 Apr 89 13:45:20 edt Date: Mon, 24 Apr 89 13:45:20 edt From: Roland Zito-wolf Posted-Date: Mon, 24 Apr 89 13:45:20 edt To: ailist.2@cs.brandeis.edu, scheme.2@cs.brandeis.edu Subject: macro-expansions I am looking for esxamples of creative/complex macro usage in LISP or SCHEME systems, with which to evaluate the differences in various macro proposals for SCHEME (expansion-passing style, syntactic closures, and hygienic macro expansion). Pointers and examples are welcome. Reply to: Roland J. Zito-wolf (aka Roy) Dept. of Computer Science, Ford Hall Room 121 Brandeis University Waltham, Mass 02254-9110 617-736-2728 RJZ@CS.BRANDEIS.EDU or RJZ%CS.BRANDEIS.EDU@RELAY.CS.NET  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 24 Apr 89 17:57:31 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 24 Apr 89 17:38:11 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: 24 Apr 89 19:11:56 GMT From: mcvax!kth!draken!tut!jh@uunet.uu.net (Hein{nen Juha) Organization: Tampere Univ of Technology Subject: NeWS interface for CL and Scheme Message-Id: References: <3918@ficc.uu.net>, , <1086@cantuar.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <1086@cantuar.UUCP> greg@cantuar.UUCP (G. Ewing) writes: Bob Sutterfield (bob@allosaur.cis.ohio-state.edu) writes: >What interpretive language would you like to use to interact with your >windows? Scheme. This may not be what you have in mind, but we have written a program called lps that takes as input a cps source file and produces Scheme or CL interface procedures that allow NeWS procedures to be called from Scheme or CL in the same way as from C. Our lps currently supports Allegro CL and pseudoscheme (by Jonathan Rees) that runs on top of it. Adding support for other CLs or Schemes that have a foreign function interface should be quite straightforward. If there is enough interest we might make the package available for anonymous ftp although no documentation has been produced yet. -- -- Juha Heinanen, Tampere Univ. of Technology, Finland jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)  Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 24 Apr 89 11:19:27 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 9141; Mon, 24 Apr 89 11:20:38 EDT Received: from IRUCCIBM.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 4197; Mon, 24 Apr 89 11:20:34 EDT Received: from IRUCCVAX.UCC.IE by IRUCCIBM.BITNET (Mailer R2.03B) with BSMTP id 9350; Mon, 24 Apr 89 13:36:33 IST Date: Mon, 24 Apr 89 13:35 GMT From: Ian Murphy Subject: (define (foo bool... and redefinition of sys funcs To: scheme@mc.lcs.mit.EDU X-VMS-To: IN%"scheme@mc.lcs.mit.edu" >>> >>> (define (foo bool) >>> (if bool >>> (define (result) #true) >>> (define (result) #false)) >>> (result)) >>> The way i'd read this is: If bool is true then define the procedure called 'result' as the value #true, which obviously doesn't make sense, and then return the result of calling the procedure 'result' which *should* be impossible as it's a value, not a procedure. Surely defining it like this is better (define (foo bool) (if bool (define result #true) (define result #false)) result) Is this the correct way to read scheme, or am I mistaken(the above works fine in xscheme). Regarding the redefinition of system functions, I'd prefer to be able to redefine them at will, BUT I think everybody wants control over their own programs, but also without altering the workings of already defined procedures. I think it would be best if compiled functions couldn't be altered by redefining a function (i.e like cschemes fasloaded functions), this will allow you to redefine, say, the display function so that it sends its output to a file instead, for *your* program and your program only and not all the older functions which have been, in effect, added to your version of the language. Does this seem reasonable? btw do many other people work with xscheme at all, its a bit limited by the pc memory constraints but apart from that i find it to be excellent as it's so quick to try things out in. +-----------------------------------------------------------------------------+ |Ian Murphy | Internet : IAN@VAX1.UCC.IE | |Dept. Computer Science | ARPA : IAN@IRUCCVAX.BITNET | |University College Cork, | janet : EARN%IRL.HEA.UCC.IRUCCVAX::IAN | |Ireland. | Voice : "IAN!!!" | +-----------------------------------------------------------------------------+  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 23 Apr 89 16:07:00 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 23 Apr 89 15:55:42 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: 23 Apr 89 19:31:51 GMT From: titan!dorai@rice.edu (Dorai Sitaram) Organization: Rice University, Houston Subject: Re: Question with binding Message-Id: <3153@kalliope.rice.edu> References: <19890421061138.6.VANMEULE@PERTA.SCRC.Symbolics.COM>, <3140@kalliope.rice.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <3140@kalliope.rice.edu> I wrote: $The reason is that you can devise your own security blanket (and sleep $tight ;-}) with the macro system that comes with any Scheme. The $declare-constant and undeclare-constant that I referred to in my $earlier posting are now simple macros. One method would be: $ $(defmacro (declare-constant x) $ `(put 'x 'constant t)) $ $(defmacro (undeclare-constant x) $ `(put 'x 'constant nil)) $ $(defmacro (setq x v) $ `(if (get 'x 'constant) $ (error "hey watch out, salman rushdie is out to set constants!") $ (set! x ,v))) All the x's above should have commas before them. I guess the constant shuttling between the new extend-syntax (which doesn't use the backquote system) and the old def*macro (which does) has taken its toll. --dorai ------------------------------------------------------------------------------ We must believe in free will. We have no choice. --Isaac Bashevis Singer ------------------------------------------------------------------------------  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 23 Apr 89 04:36:48 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 23 Apr 89 04:24:32 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: 23 Apr 89 01:16:52 GMT From: leverich@rand-unix.arpa (Brian Leverich) Organization: RAND Corp., Santa Monica, CA Subject: Re: Scheme for IBM PC compatible Message-Id: <1953@randvax.UUCP> References: <29975@bu-cs.BU.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <29975@bu-cs.BU.EDU> muller@bu-cs.BU.EDU (Robert Muller) writes: >I'm looking for an interpreter or compiler for Scheme for an IBM PC. You want PC-Scheme from Texas Instruments. Retail from TI in Dallas is about $95, and there are substantial educational discounts. TI's implementation is very fast, has gobs of good features (including understanding '87 chips, expanded and extended memory, etc.), suffers only a handful of bugs, and is wonderfully documented. Unless you're _really_ short on cash, it's not worth messing with anything else. Good luck. -- "Simulate it in ROSS" Brian Leverich | U.S. Snail: 1700 Main St. ARPAnet: leverich@rand-unix | Santa Monica, CA 90406 UUCP/usenet: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 22 Apr 89 10:57:29 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 22 Apr 89 10:52:33 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: 22 Apr 89 02:37:10 GMT From: mailrus!wasatch!cs.utexas.edu!natinst!bigtex!nueces!chari@ames.arpa (Chris Whatley) Subject: Re: Scheme for IBM PC compatible Message-Id: <270@nueces.UUCP> References: <29975@bu-cs.BU.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <29975@bu-cs.BU.EDU>, muller@bu-cs.BU.EDU (Robert Muller) writes: > I'm looking for an interpreter or compiler for Scheme for an IBM PC. > Does anyone out there know of a reasonably cheap (i.e., free) version? I'm posting this since it might be of general interest. Xscheme, the Scheme equivalent of Xlisp is available from tut.cis.ohio-state.edu by ftp and from osu-cis.uucp by uucp. It is /pub/Xscheme.tar on tut. It make properly on pc's and Unixes and is writeen in C. Chris -- Chris Whatley | "dish... crab fingers... !bigtex!nueces!chari@cs.utexas.edu | dish of crab fingers..." chari@walt.cc.utexas.edu | 1607 Nueces,Austin TX 78723 - 512/453-4238 | (that'll teach you)  Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 22 Apr 89 10:10:43 EDT Received: by chamartin.AI.MIT.EDU (5.61/1.2) id ; Sat, 22 Apr 89 09:10:29 -0500 Date: Sat, 22 Apr 89 09:10:29 -0500 From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas) Message-Id: <8904221410.AA12294@chamartin.AI.MIT.EDU> To: vanMeule@ALLEGHENY.SCRC.Symbolics.COM Cc: Scheme@mc.lcs.mit.edu In-Reply-To: Automatic Scheme Digestifier's message of 22 APR 89 00:07:06 EDT Subject: Re: Question with binding Reply-To: jinx@zurich.ai.mit.edu I just have one question for anyone that's in favor of redefinition. Are you saying you want redefinition-with-wild-abandon? I.e. do you NOT want the system to warn you and ask you: "Are you sure?"? (Admittedly there could be a hackerish thrill in living dangerously....safety is wimps. :-) Or, do you want the system to ask you? (Which could be annoying, especially for loading files.) Or, do you want the system to warn you by default, unless you set a global-dont-warn-me-about-redefinitions flag appropriately? (And if the latter, are you prepared to have zillions of such global variables for similar things in a BIG MOBY system?) There are other possibilities besides global switches and annoying warnings. In MIT Scheme and T there are first class environments, called locales in T, where incremental (top level) definition is legal. Definition in these environments affects only them and their "children", but affects no other first class environments. Systems can be structured in such a way that defining in the "user initial" environment does not affect system code at all, but affects all the user code "loaded" there. Thus the user can get whatever definition of CAR s/he wants while the system continues using whatever else it wants. If you want to "redefine" something for the system as well, you have to do a little more work, since you first have to find what binding (or bindings) affect the system, and then assign it (them) to the desired value. Since doing this unadvertently is very unlikely, there is no need for warnings or switches. I find that this scenario provides a reasonable degree of system security against unintentional damage, while providing significant power to knowledgeable users. Unfortunately R3RS does not provide any notion of multiple first class environments or top levels, so it is inconvenient to write an R3RS portable system that has the above behavior.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 22 Apr 89 10:08:07 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 22 Apr 89 09:55:03 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: 21 Apr 89 18:26:23 GMT From: killer!pollux!ti-csl!m2!gateley@eddie.mit.edu (John Gateley) Organization: TI Computer Science Center, Dallas Subject: Re: where define is legal Message-Id: <75453@ti-csl.csc.ti.com> References: <8904201554.AA13117@spt.entity.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <8904201554.AA13117@spt.entity.com> alms@spt.entity.COM (andrew lm shalit) writes: >(define (foo bool) > (if bool > (define (result) #true) > (define (result) #false)) > (result)) From the R^3S: Section 5.2 "Definitions are valid in some, but not all, contexts where expressions are allowed. They are valid only at the top level of a and, in some implementations, at the beginning of a . Section 5.2.1 describes top level definitions, and section 5.2.2 describes internal definitions. The above code can be rewritten as: (define result nil) ; dummy value for the variable result. (define (foo bool) (if bool (set! result (lambda () #true)) (set! result (lambda () #false))) (result)) You can use a local variable for result if you want. John gateley@tilde.csc.ti.com p.s. Hi Eric.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 22 Apr 89 09:42:48 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 22 Apr 89 09:29:33 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: 22 Apr 89 03:02:06 GMT From: mimos!rangkom!napi@uunet.uu.net (Mohd Hanafiah b. Abdullah) Organization: MIMOS, Malaysia Subject: mailing list Message-Id: <177@rangkom.MY> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Please include me in the mailing list. Thank you.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 22 Apr 89 08:57:33 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 22 Apr 89 08:49:31 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: 21 Apr 89 13:50:33 GMT From: mcvax!tuvie!brock@uunet.uu.net (Inst.f.Prakt.Info 1802) Organization: TU Vienna EDP-Center, Vienna, AUSTRIA Subject: package question Message-Id: <684@tuvie> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Hi I have a question or two to experienced Lisp/Scheme programmers about the package mechanism. 1.) Are packages an acceptable equivalent to modules in conv. programming lang.? 2.) Do you use them for all of Your code? 3.) Are there any common problems programmers normally have when beginning using packages? (perhaps some of you holding courses may answer this) 4.) How do you handle I/O? 5.) Do there exists alternatives to packages. (Well OO-extensions, but are there also simpler alternatives?) Please answer directly to me, I'll post a summary to comp.lang.lisp. Thanks in advance Ulrich (ulrich@vip.at UUCP: ...!mcvax!tuvie!vip!ulrich)  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 22 Apr 89 00:58:49 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 21 Apr 89 21:51:54 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: 21 Apr 89 20:04:58 GMT From: titan!dorai@rice.edu (Dorai Sitaram) Organization: Rice University, Houston Subject: Re: Question with binding Message-Id: <3140@kalliope.rice.edu> References: <19890421061138.6.VANMEULE@PERTA.SCRC.Symbolics.COM> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu $From: Andre van Meulebrouck $ From: titan!dorai@rice.edu (Dorai Sitaram) $ I agree with Andre that redefinition of system-defined functions could $ infringe upon the integrity of the system. In the old Chez, one needed $ to just type (set! cons 0) to have the whole session come tumbling $ down like a house of cards. But then, I don't think the guy who said $ "Eternal vigilance is the price of liberty" meant it as an argument $ _against_ liberty. $ $Okay. All the zeal and arguments shown for allowing the redefinition of car to $garbage sound pretty good. And, I'm NOT religious or dogmatic about not $allowing redefinition. (In fact, I'm religious about NOT being religious.) I $just enjoyed the feature in MacScheme because of all those sleepless nights that $it saved me from lots of potential inadvertent mistakes that could have made $already sleepless nights more sleepless. $ $Recall also, that MacScheme is a "micro" computer implementation. Perhaps what $might be nice for "PC"s might not be universally acceptable for "large scale" $systems. $ $I just have one question for anyone that's in favor of redefinition. $ $Are you saying you want redefinition-with-wild-abandon? I.e. do you NOT want $the system to warn you and ask you: "Are you sure?"? (Admittedly there could be $a hackerish thrill in living dangerously....safety is wimps. :-) $ $Or, do you want the system to ask you? (Which could be annoying, especially for $loading files.) $ $Or, do you want the system to warn you by default, unless you set a $global-dont-warn-me-about-redefinitions flag appropriately? (And if the latter, $are you prepared to have zillions of such global variables for similar things in $a BIG MOBY system?) $ $Just curious (And by NO means intending raging controvery and/or heated $religious debates. If I'm espousing unpopular ideas, well, I derived them from $reading Salmon Rushdie--so he's to blame!) $ $ =:0) Your concerns are perfectly legitimate: inadvertent or misguided redefinition can cause no end of trouble. However, an irreversible abolition of redefinition is not only aesthetically unpleasing to those with "hackerish thrills", it is _unnecessary_. "Redefinition with wild abandon" is not an untam(e)able animal at all. The system warnings you ask about are also unnecessary. Even for small pc implementations. Why? The reason is that you can devise your own security blanket (and sleep tight ;-}) with the macro system that comes with any Scheme. The declare-constant and undeclare-constant that I referred to in my earlier posting are now simple macros. One method would be: (defmacro (declare-constant x) `(put 'x 'constant t)) (defmacro (undeclare-constant x) `(put 'x 'constant nil)) (defmacro (setq x v) `(if (get 'x 'constant) (error "hey watch out, salman rushdie is out to set constants!") (set! x ,v))) The above is a very simple model (it hardly deserves the term "hack"!). You can of course make it more watertight by avoiding use of a global property table (make it local to the un/declare-constant and setq macros). The use of setq as the new set! can also be avoided, by lexically capturing the old set! (macro-)transform-function and replacing it with the modified version. All these are peripheral to understanding how to get a very satisfactory method of getting safe "constant" names in a system that provides redefinition. Anyway, the upshot of all this is that redefinition allows one to get the best of both worlds, while condemning the system to have immutable "constants" is an irreversible situation. Which would you choose? :-] --dorai ------------------------------------------------------------------------------ We must believe in free will. We have no choice. --Isaac Bashevis Singer ------------------------------------------------------------------------------  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 21 Apr 89 22:09:30 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 21 Apr 89 20:32:38 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: 21 Apr 89 19:02:10 GMT From: muller@bu-cs.bu.edu (Robert Muller) Organization: Boston U. Comp. Sci. Subject: Scheme for IBM PC compatible Message-Id: <29975@bu-cs.BU.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I'm looking for an interpreter or compiler for Scheme for an IBM PC. Does anyone out there know of a reasonably cheap (i.e., free) version? Thanks. Bob Muller  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 21 Apr 89 14:39:14 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 21 Apr 89 14:32:54 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: 21 Apr 89 07:57:25 GMT From: chaynes@iuvax.cs.indiana.edu (Chris Haynes) Organization: Indiana University Subject: Re: where define is legal Message-Id: References: <8904201554.AA13117@spt.entity.com> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Offhand, the following definition seems bogus: (define (foo bool) (if bool (define (result) #true) (define (result) #false)) (result)) And indeed, when I try to run this in MacScheme, I get an error message. I agree with the semantics, but I couldn't find anything in the R3 description of DEFINE which restricts where it may appear. Some people from non-scheme backgrounds might think programmatic DEFINEs perfectly reasonable, so it's probably worth mentioning the restriction in the language description. In R4 and the Standard draft, section 5.2 on definitions begins: Definitions are valid in some, but not all, contexts where expressions are allowed. They are valid only at the top level of a and at the beginning of a . This makes the above example syntactically bogus.  Received: from void.ai.mit.edu (TCP 2206400236) by MC.LCS.MIT.EDU 21 Apr 89 11:52:33 EDT Received: by void.ai.mit.edu (5.59/1.5) id AA00047; Fri, 21 Apr 89 10:57:49 EST Date: Fri, 21 Apr 89 10:57:49 EST From: jar@void.ai.mit.edu (Jonathan Rees) Message-Id: <8904211557.AA00047@void.ai.mit.edu> To: alms@spt.entity.com Cc: scheme@mc.lcs.mit.edu In-Reply-To: andrew lm shalit's message of 20 Apr 89 15:54:43 EDT (Thu) <8904201554.AA13117@spt.entity.com> Subject: where define is legal Reply-To: jar@zurich.ai.mit.edu Date: 20 Apr 89 15:54:43 EDT (Thu) From: alms@spt.entity.com (andrew lm shalit) (define (foo bool) (if bool (define (result) #true) (define (result) #false)) (result)) When I try to run this in MacScheme, I get an error message. I agree with the semantics, but I couldn't find anything in the R3 description of DEFINE which restricts where it may appear. There is nothing in section 5 that could allow one to deduce that definitions are permitted anywhere other than at top level or at the beginning of a lambda, let, etc. body. And the expression you have written isn't generated by the grammar of section 7.1, since (define ...) is never an . Some implementations do permit DEFINE forms in other places, but those implementations are extending the language.  Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 21 Apr 89 11:24:56 EDT Received: from MICKEY-MOUSE.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 251214; Fri 21-Apr-89 11:24:47 EDT Date: Fri, 21 Apr 89 11:24 EDT From: Nick Lewins Sender: SCHREQ@MC.LCS.MIT.EDU Subject: Question with binding To: scheme@MC.LCS.MIT.EDU Message-ID: <"19890421152425.8.schreq@MC"@MICKEY-MOUSE.LCS.MIT.EDU> Just to further the argument about redefining primative functions, TI's PC Scheme behaves like this: (define + (lambda (x y n) (modulo (+ x y) n))) (+ 1 2 3) ==> 0 (define blah (lambda () (+ 1 2 3))) (blah) ==> 6 I realise that + is treated specially, but this seems to be an undesirable (and inconsistant) way to handle primative function redefinition. What's more, the values of pcs-integrate-integrables and pcs-integrate-primatives don't seem to affect this behavior. Comments anyone? Nick. -- ------------------- nick@wacsvax.uwa.oz "Through Nambocour, and up the coast, Dept. of Computer Science the grass is greener, the girls are sweeter, University of Western Australia I did it all in the last ten summers." CRAWLEY 6009 - Cold Chisel, "Hound dog"