On Aug 29, 3:48 pm, ronen <nark...@gmail.com> wrote:
> In a lot of cases its seems that macros are used even when a function
> can do the same task,
> Macros seems to be less readable than their functional counterparts &
> more complex to write (to me at least).
>
> Its clear that there are special cases in which macros are the perfect
> solution (like partial evaluation of expressions, if-else constructs
> etc..).
>
> Id appreciate any thoughts on this topic.
For me, macros are no less readable than their functional
counterparts.
I mean, really, you are writing a function that returns a list of
things that gets inserted into your code, and with macro-expand, it is
pretty easy to test what your macro becomes.
I think that the biggest thing that macros benefit from is rewriting.
(all code benefits from rewriting, but macros especially). You can't
just 'figure out how to do it', and walk away. Once you figure out how
to write the macro, you have to go back and rewrite it so that it is
clean and decomposed into sub-functions (not sub-macros, sub-
functions). I think this has to due with inexperienced people
struggling with macros, rather than macros being inherently
inscrutable.
For simply in-lining code you would want to use definline or an
inlining declaration.
Macros and functions, beyond having the ability to abstract out a
pattern, are much different.
The big thing is that macros *insert* code, whereas functions call
code.
I think that you can get code that is just as complicated, if not
more, using functions.
Having to wrap something in 8 function calls to pass it to its final
execution context is going to be clunky. (which is why the macro and
the hybrid macro/function version of with-some-foo are better).
WRT boiler plate code removal, I try use a macro whenever I see a
pattern that I can specifically name. (macros get extracted from code
that I already wrote). For example I wrote a macro for writing Rest
API interfaces, it is a macro that creates named functions in a given
name-space at compile time out of a sort of data-structure that I pass
in. It saved me a lot of typing, and while doable with functions,
there was no need...
(that more complex macro I wrote as a series of functions which I in
turn wrapped in a macro).
I mean, if you are careful about gensymming (easy in clojure), and
careful about multiple evaluation, you generally just need to know
what it is that the code looks like and recognize that the computer
will do exactly what you tell it to do in terms of constructing the
code.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
