[ken]

Good point. I guess I'd agree that it "has to be those symbols", but not that it has to be a Lisp. I don't know Java's new AST classes, but if I could say something like:

    public class HelloWorldApp {
      public static void main(String args[]) {
        System.out.println("my class name is: " + HelloWorldApp.Ast.Name);
        System.out.println("i have " + HelloWorldApp.Ast.Methods.Length + " method(s)");
      }
    }

then I would consider that "homoiconic": the things I'm defining are objects in the language itself. It doesn't sound like Java does that. My guess is that the AST is only available for text you pass to the compiler at runtime.

That's a problem, in Java: the compilation model is so constrained that even if you could write this, I don't think you could use it to make macros, since there's no way to control "read-time" versus "compile-time" versus "run-time" as you can in Lisp. So perhaps homoiconicity isn't enough: you need that, plus something like EVAL-WHEN.

[6ren]

That's your DOM idea; I'd argue it's not homoiconic, because it's too indirect. But I wouldn't argue very strenuously as I don't know the actual definition of homoiconic. :-)

You're right that the AST is available only for passed text; I hadn't thought of that as a limitation, but you're right. I was thinking of macros, that you define and manipulate within a program: the limitation doesn't affect this use case. Doing it this way, you also get control of {read,compile,run}-time.

I think it's fair to say there are degrees of homoiconicity; you can get some of the benefits by having just a subset of the features. I conject that "a language with full homoiconicity" is identical with "a lisp" - but it doesn't really matter, if we're interested in benefits.