gjc@mitech.COM (08/13/90)
Many interesting replies to this "what makes scheme" thing. J Reese's detailed reply being a good guide for me (or anyone) who would want to make SIOD into a full R^4 language at some future date. The intro to the R^4 report makes an (unsubstantiated) argument about keeping a language as small as possible, or at least, trying not to add too many things to it. One cold hard way to substantiate this would be to look at what languages that have *made* it, and which have *failed* (and of course ask *why*). Be that as it may, R^4 defines a language that is sufficient for running interesting programs with interesting features which _cover_ just about all other languages without being as big as all other languages. This *coverage* aspect has been one goal of lisp implementors. But what makes lisp? From the point of view of an old Maclisp hack like myself, three things: * EXTENSIBILITY * HOOKS * STABILITY The whole point of SIOD is to have a Lisp which *lives* *well* together with code written in C. It is to recognize that C, and code written in C is in the MASTER POSITION in our current little universe. _COVERAGE_ comes from what can be done in C. What is one requirement for living well with C? That if you have a lisp-level call to a procedure like (equal (f x) (g y)) that you must be able to call it at C-level as equal(f(x),g(y)); XSCHEME, ELK, XLISP, they are all small (although many times bigger than SIOD), but all of them have rather awkward call sequences between lisp and C code compared with SIOD. (But since XSCHEME/ELK/XLISP have more stuff at lisp-level, they may be better for people who are going to do more programming at the lisp level). SIOD is aimed at those C programmers who might want to do a little lisp. It is aimed at people who might otherwise be tempted to use the classic Unix tools of Lex/Yacc to build yet another one of those countless little abortions we are faced with from day to day. Example1: SENDMAIL.CF files. (A large abortion, not a little one). Example2: MIT X-Window's TRANSLATIONS (maybe not lex/yacc, just home-brew). A parting shot here. SIOD does run code from SICP, the book (not the harder to find Teachers Guide, or the on-line problem sets, which indeed would take a lot of modification work). Even lack of BIGNUM's is not such a big deal. The second home-work assignment in the lisp course I gave at Boston University was to implement a bignum package (using binary representation, quite trivial but a bit on the slow side). Most engineering students aren't much interested in number-theoretic examples anyway. (They won't get hit with Z-transforms, coding theory, probability and generating functions until much later in life at most schools). By the way, the cutest bignum package I've seen lately is in a symbolic algebra package running in GNU EMACS LISP (dynamic scoping, fixnums only (not even floats!)). -gjc p.s. Don't misunderstand me with respect to R^4. It does not force a language implementation to be large. I have just been too busy in the last year or so to do anything about having a set of full R^4 built-in's for SIOD. The fully general CALL/CC stuff does have an adverse impact on *living* *well* with C or just about any other language [except ADA perhaps?], but that should be subject to compromise.
rees@parc.xerox.COM (08/15/90)
Date: Mon, 13 Aug 90 12:30:00 EDT
From: gjc@mitech.com
What is one requirement for living well with C? That if you
have a lisp-level call to a procedure like (equal (f x) (g y)) that
you must be able to call it at C-level as equal(f(x),g(y));
This is a tall order; the only solution of which I'm aware is a
conservative GC, and I didn't think siod had one of those (I deduce
this from the presence in slib.c of a function called "gc_protect").
Or do you have some other way of dealing with the situation where
(assuming left-to-right argument evaluation in C)
- the result of f is consed
- the only pointer to this result while in g is on the C stack
- invoking g triggers a GC
- after the gc g does more allocation, thereby overwriting the
result of the call to f? gintera@arcsun.arc.ab.ca (Andrew Ginter) (08/15/90)
In article <9008141823.AA08641@satchmo> rees@parc.xerox.COM writes: > What is one requirement for living well with C? That if you > have a lisp-level call to a procedure like (equal (f x) (g y)) that > you must be able to call it at C-level as equal(f(x),g(y)); >This is a tall order; the only solution of which I'm aware is a >conservative GC... There's another solution to the problem - the one I believe GNU emacs uses. At the top of the command loop, emacs checks that there is a "fair" amount of memory left in the garbage collected heap (as I recall, "fair" = no more than about 90% full). If there's not enough room, the collector is called. At this point in time, there are no pointers to the heap anywhere on the stack. In the rare case that a lisp command consumes all of the remaining > 10% of the heap before returning to the top of the command loop, emacs simply allocates more memory for the heap. This strategy is useful only if: (1) LISP is used as an extension language, and the system spends only small increments of time in the interpreter before returning to the application which called the extension language, AND (2) there's always a little extra memory the operating system can supply the application in a pinch. Andrew Ginter, 403-282-2984 gintera@cpsc.ucalgary.ca
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (08/17/90)
In article <1990Aug16.103617@avahi.inria.fr> colas@avahi.inria.fr (Colas Nahaboo) writes: >PS: gwm is an emacs-like WIndow Manager for X: it has a built-in lisp >interpreter for customization, fast and small, and totally C-compatible, >written in C. (and ~ 3 times faster than xlisp and emacs lisp). I don't think that's a fair comparison though, since WOOL isn't a "real lisp" (oops ... what is lisp anyways?). At last check -- WOOL used arrays as lists, didn't seem to have a dynarray facility to dynamically expand array-based lists, and couldn't handle circular lists. In my opinion, the listiness of a lisp defines it's lispness. Lists are one of the things I like about lisp... I bet forth is more than 3 * faster than xlisp and emacs-lisp... ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *
colas@avahi.inria.fr (Colas Nahaboo) (08/17/90)
In article <9008141823.AA08641@satchmo>, rees@parc.xerox.COM writes: > Or do you have some other way of dealing with the situation where > (assuming left-to-right argument evaluation in C) > - the result of f is consed > - the only pointer to this result while in g is on the C stack > - invoking g triggers a GC > - after the gc g does more allocation, thereby overwriting the > result of the call to f? In wool (the lisp interpreter I designed for gwm), I use an original time-based GC: a gc only garbage-collects objects whose GC count came to 0 more recently than the current stack frame was entered. Then in the case "equal(f(x),g(y))" a GC in g won't try to gc objects created by f, which are "older" than the invocation of g. This scheme avoids to bother the C programmer with any GC_protect type of calls. PS: gwm is an emacs-like WIndow Manager for X: it has a built-in lisp interpreter for customization, fast and small, and totally C-compatible, written in C. (and ~ 3 times faster than xlisp and emacs lisp). PPS: wool was designed to be a library for C programmers, and to be as easy and natural as possible to use from C. -- 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