Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.lang.scheme Subject: Re: Making programs out of modules in Scheme Message-ID: <6496@goanna.cs.rmit.oz.au> Date: 25 Jun 91 07:33:15 GMT Article-I.D.: goanna.6496 References: <6384@goanna.cs.rmit.oz.au> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 30 In article , davis@passy.ilog.fr (Harley Davis) writes: > It's true that in Scheme, CommonLisp, or many other languages you can > get a sort of poor man's module facility using conventions like those > described. However, they do not support many of the features that > modules are generally thought to give you: > > * Compile-time or load-time resolution of bindings. > * Renaming on import or export. The approach I presented allowed renaming. > * Ease of module integration. (In all of the proposed mechanisms, > referencing a local function is quite different from referencing an > imported function. If this is not the case, it is impossible to > hide local names.) The approach I presented involved referencing local and imported functions in EXACTLY the same way. The only difference was in definition: (define foo (lambda (...) ...)) ; local (define foo (library ... ...)) ; imported Nor did the things transported have to be functions. > In addition, a language which requires compile-time runtime features > -- eg, macros -- should distinguish between compile-time requirements > and runtime requirements, to minimize application size. This has no relevance to Standard or R**3.99 Scheme, which was my sole (and in the case of the Standard, incorrectly recalled) interest. -- I agree with Jim Giles about many of the deficiencies of present UNIX.