LEESA: An embedded traversal DSL in C++

The LEESA paper is here and the talk slides are here. Another blog already has a post about LEESA. My extended responses to the questions asked by discussant, Tony Sloane, and other attendees of the DSL'09 conference can be found in the first comment.

2 comments:

  1. [Posted for Sumant by Walid]

    Q1. Compile-time and run-time performance: During informal compile-time performance evaluations I observed that compiling expression templates is not really slow. However, if there are many different expression templates in one source file, the compilation slows down. The thing to remember is that LEESA's syntax is quite succinct and that means writing multiple expressions is equivalent to compiling a LOT of traversal code all written in one file.

    On the other hand, compilation of FullTopDown on a large schema is quite slow and memory intensive. Clearly it stretches compiler's metaprogramming capabilities to the limit. Once again, it must be remembered that a FullTopDown visitation of a large schema is a lot of visitation/traversal. Although equivalent code is only one line in LEESA, it is semantically quite rich and statically checked, which must be accounted for. Run-time evaluation is still future work. Informally, C++ inlining should be able to reduce function call overhead to close to nothing. Movable types, perfect forwarding of C++0x should further improve the performance.

    Q2. Terminology correction: It was identified that LEESA's approach is NOT pure embedded because it depends on the code generator to externalize the schema information.

    Q3. Higher-level traversal schemes: LEESA is full-fledged incarnation of Strategic Programming so supports high-level traversal schemes, which are composed from small primitives. A library of traversal schemes is available in LEESA.

    Q4: Learning efforts: Learning LEESA is simple particularly for those who are familiar with XPath. The efforts are amortized over time as you apply it over and over. Personally, I find using plain old OO API for traversal quite inconvenient now.

    Q5: How to evaluate effectiveness of DSLs quantitatively: Remains a difficult problem. Reduction in LOC is a coarse grained but helps motivate the end user.

    Q6: Why not throw all this and use attribute grammars instead: The world has adopted XML, XSD with open arms. Lot of traversal code has been and being written using old fashioned purely OO traversals, which can benefit by LEESA's generative approach. However, schema compilers should be extended (little-bit) to externalize the static meta-information. This task is quite simple compared to what they already do.

    Comments are welcome!

    ReplyDelete
  2. One of the attendees suggested (in a different talk) use of "how many times compiler was invoked" as a measure of productivity. I'm pretty sure LEESA will require fewer invocations because you essentially write 85% less code!

    ReplyDelete

Note: Only a member of this blog may post a comment.