On 29-3-2014 18:44, Dimitre Novatchev wrote:
First a general remark:
It is well-known that the modern Number theory can be entirely
expressed using only the seven Peano axioms.
I'll have to look that up to be able to make that "well-known" to me too ;).
Do we need something
similar for a programming language? I feel split on this. For
theoretical purposes it would definitely be very niceto have such a
small base of language elements, from which all other language
constructs can be expressed. I am not sure if having such clearly
defined base could be of any practical importance.
My attempt was given into by recent discussions on small parts of the
language, that focused on details. I think it helps us in distinguising
the details from the big picture, or the core from extensions (even
though in the case of XSLT, we currently do not have such distinction).
In a more dream-like manner, it may ultimately lead to splitting the
spec in Core, Extensions, Streaming, or something like that, though I'm
drifting ;).
xsl:if
xsl:choose
These two XSLT instructions aren't necessary part of a ultimate
kernel. One can achieve what they do using <xsl:apply-templates>, a
predicate in its select attribute (necessary only in XSLT 1.0 where
variable references are prohibited inside a match pattern) and a set
of templates.
Agreed, but when working with non-nodes, like atomic values, we cannot
apply-templates on them. This limitation has been lifted in XSLT 3.0, in
which case apply-templates probably suffices.
And modern refactoring concepts (such as the DRY principle) recommend
to eliminate conditional instructions by using polymorphism -- as what
I mention above for XSLT.
Unfortunately, XSLT does not have a notion of polymorphism. But that
does not mean DRY does not apply.
debatable:
xsl:value-of
xsl:comment
xsl:processing-instruction
xsl:attribute
xsl:element
xsl:namespace-alias
Do you recommend not to be able to create *new* nodes -- elements,
attributes, comments, processing instructions, and namespace nodes, in
XSLT? This would be a serious cut of functionality. Or how these can
be expressed from the proposed kernel? I don't see any way to do this.
No. The point is that with xsl:value-of and disable-output-escaping you
have an assembly-style instruction that can create all the other node
kinds. Conversely, one could argue that d-o-e is itself a non-essential
extension to the language. Still, xsl:element is not required because
you can use LRE's, but I think there are scenarios that are hard or
impossible to express without xsl:attribute, as we cannot use LRE's to
just express an attribute declaration, there already has to be an LRE of
an element as well.
To summarize, options:
1) xsl:value-of could be enough for all
2) xsl:value-of can removed, as you can use string() and concat() with
xsl:copy
3) xsl:element can be removed in favor or LRE's
4) we leave them all in
Anything else I missed in the Core?
Cheers,
Abel Braaksma
Exselt XSLT 3.0 processor
http://exselt.net
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--