Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!mintaka!ai-lab!zurich.ai.mit.edu!jinx From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas) Newsgroups: comp.lang.scheme Subject: Re: Macros again Message-ID: Date: 3 Jun 91 21:49:34 GMT References: <1510@yoakum.cs.utexas.edu> Sender: news@ai.mit.edu Reply-To: jinx@zurich.ai.mit.edu Organization: M.I.T. Artificial Intelligence Lab. Lines: 68 In-reply-to: jaffer@zurich.ai.mit.edu's message of 3 Jun 91 21:08:45 GMT In article jaffer@zurich.ai.mit.edu (Aubrey Jaffer) writes: Path: ai-lab!zurich.ai.mit.edu!jaffer From: jaffer@zurich.ai.mit.edu (Aubrey Jaffer) Newsgroups: comp.lang.scheme Date: 3 Jun 91 21:08:45 GMT References: <1510@yoakum.cs.utexas.edu> Sender: news@ai.mit.edu Organization: M.I.T. Artificial Intelligence Lab. Lines: 23 As I look towards implementing macros in scm, a few questions occur to me: I was planning to replace every invocation of a macro in the code with the expansion of the macro. Is there any problem with this? I consider macros to be new derived expression types. Since, according to the definition, derived expression types can be replaced with the expansions, this seems the natural thing to do with macros. That is the way that all implementations that I know of handle macros. It is the only way they can effectively be handled if you don't execute the S-expressions directly and instead translate them into a different code (native code for a particular real or virtual machine). Local (non-top level) macros seem like a useless gold plated feature that will introduce problems with use of symbols in programs. Scheme defined keywords are not allowed to be used as variable names. It seems a reasonable expectation that macro names also not be allowed as varible names. But local macros would seem to require that the local macro names could be used elsewhere as variables. All the examples I have seen so far of local macros are contorted and hard to read. Can anyone come up with a really useful example of a local macro? Three independent issues here: - Whether the keywords of core special forms should be disallowed as variables. I believe that the current restriction in the reports, etc. is a consequence of the lack of macros, and that when they are finally adopted (if ever), the restriction will be lifted. - Whether the keywords of macros should be disallowed as variables. This is a very bad idea. For example, if your system happens to provide a macro called TIME for timing/benchmarking expressions, then the variable TIME is no longer available for variables in programs. Similar for DELAY, LOOP, and many other common names. Furthermore, it means that programs to be used together must avoid even for local variables the names used by either as keywords! This makes combining code from different sources very painful. - Whether local macros are useful. I feel the opposite of what you feel. I think that only local macros are useful and global macros are horrible (although convenient) because of all the problems they present with respect to modularity, separate compilation, etc. When I use macros, I often wrap a LET-SYNTAX (MIT Scheme) around the whole file and all the macros are local. That way I can combine the program with any other and I know that it won't be affected by a macro vs. procedure interaction. It all depends on what size programs you expect to put together. Collisions in the name space become more common the larger the programs become, and at that point you start using lexical scoping (even for macros) more heavily in order to avoid potential problems.