On 13.05.2009, at 02:43, Mark Reid wrote: > Konrad, I agree, it would make more sense to add simple optimisations > like the one for addition to Clojure itself. However, the potential > problem you mention regarding the clash of multiple definitions of `+` > doesn't seem like that big an issue since an optimising macro can just > call `resolve` against the first symbol and see if it is equal to > `clojure.core/+`. Paul's suggestion also seems to get around this > problem.
It's not a really big issue, I just wanted to illustrate with a simple example that global code modifications requires a lot of attention to details. As you say, checking if + resolves to clojure.core/+ is one step in the correct procedure, but it's not sufficient. You need to check first if + is not locally bound in a surrounding let statement, or a surrounding function argument list. And you must expand all surrounding macros first, because they might transform the + into something else as well. In fact, the only practical way to to the kind of optimization you envisage is to do a full macro expansion first, and then walk through the code, keeping track of let* an fn* forms. I have done exactly that recently when writing clojure.contrib.macro- utils, which contains a full macro expansion engine because that's the only way to implement symbol macros and local macros. It was an interesting exercice in macro programming. Konrad. --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
