[6ren]

A DOM would give the benefits of homoiconicity, though the quote is We want a language that’s homoiconic. As an example, recent versions of Java include the compiler in Java, and therefore the classes for the AST (though undocumented). That's a DOM; you can use it to implement macros. (There's also ANTLR and BCEL to do AST twiddling - just consider them part of the standard classes of a Java variant).

But I think to be homo- (same) iconic (symbols), the language has to be those symbols. By this strict definition, it has to be a lisp. Maybe there's a looser definition possible, between a DOM and Lisp. I think a parallel lisp-syntax would do it (i.e. you can write everything using a lispy syntax; but there's also a friendlier syntax.

hmmmm, you could do this for any language, provided a AST representation (i.e. lispy) syntactically unambiguous with the rest. That subset of the language would then be homoiconic. e.g. add a first-class AST syntax to Java. Is that the kind of DOM you were thinking of?

[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.