Lambda the Ultimate

I would be more than dubious, I would be outright challenging if this was said at a conference; there is an xml project putting c++ into xml format, with a compiler etc. (don't want to go look for it right now it could take hours) and yes a simple transformation from that to actual c++ is one of the stated purposes, this on the other hand...

well anyway, one interesting thing about xslt is that most of the processors out there have extensions that bind to a particular programming language, this means that it would be possible to use the xslt as a execution environment for an xml version of the language, as I was struck with this particularly silly idea some months ago I built a quick demo using msxml to execute jscript and vbscript, python using ActivePython would also work of course but the indenting rules would be hell to get right.

The original demo had a model wherein all elements in the js namespace were evaluated by the jscript interpreter, all elements in the vbs namespace where evaluated by the vbscript interpreter, all other elements were copied to the output of the transformation. Another transformation that instead of evaluating the marked up program output it to a non-marked up form would be simple to do.

However a transformation between the two languages, no, not in xslt 1.0, probably not even in 2.0

I think all this interest in programming languages in xml format is that it would allow the direct manipulation of the xml tree, thus bringing us to fourth generation languages via another route.
With that idea in my head I also did a demo mixing the js namespaced markup with GraphML, the transformation would be called with an entry point for the graph, starting at the node specified by a parameter, then the jscript extensions had the possibility of effecting program flow by choosing what edge to follow at different points.

I mention it because, although silly, it was great fun and I think it does indicate, accidentally through the providence of most xslt processors coming equipped with other language interpreters, how a better xml-based programming language might be designed.

I'm considering setting up such a toy project about program transformation using off-the-shelf components (namely XSLT for transforming AST) to quickly get a working prototype.

Since both of you deem such an endeavour doomed, I'd very like to hear your arguments apart "XSLT syntax is painful" (I agree).

Thanks.

This isn't a field I know that much about, but it seems to me that there's more to program transformation than tree transformation (which is what XSLT essentially does). You have to analyze the tree you're transforming, and then perform transformations based on that analysis. XSLT falls down somewhat when it comes to summarizing or reasoning about the structure/contents of the document it's transforming. It's not that it can't be done, just that there are no end of better (quicker, easier, more concise) ways to do it. I've even found this when trying to produce MI reports based on XML-formatted data - for even slightly complex queries, XSLT just wasn't the right tool.

I generally use XSLT for styling and templating, and it's acceptable for those purposes, but it just isn't a language I'd want to do any real programming in, and program transformation looks like real programming to me.

I don't know - maybe for some simple things like loop unrolling it might be feasible. But (language foo)-to-C++ transformations? If it were that easy, we'd all be doing it.

I don't necessarily consider xslt the wrong tool for such a process, however in order for the xslt not to be painful your tree would have to be extremely verbose in order to be able to reason properly about the tree, the problem is coming up with a useful syntax that allows you to reason about the tree. marking things up as object, variables, functions etc. is not, I fear, abstract enough.

Furthermore if you're not already very good at xslt, by which I would say at the level where you can read the transforms of Dimitre Novatchev http://www.topxml.com/members/profile.asp?id=i1005
and not be hopelessly lost (lost with hope of finding your way is acceptable)
it would indeed be very painful, I myself do not think xslt is especially painful, however it takes a long time to understand it, at which point many things become reasonably easy.

Anyway, since such a solution would require verbosity on the part of the input data it would probably be painful on the input data side, unless you used some preprocessor like pxsl
and even then it might be painful.

I've seen some of the Novatchev transforms before (some similar material is also covered in the final chapter of the O'Reilly XSLT Cookbook). They remind me a little of Alexandrescu's adventures in template metaprogramming: very clever, but not the way I'd want to go about doing those things if I could possibly help it. The pain here is not in the difficulty of understanding how to use things like curried functions and combinators in what is effectively a pure functional programming language (hey, I bet you could do monads too! anyone wanna try?) but in knowing that you could be doing it in Scheme or Haskell instead.

I was thinking about this earlier, in relation to the C++ thread (Coplien and Alexandrescu are among the notables involved in the initiative under discussion; both have written books that I rate very highly as books about programming, although the combined effect of those books was to make me want to forget about using C++ and look for something in which the same concepts could be expressed less ponderously). You can layer RDF over XML, and perhaps you can layer [RDF query language of choice] over XPath/XSLT, just as you can layer metaprogramming in a pure functional language over the C++ template system, but if the need to do so is urgent and recurring, you're probably better off using (or creating, if needs be) a better tool.

I believe that Dimitre has also implemented monads in fxsl.

I think all this interest in programming languages in xml format is that it would allow the direct manipulation of the xml tree, thus bringing us to fourth generation languages via another route.

How does expressing a program transformation as an XML transformation solve any of the problems associated with program transformation? For example, preservation of variable scopes and preservation of semantics? The only thing XML is tolerable at is expressing hierarchies, and you can do that better in programming languages with inductive datatypes and pattern-matching.

Well I'd agree you can express hierarchies better in other languages, if we mean without all the xml cruft, however the movement towards xml as a universal data format is pretty far along, at this point the urge to use xml as the data format for programming languages is perhaps a perverse urge, but an understandable one.

I think there is a confusion here though, I'm focused on the programming language in xml concept, the direct manipulation of the tree example I discussed was an xslt manipulation but that does not mean that the tree has to be manipulated in that fashion, in fact the only reason why I prefer to do it in that fashion is that I think xslt's model for how to process an xml tree is superior to other models.

The rather weird thing I hit upon was the execution of a program as being within the process of a transformation. As I note, it's weird, not especially useful, although its weirdness might be indicative of an unexplored area.

As I discussed in one of my other posts since xslt has to work with a hierarchy, the ease of xslt usage increases in relation to the depth of that hierarchy (if we assume that document a and document b both have the same amount of information but document b has that information split up with more xml nodes than document a then document b will be easier to work with) and this means that the difficulty of use of the input data increases.

So all that said the following quick remarks a propos using xslt to do this kind of thing:

If a variable is marked up, and its scope is well-defined in a hierarchy, then it becomes relatively easy to maintain it while doing the transformation, otherwise it won't work with xslt.

If the programming language in xml is structured enough then these following bits of program transformation seem like they would be doable:

Migration, analysis, and normalization.

I'm not so sure about any complex refactoring, if we go with the first part of Fowler's definition: "a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior" this should be doable.

Well some of the usage of xml to answer these needs probably has to do with its current hammer status, maybe not when all you have is a hammer everything looks like a nail, but more like when you have a cool new hammer you want to find ways of nailing things, even if they shouldn't be nailed.

1. How do you make your language's syntax extensible.
In an xml based language I don't think it's so much that you make your syntax extensible, it is that you make your environment extensible. Extensibility should be done via namespaces, elements in a namespace other than your language's target namespace will be ignored. This allows you to extend any program instance with more information, one case would be the extension of a program with an uml diagram of program via the xmi namespace http://www.omg.org/technology/documents/formal/xmi.htm

as one possible example.

2. The example I gave in my post above, trivial though it was, is if you abstract far enough an interpreter that allows the programmer to write the interpreter rules.

3. the answer to three is essentially the answer to 1. with perhaps some of 2. added in.