Ah, only now I see what you were even trying to do. Let me explain why I think not having unpack is a good idea:
In clojure syntax, (G (F x)) is, under all circumstances - even if F is a macro -, G called with a _single_ argument, which is the result of (F x) Even if we had smth like unpack, i.e. multiple return values, it wouldn't work on macros like cond. Im pretty sure that you can't use Lua's unpack to fill the branches of an if. Even if we had unpack _and_ somehow found a way to make it work on macros, it probably wouldn't do what you expected. By the time the values get returned an unpacked into a macro, they would have been already evaluated. If the last sentence even made any sense to you at all, please think about your concept of macros and how it fits into the distinction between compile time and run time. Your cond example above only works, because for true, false, 1 and 2 it doesn't matter if they are already evaluated, because they evaluate to themselves without side effects. Concerning your core.logic example: Presumably you have a varying number of branches in you conde. You'd have to find out what the expansion of conde does at runtime and recreate the same for your input. Also s# and u# aren't defined. I hope you don't think of this response as unhelpful. I do think the whole issue arises from a misunderstanding of clojure's semantics and I hope to have helped clarify it. -- 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
