Tcl I heard has string-based homoiconicity. Otherwise, I'm yet to see a proof you can get an actual, usable and not incredibly annoying macro system working without turning your language into a Lisp. People keep trying, but it's always some inelegant subset bolted onto the core syntax.
I love using Julia, but for me writing Julia macros came with a steeper learning curve than in Lisp / Scheme, due in part to the syntax. I kept wishing Julia was a layer on top of a Lisp, and that I can just write Lisp macros. (I know the parser is currently in Scheme, but you can't exploit that easily.)
I tend to end up writing `Expr` objects directly when I'm building larger macros as I find them much easier to reason about. It's clearly not as convenient/clean as Lisp though. (David Moon actually sent a PR last year to make hygiene much easier.. unfortunately it got stuck for a while, but the PR was recently rebased and hopefully will be merged eventually).
Regarding the learning curve: we rewrote the first half of the Metaprogramming section of the manual a few months ago to try to provide a more gradual introduction, especially for people without a Lisp background. Objectively I don't know if the change has helped, but I tell myself that the number of macro-related questions has gone down :)
We would really like to make these tools accessible to people both with and without a formal CS background (probably the majority of Julia users will fall in the latter category). So, if you have any suggestions for doc/pedagogy improvements in this area, I would be very happy to hear them!
We talk sometimes about having an additional reader to support another syntax ... but so far, it isn't something where someone's actually volunteered to step up and help. It'd be interesting to play with some ideas from David Moon's PLOT as well ...
Take a look at Converge, Nemerle, TH and many other similar languages - they're doing just fine without any homoiconicity. All you need is a decent quasiquotation.
Thanks for the pointers, I never heard of those languages before.
I am actually looking at the Converge documentation on macros now, and I found the perfect quote to highlight the problem I see with those approaches:
Quasi-quotes allow ITree's to be built using Converge's normal concrete syntax. Essentially a quasi-quoted expression evaluates to the ITree which represents the expression inside it. For example, whilst the raw Converge expression 4 + 2 prints 6 when evaluated, [| 4 + 2 |] evaluates to an ITree which prints out as 4 + 2. Thus the quasi-quote mechanism constructs an ITree directly from the users' input - the exact nature of the ITree is of immaterial to the casual ITree user, who need not know that the resulting ITree is structured along the lines of add(int(4), int(2)).
That is, quasi-quotes take some code and turn it into a tree object. This tree object can then somehow get compiled into actual code later. Compare that with Lisp approach, in which code is data. You don't think about the code as something separate from the tree that represents it. The code is the tree. There is no ITree object.
It may seem like just "semantics", but I find this to be a significant cognitive difference.
> Compare that with Lisp approach, in which code is data.
It's not any different. It does not matter if your `(,a ,b) is compiled into (list a b), or your ` \a\ = \b\` is compiled into make_binary('=',a,b) - both are constructors, essentially.
