Ovidiu Predescu's Weblog

American Deserts

I just came back from a short trip to Southern California and Nevada. I noticed I visited Death Valley in the same day as James Duncan Davidson, although he was four hours earlier than me. It turns out this was perhaps better for me, we had a gorgeous day, very sunny and warm.

Other places I visited were the Huntington Library, Art Collections and Botanical Gardens. The gardens feature an incredible collection of cacti (plural form of cactus), with over 5000 species from all over the world.

We also hiked at Calico Tanks in Red Rocks State Park in Nevada, just 10 miles west of Las Vegas. My son, who's only 3 1/2 years old, did an incredible job hiking this not-so-easy trail.

Unfortunately we arrived too late in the afternoon to be able to see Valley of Fire. We'll surely return here, it is a great spectacle of nature and its elegance.

As for Las Vegas, its ligths could be seen as a glow in the sky from as far as Armagosa Valley, a small town at the entrance of Death Valley, more than 100 miles from Las Vegas! I don't like this city, it's built as a huge entertainment park for adults, with a dubious architecture and too much excess everywhere. And smoking just kills me, it is everywhere around you, even in the so-called non-smoking hotel rooms.

I'll post some pictures in the coming days, there are too many to deal with right now.

Updated Emacs binary for Jaguar

I've updated the binary package for Jaguar with a new version from CVS which seems to fix the crash problem that appeared in the previous version on each update of the operating system. Emacs would just segfault on each startup after the operating system would be updated.

Andrew Choi pointed out to me that some time ago Steven Tamm found a fix for this problem on emacs-dev. His fix seems to indeed solve the problem: I've compiled the package on 10.2.2 and it successfully survived the upgrade to 10.2.3, recently released.

So if you're running on MacOS X Jaguar and like Emacs, download the new Emacs binary package now!

Lord of the Rings: The Two Towers

I just got out from the premiere of The Lord of the Rings - The Two Towers: Excellent!!

If you haven't read the books yet, do yourself a favor and read them before you see the movie! If you haven't seen the first movie, get the DVD and watch it first! This movie has no time for introductions, it's incredibly packed. Even after reading the books, it's still amazing to see how well the movie flows and how extraordinary well the tension from the book is captured in the movie.

The movie started just after midnight and ran for 3 full hours. Most of the scenes are just incredible, the actor's play, the scenery, costumes and all the armory and special effects are a real work of art. Gollum, a computer generated character is incredibly realistic. Watching the movie completely transports you in the world described by Tolkien in his books.

One thing I thought could have been done better were the Ents and Treebeard. Their human representation is something that I didn't quite like, I would have preferred to see them represented as real trees, with no legs.

This thing aside, it's the best movie I've seen this year! The special effects are by far the best. Check out this article about the making of the battle at Helm's Deep. The techniques used are truly innovative and the quality of the algorithm can be seen on the screen, it's just impressive.

In short, a must-see movie! I'm glad I went to see it at this late hour, it was well worth it. Now I need to get some sleep, I have a long day tomorrow :)

Heavy thunderstorms

Heavy thunderstorms hit Northern California this weekend, with powerful winds and lots of rain. Many trees, including old ones, were uprooted or simply broken by the strong winds. This weather is expected to last at least until the New Year. More than half a million people were left without electricity during the week-end. Napa Valley, just north of Bay Area, where many wineries are located, was reportedly flooded as a result of the rain.

Quit Slashdot

I ran across this Quit Slashdot! Web site. Funny thing, I agree with most of what the author has to say, there is a lot of crap on Slashdot. The only reason I read it is that from time to time there is still some interesting stuff and comments; however it's becoming less and less often.

Nicola Ken Barozzi has a Weblog

Nicola finally setup a Weblog. Welcome Nicola!

More on Java macros

Continuing the thread on Java language extensibility, Carlos comments on a private email I sent to Joshua Bloch and Gilad Bracha, the spec leads of JSR 201, with Carlos, James and Ken CC-ed on the email, regarding the use of JSE-like macros added to Java.

He points out that we should break the problem in two parts. The first is what should be the syntax used to define macros, and the second what is the syntax the macros are allowed to extend.

Carlos also points out that macro usage allow for the introduction of new keywords to the language, which will soon end up in name conflicts. He argues that we need to introduce namespaces for all these new keywords.

For the first part I agree that we need to discuss the issues involved. Personally I think the way JSE defines macros is good, although it may be hard to comprehend at times, especially for non-Lisp programmers. It's definitely not going to be the usual easy to read Java code, since the reader has to change his/her typical Java procedural thinking. As for the language extensibility part, I think the current definition is good, I cannot think of more ways to extend it or of possible shortcomings.

When it comes to keyword namespaces, I think we should avoid introducing these, or at least we should avoid having to introduce them in the keyword names. IMO this is ugly and has the potential of introducing changes in the compiler (which should be avoided at all costs because of high costs/impossibility in backporting these). I haven't found this to be an issue while programming Scheme or Lisp, and I don't think this could be a real issue with Java.

Another good point raised by Carlos is that macros cannot address things like autoboxing, which is a new feature proposed by JSR 201. I definitely agree. I think the scope of JSR 201 should be reduced to extending the language syntax only in ways which cannot be addressed by macros, currently autoboxing and static imports. The rest of the extensions (enumerations and enhanced for loop) should be defined as macros part of a standard library of macros, addressed either by this JSR or a different one.

A last comment I have is that the macros implementation should be easily backported to older versions of Java, so we can easy their adoption and ease the migration to this new feature.

Control flow gaining popularity

The continuations-based control flow engine, which I implemented for Cocoon on top of Christopher Oliver's modified Rhino JavaScript engine is gaining a lot of popularity.

Miles Elam writes in an email on xml-cocoon-dev:

It's great to see people getting the idea! I've also seen people like Marc Portier delving really deep in the control flow continuations-based code.

I definitely need to find some time and write good documentation on the subject. It should be really useful in spreading the idea.

JSR 201 thoughts

As I pointed out in previous threads, I think the JSR 201 should broaden the scope of the proposed extensions. Instead of proposing just some minor syntactic sugars to the Java syntax, it should try to extend the language in such a way that allows unlimited extensibility of the syntax by means of macros.

The idea of macros comes from Lisp languages, which use this to successfully extend the semantic of the language. In Lisp the core runtime engine deals with very few abstractions, everything else is implemented through macros.

A very interesting macro system written for Java is Java Syntactic Extensions (JSE) from MIT, which allows the language to be extended by developers, with no need for a JSR. The scope of JSR 201 for example is already implemented in few lines of code in JSE and is completely portable. No need for compiler or VM changes to support them.

Many of the proposed extensions being talked on Java blogs these days, like functions (with or without closures), blocks and many other syntactic sugars can be easily implemented with a macro facility, as demonstrated by JSE.

Here are some examples taken from the JSE distribution:

• enums

    public enum PowerWarning BATTERY_NORMAL, BATTERY_LOW, BATTERY_CRITICAL;
  

• asserts, which are completely portable, no need to upgrade to JDK 1.4 to use them:

      public void yuk (boolean x) {
          assert(x, "hello");
      }
  

• foreach:

      static void tst (List c, List l) {
          forEach (Integer i in c, Float f in l)
              System.out.println("contents: " + i + " and " + f);
      }
  

• when:

      static void tst (boolean b) {
          when (b) { panic(); }
      }
  

JSE works by preprocessing the extended source code and generating pure Java source code which runs on any Java platform. There is no need for any compiler change or JVM change. Very beautifully done I think!

The beaty of this approach is that one can extend the syntax of the language to support C# annotations, functions , blocks or anything else which is needed using macros and the existing Java language.

Why GPL should not impede using JSE

I've looked at JSE more carefully and I believe GPL should not be an impediment in using it. The reason is that JSE is used as a preprocessor and none of its code is actually linked in the resulting binary. JSE simply transforms everything to pure Java code which should compile cleanly on any JVM.

Now the only question is whether the macros defined by developers are covered by GPL or not. To me it appears that if the macro is just a syntax object, and does not depend on any of the classes JSE uses, the code is clean and the macro could be released under any license. And most of the time developers would develop such macros without going into the guts of JSE.

Java hygienic macros

In a comment on my hygienic macros for Java idea, Ken Meltsner points out Java Syntactic Extensions, a macro system for Java. Great stuff, thanks for pointing it out!!

Check out in the slides how the forEach statement (slide 30) is implemented in the system: the implementation fits in only one slide! The slides also show as example an accessible keyword (slide 39) which, when used to declare an instance variable, automatically generates setter and getter methods.

One thing I liked about the system is that it's procedural, thus potentially easier to understand and master than the declarative syntax macros in Scheme. Even then however, it could still be a challenge to understand and master.

Such a macro system would be the only thing needed in Java, everything else could be implemented using it. This is the case in most implementations of Scheme, which have a very small core and everything else is implemented as macros.

Matthew Langham: #600

Matthew Langham is number 600 in the list of Apache committers! Congratulations Matthew!

Extending the Java language: hygienic macros

The idea of hygienic macros like in Scheme for language with "non-regular", Lisp-like syntax is something which had me thinking for a long time. The challenge is how to provide not only semantics to new language constructs through macros, but also syntactic extensions to the language. Macros are possible in Scheme because of its uniform syntax, the new language constructs introduced by macros are just conventions translated to lower level constructs using the same regular syntax.

In Scheme you don't need any special support in the parser, macros are built entirely within the language. This is possible because of the simple syntax (or lack of it I should say ;) In Java this is not possible, you need compiler support for this to happen.

One idea would be to implement the parser for the Java language in an extensible way, which could allow new syntax extensions to be added at runtime. The only thing we would need to add new to the language is the ability to define "hygienic macros", e.g. ways to extend the syntax of the language understood by the compiler. The compiler's parser would need to be able to read these macros and record their definitions. In the process of doing this it has a chance to verify the new syntax described in the macro is still a valid grammar. During the syntax tree construction, it could invoke the defined macros to do tree transformation, which would transform the extended language into a pure Java syntax tree.

These Java macros would do nothing else than manipulate the syntax tree produced by the parser. Now while this would not be as powerful as Scheme's hygienic macros, it would still be a good alternative for all these language extensions. We won't need JSRs to extend the language in different ways, the only needed is a JSR to define the Java hygienic macro.

I wouldn't expect all the developers to start extending the Java syntax in their own way. Only experienced developers will do it. We could quickly have a library of such useful extensions which become used a lot.

New Java language features (JSR 201)

I dont't think we actually need a full compiler for the extended language to translate to the 1.2 and 1.3 JVMs. Since most of these changes (except enu ms) are only syntactic sugars to the language, thus maintaining the semantics of the language, a source translator could do the job. Unfortunately the source translator would have to do quite a bit of type checking to generate correct code, which makes it a non-trivial piece of code.

I'm sure there must be some tools out there that already do Java parsing, syntax tree construction and minimal type checking. Perhaps we can reuse thos e to create such a source translator. Once the source is translated to plain Java, it can be compiled by any 1.2 and 1.3 compiler. Ant or Maven could automate this process and make it really painless.

Picture gallery

I've setup a gallery of pictures made since I bought my Powershot S30 digital camera. I uploaded some of the pictures I've taken in the past 6 months. Older pictures taken on film still wait to be scanned, as I'm too lazy to take the time to scan them.

Update (June 2010): I disabled the picture gallery hosted on this site after an attack exploiting some PHP vulnerabilities in Gallery. After the post-mortem I've decided PHP is not safe to be run on a web site, and I removed all the PHP code I had on this site.

My current pictures can be found on Picasaweb.