https://github.com/json-schema/json-schema/wiki/switch-(v5-p... http://www.ibm.com/support/knowledgecenter/SSEPEK_11.0.0/jso... https://www.npmjs.com/package/lib-jsl http://jsonnet.org/language/design.html
On the other hand, this language is bananas because the programmer is writing the AST and that is what a parser is supposed to do for him/her. Manually coding the AST is like harvesting an acre of corn by hand. If you can find a more inefficient method, then by all means use it.
And just for good measure, XML is not a "data description language", it is a type system; probably the most complex type system I've ever seen and it wasn't a bad idea, it was simply more complex than any application would ever need.
I don't dislike XML, and I think it will continue to live just like Haskell because every generation will come to understand that its extreme faith in generalization has little practical use just about the same time that a new generation first discovers it. So while one is dying to simplify, the other is dying to espouse the existential core of computer science.
XML means "eXtensible Markup Language" - so pretty much exactly a description of the data it contains. Granted, you can mark up a bit of data with a type, but you can mark it up with anything else as well.
I've even seen entire programming languages built upon XML.
That could actually be a really fun language: "you can write this in Haskell-syntax, Python-syntax, or C-syntax, we don't care, just make sure that you enclose it in the corresponding
<parse-as lang="c">
// ...
</parse-as>
Sort of like the PL equivalent of Lennon's Imagine.
This is the belief that Eric Browne argued against in 2003[1]. "exactly a description of the data" only works when a human looks at it, which is the same argument for JSON. These two things "describe" the same object:
<person><firstname>Eric</firstname></person> { "person" : { "firstname":"Eric" } }
But using Browne's argument, a parser might see these objects as:
<hshhd><uueus>Eric</uueus></hshhd> { "hshhd" : { "uueus":"Eric" } }
How does that description help the parser?
What I'm saying is that XML is system for defining types, subtypes, relationships, etc. and that this type system can be used by programs that are written to interact with document instances in a way that is not dissimilar from other statically-typed languages. In a sense, you're agreeing when you say that XML has been used for programming languages because, in that case, a document instance might contain blocks of programming statements not instructions for a machine. It must be parsed and compiled first which takes some knowledge of the type system, i.e. how to create AST's and transform them into instructions.
I'm also saying that the problem with XML comes from the inability to reason about type systems in a general way. I can give you my XSD but will you know what to do with my data? And if I give you the XSD, and I tell you what to do with the data, then won't we writing the same program? Wouldn't it be easier to just share a library?
[1] http://workflow.healthbase.info/monographs/XML_myths_Browne....
Of course, that flexibility is what burdened us with SOAP, XBRL, and other monstrosities; but I blame the creators of SOAP, not XML. XML is the "C" of the data markup world (simple but flexible), whereas JSON is more akin to "Java" (heavily restricted in capability, resulting in workarounds to represent complex concepts).
{ "hshhd" : { "uueus":"Eric" } }
Unless it is Lisp s-expressions.
Also when real programmers have to interact with those systems (and my practice shows, that business users don't want to program, they ask programmers to do it), it's so much pain to use those GUI languages or whatever and it's so easy just to write some code in sane language.
It's also a potential security risk - the downloaded script could perform things other than logic and so would require sandboxing/whitelisting of commands.
Putting logic in JSON avoids both of these issues since the actual handling of the logic is performed by a client-side library.
My point is that for the purpose of letting some non-trusted instructions run safely in a program, encoding them as JSON or Lua will come with the same caveats. Ultimately, they are both interpreted and can be sandboxed thus. Neither contain any code that will be passed off as-is for the CPU to execute. In some cases, neither does an ELF blob.
- html/xml has become the definitive declarative ui language since it generally acts exactly how we expect it
- css queries and xpath have been effective at providing a way to search a structured tree
- regexp hqve provided us a way to search or structure strings
I dont find it absurd to believe that there can be a language for transformations