Lambda the Ultimate

Visual editor as an input and Java source as an output was a must have requirement, so we basically had two options: either to use Java source as a model for the editor or to generate that source from some other model.

The first options would be feasible for embedded DSL, but Java is so crippled in embedding that we dropped that option. That left us with codegen option on hands.

Just for record: The things we missed in Java as either host for embedded DSL or codegen target language were:

1. Closures.
2. Parametric polymorphism.
3. Direct support for attaching custom metadata to elements of the language.
4. Auto boxing/unboxing (if we cannot ask for dropping unboxed types from the language)
5. Multiple dispatch.
6. Multiple copies of the same interface on one object.
7. Differentiation between methods using their host interfaces, and not only names.

Well, many others, but I would not bother you :-)

I have some Python code that takes a dictionary with details (names, parameter names, parameter types) of stored procedures in a SQL Server database, creates appropriate ADO command objects based on the contents of that dictionary, creates __call__able objects that execute the ADO commands, and attaches those objects to a "database" object.

The intention is that I should be able to call db.sp_foo(param1="bar", param2="baz") to call a stored procedure, and ask for db.sp_foo.param2 to get the value of a return parameter.

This is effectively a form of code generation, but it happens at run-time and works by adding items to objects' internal dictionaries instead of outputting literal Python code.

I believe that CodeDom in .Net is sometimes used to generate customized parsers for XML documents that conform to a standard interface but have an implementation optimized for a particular schema. This is potentially useful if you need to do some generic processing of XML that includes schema validation, and the schema to be used is not known until run-time.

That's the first time I heard such a request. Could you give an example when you need it, and how you think it should look like in code? F.e. if a method accepts an object with that interface, how could you pass this object and choose which copy of the interface the method is supposed to use?

How would these items stop you? It sounds like you couldn't do things exactly the way you want to, but that will be true generally. Will the autoboxing and meta data in 1.5 help you at all? Will groovy help with some of the other issues?

Generally i think if you can only do something through code generation then that is a concern. But if code generation rests on a good infrastructure anyone can use then that is ok.

Also, macros are code generation, and i don't think those are evil, are they?

Depends on who you ask. ;-)

I would say that both code generation and macros have legitimate uses, but that they are "strong medicine" and you should exhaust other techniques before employing them, and really know what you are doing with them.

The reason for this is that they open the door to certain bugs that are hard to detect.

Andris: Multiple copies of the same interface on one object.

Sjoerd: That's the first time I heard such a request.

Yes, I used bad wording, I actually meant something like ports in CORBA Components. We ended up with component interfaces containing only getters for port interfaces, like:

interface CoolComponent { FooPort getFirstPort(); FooPort getSecondPort(); BarPort getThirdPort(); }

and all business functions located in port interfaces. On the second thought, the lack of a first-class construct for ports is not a problem of Java, I remove that from my wishlist.

As a side-thought: ports in CORBA Components and other frameworks are a step towards capability-based programming.