Why Java Won't Have Macros

bugbear writes "Carlos Perez has just posted a page that quotes Sun Java 'theologist' Gilad Bracha about why there is no plan to add macros (in the Lisp sense) to Java."

Comments

OOP

[sporty]

Just to clarify further why macro's are bad.

The problem with macros, is they sorta defeat Java's OOP. Think of it. Defining a symbol, just to be replaced in thousands of other places where it's written, tied only to the global space.

Sounds awfully like a procedure/function to me.

If you tied macros to objects, they'd just be inline methods. So there really is no point.

Re:OOP

[Dr. Photo]

The macros the article is talking about are Lisp-style macros.

These are not your "shoot self in foot" C macros (i.e. replace text x with text y), but a very powerful and expressive way to have the entire language at your disposal at compile time.

If you've seen the neat tricks you can do with C++ templates (template metaprogramming, etc), you might have an idea of what real macros would be like, when severely watered-down.

Lisp macros make things like Generic programming and OOP very simple to add to a language, as well as almost any other conceivable programming construct.

For instance, with proper macros in Java, you wouldn't ask, "When will templates be added to Java?"; you could add them yourself.

Re:OOP

[Dr. Photo]

It's not obvious to us all. I'm slightly confused on what exactly is happening. It looks recusive... though it prolly isn't.

Actually, you're correct. It defines a syntax for a while loop by creating a function that does (in pseudocode):

def loop() {
if(test) {
do_stuff_in_loop_body();
loop();
}
}

Note that this kind of recursion is a common way to express iteration in Scheme/Lisp, as it is "tail-recursive" (i.e., doesn't require going back to the calling function once the next loop() is called), and is optimized by the interpreter/compiler to be generally as efficient as iteration.

Re:useless

[reynaert]

No, in Lisp macro's aren't used for inline functions , but for syntax extensions. For a demonstration of what real macros can do, look at The Swine Before Perl. That presentation shows how easy it is to implement special syntax for automatons in Scheme, and how natural & simple the result looks.

If this is what Jabba does, then Jabba will lose.

[ArmorFiend]

The crux of his argument is that user defined macros make code unreadable. If users are able to create their own macro constructs, they'll be "making their programs unreadable for everyone else". This is pure hogwash from someone that's probably never used hairy-chested lisp macros seriously. I'll demonstrate to you the hogwashishness in two phases.

Flash-back to 1969 when the same arguments were put forward by assembly programmers against named functions:

User defined functions make code unreadable. If users are able to create their own functions, they'll be "making their programs unreadable for everyone else".

History has show that user defined functions are good. People are finally realizing that lisp macros are perhaps an equally important good. By taking this position, Jabba is positioning itself on the losing side of history.

Seriously, what's easier to read:

// macro-less call
{
window.context().glxMakeContextCurrent();
float[4] color = window.fgColor();
glColor(color);
glPushMatrix() ;
glIdent();
glAlphaBlend( GL_FALSE );
...non-boiler-plate-code...
glAlphaBlend( GL_TRUE );
glPopMatrix();
}

OR

// macro call
withGLDrawing (color) {
...non-boiler-plate-code...
}

If you look at it in terms of lines of code, in terms of error-prone-ness, in terms of high-level versus low-level, in terms of maintainability, ONLY AN IDIOT WOULD CHOOSE AGAINST MACROS.

Okay, sorry for being ornery, but mod this scruffy post up!

Re:useless

[Procyon101]

I politely disagree. Although I have never actually used goto in a program, I can concieve of a severely nested loop with an exit condition that would have to be propagated all the way out of a the loop. This could prove overly complex, having to check for the condition in every loop (perhapse this is a 16 dimentional data structure and we are doing a search and we happen to find the value early by luck). Throwing an exception is an option, but since this might not be an "exceptional" condition, some people might be philosophically opposed to it. In this (extremely rare) case, goto has a very good organization purpose.

Gotos

[r6144]

In some cases GOTOs are very useful, especially in languages like C for error recovery. Look at the many "goto error"s in Linux Kernel code, they cannot look as good in any other C way. Of course in java you don't need to manually destruct things so often, so gotos are not that useful. Multi-level exits are also an important use for GOTO, and IMHO block labels are similar but less readable.

Also, some programs that does loops in irregular ways (such as non-recursive searching programs that backtracks) can be rewritten in a way that is much more readable IMHO. Alas, it is still as hard to make sure such code is correct, since you still have to follow every possible execution path, so it doesn't make the writer's life better.

Macros are not macros!

[mrami]

Just so everyone understands, in Lisp, macros are not text replacement systems. In Lisp, macros are functions that take a set of syntactic forms and return a new syntactic form to the compiler. You're not breaking any OOP principles here, any more than ArrayList breaks them by always using Objects.

So, for example you could write a macro that takes a variable, a list, and a statement and returns a for-loop that iterates over the variable, and call the macro, say, 'foreach'. Or you could write a macro that takes a boolean expression on a set of classes and return a statement block to do some JDBC calls and create a bunch of objects that represent the join of that expression. Or... (substitute here anyting you do on a regular basis that can't be made into a method).