That really only applies to `define-macro` style macros. You can have syntax-case style macros if the language can disambiguate reading and parsing, which a lot of them have trouble with, and why they don't support them.

sweet.js figured out how to do that in javascript, so we have full syntax-case macros just as easily.

Wait so does sweet.js support arbitrary JS execution in macros now?

Not yet, but it's theoretically possibly with all the groundwork that's already been done. See https://github.com/mozilla/sweet.js/issues/12

So I should have said syntax-rules (for now). My bad!

Seems like you would still need to provide something like syntax objects and a special API to manipulate them?

This involves a longer discussion, and I'm not sure what Tim is thinking along those lines. Suffice to say, Clojure's macros are always going to be the best, but I have pretty high hopes that you can get 95% of the way with sweet.js. :)

Yes indeed. Sweet.js already uses syntax objects internally so the groundwork is there for syntax-case. We "just" need to implement and surface the API :)

Agreed. But it's not like macros without homoiconicity are totally useless. They are just more cumbersome to write.

In Groovy, for example, you have the equivalent of macros in the form of AST Transformations †, that look just like Java annotations, but can actually convert the code their are applied to (or, more specifically, the AST node) and transform it into something else at compile time. Writing AST Transformations in Groovy is not as smooth as writing macros in Lisp, as you have to deal with the AST nodes as objects (there are DSLs for this fortunately), instead of using the same language syntax directly, but they provide awesome metaprogramming capabilities as well. The Groovy standard library includes some very useful AST Transformations and frameworks like Grails use them to a great extent too.

So, i think that, even though macros (or equivalent code transformations) are not very accessible to the average programmer if the language does not have homoiconicity, they can be of great value for library writers. As the linked article shows, they could be used to make something that looks like jQuery but generates much more efficient code :D

† http://groovy.codehaus.org/Compile-time+Metaprogramming+-+AS...

> you have to deal with the AST nodes as objects (there are DSLs for this fortunately)

I tried using D'Arcy's DSL for Grϕϕvy's AST a few years ago but it was very slow.