Thanks. I'm not looking for code templating. I'm looking for an input format with standard validation and transformation tools.
Unfortunately, I'm *also* looking to avoid admitting java into my build chain (shudder). This seems to mean that I'm limited to xsltproc, which supports Relax NG but not XML Schemas. My sense at one time was that Relax NG had "lost" the political battle to be the preferred schema description language. What's a bit weird is that xsltproc supports part II of XML Schema (datatype specifications) but not part I (structure). It's frustrating to me that work on xsltproc proceeds to slowly. It hit a plateau of being "good enough" and then Daniel got pulled into other things. shap On Sat, Sep 28, 2013 at 3:24 PM, david j <[email protected]> wrote: > 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 > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
