That's not how macros work. They can only operate on the parameters
they're passed, as symbols and lists. If you prepare a value for them
elsewhere, those values will only be available in the macroexpansion
(runtime), not at compile time.
Granted, it would be nice if the functionality were exposed as
functions as well as macros, but that's harder and has to be done at
runtime (leading to the perception of "slow java"). But you definitely
don't want to make a macro work the way you suggest.
On Feb 3, 8:12 pm, Vagif Verdi <vagif.ve...@gmail.com> wrote:
> It would be better if your macro would accept maps and vectors,
> because those can be prepared somewhere else and passed around as
> parameters. Your current macro allows only hardcoding.
>
> On Feb 3, 4:23 pm, Alexander Yakushev <yakushev.a...@gmail.com> wrote:
>
> > >(deflayout frame
> > >{:west gamepanel
> > >:east (deflayout sidepanel
> > >[nextpanel (JButton. "Exit")] :flow :trailing))
>
> > Actually I thought about something like that, but then I decided to come
> > up with something at least a bit uniform.
--
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
