tame/tamer/tests/xmli/template/src.xml

210 lines
5.8 KiB
XML
Raw Normal View History

<?xml version="1.0"?>
<package xmlns="http://www.lovullo.com/rater"
xmlns:c="http://www.lovullo.com/calc"
xmlns:t="http://www.lovullo.com/rater/apply-template">
<template name="_empty_" desc="Empty" />
<template name="_with-static-identified_"
desc="Template with identified expressions">
<rate yields="tplStaticA">
<c:sum />
</rate>
<classify as="tpl-static-b">
<any />
</classify>
</template>
<template name="_with-static-unidentified_"
desc="Unidentified expressions in body">
<c:sum>
<c:product />
</c:sum>
</template>
<template name="_with-static-mix_"
desc="Both identified and unidentified that may or may
not be reachable in expansion context">
<c:product> <!-- depth N -->
<c:sum /> <!-- depth N+1 -->
</c:product>
The above expression will end at depth N+1,
to be auto-closed.
The below expression will yield an Ident->Expr,
and so will _begin_ at N+1.
We must therefore ensure,
and this test do so assert,
that this matching depth does not cause the reparenting of this next
expression into its preceding sibling.
<rate yields="tplStaticMix" /> <!-- begins at depth N+1 -->
<rate yields="tplStaticMixEnd">
<c:product />
</rate>
</template>
Short-hand template application.
These get expanding into the long form so that we don't have to translate
back and forth between the underscore-padded strings.
The fixpoint test will further verify that TAMER also recognizes the long
`apply-template` form,
asserting their equivalency.
<template name="_short-hand-nullary_" desc="No params" />
<t:short-hand-nullary />
<template name="_short-hand-unary_" desc="One param" />
<t:short-hand-unary foo="bar" />
<template name="_short-hand-nary_" desc="N params" />
<t:short-hand-nary foo="bar" bar="baz" baz="quux" />
tamer: nir::tplshort: Desugar body into @values@ This represents a significant departure from how the XSLT-based TAME handles the `@values@` param, but it will end up having the same effect. It builds upon prior work, utilizing the fact that referencing a template in TAMER will expand it. The problem is this: allowing trees in `Meta` would add yet another container; we have `Pkg` and `Tpl` already. This was the same problem with template application---I didn't want to add support for binding arguments separately, and so re-used templates themselves, reaching the generalization I just mentioned above. `Meta` is intended to be a lexical metasyntatic variable. That keeps its implementation quite simple. But if we start allowing trees, that gets rather complicated really quickly, and starts to require much more complex AIR parser state. But we can accomplish the same behavior by desugaring into an existing container---a template---and placing the body within it. Then, in the future, we'll parse `param-copy` into a simple `Air::RefIdent`, which will expand the closed template and produce the same result as it does today in the XSLT-based system. This leaves open issues of closure (variable binding) in complex scenarios, such as in templates that introduce metavariables to be utilized by the body. That's never a practice I liked, but we'll see how things evolve. Further, this does not yet handle nested template applications. But this saved me a ton of work. Desugaring is much simpler. The question is going to be how the XSLT-based compiler responds to this for large packages with thousands of template applications. I'll have to see if it's worth the hit at that time, or if we should inline it when generating the `xmli` file, producing the same `@values@` as before. But as it stands at this moment, the output is _not_ compatible with the current compiler, as it expects `@values@` to be a tree, so a modification would have to be made there. DEV-13708
2023-03-23 14:40:40 -04:00
Shorthand template bodies desugar into the param `@values@`.
Unlike in the XSLT-based TAMER,
metavaraibles (template parameters) are purely lexical,
and do not contain trees,
simplifying its implementation.
Desugaring instead takes advantage of existing features by generating a
_new_ closed template with the body from the shorthand application.
Since closed templates can be applied by referencing them as a value,
which expands them in place,
this ends up having the same effect as a `param-copy`.
For now,
the expected output asserts on this behavior,
but if this has a significantly negative impact on performance of the
XSLT-based compiler,
then it'll have to inline during desugaring.
This asserts verbatim on the output,
which uses a generated id based on the span.
This is fragile,
and it may break often;
just take the hex span from the test failure in that case.
<template name="_short-hand-nullary-body_" desc="Nullary with body" />
<t:short-hand-nullary-body>
tamer: nir::tplshort: Desugar body into @values@ This represents a significant departure from how the XSLT-based TAME handles the `@values@` param, but it will end up having the same effect. It builds upon prior work, utilizing the fact that referencing a template in TAMER will expand it. The problem is this: allowing trees in `Meta` would add yet another container; we have `Pkg` and `Tpl` already. This was the same problem with template application---I didn't want to add support for binding arguments separately, and so re-used templates themselves, reaching the generalization I just mentioned above. `Meta` is intended to be a lexical metasyntatic variable. That keeps its implementation quite simple. But if we start allowing trees, that gets rather complicated really quickly, and starts to require much more complex AIR parser state. But we can accomplish the same behavior by desugaring into an existing container---a template---and placing the body within it. Then, in the future, we'll parse `param-copy` into a simple `Air::RefIdent`, which will expand the closed template and produce the same result as it does today in the XSLT-based system. This leaves open issues of closure (variable binding) in complex scenarios, such as in templates that introduce metavariables to be utilized by the body. That's never a practice I liked, but we'll see how things evolve. Further, this does not yet handle nested template applications. But this saved me a ton of work. Desugaring is much simpler. The question is going to be how the XSLT-based compiler responds to this for large packages with thousands of template applications. I'll have to see if it's worth the hit at that time, or if we should inline it when generating the `xmli` file, producing the same `@values@` as before. But as it stands at this moment, the output is _not_ compatible with the current compiler, as it expects `@values@` to be a tree, so a modification would have to be made there. DEV-13708
2023-03-23 14:40:40 -04:00
<c:product>
<c:sum />
</c:product>
</t:short-hand-nullary-body>
tamer: nir::tplshort: Desugar body into @values@ This represents a significant departure from how the XSLT-based TAME handles the `@values@` param, but it will end up having the same effect. It builds upon prior work, utilizing the fact that referencing a template in TAMER will expand it. The problem is this: allowing trees in `Meta` would add yet another container; we have `Pkg` and `Tpl` already. This was the same problem with template application---I didn't want to add support for binding arguments separately, and so re-used templates themselves, reaching the generalization I just mentioned above. `Meta` is intended to be a lexical metasyntatic variable. That keeps its implementation quite simple. But if we start allowing trees, that gets rather complicated really quickly, and starts to require much more complex AIR parser state. But we can accomplish the same behavior by desugaring into an existing container---a template---and placing the body within it. Then, in the future, we'll parse `param-copy` into a simple `Air::RefIdent`, which will expand the closed template and produce the same result as it does today in the XSLT-based system. This leaves open issues of closure (variable binding) in complex scenarios, such as in templates that introduce metavariables to be utilized by the body. That's never a practice I liked, but we'll see how things evolve. Further, this does not yet handle nested template applications. But this saved me a ton of work. Desugaring is much simpler. The question is going to be how the XSLT-based compiler responds to this for large packages with thousands of template applications. I'll have to see if it's worth the hit at that time, or if we should inline it when generating the `xmli` file, producing the same `@values@` as before. But as it stands at this moment, the output is _not_ compatible with the current compiler, as it expects `@values@` to be a tree, so a modification would have to be made there. DEV-13708
2023-03-23 14:40:40 -04:00
<template name="_short-hand-nary-body_" desc="N-ary with body" />
tamer: nir::tplshort: Desugar body into @values@ This represents a significant departure from how the XSLT-based TAME handles the `@values@` param, but it will end up having the same effect. It builds upon prior work, utilizing the fact that referencing a template in TAMER will expand it. The problem is this: allowing trees in `Meta` would add yet another container; we have `Pkg` and `Tpl` already. This was the same problem with template application---I didn't want to add support for binding arguments separately, and so re-used templates themselves, reaching the generalization I just mentioned above. `Meta` is intended to be a lexical metasyntatic variable. That keeps its implementation quite simple. But if we start allowing trees, that gets rather complicated really quickly, and starts to require much more complex AIR parser state. But we can accomplish the same behavior by desugaring into an existing container---a template---and placing the body within it. Then, in the future, we'll parse `param-copy` into a simple `Air::RefIdent`, which will expand the closed template and produce the same result as it does today in the XSLT-based system. This leaves open issues of closure (variable binding) in complex scenarios, such as in templates that introduce metavariables to be utilized by the body. That's never a practice I liked, but we'll see how things evolve. Further, this does not yet handle nested template applications. But this saved me a ton of work. Desugaring is much simpler. The question is going to be how the XSLT-based compiler responds to this for large packages with thousands of template applications. I'll have to see if it's worth the hit at that time, or if we should inline it when generating the `xmli` file, producing the same `@values@` as before. But as it stands at this moment, the output is _not_ compatible with the current compiler, as it expects `@values@` to be a tree, so a modification would have to be made there. DEV-13708
2023-03-23 14:40:40 -04:00
<t:short-hand-nary-body bar="baz" baz="quux">
<c:sum>
<c:product />
</c:sum>
</t:short-hand-nary-body>
<template name="_short-hand-nullary-outer_"
desc="Outer template holding an inner" />
<t:short-hand-nullary-outer>
<template name="_short-hand-nullary-inner-dfn-inner_"
desc="Inner template applied inner" />
<t:short-hand-nullary-inner-dfn-inner />
</t:short-hand-nullary-outer>
<template name="_short-hand-nullary-inner-dfn-outer_"
desc="Define template outer but apply inner" />
<t:short-hand-nullary-outer>
<t:short-hand-nullary-inner-dfn-outer />
</t:short-hand-nullary-outer>
<template name="_short-hand-unary-with-body_"
desc="Unary with body" />
<t:short-hand-unary-with-body foo="bar">
<template name="_short-hand-unary-with-body-inner_"
desc="Inner template" />
<t:short-hand-unary-with-body-inner />
</t:short-hand-unary-with-body>
<template name="_short-hand-in-expr_"
desc="Template to be applied within an expression" />
<rate yields="shortHandTplInExpr">
<t:short-hand-in-expr in="rate" />
</rate>
<template name="_tpl-with-short-hand-inner_"
desc="Template with a shorthand application in its body">
<template name="_tpl-with-short-hand-inner-inner_" />
<t:tpl-with-short-hand-inner-inner />
<c:sum>
<t:tpl-with-short-hand-inner-inner in="sum" />
</c:sum>
</template>
This next one is a bit awkward,
because it creates an ambiguity when regenerating XML.
Each of `match`, `when`, and `c:*` are represented the same on the graph,
so it will not be clear until expansion how the body of the below
The ambiguity will go away once template application is performed by
TAMER in the near future;
until that time,
we cannot support the generation of each of those things within
templates.
<template name="_match-child_" desc="Template with a match child">
<match on="foo" />
</template>
<template name="_tpl-param_" desc="Template with a param">
<param name="@foo@" desc="A parameter" />
<param name="@bar@" desc="Another parameter" />
</template>
<template name="_tpl-param_body_"
desc="Template with params with bodies">
<param name="@text@" desc="A param with a literal">
<text>lonely foo</text>
</param>
<param name="@ref@" desc="A param with a ref">
<param-value name="@text@" />
</param>
<param name="@both@" desc="A param with both literal and ref">
<text>foo </text>
<param-value name="@text@" />
<text> bar</text>
</param>
</template>
</package>