macros
in [Lisp]
|
From: Haris Bogdanovi� on 16 Feb 2010 16:11 I don't get the difference between defun and defmacro ? If code is data and data is code then macros are functions and functions are macros and everything is everything and then comes Monty Python's foot on top of that. I don't get what's about that 'get it' in lisp ? That code and data can be and is represented as a tree ? Not much of a 'get it'.
From: Mark Tarver on 16 Feb 2010 16:35 On 16 Feb, 21:11, "Haris Bogdanoviæ" <fbogdano...(a)xnet.hr> wrote: > I don't get the difference between defun and defmacro ? > > If code is data and data is code then macros are functions and functions are > macros > and everything is everything and then comes Monty Python's foot on top of > that. > > I don't get what's about that 'get it' in lisp ? > That code and data can be and is represented as a tree ? > Not much of a 'get it'. People might give various answers to your question. But here is one. The great usefulness of macros lies in their ability to change the default flow on control, which like many functional languages, is strict applicative order. But sometimes you don't want that, and there are certain functions which absolutely require you to change that flow. For instance, in my work I wanted to define my own 'if' that worked with 'true' and 'false' and not T and NIL. A simple definition is (define if true X Y -> X false X Y -> Y) But that's no good because my 'if' evaluates all of its arguments. Hence I need to change the flow of control. A macro does that. (DEFMACRO if (X Y Z) `(LET ((*C* ,X)) (COND ((EQ *C* 'true) ,Y) ((EQ *C* 'false) ,Z) (T (error "~S is not a boolean~%" *C*))))) Mark
From: refun on 16 Feb 2010 17:08 In article <hlf1mo$4ge$1(a)gregory.bnet.hr>, fbogdanovic(a)xnet.hr says... > > I don't get the difference between defun and defmacro ? > Functions are executed at runtime(whatever runtime is), macros are special- purpose functions executed at compile time. A DEFUN registers a (global) function under the symbol that names it. A function evaluates its arguments from the first to last, like a PROGN. DEFUN is a macro itself. A DEFMACRO registers a (global) macro function under the symbol that names it. A macro function is a function which receives a form, an environment, does processing on that form and returns a form to be used in place of it. It's basically a code transformation. The form it receives is quoted, and the result is usually such an expression too (which can be evaluated). DEFMACRO defines a nicer syntax over it as it usually allows you to destructure your form. Obviously, since macros are expanded at compile time, you cannot access the lexical environment or anything that would be available at runtime. It's nothing more than a code transform. This is also a reason why you probably don't want to have your macros generate side-effects at compile-time (if you want side-effects, expand it into a SETF form or something similar, which will be ran at runtime). DEFMACRO is a macro itself, it's syntax sugar for generating a function which destructures a form, parses it (body), and assigns/places this function in the macro namespace under the named symbol (like: (setf (macro-function name) fun)). There are some more subtle things here, such as the form that DEFMACRO receives and returns are actually Lisp data objects, and not text. This allows for nice things like generating gensyms within the macro and using them to represent various objects which are EQ. > If code is data and data is code then macros are functions and functions are > macros and everything is everything and then comes Monty Python's foot on top > of that. That's pretty much it, however there are various ways to break vicious metacircular cycles if you want to implement a Lisp. > I don't get what's about that 'get it' in lisp ? > That code and data can be and is represented as a tree ? That's a short term for saying Lisp is a homoiconic language. This property allows for easy to implement real macros, and EVAL. It simplifies parsing, and allows the user to operate on ASTs, an option which he would get in non- homiconic languages only by writing their own parser. > Not much of a 'get it'. Easy metaprogramming is a very useful feature which can save you quite a bit of time if you use it.
From: Haris Bogdanovic on 16 Feb 2010 17:40 Can I make my own code forms like, for example: (for i in list do |i| body ) or everything is in form of (macro-name arguments) ? Or here would 'for' be a macro name and everything else an argument ? That 'body' would also be just an argument ?
From: Barry Margolin on 16 Feb 2010 17:48
In article <hlf6ts$ehl$1(a)gregory.bnet.hr>, "Haris Bogdanovic" <fbogdanovic(a)xnet.hr> wrote: > Can I make my own code forms like, for example: > > (for i in list do |i| > body > ) > > or everything is in form of (macro-name arguments) ? > Or here would 'for' be a macro name and everything else an argument ? > That 'body' would also be just an argument ? Yes, you can do this. That's how LOOP is implemented, for instance. -- Barry Margolin, barmar(a)alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group *** |