Justin Johansson wrote:
I'm presuming that many would agree that a programming language
based upon an XML syntax is not pretty.
I suppose I am not around those 'many'. I actually love (no, really!)
the mix of the very familiar XML syntax (not needing to learn another
syntax again) and the non-xml syntax of XPath (takes most people a while
to learn this new syntax though ;) ). I love it to often have the
choice between two languages, i.e., one can do:
<xsl:value-of separator="">
<xsl:for-each select="65 to 90">
<xsl:variable name="a" select="." />
<xsl:for-each select="$a to 90">
<xsl:sequence select="codepoint-to-string($a),
codepoint-to-string(.)" />
</xsl:for-each>
</xsl:for-each>
</xsl:value-of>
or one can do:
<xsl:value-of separator="" select="
for $a in 65 to 90 return
for $b in $a to 90 return
codepoint-to-string($a), codepoint-to-string($b)" />
Both will output all permutations of the Latin alphabet A-Z. Whether you
choose the XML syntax of XSLT of the non-xml syntax of XPath is up to
the programmer.
However we all put up with
XSLT because at the end of the day it does a damm good job with text
processing despite the tedium.
what tedium? But I guess that is a matter of taste. In XSLT 1.0 I would
go a long way with your argument, esp. because of the verbosity. But in
XSLT 2.0 I have found many transformations very terse, one-liners even,
sometimes beating terse languages like Perl with a landslide, which does
away (for me) the verbosity problems that XML seemed to bring in the
dawn of XSLT (but which was not XML's fault, but due to the design of
XSLT of course)
To that end, I'm working on a translator from a language with a higher level
syntax (ie. either reduced XML or no XML at all) into XSLT 2.0.
The translator itself is an XSLT stylesheet, though eventually the translator
itself will be written in the language of the higher level syntax.
Interesting as a theoretical exercise. Why would you reinvent a
language? Do you want people to learn a new syntax again, with all its
own peculiarities? It is far from a trivial task and it is highly
debatable whether it will bring more clarity or - even - higher
productivity. Note that there will be no handy language aids like with
Altova, Stylus Studio, Eclipse or Oxygen (which did I forget?), no
intellisense and auto-syntax completion etc. Do you really think you
will benefit from a new language doing the same job?
It occurs to me that it is possible to simulate local functions in XSLT 2.0
(which effectively could be declared inside xsl:template and xsl:function
elements
and the local function elements themselves).
Not sure I understand you here. It is not possible to declare a function
inside either xsl:template or xsl:function. The xsl:function is a
declaration and must appear at top level. Encapsulation can be achieved
- to some extend - with the help of modules.
Would it be desirable if XSLT 2.0 were to support local functions?
I don't see the need. If I want something local to be done in a
function, I usually create a helper function, starting with an
underscore and inside a namespace that is not used outside the module.
This effectively behaves the same as a local function. If you do decide
to reinvent the language, you can of course add the possibility for
local functions and translate them into their own namespace when you
transform them into XSLT.
You might be interested in some projects of Dimitre who used XSLT to do
language parsing (JSON and XPath I believe). It may help you build your
own parser in XSLT for your lang-x to xslt translation.
Cheers,
-- Abel Braaksma