r177704 - More documentation on the module map language.

[Sean Silva]

Crazy idea, but would it be simpler to just have the module maps be
JSON(/YAML/plist)? That's one fewer parser to write, one fewer language to
learn for users, and easier for tools to consume and output.

Yes, it's a bit unwieldy, but it would enable a whole new set of use cases,
and would make it easier for other compilers (someday) to adopt. One use
case that would follow naturally from a JSON/etc. representation would be
tools that operate on modules as a whole (such as package managers,
centralized package repositories, etc. which I think would be really cool).
Also, strictly from an extensibility standpoint it would trivially allow
adding new features in a backward compatible way, whereas adding new syntax
would break all existing parsers for the format (in the long term, we want
this to be adopted outside clang right? this would ease that). It also
removes all potential syntax bikeshed.

Of course, it's not as nice as a dedicated language to write in, but
realistically, developers really aren't going to be spending that much time
writing these module map files anyway, and it would be nice to have tools
that can spit out an "mostly there" module map file which developers can
then tweak to suit their specific scenario (like adding special flags or
whatever); using JSON/etc. saves the developer of these tools time by
eliminating the need to write special "module map language" output routines.

Using JSON for library/component specifications has precedent for example
in the node.js (npm's package.json) community or web developer community
(bower's component.json). Both of these are battle-tested and have legions
of packages. YAML and plist (which are effectively JSON with a different
syntax) are also used for this purpose in many places.

Just something to think about. I think it might have some interesting
advantages to use this approach, which focuses more on the semantic content
of the module map files than any particular syntax.

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130322/afddb956/attachment.html>