I've at times had similar thoughts. I have used both XML/XSLT and Clearsilver (a similar but different text-transformation system) for code-templating.
XML offers the benefit of schema validation and some amount of content-aware editing in good IDEs. Clearsilver has no data-schema concepts, but it has the advantage that it's template language is based on PHP-like <?cs ?> tags instead of XML, so your template fragments don't have to be well-formed XML, and don't have to use clunky things like > and < (a disaster for templating C code, I assure you) Clearsilver's dataset format (HDF) predates popular use of JSON, but the syntax is close. Things I like about using these methods, in order of priority: 1) I like to keep build dependencies simple, and so I much prefer using a text-templating engine which runs on a VM (JVM/CLR). This keeps my build simple and very cross-platform. I'd rather have one build dependency to solve (aka, have a JVM or CLR), rather than a bunch of custom-authored IDL translators, each written in their own languages, with their own platform issues like the google-protocol-buffer compiler or facebook thrift compiler. 2) text-templating is a nice way of doing compile-time meta-programming, and in some ways offers advantages over language-embedded techniques. For example, it's easy to see and reason about the templated output, and the same input spec can generate code in multiple languages. 3) I like the schema-validation, documentation, and editor-help of XML with XML-schema. (I have not yet tried to use a static XML-Schema/XSLT validator) However, the benefits of schema validation for my uses so far have been far LESS beneficial than the pain of being forced into well-formed XML. In fact, the reason I'm using XML/XSLT is because of #1, they are trivially available in CLR/JVM to simplify the build. I'd prefer to use Clearsilver, but it's written in C and I don't like wasting time on cross-platform build tools issues (I have enough of them in the projects!). Foward looking thoughts include... a) I have wondered if I could solve even more problems this way if I had a straightforward parse/lex to dataset converter (XML, Json, HDF, whatever). For example, to accept Google Protocol Buffer syntax, and use XSLT or Clearsilver to produce output code, rather than relying on their protocol buffer compiler. This would enable the trivial construction of code-transformation DSLs which are more convenient than XML or Json for data-input. b) I'm not clear on what the sweet-spot of these text-transformation techniques are, compared to general purpose programming. For example, most of my code templating use-cases basically have a dataset which drives structured macro-expansion, but not much logic or calculation. To me, the clarity and conciseness of doing this with text-templating tools is *very* apparent. However, I'm not sure what kinds of IDL transformations would have enough calculation to outweigh the benefits of concise text-templating. (note: while both XSLT and Clearsilver are turing complete, they are very inefficient at calculation WRT code-size) c) I have yet to see a great method for "packaging" up a specific application of text-templating as a component. That is, integrating it into IDEs and/or build-tools can still be a bit of a chore. Much better than integrating a bunch of custom IDL compilers though. Visual Studio T4 templating tries to do something here, with a method to compile T4 templates into library functions, but T4 is not a good fit for my use cases. It'ss designed to do one-to-one T4-to-C# code templating, wheras I need a shared piece of "templating software" which drives dataset-to-C# code templating. (If the meaning of this isn't clear, I'm happy to elaborate)
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
