Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!hsdndev!husc6!carlton From: carlton@husc10.harvard.edu (david carlton) Newsgroups: comp.lang.scheme Subject: Optional extensions for compiling Scheme Message-ID: Date: 31 May 91 20:00:46 GMT References: <5204@autodesk.COM> Sender: news@husc6.harvard.edu Organization: Citizens for Boysenberry Jam Lines: 45 In-reply-to: robertj@autodesk.com's message of 28 May 91 21:10:06 GMT While we're talking about optional extensions for Scheme, how 'bout adding a package of extensions to Scheme for compiling Scheme? Right now, it's (IMHO) next to impossible to compile portable Scheme into code that is as efficient as, say, code generated by a decent C compiler, but the language isn't really not too far off from that. And, in particular, all of the major Scheme implementations provide various ways to compile Scheme efficiently, but of course they all use different syntax for this, so this is an area begging for standardization. So what would be important for such an extention? The most important thing to keep in mind, I think, is that it should be possible (and easy) to have your compiler compile what is now portable Scheme code correctly. That is, all of the "features" which speed up compiling at the sake of "correctness" should be able to be turned off. Keeping this in mind, things that I think are important are: 1) Named constants. This is probably the single most important feature necessary to compile Scheme efficiently. Of course, it should be possible to toggle the inlinedness of individual variables; and it should also be possible to turn on and off the inlinedness of whole groups of variables, such as the ones in the standard. 2) Modules. You need some sort of module facility. Of course, this isn't just a compilation issue, but the two are certainly related. For example, once you have modules you can have the compiler store information about the modules that have been compiled (what args various functions take, whether or not they are inlined, etc.). 3) Declarations. This one is a bit harder to standardize, but at least the syntax should be standardized, along with some of the more common declarations, such as what sort of arithmetic to use and how much optimization to perform, in case the compiler wishes to support them. 4) Extend the i/o functions in a few trivial ways, such as adding a "compile" command and extending load to look for compiled files if possible. How does this sound? What have I left out, and what have I included that I shouldn't have? What do other Scheme implementations do about these issues? david carlton carlton@husc10.harvard.edu