wilson@UICBERT.EECS.UIC.EDU (Paul Wilson) (12/08/88)
Several people (myself included) have posted requests for large Scheme programs, with disappointing results. Apparently relatively few people use Scheme for really serious development, and very few write portable (e.g., R3RS) Scheme code. I was wondering if this is likely to change over the next couple of years, perhaps as a result of a more completely standardized language. When is the R4RS likely to come out, and what is it likely to standardize? Will a macro facility be standardized? Dynamic or fluid variables? These seem to me to be the most important Lisp features not specified by the R3RS. Is there a consensus growing as to how either of these should be done, or is it too early to settle on a standard? Whatever the answer is, what does it imply for the future of Scheme? Will it be a "toy" language forever, like unextended Pascal? Or will it eventually be a medium-sized language with a lot of available libraries, like C? (And will it be a family of incompatible languages, like Pascal, or take over the world, like C? :-). Right now, I need to guess whether there will be sufficient programs available within two years to gather performance data for some implementation techniques. If not, I may have to go with another language for some of the things I need to do, and that could be painful. -- Paul Paul R. Wilson Human-Computer Interaction Laboratory U. of Illin. at C. EECS Dept. (M/C 154) wilson%uicbert@uxc.cso.uiuc.edu Box 4348 Chicago,IL 60680
will@uoregon.uoregon.edu (William Clinger) (12/08/88)
In article <8812072227.AA00515@uicbert.eecs.uic.edu> wilson@UICBERT.EECS.UIC.EDU (Paul Wilson) writes: >Several people (myself included) have posted requests for large >Scheme programs, with disappointing results. Apparently relatively few >people use Scheme for really serious development, and very few write >portable (e.g., R3RS) Scheme code. I think you are right that relatively few of the people who use Scheme for really serious development are writing portable Scheme code. On the Macintosh, for example, "really serious" implies calling ROM routines to achieve the Apple look and feel, which is hardly portable even with all the high-level support provided by MacScheme+Toolsmith. It's not portable in C, either. Some of the larger Scheme programs, like Edwin, TI's Personal Consultant for the PC family, and various programs written in T, are non-portable in part because they are rooted in systems that antedate the RRRS, let alone the R3RS. I would imagine that they also have to do a lot of inherently non-portable things with i/o. >I was wondering if this is likely to change over the next couple of >years, perhaps as a result of a more completely standardized language. I think it will. Most of Scheme's popularity has been a result of the Abelson & Sussman(s) book, which has prompted universities to use Scheme in their introductory courses, often on an experimental basis. Universities are only now beginning to accept Scheme as a language worthy of use in upper division and graduate courses, and upper level textbooks that use Scheme are only now being written. I expect the most significant publicly available Scheme programs, some of them portable, will be written in the universities. That's the way it is with other languages. >When is the R4RS likely to come out, and what is it likely to standardize? >Will a macro facility be standardized? Dynamic or fluid variables?... >...Is there a consensus growing as to how either of these should >be done, or is it too early to settle on a standard? The R4RS will come out early next year. It will not standardize dynamic or fluid variables, and I am skeptical that it will standardize macros. There seems to be a fair consensus on macros, but the details aren't yet worked out. There are technical problems concerning the interaction of dynamic variables with multitasking and I don't expect them to be resolved anytime soon. A draft of the IEEE standard will be ready in February. This is probably more important than the R4RS, on which it will be based. >Whatever the answer is, what does it imply for the future of Scheme? Will >it be a "toy" language forever, like unextended Pascal? Or will it >eventually be a medium-sized language with a lot of available libraries, >like C? I think the availability of generally useful public code will soon be better for Scheme than for unextended Pascal (if it isn't already). I doubt that Scheme will ever approach C in the volume of generally available code, but Scheme may be stronger than C in certain important areas such as numerical software. It would be a waste to duplicate some C libraries, such as X, in Scheme; better to let Scheme code call the C libraries. >Right now, I need to guess whether there will be sufficient programs >available within two years to gather performance data for some implementation >techniques. If not, I may have to go with another language for some of >the things I need to do, and that could be painful. Though we've talked, I still don't have a good idea of the kind of programs you're looking for. The main reason I haven't responded to your call for programs is that I'm inclined to interpret a call for "large" programs as a call for programs with more than 10,000 lines (at least) and I've never written a standalone program that large in any single language. Peace, Will
jbs@fenchurch.mit.edu (Jeff Siegal) (12/09/88)
In article <3348@uoregon.uoregon.edu> will@fog.UUCP (William Clinger) writes: >I think you are right that relatively few of the people who use Scheme for >really serious development are writing portable Scheme code. On the >Macintosh, for example, "really serious" implies calling ROM routines >to achieve the Apple look and feel, [...] This is true in any language, but all "real" languages (Scheme included) provide ways to package up these system dependencies to allow easier retargeting of the code. However, this is quite different from the non-standardization of actual language features (e.g. dynamic bindings, macros, internal define's), which can require converting the lots of code to transport a system. I'm glad to hear there is at least a possibility of macros becoming standard; the other features I can live without. On the other hand, aren't dynamic bindings required for many of the interesting uses of call/cc (i.e. catch and throw). Jeff Siegal
wilson@uicbert.eecs.uic.edu (12/13/88)
With regard to standardization, I would think it would be possible
to standardize a rather underspecified version of a macro facility,
without specifying things like scope rules. In that way, careful
programmers could use basic macros in a portable way, so that their
programs could run in varying Schemes, and be compatible with an
eventual more detailed specification; e.g., if all of your macros
have unique names, you don't have to worry about name collision
resolution details.
(This would be akin to programmers who write programs
that don't rely on dynamic or static scoping, so that
they run the same way with a dynamically-scoped interpreter and a
lexically-scoped compiler. While it's not the best situation, it's
better than not being able to use a macros (or a compiler).)
Or is this considered a path to perdition, with people writing
code that they think is portable but isn't, because of accidental
implementation dependencies? Standardization of noncontroversial
aspects of features is just one step down the slippery slope from
fully specified standard features, but it seems a particularly
attractive step to me. A small commitment to a core functionality
of macros and dynamic/fluid variables could come in very handy in
the short run, and still allow a fuller, more righteous specification
the next time around.
-- Paul
Paul R. Wilson
Electronic Mind Control* Laboratory
U. of Illin. at C. EECS Dept. (M/C 154) wilson%uicbert@uxc.cso.uiuc.edu
Box 4348 Chicago,IL 60680 *a.k.a. Human-Computer Interactionwilson@uicbert.eecs.uic.edu (12/13/88)
On the subject of the portable code I'm looking for:
I don't know about others who are looking, but I'm looking for
programs that allocate at least one megabyte of memory during a
run, and preferably ten or more. I'd really like programs that
actually have a megabyte or more of data that is *live* at one
time. I'm especially interested in programs that run for several
minutes or more on a serious workstation (compiled). This is
for gathering locality statistics and data survival curves.
Bob Shaw's recentPh.D. dissertation at stanford reported some similar
statistics for four large Common Lisp programs. His programs were
the Reduce symbolic math package, a natural language understanding
program, a Common Lisp compiler (Hewlett-Packard's) compiling
itself, and the RSIM circuit simulator.
I would be very interested in similar programs written in
portable Scheme. Eventually I may take on porting some programs
if they don't use too many incompatible extensions, but I'd
rather not have to.
I am interested in getting a variety of programs that are
large and/or long-running, with a preference for things that
people could actually use, rather than throwaway prototypes. For
example, an implementation of OPS5 that actually uses the
RETE matching algorithm would be excellent. Non-AI "plain old
programs" that do something useful would be particularly good,
since I'm looking for data that generalize beyond AI applications.
Interactive programs would be particularly nice, if they use ASCII-
only interactions (so that I can hack up a script facility to repeatedly
run them offline).
(The reason for all this is to gather statistics that will
guide the design of generation-based garbage collectors,
virtual memories, and copy-on-write virtual copy mechanisms
for checkpointing and side-effect isolation. I'm implementing
a generational garbage collector for Scheme-48, and it will
be instrumented to gather the relevant statistics. Of
course, we'll have to scale our results to compensate for
the slowness of the bytecoded Scheme-48 interpreter. A bigger
problem is the availability of reasonable test programs --
that may require more work in porting than is involved in
implementing the gc itself.
I may have to implement the instrumented gc for something hairier,
like Kyoto Common Lisp or T, to gather data on larger programs.
The Scheme-48 version should still be valuable, because it could
be more easily extended for simulating parallel systems, etc.)
-- Paul
Paul R. Wilson
Human-Computer Interaction Laboratory
U. of Illin. at C. EECS Dept. (M/C 154) wilson%uicbert@uxc.cso.uiuc.edu
Box 4348 Chicago,IL 60680