Hacker News new | ask | show | jobs
by apalmer 4005 days ago
I dont really understand the downvotes... I agree with you would go nuts.

My two cents, if your macro is expanding to thousands of lines of code, your doing something wrong I think. I would expect Macros to expand out to a few lines of code which might have function calls that themselves may contain however many lines of code... but expanding to thousands of lines INLINE via macros seems wrong.

5 comments

Some macros expand to a lot of code, especially when doing more in-depth transformations such as those performed by core.async in Clojure where they transform standard sequential code into a state machine with exactly the same semantic but with the added ability to execute, yield and resume like a coroutine.
I assume their macros do compilation of an expressive DSL to efficient low level code, as one would expect in their domain. So keep in mind that this is something pretty fancy you can pretty much only do with Lisp (or by writing a full blown compiler).
You're getting a lot of pushback on this, but I think it's a legitimate question at the very least. In this situation I would wonder whether some procedural abstractions could be introduced to cut down the size of the expansions.

And before anyone jumps on me -- I have 35 years of Zetalisp and Common Lisp experience and have written some pretty hairy sets of macros. There might turn out to be no easy way to make the expansions smaller, but there's nothing wrong with asking the question.

I have pointed to the call-with-* style which is a general "best practice" for that (it's even mentioned in Google CL Style guide). However, expanding to low-level stuff also has it's benefits for a clearly delimited space (mainly, performance) if you know what you're doing