Steven D'Aprano <[EMAIL PROTECTED]> writes: > With Lisp macros, even that isn't guaranteed. Now, if Lispers would say > "Oh yes, macros give you great power, and with great power comes great > responsibility. Be careful." then, no doubt, we'd take you guys more > seriously. But we don't hear that -- we hear Lispers going on and on about
And, of course, we do say that. Nobody wants people running around writing incomprehensible macros. How does that help anyone? Fortunately, it's not a problem in practice, because most macros map quite straightforwardly to Lisp constructs and almost no one has the time or the intelligence to write the mini-languages that seem to be terrifying you so much. > how great it is that they can easily redefine every corner of the > language. Do you blame people for *believing them* and imagining that > reading Lisp code is like following some ghostly will-o-the-wisp across a > swamp, where nothing is what it seems and the landscape is forever > shifting? "every corner of the language"? Please. Why are you so post-happy when it's quite obvious that you don't know enough about Lisp to attack it? Most programmers do not write macros that are incredibly difficult to understand. Beginners might, but beginners might also write incomprehensible code in Java or Python. As you learn Lisp, you learn to keep your macros tied to the underlying Lisp. You learn to make the expansions into function or method defintions, instead of reinventing the wheel. You leverage what Lisp offers, instead of redefining it. The only times you are really going to find completely alien semantics are in textbooks (like Prolog in Lisp), in very ambitious and large projects where the new semantics are the only reason you'd use the code in the first place (like Franz's AllegroProlog or Marco Baringer's CPS transformer), or in code written by beginners. Please stop spreading FUD about this. In real life, macros make coding more pleasant and make your code more maintainable. They are something to embrace, not something to fear. To provide a more solid example, Peter Seibel's book _Practical Common Lisp_ (full text at http://www.gigamonkeys.com/book) provides a set of classes for parsing binary files. Some user code provided in the book: (define-binary-class id3v2.3-tag (id3-tag) ((extended-header-size (optional :type 'u4 :if (extended-p flags))) (extra-flags (optional :type 'u2 :if (extended-p flags))) (padding-size (optional :type 'u4 :if (extended-p flags))) (crc (optional :type 'u4 :if (crc-p flags extra-flags))) (frames (id3-frames :tag-size size :frame-type 'id3v2.3-frame)))) This code very closely mirrors the standard DEFCLASS in Common Lisp, so a maintainer knows right away what to expect. The macro expands into DEFCLASS and DEFMETHOD forms. There's nothing mysterious going on here; the macro is just a friendlier syntax for expressing an idea. What I get from this are methods that read binary data into objects of the class that I've just defined (*). That's all - methods and a class. There is no mind-bending going on at all here. It's true of course that I have to understand how the macro works. But without it, I'd have to write and/or read through a lot of similar-looking code for handling binary data. Which would you prefer? Without a macro like this, the code required would be the definition of boilerplate. Instead of specifying declaratively the order and type of fields in the binary file, I would write code to read each field from the file and then store the result in an object. I'd also have to take into account fields that are optional. This is ugly and boring code. Did I mention that DEFINE-BINARY-CLASS also defines methods to save these objects back to binary files? Because it does. So why not write this code once and then take advantage of it in the future to get more expressive, less boring programs? * If you don't believe me, here is the expansion of the code I cited above: http://paste.lisp.org/display/31799 Just methods and a class. -- http://mail.python.org/mailman/listinfo/python-list