Java Syntax Extensions

[James Willans]

Hello All,

We have put together a document which outlines a proposal for adding
mechanisms to the Java language which allow it to be arbitrarily
extended, such mechanisms would support Language Oriented Programming
(LOP) and Domain Specific Languages (DSLs). The proposal is based on
some work we have been doing with XMF, an open source industrial
strength language, and all the technology required to implement this
mechanism in Java has been validated within XMF. We are interested to
receive feedback on this proposal and any thoughts are most welcome.
You can download the proposal document called "Beyond Annotations: A
Proposal for Extensible Java (XJ)" from:

http://www.ceteva.com/book.html

More details of XMF can be found on the same site.

Kind Regards,

James

 

[Mark Space]

We have put together a document which outlines a proposal for adding
mechanisms to the Java language which allow it to be arbitrarily
extended, such mechanisms would support Language Oriented Programming

It's a well written document and very accessible to someone who is not
familiar with DSLs. However, I'm rather against anything that adds too
much complexity to the base language. Your examples, brief as they are,
are pretty complex and rather more difficult to read than they really
need to be. I'm not sure I'd like to actually puzzle out new grammars
and new grammar-specifications every time I open a Java source file. I
can't imagine what trying to specify a full grammar would be like. A
horrid mess, I'm sure.

Rather, I don't think you've given enough thought to frameworks and
libraries, as your paper calls them. Look at languages like Scala and
Jython. They are full independent languages that use the JVM. If you
need a DSL, use a DSL. Don't use Java. Then if you need bindings to
access your DSL functions in Java, or to access the Java API from your
new language, well that's I think that's where some opportunities are
for research.

C++ provides the best counter example why we should not accept your
proposal. C++ is a baroque mess. It tries to be all things to all
people and fails by being too complex to use for a full lifecycle. Java
succeeds by being simple enough to maintain while having enough tools to
get the job done. Let's keep that feature. It's Java's primary strength.

 

[Chase Preuninger]

3 things that I want to see happen with Java are...

1)Allow static inside of inner classes
2)Anonymous inner classes can use variables other than final ones
3)Operator Overloading

 

[Patricia Shanahan]

Chase Preuninger wrote:
....

2)Anonymous inner classes can use variables other than final ones

What semantics would you expect this to have? Value of the local
variable at the time of construction of the anonymous class instance?
Value of the local variable at the time of reference?

Patricia

 

[Mark Space]

3 things that I want to see happen with Java are...

1)Allow static inside of inner classes

This I don't see the value of. How would this be different than simply
declaring a static field in the outer class?

2)Anonymous inner classes can use variables other than final ones

Physically I don't see how this would even work. To get a local or
other variable into an anonymous inner class, assign the vale of the
variable to a new final variable of the same type. (Clear as mud,
wasn't that?)

for( int i = 0; i<MAX; i++) {
final int j = i;
addListener( new Listener() { //... use j here..
} );
}

Here, I just make a final int, j, so that I can use it in an anonymous
inner class. You can do this with any other variable. As Patricia
says, if you have some other semantic in mind, you'll have to implement
it yourself.

3)Operator Overloading

Ack! Thpfff! *hurl* No way. Worst idea ever. Leave the operators in
the hands of the language writers. That's the best option, because
programmers will go all over the map if allowed free reign to alter the
language. See the first post on this thread.

 

[Roedy Green]

2)Anonymous inner classes can use variables other than final ones

That request logically does not make sense, though I agree it is an
nuisance to create the finals. I explain why at

http://mindprod.com/jgloss/nestedclasses.html#ANONYMOUSVISIBILITY

This piece of Java syntax makes me cringe.

 

[Patricia Shanahan]

Chase Preuninger wrote: ....

Ack! Thpfff! *hurl* No way. Worst idea ever. Leave the operators in
the hands of the language writers. That's the best option, because
programmers will go all over the map if allowed free reign to alter the
language. See the first post on this thread.

I get very offended by this point of view. I would not choose to use
"+" for string concatenation, or ">>" for data input, the sort of thing
language writers have been known to do. I just want to use arithmetic
operators for arithmetic operations.

I realize that Java will probably never make it as a language for
numerically intense work, but the clunky syntax for complex arithmetic
cannot help.

Patricia

 

[Roedy Green]

3)Operator Overloading

I could have strangled Stroustrup and his overloading of the shift
operators in C++ to do I/O. Java has the entire Unicode character
set. There are plenty of unused symbols. There is no need to overload
and confuse the meaning of the currently defined operators with
overloading.

I would like however to define new operators in Java, just as you can
in Forth, but not overloading the primitive operators, using symbols
like Circle Plus.

I find even Java's overload of + for both addition and concatenation
infuriating. see
http://mindprod.com/jgloss/gotchas.html#CONCATENATION

To the mathematician, it sounds like a good idea, but in practice,
e.g. in C++, it primarily becomes a technique for writing
impenetrable code.
see http://mindprod.com/jgloss/umain.html
Mathematicians have dozens of fonts they use to help sort out what you
really mean by (+).

 

[Roedy Green]

1)Allow static inside of inner classes

That one I find strange. I don't understand why that restriction is
there. There must be a per-class object anyway for inner classes.

 

[Mark Space]

I get very offended by this point of view. I would not choose to use
"+" for string concatenation, or ">>" for data input, the sort of thing
language writers have been known to do. I just want to use arithmetic
operators for arithmetic operations.

If I understand you correctly, then in my defense I'll point out that if
operator overloading were part of the language, the offenses would be a
lot worse than using "+" for String concatenation.

I'm sure there are better ways to implement these kinds of conveniences
like a single binary operator for string concatenation, but I'm just
happy that "+" is one of the few overloaded operators that I have to
look out for. I can surely imagine a worst case far worse than that.

Java succeeds, imo, by being a relatively simple, common language that
everyone uses, even if it isn't ideal. I know any program I get in Java
to review or maintain will use operators in exactly the same way. I
have to look out for "+" and maybe a few others, but I know about them
and I can train myself to be aware of them. I can't re-train myself
each time I open a new source file.

As a comparison: as much as I love the preprocessor in C (it was such a
cool idea in 1980), it's a huge mistake. It suffers from the same sorts
of abuses (sometimes worse) as operator overloading.

 

[Patricia Shanahan]

Mark Space wrote:
....

Java succeeds, imo, by being a relatively simple, common language that
everyone uses, even if it isn't ideal. I know any program I get in Java
to review or maintain will use operators in exactly the same way. I
have to look out for "+" and maybe a few others, but I know about them
and I can train myself to be aware of them. I can't re-train myself
each time I open a new source file.

....

Given the capabilities of modern IDEs, I don't think it should be up to
the programmer to look for overloaded operators. An IDE could use a
different color for overloaded operators than for language-defined
operators, and a quick option to display the declaration.

Patricia

 

[Arne Vajhøj]

Given the capabilities of modern IDEs, I don't think it should be up to
the programmer to look for overloaded operators. An IDE could use a
different color for overloaded operators than for language-defined
operators, and a quick option to display the declaration.

I don't like the idea of adding features to a language that assume
a colour coding IDE.

Arne

 

[Arne Vajhøj]

I could have strangled Stroustrup and his overloading of the shift
operators in C++ to do I/O. Java has the entire Unicode character
set. There are plenty of unused symbols.

Non ASCII operators would create tons of problems for
primitive development environments.

Arne

 

[Arne Vajhøj]

However, I'm rather against anything that adds too
much complexity to the base language.

C++ provides the best counter example why we should not accept your
proposal. C++ is a baroque mess. It tries to be all things to all
people and fails by being too complex to use for a full lifecycle.

There are even worse examples. C++ actually still lives.

PL/I and Ada95 was even more complex than C++. And even though
they are still used, then they are definitely in decline.

Arne

 

[Roedy Green]

To the mathematician, it sounds like a good idea, but in practice,
e.g. in C++, it primarily becomes a technique for writing
impenetrable code.
see http://mindprod.com/jgloss/umain.html

oops http://mindprod.com/jgloss/unmain.html

 

[Roedy Green]

Non ASCII operators would create tons of problems for
primitive development environments.

Good. That would discourage frivolous use, and would encourage
proper tools for writing international code.

 

[Roedy Green]

This I don't see the value of. How would this be different than simply
declaring a static field in the outer class?

It would restrict the scope to the inner class. It is confusing to
have a variable declared at a broader scope than it is actually used.

It is mildly wicked for the same reason global variables are wicked.

 

[Roedy Green]

I don't like the idea of adding features to a language that assume
a colour coding IDE.

i do. See http://mindprod.com/project/scid.html

I think the notion of a computer programming specifications purely as
ascii text manipulated with glorified word processors is really
holding things back. It is so sixties.

 

[Patricia Shanahan]

Chase Preuninger wrote: ....

Ewwwww!

I notice that there are workarounds already in the language for each of
these "features", and that they are all features that allow for looser
coding, but risk more difficulty maintaining code. This is a priority
inversion.

However, the combination of a very limited set of primitive arithmetic
types and the lack of operator overloading also risks increasing the
difficulty of code maintenance - or forces people to avoid Java for
anything that has non-trivial arithmetic expressions in any types other
than the Java numeric primitives.

Patricia

 

[Ulrich Eckhardt]

Roedy Green wrote:
[about Operator Overloading]

I could have strangled Stroustrup and his overloading of the shift
operators in C++ to do I/O.

That wasn't him, I think it was Barry Schwarz that wrote the IOStreams
library which was later in a modified version incorporated into the
standard. Further, the use of '<<' for output wasn't even new there.

Java has the entire Unicode character set. There are plenty of unused
symbols. There is no need to overload and confuse the meaning of the
currently defined operators with overloading.

1. They are already overloaded, as you yourself say below.
2a. Please suggest one of the mentioned Unicode characters to use for adding
two 3D vectors.
2b. Please suggest one for use with 2D vectors.
2c. Tell me how to type that one on a Dvorak keyboard. :/

To the mathematician, it sounds like a good idea, but in practice,
e.g. in C++, it primarily becomes a technique for writing
impenetrable code.

That claim that operator overloading in C++ is mainly a technique that
obfuscates code is in my experience wrong. However, I'd say that at least
80% of all C++ code I have seen is of bad quality, regardless of how it
achieved that quality, which is partly also due to the language itself
being _extremely_ complicated. The price for using a sharp tool is that you
can cut yourself and that is especially true for C++.

Uli