Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!bloom-beacon!think!rlk From: rlk@think.com (Robert Krawitz) Newsgroups: comp.emacs Subject: Re: defmacro vs. defun Message-ID: <24076@think.UUCP> Date: 18 Jul 88 13:53:52 GMT References: <4300016@m.cs.uiuc.edu> <33735@yale-celray.yale.UUCP> Sender: usenet@think.UUCP Reply-To: rlk@think.com (Robert Krawitz) Organization: Thinking Machines Corp., Cambridge MA Lines: 28 In-reply-to: Ram-Ashwin@cs.yale.edu (Ashwin Ram) In article <33735@yale-celray.yale.UUCP>, Ram-Ashwin@cs (Ashwin Ram) writes: ]Perhaps there should be a way to declare autoload's for macros, such that the ]byte-compiler would do the autoload before compilation, just like eval does ]before evaluation? That's what require is for. Autoloads aren't a particularly standard part of lisp, and in emacs lisp they're primarily for use with interactive commands, not internal lisp code. The byte compiler respects requires in files, so you can load in macro definitions. I suspect that putting a (require 'cl) followed by a (provide 'cl) at the top of the cl.el file would solve the compilation problems with that file (of course, the correct solution is to eliminate the dependencies by ensuring that all macros are defined before they are referenced). I use require and provide for all packages that I write that consist of multiple files, as emacs lisp doesn't have anything like make, or systems, or the like (although I'm slowly working on this, so stay tuned). We actually did implement a vdefun (virtual defun, which is basically an autoload) for common lisp around here, but we don't use it all that much. In fact, the only common use for it around here is interactively loading Connection Machine software into a lisp world, which is more in line with how Emacs Lisp normally uses autoloads. -- harvard >>>>>> | Robert Krawitz bloom-beacon > |think!rlk topaz >>>>>>>> . rlk@a.HASA.disorg