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

220 lines
5.5 KiB
XML
Raw Normal View History

<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>
<c:sum />
</c:product>
<rate yields="tplStaticMix" />
<rate yields="tplStaticMixEnd">
<c:product />
</rate>
</template>
<template name="_short-hand-nullary_" desc="No params" />
<apply-template name="_short-hand-nullary_" />
<template name="_short-hand-unary_" desc="One param" />
<apply-template name="_short-hand-unary_">
<with-param name="@foo@" value="bar" />
</apply-template>
<template name="_short-hand-nary_" desc="N params" />
<apply-template name="_short-hand-nary_">
<with-param name="@foo@" value="bar" />
<with-param name="@bar@" value="baz" />
<with-param name="@baz@" value="quux" />
</apply-template>
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-nullary-body_" desc="Nullary 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
<apply-template name="_short-hand-nullary-body_">
<with-param name="@values@" value="___dsgr-bb5___" />
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
</apply-template>
<template name="___dsgr-bb5___"
desc="Desugared body of shorthand template application of `_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>
</template>
<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
<apply-template name="_short-hand-nary-body_">
<with-param name="@bar@" value="baz" />
<with-param name="@baz@" value="quux" />
<with-param name="@values@" value="___dsgr-c6c___" />
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
</apply-template>
<template name="___dsgr-c6c___"
desc="Desugared body of shorthand template application of `_short-hand-nary-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:sum>
<c:product />
</c:sum>
</template>
<template name="_short-hand-nullary-outer_"
desc="Outer template holding an inner" />
<apply-template name="_short-hand-nullary-outer_">
<with-param name="@values@" value="___dsgr-d50___" />
</apply-template>
<template name="___dsgr-d50___"
desc="Desugared body of shorthand template application of `_short-hand-nullary-outer_`">
<template name="_short-hand-nullary-inner-dfn-inner_"
desc="Inner template applied inner" />
<apply-template name="_short-hand-nullary-inner-dfn-inner_" />
</template>
<template name="_short-hand-nullary-inner-dfn-outer_"
desc="Define template outer but apply inner" />
<apply-template name="_short-hand-nullary-outer_">
<with-param name="@values@" value="___dsgr-ea4___" />
</apply-template>
<template name="___dsgr-ea4___"
desc="Desugared body of shorthand template application of `_short-hand-nullary-outer_`">
<apply-template name="_short-hand-nullary-inner-dfn-outer_" />
</template>
<template name="_short-hand-unary-with-body_"
desc="Unary with body" />
<apply-template name="_short-hand-unary-with-body_">
<with-param name="@foo@" value="bar" />
<with-param name="@values@" value="___dsgr-f6b___" />
</apply-template>
<template name="___dsgr-f6b___"
desc="Desugared body of shorthand template application of `_short-hand-unary-with-body_`">
<template name="_short-hand-unary-with-body-inner_"
desc="Inner template" />
<apply-template name="_short-hand-unary-with-body-inner_" />
</template>
<template name="_short-hand-in-expr_"
desc="Template to be applied within an expression" />
<rate yields="shortHandTplInExpr">
<apply-template name="_short-hand-in-expr_">
<with-param name="@in@" value="rate" />
</apply-template>
</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_" />
<apply-template name="_tpl-with-short-hand-inner-inner_" />
<c:sum>
<apply-template name="_tpl-with-short-hand-inner-inner_">
<with-param name="@in@" value="sum" />
</apply-template>
</c:sum>
</template>
<template name="_match-child_" desc="Template with a match child">
<match on="foo" value="TRUE" />
</template>
<template name="_tpl-param_" desc="Template with a param">
<param name="@foo@" desc="A parameter" />
<param name="@bar@" desc="Another parameter" />
tamer: asg: Require that all template parameters be referenced in body This ensures that each metavariable defined within a template (a template parameter) has, by the time that the template definition is ended, at least one reference to each metavariable. This has practical benefits---ensuring that you haven't forgotten to use a metavariable; ensuring that you clean up when code is removed; and ensuring that you didn't accidentally delete some reference that you didn't intend to (at least in the case of _all_ references...)---but the rationale for it in this commit is a bit different. More on that below. This does introduce the negative effect of making it more difficult to consume inputs without utilizing them, acting more like a relevant type system (in terms of substructural type systems and with respect to metavariables, at least). You can for now reference them in contexts that would reasonably have no effect on the program or be optimized away, but in the future it'd be nice to explicitly state "hey this isn't intended to be used yet", especially if you're creating shells of templates, or trying to maintain BC in a particular situation. But more on that in the future. For now, the real reason for this change is because of how I intend for template expansion to work: by walking the body. Rather than having to check both the parameters of the template and then expand the body separately, we can simply trust that each parameter is referenced. Then, after rebinding metavariable references, we can perform the same check on the expansion template to see if there were arguments provided that do not correspond to parameters. This also adds flexibility with parameters that are used conditionally---we'll be able to have conditionally required parameters in error reporting. More information on this is coming, though; it'll be included in the docs of the commit that introduces the changes. DEV-13163
2023-08-16 15:17:00 -04:00
<any>
<match on="@foo@" value="TRUE" />
<match on="@bar@" value="TRUE" />
</any>
</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>
tamer: asg: Require that all template parameters be referenced in body This ensures that each metavariable defined within a template (a template parameter) has, by the time that the template definition is ended, at least one reference to each metavariable. This has practical benefits---ensuring that you haven't forgotten to use a metavariable; ensuring that you clean up when code is removed; and ensuring that you didn't accidentally delete some reference that you didn't intend to (at least in the case of _all_ references...)---but the rationale for it in this commit is a bit different. More on that below. This does introduce the negative effect of making it more difficult to consume inputs without utilizing them, acting more like a relevant type system (in terms of substructural type systems and with respect to metavariables, at least). You can for now reference them in contexts that would reasonably have no effect on the program or be optimized away, but in the future it'd be nice to explicitly state "hey this isn't intended to be used yet", especially if you're creating shells of templates, or trying to maintain BC in a particular situation. But more on that in the future. For now, the real reason for this change is because of how I intend for template expansion to work: by walking the body. Rather than having to check both the parameters of the template and then expand the body separately, we can simply trust that each parameter is referenced. Then, after rebinding metavariable references, we can perform the same check on the expansion template to see if there were arguments provided that do not correspond to parameters. This also adds flexibility with parameters that are used conditionally---we'll be able to have conditionally required parameters in error reporting. More information on this is coming, though; it'll be included in the docs of the commit that introduces the changes. DEV-13163
2023-08-16 15:17:00 -04:00
<any>
<match on="@ref@" value="TRUE" />
<match on="@both@" value="TRUE" />
</any>
</template>
</package>