Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!ai-lab!zurich.ai.mit.edu!jaffer From: jaffer@zurich.ai.mit.edu (Aubrey Jaffer) Newsgroups: comp.lang.scheme Subject: Re: Making programs out of modules in Scheme Message-ID: Date: 22 Jun 91 01:33:59 GMT References: <6384@goanna.cs.rmit.oz.au> <507@data.UUCP> Sender: news@ai.mit.edu Organization: M.I.T. Artificial Intelligence Lab. Lines: 36 In-reply-to: kend@data.UUCP's message of 21 Jun 91 16:28:22 GMT In article <507@data.UUCP> kend@data.UUCP (Ken Dickey) writes: ... I have yet to see an implementation of Scheme lacking either EVAL or LOAD, so I think that we can safely say that they are part of Scheme--even if not part of the minimalist IEEE standard. I agree that it would be much better to have the interface (call form) of EVAL and LOAD as a standard--not to mention ERROR! LOAD is certainly in R^3RS (and I suspect R^4RS, but I don't have a copy in front of me 8^). EVAL is not part of scm2 (available from altdorf.ai.mit.edu). Adding EVAL would prevent scm2 from memoizing the locations of variable references. It would be good if in R^5RS there was agreement on what the call forms for EVAL, ERROR, etc. are if they are provided. There is no consensus on which environment to use for EVAL and how to specify it. LOAD is subject to the same environment problems. ---------------- I think that Scheme is seriously deficient in it's lack of library facility. One could have system varibles *library-prefix* and *library-suffix* in order to transform library names to absolute filenames or have a routine to do this. This is not sufficient with an interpreted system, however. In an interpreted system I want to be able to run my program from a directory other than the one where the Scheme source for the program is stored. So I need some sort of local library as well. The problem is complicated even more by the desire to have non-scheme files accessible in the local library directory as well. This problem is NOT addressed the module proposals. This library problem is present in all modern computer languages. I have not seen any solutions I like (although I haven't surveyed the literature). I would really like to see Scheme solve this one RIGHT instead of in an ad-hoc manner.