Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 15 Jan 88 18:03:39 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA22413; Fri, 15 Jan 88 11:45:20 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Jan 88 14:43:22 GMT From: ucsdhub!hp-sdd!ncr-sd!ncrlnk!ncrcam!ncrcpx!craig@sdcsvax.ucsd.edu (R. Craig Peterson) Organization: NCR E&M Cambridge, Ohio Subject: Re: SYSV Scheme was Re: Request for C-Scheme info Message-Id: <1821615@ncrcpx.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <3057@okstate.UUCP> norman@a.cs.okstate.edu writes: >I'm about to uucp C-Scheme from Ohio State, but before I do I would >like to know what I'm getting myself into. Some of the questions >going through my mind right now are > > - Is this thing SysV compatible? > - If it's not, is it easily portable (or has someone else done it :-)? > - Is it a decent implementation? > - Is it documented? > - Is it the greatest thing since sliced bread? > >If it is not sysV compatible I would appreciate hearing any war stories >about porting it. > >Please send mail to me as I'm sure that this has been discussed before. > >-- >Norman Graham >Oklahoma State University Internet: norman@a.cs.okstate.edu >Computing and Information Sciences UUCP: {cbosgd, ihnp4, >219 Mathematical Sciences Building rutgers}!okstate!norman >Stillwater, OK 74078-0599 I've uploaded the MIT-Scheme from OSU. I have a few System VR2 boxes here, and I've worked at porting it to SYSV. I've got it working just fine until part way through its conversion of some files from its non-machine-specific format to something for your machine; creating its runtime library stuff. It ends up getting a segmentation violation. I haven't had any chance to look at it for a couple of weeks as I'm very busy getting ready for a demo for another product here. If you'd like what I've done, I'd be glad to send it to you. I'm still looking for help!! Does anyone know of any known bugs. Here's the scenario: I am trying to get MIT Scheme up on an NCR Tower 32 - SYSVR2. I've got everything going along just fine until: Psbtobin /usr/craig/Scheme/runtime/screen.psb Psbtobin /usr/craig/Scheme/runtime/sdata.psb /usr/craig/Scheme/microcode/Psbtobin: Segmentation violation -- Core dumped *** Error code 1 `runtime/scheme.bin' not remade because of errors Not very nice. I looked into Psbtobin and found it to be quite involved. I wonder if you know of any bugs that may be obvious. An sdb run on the core shows: $ sdb Psbtobin ../runtime/core 0x80a in read_a_string:138: *string++ = ((char) read_a_char()); *w 133: To[STRING_LENGTH] = Make_Non_Pointer(TC_FIXNUM, len); 134: 135: /* Space */ 136: getc(Portable_File); 137: while (--len >= 0) 138: *string++ = ((char) read_a_char()); 139: *string = '\0'; 140: return (To + Pointer_Count); 141: } 142: *t read_a_string(To=0x8134,Slot=0x7228) [Psbtobin.c:138] Read_External(N=300,Table=0x7078,To=0x7528) [Psbtobin.c:410] do_it() [Psbtobin.c:750] Setup_Program(argc=1,argv=0xdffd84,Noptions=0,Options=0x5274) [Psbtobin.c:226] main(argc=1,argv=0xdffd84,14679436) [Psbtobin.c:851] *To/s '7^?J^Z_} *To/x 0x8134 *To/2x 0x8134 0x7228 *Pointer_Count/2x 0x37ff4b 0xdfc63b * BTW, adb agrees with sdb about the arguments: $ adb Psbtobin ../runtime/core ready $c Read_External+0x4e: read_a_string (0x8134, 0x7228) do_it+0x58: Read_External (0x12c, 0x7078, 0x7528) Setup_Program+0x76: do_it (0x5274) main+0x22: Setup_Program (0x1, 0xdffd84, 0x0, 0x5274) start%+0x2c: main (0x1) ???: start% (0x518f2eaf, 0x841ef, 0xc2f48) $q Can you be of any help? I would really like to get this stuff going. Thanks in advance. -- R. Craig Peterson "Next time someone asks you if you're a god ncrlnk!ncrcam!ncrcpx!craig say YES!!" N8INO Ghost Busters E Pluribus Unum (NSA stuff - terrorist, DES, cipher, secret, NRO, CIA)  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 13 Jan 88 20:19:17 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA03417; Wed, 13 Jan 88 16:49:01 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Jan 88 03:57:15 GMT From: pbox!okstate!norman@rutgers.edu (Norman Graham) Organization: Oklahoma State Univ., Stillwater Subject: Request for C-Scheme info Message-Id: <3057@okstate.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I'm about to uucp C-Scheme from Ohio State, but before I do I would like to know what I'm getting myself into. Some of the questions going through my mind right now are - Is this thing SysV compatible? - If it's not, is it easily portable (or has someone else done it :-)? - Is it a decent implementation? - Is it documented? - Is it the greatest thing since sliced bread? If it is not sysV compatible I would appreciate hearing any war stories about porting it. Please send mail to me as I'm sure that this has been discussed before. -- Norman Graham Oklahoma State University Internet: norman@a.cs.okstate.edu Computing and Information Sciences UUCP: {cbosgd, ihnp4, 219 Mathematical Sciences Building rutgers}!okstate!norman Stillwater, OK 74078-0599  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 12 Jan 88 22:46:00 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA06955; Tue, 12 Jan 88 19:22:51 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Jan 88 20:37:39 GMT From: gt-cmmsr!rr@gatech.edu (Richard Robison) Organization: Center for Man-Machine Systems Research - Ga Tech Subject: Scheme for Unix 4.3 BSD, Ultrix 2.0, or Sys V 3.0 ??? Message-Id: <31868@gt-cmmsr.GATECH.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Is Scheme available for Unix 4.3 BSD, Ultrix 2.0, or Sys V 3.0? Thanks. -Richard -- Richard Robison UUCP: rr@gt-cmmsr.UUCP (404-894-6221) ...!{allegra,hplabs,ihnp4,ulysses}!gatech!gt-cmmsr!rr INTERNET: rr@cmmsr.gatech.edu  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 11 Jan 88 16:48:44 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA03617; Mon, 11 Jan 88 13:36:23 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Jan 88 18:07:05 GMT From: ucsdhub!hp-sdd!ncr-sd!ncrlnk!ncrcam!ncrcpx!craig@sdcsvax.ucsd.edu (R. Craig Peterson) Organization: NCR E&M Cambridge, Ohio Subject: Problem with MIT-Scheme Message-Id: <1821614@ncrcpx.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I've tried to send this to MIT, but couldn't get through: To: info-cschme-request%oz@mc.lcs.mit.edu, INFO-CSCHEME%OZ@MC.LCS.MIT.EDU Subject: join scheme mailing list & problem I am trying to get MIT Scheme up on an NCR Tower 32 - SYSVR2. I've got everything going along just fine untill: Psbtobin /usr/craig/Scheme/runtime/screen.psb Psbtobin /usr/craig/Scheme/runtime/sdata.psb /usr/craig/Scheme/microcode/Psbtobin: Segmentation violation -- Core dumped *** Error code 1 `runtime/scheme.bin' not remade because of errors Not very nice. I looked into Psbtobin and found it to be quite involved. I wonder if you know of any bugs that may be obvious. An sdb run on the core shows: $ sdb Psbtobin ../runtime/core 0x80a in read_a_string:138: *string++ = ((char) read_a_char()); *w 133: To[STRING_LENGTH] = Make_Non_Pointer(TC_FIXNUM, len); 134: 135: /* Space */ 136: getc(Portable_File); 137: while (--len >= 0) 138: *string++ = ((char) read_a_char()); 139: *string = '\0'; 140: return (To + Pointer_Count); 141: } 142: *t read_a_string(To=0x8134,Slot=0x7228) [Psbtobin.c:138] Read_External(N=300,Table=0x7078,To=0x7528) [Psbtobin.c:410] do_it() [Psbtobin.c:750] Setup_Program(argc=1,argv=0xdffd84,Noptions=0,Options=0x5274) [Psbtobin.c:226] main(argc=1,argv=0xdffd84,14679436) [Psbtobin.c:851] *To/s '7^?J^Z_} *To/x 0x8134 *To/2x 0x8134 0x7228 *Pointer_Count/2x 0x37ff4b 0xdfc63b * BTW, adb agrees with sdb about the arguments: $ adb Psbtobin ../runtime/core ready $c Read_External+0x4e: read_a_string (0x8134, 0x7228) do_it+0x58: Read_External (0x12c, 0x7078, 0x7528) Setup_Program+0x76: do_it (0x5274) main+0x22: Setup_Program (0x1, 0xdffd84, 0x0, 0x5274) start%+0x2c: main (0x1) ???: start% (0x518f2eaf, 0x841ef, 0xc2f48) $q Can you be of any help? I would really like to get this stuff going. Thanks in advance. -- R. Craig Peterson "Next time someone asks you if you're a god ncrlnk!ncrcam!ncrcpx!craig say YES!!" N8INO Ghost Busters E Pluribus Unum (NSA stuff - terrorist, DES, cipher, secret, NRO, CIA)  Received: from G.BBN.COM (TCP 1000400022) by MC.LCS.MIT.EDU 11 Jan 88 08:17:00 EST Date: Mon 11 Jan 88 08:15:32-EST From: AHAAS@G.BBN.COM Subject: leaving To: scheme@MC.LCS.MIT.EDU Please take me off the list. -------  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 8 Jan 88 19:56:27 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA20886; Fri, 8 Jan 88 15:28:24 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Jan 88 21:45:30 GMT From: wpd@athena.mit.edu (William P Doyle) Organization: Massachusetts Institute of Technology Subject: Re: Scheme for the Amiga Message-Id: <2194@bloom-beacon.MIT.EDU> References: <518@acf3.NYU.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu In article <518@acf3.NYU.EDU> goldberg@acf3.nyu.edu (Benjamin Goldberg) writes: >Does anyone know of a Scheme implementation for the Amiga? I have implemented scheme 6.1 on my Amiga. I'll tell you, it's not an easy thing to do. First of all, there is no way CScheme will work on a machine with only 0.5M of RAM. I have got it working with 2.5M, but it really wants 4M, heavy sigh... Also, if you want to work on implementing it, you will need a hard disk. But the important thing is, it does exist and is alive. I am currently trying to work on the interrupt scheme (sorry, no pun intended) before I am happy with it. ______________________________________________ | | | Patrick Doyle wpd@ATHENA.MIT.EDU |  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 7 Jan 88 21:43:40 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA22119; Thu, 7 Jan 88 12:09:07 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Jan 88 16:17:58 GMT From: goldberg@acf3.nyu.edu (Benjamin Goldberg) Organization: New York Univsersity Subject: Scheme for the Amiga Message-Id: <518@acf3.NYU.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Does anyone know of a Scheme implementation for the Amiga? -Ben Goldberg  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 7 Jan 88 20:09:04 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA26851; Thu, 7 Jan 88 16:38:45 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Jan 88 17:11:54 GMT From: marge.math.binghamton.edu!sullivan@bingvaxu.cc.binghamton.edu (fred sullivan) Organization: SUNY Binghamton, NY Subject: Re: Scoops ? Message-Id: <759@bingvaxu.cc.binghamton.edu> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I also need scoops for c-scheme. Is it available? Thanks, Fred Sullivan Department of Mathematical Sciences State University of New York at Binghamton Binghamton, New York 13903 Email: sullivan@marge.math.binghamton.edu  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 7 Jan 88 08:01:45 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Thu, 07 Jan 88 08:01:02 EST Received: from SCF1.FNDP.AC.BE by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 8229; Thu, 07 Jan 88 08:00:59 EST Received: by BNANDP11 (Mailer X1.25) id 5533; Thu, 07 Jan 88 13:41:10 +01 Date: Thu, 07 Jan 88 13:36:44 +01 From: Michel Debar Subject: Scoops ? To: SCHEME@MC.LCS.MIT.EDU If you have an implementation of Scoops for either C Scheme (on a vax VMS), or MacScheme (on a Macintosh), please let me know. Better yet, if you can do it, mail me the Scheme code. Thanks a lot. To be clear, I am looking for both implementations, not just any one, but evidently, either one is much better than none... Michel Debar - Fndp Computing Centre - Rue Grandgagnage 21, 5000 namur Belgium - Tel + 32 (81) 22 06 31 mdebar%bnandp11.bitnet@cunyvm.cuny.edu  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 6 Jan 88 16:21:36 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA25879; Wed, 6 Jan 88 12:57:27 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Jan 88 16:29:29 GMT From: siemens!edsel!biggers@princeton.edu (Mark Biggers) Organization: Siemens RTL, Princeton, NJ Subject: getting C-Scheme running on Sun-3 / want Scoops info Message-Id: <374@siemens.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Hello, I am sure this has been requested before (maybe it should be with the C-Scheme distribution), but has anyone gotten C-Scheme fully installed on SunOS v3.4? I think the installation went fine until the undump attempt. Also, would like to get SCOOPS source and info on SCOOPS; any pointers to this appreciated! mark ------------------------------------------------------------------------- Mark Biggers Siemens Research & Technology Laboratories 105 College Road East Princeton, NJ 08540 UUCP: {almost anywhere}!princeton!siemens!biggers ARPA: biggers%siemens@princeton.edu -------------------------------------------------------------------------  Received: from csd16.nyu.edu (TCP 20036500057) by MC.LCS.MIT.EDU 2 Jan 88 15:46:50 EST Received: by csd16.nyu.edu (3.2/25-eef) id AA17960; Sat, 2 Jan 88 15:48:48 EST Date: Sat, 2 Jan 88 15:48:48 EST From: Lars Ericson Message-Id: <8801022048.AA17960@csd16.nyu.edu> To: scheme@mc.lcs.mit.edu Subject: Optimizing tail-recursive operations using jumps Consider the following calling pattern: ;0 Calling /' with arguments (> >>>) ; 1 Calling // with arguments (> >>>) ; 2 Calling /' with arguments ( >>) ; 3 Calling // with arguments ( >>) ; 4 Calling /' with arguments (1 >) ; 5 Calling // with arguments ( >) ; 5 Returned from // with values (() / (>)) ; 4 Returned from /' with values (() / (>)) ; 3 Returned from // with values (() / (>)) ; 2 Returned from /' with values (() / (>)) ; 1 Returned from // with values (() / (>)) ;0 Returned from /' with values (() / (>)) /' is a procedure and // is an operation. Both are compiled, one calls the other. It is apparent that every call is tail-recursive, since the results on the way "back up" are unmodified. Why not use continuations somehow to have a "REWRITE-CALL", similar to a plain old JUMP, which passes arguments to a subprocedure, overwriting the argument space on the stack for the calling procedure, such that when the subprocedure returns, it returns to the caller of the caller? Like DEFINE-INTEGRABLE, REWRITE-CALL would be an optimization that the user applies intentionally when it is clear that the call is tail-recursive. This seems like it would be pretty easy to implement, both for interpreted and compiled code, in terms of continuations. -- Lars Ericson  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 31 Dec 87 13:07:32 EST Date: Thu, 31 Dec 87 13:05:50 EST From: Jonathan A Rees Subject: Question about load. To: net%TUB.BITNET@MITVMA.MIT.EDU cc: scheme@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 29 Dec 87 14:40:01 +0100 from Oliver Laumann Message-ID: <305448.871231.JAR@AI.AI.MIT.EDU> Date: Tue, 29 Dec 87 14:40:01 +0100 From: Oliver Laumann The R3RS does not specify in which environment definitions loaded from a file will be bound. Consider the following function: (define (f) (load "foo")) where "foo" contains the definition (define x 9). When "f" is invoked, is the variable "x" put into the environment frame created by the call to "f", that is, is it made a local variable, or is it entered into the environment frame in which "f" has been defined? I personally would expect the former, but this would make it impossible to write a function similar to "require" supported by Gnu-Emacs. C-Scheme seems to load definitions into the environment employed by the read-eval-print loop, which is more useful (but less obvious). Scheme is lexically scoped, and LOAD is a procedure, therefore there's no way that LOAD could find out the environment from which it was called. Thus it has to get an environment from somewhere else, e.g. the current global state of the read-eval-print loop. C Scheme and T both have this semantics. What is your opinion about this and how is it handled by existing interpreters? In interpreters that support environments as first-class objects (like C-Scheme), shouldn't "load" receive a second argument -- the environment in which the contents of the file will be evaluated? C-Scheme and T both do indeed accept an environment as an optional second argument to LOAD.  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 31 Dec 87 04:47:46 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA23229; Thu, 31 Dec 87 01:39:47 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 Dec 87 21:26:08 GMT From: ucsdhub!hp-sdd!ncr-sd!ncrlnk!ncrcam!ncrcpx!craig@sdcsvax.ucsd.edu (R. Craig Peterson) Organization: NCR E&M, Cambridge OH Subject: problem bringing up Scheme 6.1 Message-Id: <1821610@ncrcpx.UUCP> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu I've been able to get Scheme to link under System V Release 2 on an NCR Tower 32. This is 68020-based. I've had to modify the C preprocessor (may the source be with you), and have had to make some minor additions/changes to unix.c, config.h - the usual things from what I can tell. I'm starting to get excited. Maybe it will work, eh? (Canadian accent showing...) But No... Here's what happened in the next step: cd /usr/craig/Scheme/ make runtime/scheme.bin cd runtime; rm -f *.bin etc/make_bin Psbtobin /usr/craig/Scheme/runtime/Sgraph.psb : : (Additional stuff deleted) : Psbtobin /usr/craig/Scheme/runtime/sdata.psb /usr/craig/Scheme/microcode/Psbtobin: Segmentation violation -- Core dumped *** Error code 1 Stop. Compilation exited abnormally with code 1 at Wed Dec 30 16:12:06 Gag, gag, gag. Looking into the source code there's nothing obvious. Could some kind soul out there point me in the right direction. I've found at least one definate bug in the distributed code. Maybe there's another??? I would really LOVE to get this stuff working. Once working I hope to modify GNU cpp so that others can use it on SYSVR2. (I've already tried, but GNU cpp gets VERY confused trying to play with all the defines - even more than USG cpp. Just need more time.) Any help offers??? Please??? -- R. Craig Peterson "Next time someone asks you if you're a god ncrlnk!ncrcam!ncrcpx!craig say YES!!" N8INO Ghost Busters E Pluribus Unum (NSA stuff - terrorist, DES, cipher, secret, NRO, CIA)  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 27 Dec 87 13:04:45 EST Date: Sun, 27 Dec 87 13:02:57 EST From: Jonathan A Rees Subject: skim (a low fat implementation of Scheme) To: scheme@MC.LCS.MIT.EDU Message-ID: <304152.871227.JAR@AI.AI.MIT.EDU> Date: Thu, 24 Dec 87 11:10:47 +0100 From: harvard!ut-sally!uunet!mcvax!litp!ald at bbn.com To: jar at ai.ai.mit.edu Re: Scheme on CMS? Organization: L.I.T.P, Universite P7, PARIS Return-Receipt-To: uunet!mcvax!inria!litp!ald@RUTGERS.EDU In article <302853.871222.JAR@AI.AI.MIT.EDU> you write: > >If you know of any available implementations that are missing from the >list, or if you discover any inaccurate information, please let me know. There is an implementation of Scheme, that i believe is not currently registered: Name: skim (a low fat implementation of Scheme) Authors: A. Deutsch, R. Dumeur, C. Consel, J.D. Fekete. Runs-on: Sun[23], Vax, Orion under BSD Unix. Has: An interpreter and a compiler (vax only for now). Features: - R3RS compatibility (but misses complex, bignums and ratios); - extensible type system and operations; - stop/copy gc; - scode based interpreter. Availability: - the system has been registered; - binaries are available (we do not plan to distribute sources now). Performance: - the interpreter is quite fast (5 times faster that MIT-scheme). - the compiler is not an optimizing compiler. Contact: - ...mcvax!inria!litp!{ald|chac|jdf|red} Best regards, Alain Deutsch.  Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 24 Dec 87 14:02:10 EST Date: Thu, 24 Dec 87 14:00:52 est From: R. Kent Dybvig To: scheme@mc.lcs.mit.edu Subject: Re: Why are case implementations so slow? One reason is that the "natural" expansion of (case e0 ((k1 k2 ...) e1 e2 ...) ...) is (let ([tag e0]) (cond ((memv? tag '(k1 k2 ...)) e1 e2 ...) ...)) where "tag" does not occur free in e1 e2 .... This is surely slower than using the "equivalent" eq? tests when there is only one key per clause and that key is a symbol. The Chez Scheme expander looks for these special cases and expands them "appropriately", so you should find case as fast as cond. You could write your own case macro that does the same thing. However, it is not practical to turn case into a computed goto unless there are several keys within a relatively small range of fixnums or characters. It could be beneficial, certainly, but Chez Scheme doesn't bother, and I suspect that most other implementations don't either. R. Kent Dybvig | arpa: dyb@iuvax.cs.indiana.edu Computer Science Department | csnet: dyb@indiana Indiana University | usenet: ...!ihnp4!iuvax!dyb Bloomington, IN 47405 | phone: 812/335-6486  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 24 Dec 87 01:15:57 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA00126; Wed, 23 Dec 87 21:22:12 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Dec 87 07:55:42 GMT From: jh@ohio-state.arpa (Juha Hein{nen) Organization: Tampere University of Technology, Finland Subject: Why are case implementations so slow? Message-Id: <2225@korppi.tut.fi> References: <5821.8712220254@aiva.ed.ac.uk> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Dispatching of a method is straighforwardly done using a case expression on the operation symbol. I have tested the case speed of three Scheme implementations (CScheme, MacScheme and PC Scheme) and in all of them cond is faster than case! Since the case labels have to be symbols, shouldn't the case expression be faster than the corresponding cond expression? Is there some reason why Scheme's case can't be implemted using a computed goto like in ordinaty programming languages? -- Juha Heinanen Tampere Univ. of Technology Finland jh@tut.fi (Internet), tut!jh (UUCP)  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 22 Dec 87 16:16:44 EST Received: from relay2.cs.net by RELAY.CS.NET id ab12439; 22 Dec 87 15:52 EST Received: from ubc by RELAY.CS.NET id ab15820; 22 Dec 87 15:38 EST Received: by ean.ubc.ca id AA27211; Tue, 22 Dec 87 10:21:35 pst Date: 22 Dec 87 13:21 -0500 From: Marc Feeley To: scheme@mc.lcs.mit.edu MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET Message-Id: <90*feeley@iro.udem.cdn> Subject: Small Scheme compiler in Prolog... Hi everyone, I recently wrote a Scheme compiler in Prolog (for a logic programming course). The compiler handles almost all of scheme's special forms (only backquote notation, => syntax in conds and rest arguments are not implemented). It generates native-code for SUNs, has only a few primitive procedures implemented and no garbage-collector. The code generated is fairly efficient (tak takes 1 sec on a SUN3). Those who are interested in having the source please send me a message directly (the compiler is 45Kbytes and is written in Quintus prolog but should be easily ported to other prologs). If there are enough requests, I'll write a couple pages of doc (presently you have to read the scarce comments in the code) and maybe I'll add some more primitives and who knows... maybe a GC. Don't expect any replies before the middle of January... Happy holidays! Send requests to: feeley@brandeis.csnet (my current address at Brandeis University) feeley%grafik.iro.udem.cdn@ubc.csnet (my `home' address at the University of Montreal).  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 22 Dec 87 13:00:52 EST Date: Tue, 22 Dec 87 12:58:31 EST From: Jonathan A Rees Subject: Scheme on CMS? To: ihnp4!alberta!calgary!jameson@UCBVAX.BERKELEY.EDU cc: scheme@MC.LCS.MIT.EDU In-reply-to: Msg of 21 Dec 87 17:43:41 GMT from ihnp4!alberta!calgary!jameson at ucbvax.Berkeley.EDU (Kevin Jameson) Message-ID: <302853.871222.JAR@AI.AI.MIT.EDU> Date: 21 Dec 87 17:43:41 GMT From: ihnp4!alberta!calgary!jameson at ucbvax.Berkeley.EDU (Kevin Jameson) Several of the previous transactions appear to be seeking info on Scheme implementations (and source) for various purposes. There appear to be implementations of Scheme in Common Lisp and C, and maybe Common Lisp implementations in Scheme, Scoops in Scheme, etc. etc. I am also looking for an implementation (for a pc). Could someone in the know please summarize what implementations are available, for what machines, and if source is available at what cost? I periodically announce that I have a list of implementations, which I'll send to anyone requesting it. (Send your request to scheme-request@mc.lcs.mit.edu.) It's not quite up to date, but it's close. It's sort of big so I'd rather not post it to the mailing list. People with Internet FTP access can get the list from MC.LCS.MIT.EDU:LSPMAI;SCHEME IMPLS If you know of any available implementations that are missing from the list, or if you discover any inaccurate information, please let me know.  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 22 Dec 87 09:13:07 EST Received: from relay2.cs.net by RELAY.CS.NET id aa07692; 22 Dec 87 9:02 EST Received: from tektronix.tek.com by RELAY.CS.NET id bc13377; 22 Dec 87 8:49 EST Received: by tektronix.TEK.COM (5.51/6.24) id AA23859; Mon, 21 Dec 87 18:22:04 PST Received: by tekchips.TEK.COM (5.51/6.24) id AA11558; Mon, 21 Dec 87 18:20:35 PST Date: Mon, 21 Dec 87 18:20:35 PST From: Will Clinger Message-Id: <8712220220.AA11558@tekchips.TEK.COM> To: scheme@mc.lcs.mit.edu Subject: Re: Byte code speed David Bartley of TI wrote concerning PC Scheme: Our emulator does no consing on its own except to extend the stack when it overflows. In the sense intended by David this is true of MacScheme 1.5 also, but it depends on what is meant by "on its own". Besides the byte codes that obviously allocate storage, such as cons and make-vector, there are byte codes such as + that allocate storage on occasion. Of more interest are the byte codes that create closures, that allocate lists for rest arguments, and that allocate heap storage for variables that are closed over by lambda expressions (unless this is done by the byte codes that create closures). Clearly both PC Scheme and MacScheme have such byte codes. I think the French wisdom is that fast interpreters do not allocate garbage-collected storage for argument lists, implicit temporaries, or continuations. This is true of PC Scheme and MacScheme 1.5, but older versions of MacScheme were significantly slower than Version 1.5 in part because they allocated continuations on the heap. It's interesting that the original design back in 1983 called for stack-allocated continuations, but the heap-allocated continuations that were used as a temporary measure during the bootstrap ran fast enough (because of a fairly fast garbage collector) that there wasn't much pressure to change it until the native code compiler was added this spring (by Eric Ost and Anne Hartheimer). Peace, Will Clinger  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 22 Dec 87 09:12:27 EST Received: from relay2.cs.net by RELAY.CS.NET id aa07689; 22 Dec 87 9:02 EST Received: from tektronix.tek.com by RELAY.CS.NET id ax13377; 22 Dec 87 8:48 EST Received: by tektronix.TEK.COM (5.51/6.24) id AA23301; Mon, 21 Dec 87 17:50:40 PST Received: by tekchips.TEK.COM (5.51/6.24) id AA11388; Mon, 21 Dec 87 17:49:12 PST Date: Mon, 21 Dec 87 17:49:12 PST From: Will Clinger Message-Id: <8712220149.AA11388@tekchips.TEK.COM> To: scheme@mc.lcs.mit.edu Subject: Re: Speed (of byte code interpreters) The byte code interpreter and compiler used in MacScheme are described in not much detail in a paper by Will Clinger in the 1984 Lisp and FP Symposium proceedings, "The Scheme 311 compiler: An exercise in denotational semantics." More detail can be found in Appendix D of the current MacScheme and MacScheme+Toolsmith manuals. The purpose of this appendix is to tell how to write a machine code procedure that can be called from Scheme, but in doing so it describes some of the data representations, register conventions, calling conventions, and byte codes. Along with the paper cited by Jonathan, this is everything that has been published about the implementation of MacScheme. Peace, Will Clinger  Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 22 Dec 87 02:15:36 EST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA13746; Mon, 21 Dec 87 22:49:37 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Dec 87 17:43:41 GMT From: ihnp4!alberta!calgary!jameson@ucbvax.Berkeley.EDU (Kevin Jameson) Organization: U. of Calgary, Calgary, Ab. Subject: Re: Scheme on CMS? Message-Id: <1267@vaxb.calgary.UUCP> References: <8712202027.AA12866@ucbvax.Berkeley.EDU> Sender: scheme-request@mc.lcs.mit.edu To: scheme@mc.lcs.mit.edu Several of the previous transactions appear to be seeking info on Scheme implementations (and source) for various purposes. There appear to be implementations of Scheme in Common Lisp and C, and maybe Common Lisp implementations in Scheme, Scoops in Scheme, etc. etc. I am also looking for an implementation (for a pc). Could someone in the know please summarize what implementations are available, for what machines, and if source is available at what cost? I'd be happy to write the summary if someone will send me the info, but it might be faster if somone more knowledgeable posted it directly. As a fail safe, I'll summarize and post whatever I receive, whether or not a knowledgeable sumary is posted. Kevin ...{ihnp4,ubcvision}!alberta!calgary!vaxb!jameson  Received: from NSS.Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 21 Dec 87 22:09:19 EST Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa01076; 22 Dec 87 3:04 GMT From: Jeff Dalton Date: Tue, 22 Dec 87 02:54:02 gmt Message-Id: <5821.8712220254@aiva.ed.ac.uk> To: adams <@relay.cs.net:adams@tekchips.tek.com>, scheme@mc.lcs.mit.edu Subject: Re: Object oriented programming in Scheme > Date: Mon, 21 Dec 87 12:15:32 PST > From: Norman Adams > We have been experimenting with an object system based on T's. [...] > For those not familiar with the T object system: I eschew zealotry, but I > find the T approach (roughly closures + dispatch) more in the Scheme spirit > than anything in the Flavors family. Our changes to the T object system > are intended to make reasonably fast implementions possible. I would > consider an implementation reasonably fast if time to send a message, do > the method lookup, and pass control to the method, is less than the cost of > 2 procedure calls in the worst case. This is interesting. If you don't mind saying something about your implementation short of posting the source, I'd like to hear more. It seems that you'll always have to do two procedure calls: one for the operation and another for the method; three if you must also call a handler that returns the method. And that still leaves the method lookup itself. Flavors are about the same: one for the generic function, one for the method, and about a call's worth (let's say) for looking up the method. So, generic operations should have 2-3 times the overhead of an equivalent function. But... I recently implemented a T-like system in a completely straightforward way in Common Lisp. I expected an operation to take 3 calls (operation, handler, method), and timing with KCL on a VAX more or less confirmed this. Here procedure calls were pretty expensive because they used CALLS. I reasoned that they might be less dominant on a Sun, so I tried again on a 3/260. To make this even less meaningful, I used Sun Common Lisp this time. Calling a (generic) operation on an object with just one method that returned the square of its arguement (this is what I was doing) took 1.9 times longer then an equivalent function when both were adjusted to take out the time required to square in-line. The total time (10000 iterations) was still pretty small, though, so the results may not be very meaningful. Why was the factor 1.9 instead of, say, 3? I don't know. In any case, it's difficult to implement T objects exactly. T objects can be used as functions, and it's difficult to get most Lisp systems to accept new kinds of function objects. So, since I couldn't do (OBJECT fn . clauses) I just implemented (OBJECT . clauses) I also had operation lookup based on the name of the operation. That is, the dispatch function had (cond ((eq request 'op)) ...) instead of (cond ((eq request op)) ...). There's a certain elegance to this system that I didn't fully appreciate until I'd used it for a while. Now I even miss the objects-as-functions. Nonetheless, it is somewhat inflexible. You can't add new methods incrementally (they must all be there in the OBJECT body), for example. Jeff Dalton, JANET: J.Dalton@uk.ac.ed AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 21 Dec 87 20:34:24 EST Date: Mon, 21 Dec 87 20:31:47 EST From: Jonathan A Rees Subject: Quasiquotation To: Pavel.pa@XEROX.COM cc: Scheme@MC.LCS.MIT.EDU In-reply-to: Msg of Mon 21 Dec 87 09:44:58 PST from Pavel.pa at Xerox.COM Message-ID: <302612.871221.JAR@AI.AI.MIT.EDU> Date: Mon, 21 Dec 87 09:44:58 PST From: Pavel.pa at Xerox.COM ::= ' Shouldn't this be ::= '