Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!uoregon!will From: will@uoregon.uoregon.edu (William Clinger) Newsgroups: comp.lang.scheme Subject: Re: R4RS changes? Code? Message-ID: <3348@uoregon.uoregon.edu> Date: 8 Dec 88 02:58:39 GMT References: <8812072227.AA00515@uicbert.eecs.uic.edu> Reply-To: will@fog.UUCP (William Clinger) Organization: University of Oregon, Computer Science, Eugene OR Lines: 68 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