gjc@mitech.COM (08/03/90)
ted@opus writes: >... except for the fact that siod is not scheme. all kinds of things >are missing. >better to grab elk or fool's lisp if you want small ones, scheme->c or >t if you want compiled programs. Maybe it is possible to have an intelligent discussion about this. Q: What is Scheme? What makes something scheme? What is "all kinds of things are missing" from siod? For what purposes would elk or fool's lisp be better (than siod)? How about some concrete examples: Like, here is a type of program you can run in *x* but not in siod. True, times are changing. But how? Is it not true that *today* it is extremely important to have a straightforward interface to code written in C? (That is, to respect the C calling sequence by making the Lisp calling sequence the *same* as the C calling sequence/conventions). -gjc
carroll@udel.edu (Mark Carroll <MC>) (08/04/90)
In article <9008031618.AA02461@mailhost.samsung.com> gjc@mitech.com writes: ]Maybe it is possible to have an intelligent discussion about this. ]Q: What is Scheme? ] ]What makes something scheme? Compliance with the specification of the language Scheme - R3RS, or soon R4RS. ]What is "all kinds of things are missing" from siod? ] Continuations, bignums, all sorts of other things. ]For what purposes would elk or fool's lisp be better (than siod)? ] Anything which makes use of real first class continuations, etc. <MC> -- |Mark Craig Carroll: <MC> |"We the people want it straight for a change; |Soon-to-be Grad Student at| cos we the people are getting tired of your games; |University of Delaware | If you insult us with cheap propaganda; |carroll@dewey.udel.edu | We'll elect a precedent to a state of mind" -Fish
oz@sprawl.yorku.ca (Ozan Yigit) (08/05/90)
In article <9008031618.AA02461@mailhost.samsung.com>, gjc@mitech.COM writes: |> What makes something scheme? |> What is "all kinds of things are missing" from siod? Surely you forgot your smiley, or lost your R3.99RS or both. ;-) |> ... it is extremely important to have a straightforward interface to |> code written in C? ... What does this have anything to do with a complete/proper implementation of the language? oz
rich@Rice.edu (Carey Richard Murphey) (08/07/90)
In article <1990Aug5.175401@sprawl.yorku.ca> oz@sprawl.yorku.ca (Ozan Yigit) writes: ]In article <9008031618.AA02461@mailhost.samsung.com>, gjc@mitech.COM writes: ]|> ... it is extremely important to have a straightforward interface to ]|> code written in C? ... ]What does this have anything to do with a complete/proper implementation ]of the language? ]oz Hm... after watching this thread for the last week, I've got a question. Are there any other small, redistributable scheme interpreters written in C which have a straightforward interface to code written in C? To be specific, are there any others better for the purpose of adding a scheme subset as an extension language to small (1000 line) C language programs. Are there redistributable scheme interpreters which run on both unix and *ms-dos*? I'm curious to know what else is out there that's a minimal implementation, easy to modify, port, interface with other C code, and redistribute. As a scheme novice, I am easily overwhelmed by the size of elk and even Jason Coughlin's interpreter, and I wouldn't even think about trying to port them to ms-dos. Thanks! Rich
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (08/08/90)
In article <RICH.90Aug7015042@uncle-bens.Rice.edu> Rich Murphey <Rich@Rice.edu> writes: >Are there any other small, redistributable scheme interpreters written >in C which have a straightforward interface to code written in C? To >be specific, are there any others better for the purpose of adding a >scheme subset as an extension language to small (1000 line) C language >programs. Are there redistributable scheme interpreters which run on >both unix and *ms-dos*? > >I'm curious to know what else is out there that's a minimal >implementation, easy to modify, port, interface with other C code, and >redistribute. As a scheme novice, I am easily overwhelmed by the size >of elk and even Jason Coughlin's interpreter, and I wouldn't even >think about trying to port them to ms-dos. Thanks! Rich There's Xscheme -- see comp.lang.lisp.x for discussions of it. In particular, xscheme (and it's older brother xlisp) are designed to be small & portable enough to run on MS-DOS machines (and amigas, macs, etc) W/r/t interfacing to other C code, I use Xlisp as a user-interface&application extension language for OSF/Motif-based applications (WINTERP) that are written in a hybrid of C and interpreted Lisp. I find it relatively easy to interface between C and Xlisp. Xscheme is quite similar to xlisp and allows for the same kind of hybrid Lisp+Scheme programming that I do in WINTERP. I very much doubt you are going to see a decent scheme implementation that is significantly smaller than the size of xscheme, or Elk. Once they get "too minimal" you're going to have to go about kludging up pieces of the necessary functionality every time you try to do something. ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *
oz@yunexus.yorku.ca (Ozan Yigit) (08/09/90)
In article <RICH.90Aug7015042@uncle-bens.Rice.edu> Rich Murphey <Rich@Rice.edu> writes: >I'm curious to know what else is out there that's a minimal >implementation, easy to modify, port, interface with other C code, and >redistribute. A scheme interpreter, tentatively called "psi" (portable scheme interpreter) is currently alpha testing. It has been ported to macs, pc's under ms-dos, and various un*x systems of course. Psi is intended either as a stand-alone interpreter, or as an extension interpreter. It is easy to understand, modify and port. It is small, and fast. It is R3.99RS/IEEE compliant [it passes a large validation suite written to test such compliance]. It supports call/cc portably, because the whole thing is based on compiler/vm approach. It supports macros, quasiquotes, string ports, etc. I will post more details when psi is ready for beta distribution, sometime late this month or early september. oz --- First learn your horn and all the theory. Internet: oz@nexus.yorku.ca Next develop a style. Then forget all that uucp: utzoo/utai!yunexus!oz and just play. Charlie Parker [?] York U. CCS: (416) 736 5257
net@tub.UUCP (Oliver Laumann) (08/09/90)
In article <RICH.90Aug7015042@uncle-bens.Rice.edu> Rich Murphey <Rich@Rice.edu> writes: > > I'm curious to know what else is out there that's a minimal > implementation, easy to modify, port, interface with other C code, and > redistribute. As a scheme novice, I am easily overwhelmed by the size > of elk Speaking about Elk, do you really think that 8000 lines of C code is large for a Scheme implementation that supports bignums, call/cc, dynamic loading of .o-files and "dump"? Any implementation I have seen so far that claims to be "small" (SIOD, XScheme, ...) supports at most one of these. Note that the size of Elk's bignum implementation alone makes up 10 percent of the entire size. > and even Jason Coughlin's interpreter, and I wouldn't even > think about trying to port them to ms-dos. Guess what I'm doing right now. Our local DOS guru says "No problem!", but I'm not so sure... :-) Regards, -- Oliver Laumann, Technical University of Berlin, Germany. pyramid!tub!net net@TUB.BITNET net@tub.cs.tu-berlin.de
peter@ficc.ferranti.com (Peter da Silva) (08/09/90)
In article <5752@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes: > In particular, xscheme (and it's older brother xlisp) are designed to be > small & portable enough to run on MS-DOS machines (and amigas, macs, etc) In a multitasking system with limited resources, too many copies of Xlisp hanging around together are going to eat your lunch. And, unlike TCL, it's not really well designed as a shared library. (still looking for a reasonably small, portable, and fast extension language) -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
net@tub.UUCP (Oliver Laumann) (08/10/90)
In article <J:25_41@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > > (still looking for a reasonably small, portable, and fast extension language) I'm wondering what exactly you mean by "reasonably small" in this context. Less than 64 KBytes? Less than 1 MByte? Smaller than MIT-Scheme :-)? I'm asking because I have read this Scheme-implementations-must-be-small and XYZ-Scheme-is-too-large argument over and over again. Please define a predicate is-small(X) that we can apply to the existing implementations to be able to determine whether they can be considered "small". Thanks, -- Oliver Laumann net@TUB.BITNET net@tub.cs.tu-berlin.de net@tub.UUCP
thompson@CEBAF4.CEBAF.GOV (Al Thompson) (08/10/90)
Are there sources around for system programmer/hacker types to fool around with? I'm asking in the hope of finding a model I can based a small-scheme on.
roger@kymijoki.wrs.com (Roger Rohrbach) (08/11/90)
George Carrette's SIOD is what you want. Dunno why he didn't post the following to comp.lang.scheme... --- > From: gjc@paradigm.com > Newsgroups: comp.lang.lisp > Subject: new version of SIOD (Scheme in one Day) available > Date: 14 Jun 90 14:24:51 GMT > Organization: Paradigm Associates Inc, Cambridge MA SIOD version 2.4 is now available. What is SIOD? It is an extremely small scheme implementation in C arranged as set of subroutines that can be called from any main program for the purpose of introducing an interpreted extension language. How small is it? Compiling using the VAX/VMS C compiler results in a total of 16333 bytes of executable code. What features? * Lisp calls C and C calls lisp transparently * no hassle in C coded functions due to GC or EVAL considerations. * ability to hook into the read-eval-print loop without modifying the code. * ability to extend the datatypes without modifying the code. * mark-and-sweep or stop-and-copy GC selectable at runtime. * readmacros * macros * backquote (quasi-quote) * optionally loadable pratt (infix-language) parser Platforms? * VAX/VMS * VAX UNIX * SUN-3 * SUN-4 * AMIGA * MACINTOSH * MIPS * CRAY Availability? Anonymous FTP to BU.EDU (128.197.2.6), cd to users/gjc and get siod-v2.4-shar Copyright? Has MIT/X-WINDOWS style copyright notice. Free for any purpose, including commercial use. Roger Rohrbach sun!wrs!roger roger@wrs.com - Eddie sez: ----------------------------------------------- (c) 1986, 1990 -. | {o >o | | \ -) "I was an infinitely hot and dense dot." |
oz@yunexus.yorku.ca (Ozan Yigit) (08/11/90)
In article <1459@tub.UUCP> net@tub.UUCP (Oliver Laumann) writes: >I'm asking because I have read this Scheme-implementations-must-be-small >and XYZ-Scheme-is-too-large argument over and over again. This is a strawman argument. There is no "must", and there is also nothing wrong with people asking for smaller interpreters. Some people also use "small" to mean "free of fat and feeeetures", "well thought out to conserve code/data space", "proper subset". I wonder what that XYZ is. oz
colas@avahi.inria.fr (Colas Nahaboo) (08/11/90)
In article <1457@tub.UUCP>, net@tub.UUCP (Oliver Laumann) writes: > In article <RICH.90Aug7015042@uncle-bens.Rice.edu> Rich Murphey <Rich@Rice.edu> writes: > > > > I'm curious to know what else is out there that's a minimal > > implementation, easy to modify, port, interface with other C code, and > > redistribute. As a scheme novice, I am easily overwhelmed by the size > > of elk > > Speaking about Elk, do you really think that 8000 lines of C code is > large for a Scheme implementation that supports bignums, call/cc, > dynamic loading of .o-files and "dump"? Size of code is not very relevant... the allocated size is MUCH more important, since it can't be shared. Then, when I do a ps -l and I see that elk takes 1600K of memory whereas xscheme only 300, for me xscheme is smaller. Of course, real dump/undump capabilities will make this size a "text" (sharable) size, and will change the picture... Is this the case with Elk? -- Colas Nahaboo, Bull Research France -- Koala Project -- GWM X11 Window Manager colas@avahi.inria.fr Phone: (33) 93.65.77.70, Fax: (33) 93 65 77 66 INRIA - Sophia Antipolis, 2004, rte des Lucioles, 06565 Valbonne Cedex, FRANCE
net@tub.UUCP (Oliver Laumann) (08/11/90)
In article <1990Aug10.133859@avahi.inria.fr> colas@avahi.inria.fr (Colas Nahaboo) writes: > Then, when I do a ps -l and I see that elk takes 1600K of memory whereas > xscheme only 300, for me xscheme is smaller. The reason why "ps" shows more than 1000 KBytes is that Elk has a heap of size 1 MByte by default (you can specify a smaller one by means of an option). The rest is the stack and possibly the text size (1000 KByte). By the way, 1600 KBytes is a bit much; on our machines "ps" never shows more than 1250 KBytes. Anyway, I don't see why this should be so important. Isn't the virtual memory behaviour of a program (locality, resident set size) much more relevant than just the plain size? Unused pages get paged out by the operating system when memory runs low anyway. Elk employs a stop-and-copy garbage collection algorithm, which is known to keep the interpreter's locality high. Note that half of the heap (512 KBytes) is never used by the interpreter except during a GC, thus the corresponding pages need only be paged in during a GC run. If you have a program of size, say, 32 MBytes, but it only executes a loop within a single page during its lifetime-- is this a "large" program? Only looking at the output of "ps" is a poor way to judge whether a program is "large" or "small"; you need to do a more careful analysis to come to a useful judgement. Regards, -- Oliver Laumann, Technical University of Berlin, Germany. pyramid!tub!net net@TUB.BITNET net@tub.cs.tu-berlin.de
wilson@UICBERT.EECS.UIC.EDU (Paul Wilson) (08/12/90)
Oliver's comment about stop-and-copy and locality seems off the mark. If Elk uses simple stop-and-copy, its locality is bound to be very poor, so heap size matters a lot. A stop-and-copy collector does compact the data at every gc, but between gc's it touches every location in the space being allocated. (It writes to them all, too, so all those pages have to be written back to disk as well as paged in the first place.) A simple semispace copy collector writes to every location in the heap every two gc cycles. What you need is a generational collector if you want good locality. This may be unnecessary for programs that don't do a whole lot of allocation, and which never have much live data at any one time; you may just be able to get away with making your heap size really small. But you will touch every location in that heap in a highly regular and repetitious fashion. -- Paul Paul R. "Garbageman" Wilson Software "Dirtbag" Systems Laboratory lab ph.: (312) 996-9216 U. of Illin. at C. EECS Dept. (M/C 154) wilson@bert.eecs.uic.edu Box 4348 Chicago,IL 60680
rich@Rice.edu (Carey Richard Murphey) (08/12/90)
In article <RICH.90Aug7015042@uncle-bens.Rice.edu> Rich Murphey <Rich@Rice.edu> writes: > I'm curious to know what else is out there that's a minimal > implementation, easy to modify, port, interface with other C code, and > redistribute. As a scheme novice, I am easily overwhelmed by the size > of elk I've had several responses which recomended siod highly. Robert C. Pettengill <rcp@mcc.com> writes: >This is exactly what SIOD is good for! All the others are much >larger. Although Elk and Jason Coughlin's interpreter are relatively small compared to distribuitions like mit-scheme, siod's under 2000 lines. Neil MacDonald <nbm@uk.ac.ed.castle> writes: >siod (Scheme in One Day/Defun) is a small, clearly written, easily >ported implementation of a Scheme subset. I have built it on a variety >of Unix-ish systems. I'm still learning scheme, and the simplicity of siod is a great help. The small source size makes the task of understanding the interpreter much more manageable. Rich
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (08/13/90)
> Please define a predicate is-small(X) that we can apply to the existing > implementations to be able to determine whether they can be considered > "small". For an extension language, may I propose "size(1)" of code for the extension language kernel as a library that can be linked with the program that uses it is < 50k on a VAX < 100k on a MIPS as the definition of small-scheme-like-extension-kit? I have an emacs-like editor which I'd like to add an extension language to. I would rather the extension language were smaller than the editor. For something which is not intended as an extension language but as a reasonable Scheme programming environment, I suggest < 1 M of code on a VAX < 2 M of code on a MIPS as the definition of small-scheme-implementation? or alternatively runs in < 4M of VM on a VAX runs in < 5M of VM on a MIPS Something like a stripped down T3.1 would be just about right. -- The taxonomy of Pleistocene equids is in a state of confusion.
alfred@dutepp1.tudelft.nl (Alfred Kayser) (08/13/90)
roger@kymijoki.wrs.com (Roger Rohrbach) writes: >George Carrette's SIOD is what you want. Dunno why he didn't post the >following to comp.lang.scheme... >> Newsgroups: comp.lang.lisp >> Subject: new version of SIOD (Scheme in one Day) available ^^^^^^^^^^^^^^^^^ I read in its docs: Scheme In One Defun! >SIOD version 2.4 is now available. A lot hipe over features of the SIOD interpreter >Platforms? > * VAX/VMS * VAX UNIX * SUN-3 * SUN-4 * AMIGA * MACINTOSH * MIPS * CRAY I've once tryed to port it to MSDOS or OS2 (compiler and cpu are the same) but it crashed enormously. The code was too unreadable to be debugged. Keep in mind that it was started from a 'joke'. SIOD stands for Scheme In One Defun. Thus a scheme interpreter in Lisp, which was ported to C somewhere between 1.0 and 2.4. -- -- Ir. Alfred Kayser. PACS, OS/2, TCP/IP. --- Email: AKayser@et.tudelft.nl -- -- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 -- -- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --
colas@avahi.inria.fr (Colas Nahaboo) (08/14/90)
In article <1460@tub.UUCP>, net@tub.UUCP (Oliver Laumann) writes: > Only looking at the output of "ps" is a poor way to judge whether a > program is "large" or "small"; you need to do a more careful analysis > to come to a useful judgement. less poor than just counting the lines of C code... That was the point of my article: text size is not the problem, the problem is the active non-sharable, non-swappable memory it consumes. -- Colas Nahaboo, Bull Research France -- Koala Project -- GWM X11 Window Manager colas@avahi.inria.fr Phone: (33) 93.65.77.70, Fax: (33) 93 65 77 66 INRIA - Sophia Antipolis, 2004, rte des Lucioles, 06565 Valbonne Cedex, FRANCE
brian@granite.jpl.nasa.gov (Brian of ASTD-CP) (08/15/90)
In article <.650536187@dutepp1> alfred@dutepp1.tudelft.nl (Alfred Kayser) writes: >>Platforms? >> * VAX/VMS * VAX UNIX * SUN-3 * SUN-4 * AMIGA * MACINTOSH * MIPS * CRAY >I've once tryed to port it to MSDOS or OS2 (compiler and cpu are the same) >but it crashed enormously. I think MSDOS/OS2 is a very special case, so your failure to bring up SIOD on this machine should not be viewed as an indictment of SIOD. All the other platforms at least have Von Neumann architectures underneath. MSDOS/OS2 runs on 80x86 chips, which are not Von Neumann computers: almost every cell in memory has 4096 DIFFERENT addresses (segment/offset pairs)! It is very difficult to write a Lisp/Prolog implementation that ports easily between Intel processors and the rest of the world, mostly because the assumption that every cell in memory has a unique address is implicit in implementation languages such as C and Pascal. If it is not the case that every cell in memory has a unique address, then the programmer of a would-be portable program must tip-toe very carefully around pointer arithmetic, indirection, and address-taking operations. Also, the programmer must make decisions about "memory model": tiny, small, medium, big, huge etc. Such decisions do not exist on the other platforms mentioned. >-- >-- Ir. Alfred Kayser. PACS, OS/2, TCP/IP. --- Email: AKayser@et.tudelft.nl -- >-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 -- >-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 -- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Brian Beckman . . . . . . . . . . brian@granite.jpl.nasa.gov. . . . . . meta-disclaimer: every statement in this message is false . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
manis@cs.ubc.ca (Vincent Manis) (08/16/90)
I think SIOD needs a bit of work before it is genuinely portable.
Basically, it's full of the following sort of code:
foo(1);
int foo(x); long x; {...}
This violates all sorts of C rules, even in K&R. (Hint: on what sorts of
machines does sizeof(long) == sizeof(int)?) I thought of fixing the
code, but decided that if I were to do that, I'd end up rewriting it.
I'm looking forward to psi. I hope it's a bit more portable.
--
\ Vincent Manis <manis@cs.ubc.ca> "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-2394markha@microsoft.UUCP (Mark HAHN) (08/16/90)
In article <.650536187@dutepp1> alfred@dutepp1.tudelft.nl (Alfred Kayser) writes: >>Platforms? >> * VAX/VMS * VAX UNIX * SUN-3 * SUN-4 * AMIGA * MACINTOSH * MIPS * CRAY >I've once tryed to port it to MSDOS or OS2 (compiler and cpu are the same) >but it crashed enormously. The code was too unreadable to be debugged. >Keep in mind that it was started from a 'joke'. SIOD stands for >Scheme In One Defun. Thus a scheme interpreter in Lisp, which was ported to >C somewhere between 1.0 and 2.4. SIOD (1.3 or 2.4) runs just fine under os2. the only change I had to make was to disable the signal stuff, because my std libs were flaky. (I was compiling it 32-bit flat for os/2 2.0, which is some distance away from release.) I thought the source formatting was strange, too, but a quick pass through cb solves all that... Besides, lisp itself was originally a joke, or at least not a seriously intended programming language. For reference, my copies of xlisp, xscheme and elk weigh in at 5-6K locs, while siod 1.3 is 980, and siod 2.4 is 1715. regards, -- Mark Hahn microsoft!markha@uunet.uu.net uunet!microsoft!markha YES, Bill Gates IS my personal savior, and I CHANNEL for him in CLEAR WEATHER.
lishka@uwslh.slh.wisc.edu (a.k.a. Chri) (08/16/90)
alfred@dutepp1.tudelft.nl (Alfred Kayser) writes: >roger@kymijoki.wrs.com (Roger Rohrbach) writes: >>George Carrette's SIOD is what you want. Dunno why he didn't post the >>following to comp.lang.scheme... >>> Newsgroups: comp.lang.lisp >>> Subject: new version of SIOD (Scheme in one Day) available > ^^^^^^^^^^^^^^^^^ > I read in its docs: Scheme In One Defun! > >I've once tryed to port it to MSDOS or OS2 (compiler and cpu are the same) >but it crashed enormously. The code was too unreadable to be debugged. Hmmmm. I ported it to the Commodore Amiga with almost no trouble. Pretty much compile-and-run. And I thought the code was actually pretty "readable;" I had little trouble understanding what I needed to. The fact that this is so little source code makes it much easier to understand (hey, I have written compilers twice that size in less than two months!). -- Christopher Lishka 608-262-4485 "Dad, don't give in to mob mentality!" Wisconsin State Lab. of Hygiene -- Bart Simpson lishka@uwslh.slh.wisc.edu "I'm not, Son. I'm jumping on the bandwagon." uunet!uwvax!uwslh!lishka -- Homer Simpson
oz@yunexus.yorku.ca (Ozan Yigit) (08/17/90)
In article <9171@ubc-cs.UUCP> manis@cs.ubc.ca (Vincent Manis) writes: >I'm looking forward to psi. I hope it's a bit more portable. That is why it is called "portable scheme interpreter". In all platforms, code required no change except few ifdefs for various include files, and to accomodate ANSI-C related things. oz --- First learn your horn and all the theory. Internet: oz@nexus.yorku.ca Next develop a style. Then forget all that uucp: utzoo/utai!yunexus!oz and just play. Charlie Parker [?] York U. CCS: (416) 736 5257
ted@nmsu.edu (Ted Dunning) (08/17/90)
comparing the sizes of siod and any scheme implementation is completely spurious. if we add to this the fact that the code isn't terribly well done, it becomes pointless to consider siod as anything but a joke. From: N MacDonald <nbm%castle.edinburgh.ac.uk> Subject: Re: a scheme via FTP To: Ted Dunning <ted%nmsu.edu> > > In article <9008020346.AA21985@mailhost.samsung.com> gjc@mitech.COM writes: > > One small and simple scheme: FTP anonymous to BU.EDU, > cd to users/gjc and get siod-v2.4-shar > > > good except for the fact that siod is not scheme. all kinds of things > are missing. Could you elaborate, please? i just grabbed siod again and note on quick examination the following missing features: labels on lets all string functions all vector functions all character functions all formatting functions rationals bignums do let* case delay force letrec c[ad]+r for more than a very few [ad]'s length list-tail list-ref last-pair memq memv member assv assoc exact? inexact? complex? real? rational? integer? zero? positive? negative? odd? even? <= >= = max min abs quotient remainder modulo numerator denominator gcd lcm floor ceiling truncate round rationalize exp log sin cos tan asin acos atan sqrt expt make-rectangular make-polar real-part imag-part magnitude angle exact->inexact inexact->exact procedure? apply map for-each call-with-input-file call-with-output-file input-port? output-port? current-input-port current-output-port with-input-from-file with-output-to-file open-input-file open-output-file close-input-file close-output-file write eof-object? display newline write-char char-ready? read-char transcript-on transcript-off and the following errors: load won't take a string consp should be pair? symbolconc should be more like append-string call/cc doesn't allow upward funargs these are a few reasons is why siod is not scheme and why comparing it with any scheme is pointless. -- Offer void except where prohibited by law.
dmw9q@uvacs.cs.Virginia.EDU (David M. Warme) (09/05/90)
In article <26569@nigel.udel.edu> carrol@udel.edu (Mark Carrol <MC>) writes: >GJC writes: >]Maybe it is possible to have an intelligent discussion about this. >]Q: What is Scheme? >] >]What makes something scheme? > >Compliance with the specification of the language Scheme - R3RS, or soon R4RS. > There seem to be two camps here. One camp says that implementation X is not language Y unless it conforms to ANSI/ISO standard 3.162277*pi/2. These are the hackers who want to buy a Scheme implementation to hack (or work) with, and wouldn't be caught dead with something that wasn't the "real" thing. They spend money, implement systems and maybe even port them, so their concerns are real. The other camp says that when scheme was born as a research hack in the 1970's, it came out of a few adjustments to LISP: - lexically scoped variables - one name space - functions are first-class - recursion is the only loop (tail-recursive implementation) As it turns out, these few "small" tweaks produced a very different critter, as we all know well. I suspect that continuations came into the language *after* they were first used to IMPLEMENT point 4 above using CPS semantics. Care to shed any light on this Guy? LISP came from humble beginnings and is now standardized in the form of Common Lisp. Likewise, Scheme began humbly and developed into RnRS. It is difficult to deny that LISP 1.5 is in fact LISP. So too is it difficult to deny that a dog with its tail removed is still a dog. Scheme was and is a very successful research vehicle. Language researchers tend to balk at standards -- from their point of view, a language stops being interesting the moment it is cast into stone. I believe that GJC knows all of this, and is himself doing further research -- how can we combine the Scheme and C worlds? Yes, it may be missing its RnRS tail. Compare it against Scheme's humble beginnings, however, and it still looks like a dog. :^) - Dave Warme Dept of CS, Univ. of Virginia