2023-02-22 23:03:42 -05:00
|
|
|
<?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">
|
|
|
|
|
2023-02-28 15:31:49 -05:00
|
|
|
<template name="_empty_" />
|
2023-03-07 12:41:47 -05:00
|
|
|
|
2023-03-08 14:47:31 -05:00
|
|
|
<template name="_with-static-reachable_">
|
|
|
|
All expressions here are reachable
|
|
|
|
(having been derived from named statements).
|
|
|
|
|
|
|
|
<rate yields="tplStaticA">
|
|
|
|
<c:sum />
|
|
|
|
</rate>
|
|
|
|
<classify as="tpl-static-b">
|
|
|
|
<any />
|
|
|
|
</classify>
|
|
|
|
</template>
|
2023-03-08 23:44:40 -05:00
|
|
|
|
|
|
|
<template name="_with-static-unreachable_">
|
|
|
|
This expression is on its own unreachable,
|
|
|
|
intended to be expanded into another expression.
|
|
|
|
|
|
|
|
<c:sum>
|
|
|
|
<c:product />
|
|
|
|
</c:sum>
|
|
|
|
|
|
|
|
<c:product>
|
|
|
|
<c:sum />
|
|
|
|
</c:product>
|
|
|
|
</template>
|
|
|
|
|
|
|
|
<template name="_with-static-mix-reachability_">
|
|
|
|
Both reachable and unreachable,
|
|
|
|
with the intent of expanding into an expression but also providing
|
|
|
|
itself with supporting expressions.
|
|
|
|
|
|
|
|
<c:sum>
|
|
|
|
<c:product />
|
|
|
|
</c:sum>
|
|
|
|
|
|
|
|
<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 -->
|
|
|
|
|
|
|
|
<c:sum>
|
|
|
|
<c:product />
|
|
|
|
</c:sum>
|
|
|
|
</template>
|
tamer: Very basic support for template application NIR -> xmli
This this a big change that's difficult to break up, and I don't have the
energy after it.
This introduces nullary template application, short- and long-form. Note
that a body of the short form is a `@values@` argument, so that's not
supported yet.
This continues to formalize the idea of what "template application" and
"template expansion" mean in TAMER. It makes a separate `TplApply`
unnecessary, because now application is simply a reference to a
template. Expansion and application are one and the same: when a template
expands, it'll re-bind metavariables to the parent context. So in a
template context, this amounts to application.
But applying a closed template will have nothing to bind, and so is
equivalent to expansion. And since `Meta` objects are not valid outside of
a `Tpl` context, applying a non-closed template outside of another template
will be invalid.
So we get all of this with a single primitive (getting the "value" of a
template).
The expansion is conceptually like `,@` in Lisp, where we're splicing trees.
It's a mess in some spots, but I want to get this committed before I do a
little bit of cleanup.
2023-03-17 10:25:56 -04:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2023-03-23 00:04:53 -04:00
|
|
|
<template name="_short-hand-nullary_" />
|
tamer: Very basic support for template application NIR -> xmli
This this a big change that's difficult to break up, and I don't have the
energy after it.
This introduces nullary template application, short- and long-form. Note
that a body of the short form is a `@values@` argument, so that's not
supported yet.
This continues to formalize the idea of what "template application" and
"template expansion" mean in TAMER. It makes a separate `TplApply`
unnecessary, because now application is simply a reference to a
template. Expansion and application are one and the same: when a template
expands, it'll re-bind metavariables to the parent context. So in a
template context, this amounts to application.
But applying a closed template will have nothing to bind, and so is
equivalent to expansion. And since `Meta` objects are not valid outside of
a `Tpl` context, applying a non-closed template outside of another template
will be invalid.
So we get all of this with a single primitive (getting the "value" of a
template).
The expansion is conceptually like `,@` in Lisp, where we're splicing trees.
It's a mess in some spots, but I want to get this committed before I do a
little bit of cleanup.
2023-03-17 10:25:56 -04:00
|
|
|
<t:short-hand-nullary />
|
|
|
|
|
2023-03-23 00:04:53 -04:00
|
|
|
<template name="_short-hand-unary_" />
|
|
|
|
<t:short-hand-unary foo="bar" />
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<template name="_short-hand-nary_" />
|
|
|
|
<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_" />
|
tamer: Very basic support for template application NIR -> xmli
This this a big change that's difficult to break up, and I don't have the
energy after it.
This introduces nullary template application, short- and long-form. Note
that a body of the short form is a `@values@` argument, so that's not
supported yet.
This continues to formalize the idea of what "template application" and
"template expansion" mean in TAMER. It makes a separate `TplApply`
unnecessary, because now application is simply a reference to a
template. Expansion and application are one and the same: when a template
expands, it'll re-bind metavariables to the parent context. So in a
template context, this amounts to application.
But applying a closed template will have nothing to bind, and so is
equivalent to expansion. And since `Meta` objects are not valid outside of
a `Tpl` context, applying a non-closed template outside of another template
will be invalid.
So we get all of this with a single primitive (getting the "value" of a
template).
The expansion is conceptually like `,@` in Lisp, where we're splicing trees.
It's a mess in some spots, but I want to get this committed before I do a
little bit of cleanup.
2023-03-17 10:25:56 -04:00
|
|
|
<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>
|
tamer: Very basic support for template application NIR -> xmli
This this a big change that's difficult to break up, and I don't have the
energy after it.
This introduces nullary template application, short- and long-form. Note
that a body of the short form is a `@values@` argument, so that's not
supported yet.
This continues to formalize the idea of what "template application" and
"template expansion" mean in TAMER. It makes a separate `TplApply`
unnecessary, because now application is simply a reference to a
template. Expansion and application are one and the same: when a template
expands, it'll re-bind metavariables to the parent context. So in a
template context, this amounts to application.
But applying a closed template will have nothing to bind, and so is
equivalent to expansion. And since `Meta` objects are not valid outside of
a `Tpl` context, applying a non-closed template outside of another template
will be invalid.
So we get all of this with a single primitive (getting the "value" of a
template).
The expansion is conceptually like `,@` in Lisp, where we're splicing trees.
It's a mess in some spots, but I want to get this committed before I do a
little bit of cleanup.
2023-03-17 10:25:56 -04:00
|
|
|
</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_" />
|
|
|
|
<t:short-hand-nary-body bar="baz" baz="quux">
|
|
|
|
<c:sum>
|
|
|
|
<c:product />
|
|
|
|
</c:sum>
|
|
|
|
</t:short-hand-nary-body>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-05 10:45:54 -04:00
|
|
|
<template name="_short-hand-nullary-outer_" />
|
|
|
|
<t:short-hand-nullary-outer>
|
|
|
|
<template name="_short-hand-nullary-inner-dfn-inner_" />
|
|
|
|
<t:short-hand-nullary-inner-dfn-inner />
|
|
|
|
</t:short-hand-nullary-outer>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<template name="_short-hand-nullary-inner-dfn-outer_" />
|
|
|
|
<t:short-hand-nullary-outer>
|
|
|
|
<t:short-hand-nullary-inner-dfn-outer />
|
|
|
|
</t:short-hand-nullary-outer>
|
|
|
|
|
tamer: Very basic support for template application NIR -> xmli
This this a big change that's difficult to break up, and I don't have the
energy after it.
This introduces nullary template application, short- and long-form. Note
that a body of the short form is a `@values@` argument, so that's not
supported yet.
This continues to formalize the idea of what "template application" and
"template expansion" mean in TAMER. It makes a separate `TplApply`
unnecessary, because now application is simply a reference to a
template. Expansion and application are one and the same: when a template
expands, it'll re-bind metavariables to the parent context. So in a
template context, this amounts to application.
But applying a closed template will have nothing to bind, and so is
equivalent to expansion. And since `Meta` objects are not valid outside of
a `Tpl` context, applying a non-closed template outside of another template
will be invalid.
So we get all of this with a single primitive (getting the "value" of a
template).
The expansion is conceptually like `,@` in Lisp, where we're splicing trees.
It's a mess in some spots, but I want to get this committed before I do a
little bit of cleanup.
2023-03-17 10:25:56 -04:00
|
|
|
|
2023-04-05 10:45:54 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<template name="_short-hand-unary-with-values_" />
|
|
|
|
<t:short-hand-unary-with-values foo="bar">
|
|
|
|
<template name="_short-hand-unary-with-values-inner_" />
|
|
|
|
<t:short-hand-unary-with-values-inner />
|
|
|
|
</t:short-hand-unary-with-values>
|
tamer: Very basic support for template application NIR -> xmli
This this a big change that's difficult to break up, and I don't have the
energy after it.
This introduces nullary template application, short- and long-form. Note
that a body of the short form is a `@values@` argument, so that's not
supported yet.
This continues to formalize the idea of what "template application" and
"template expansion" mean in TAMER. It makes a separate `TplApply`
unnecessary, because now application is simply a reference to a
template. Expansion and application are one and the same: when a template
expands, it'll re-bind metavariables to the parent context. So in a
template context, this amounts to application.
But applying a closed template will have nothing to bind, and so is
equivalent to expansion. And since `Meta` objects are not valid outside of
a `Tpl` context, applying a non-closed template outside of another template
will be invalid.
So we get all of this with a single primitive (getting the "value" of a
template).
The expansion is conceptually like `,@` in Lisp, where we're splicing trees.
It's a mess in some spots, but I want to get this committed before I do a
little bit of cleanup.
2023-03-17 10:25:56 -04:00
|
|
|
|
2023-04-05 14:21:56 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<template name="_short-hand-in-expr_" />
|
tamer: Very basic support for template application NIR -> xmli
This this a big change that's difficult to break up, and I don't have the
energy after it.
This introduces nullary template application, short- and long-form. Note
that a body of the short form is a `@values@` argument, so that's not
supported yet.
This continues to formalize the idea of what "template application" and
"template expansion" mean in TAMER. It makes a separate `TplApply`
unnecessary, because now application is simply a reference to a
template. Expansion and application are one and the same: when a template
expands, it'll re-bind metavariables to the parent context. So in a
template context, this amounts to application.
But applying a closed template will have nothing to bind, and so is
equivalent to expansion. And since `Meta` objects are not valid outside of
a `Tpl` context, applying a non-closed template outside of another template
will be invalid.
So we get all of this with a single primitive (getting the "value" of a
template).
The expansion is conceptually like `,@` in Lisp, where we're splicing trees.
It's a mess in some spots, but I want to get this committed before I do a
little bit of cleanup.
2023-03-17 10:25:56 -04:00
|
|
|
<rate yields="shortHandTplInExpr">
|
2023-04-05 14:21:56 -04:00
|
|
|
<t:short-hand-in-expr in="rate" />
|
tamer: Very basic support for template application NIR -> xmli
This this a big change that's difficult to break up, and I don't have the
energy after it.
This introduces nullary template application, short- and long-form. Note
that a body of the short form is a `@values@` argument, so that's not
supported yet.
This continues to formalize the idea of what "template application" and
"template expansion" mean in TAMER. It makes a separate `TplApply`
unnecessary, because now application is simply a reference to a
template. Expansion and application are one and the same: when a template
expands, it'll re-bind metavariables to the parent context. So in a
template context, this amounts to application.
But applying a closed template will have nothing to bind, and so is
equivalent to expansion. And since `Meta` objects are not valid outside of
a `Tpl` context, applying a non-closed template outside of another template
will be invalid.
So we get all of this with a single primitive (getting the "value" of a
template).
The expansion is conceptually like `,@` in Lisp, where we're splicing trees.
It's a mess in some spots, but I want to get this committed before I do a
little bit of cleanup.
2023-03-17 10:25:56 -04:00
|
|
|
</rate>
|
|
|
|
|
2023-04-05 14:21:56 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
tamer: Very basic support for template application NIR -> xmli
This this a big change that's difficult to break up, and I don't have the
energy after it.
This introduces nullary template application, short- and long-form. Note
that a body of the short form is a `@values@` argument, so that's not
supported yet.
This continues to formalize the idea of what "template application" and
"template expansion" mean in TAMER. It makes a separate `TplApply`
unnecessary, because now application is simply a reference to a
template. Expansion and application are one and the same: when a template
expands, it'll re-bind metavariables to the parent context. So in a
template context, this amounts to application.
But applying a closed template will have nothing to bind, and so is
equivalent to expansion. And since `Meta` objects are not valid outside of
a `Tpl` context, applying a non-closed template outside of another template
will be invalid.
So we get all of this with a single primitive (getting the "value" of a
template).
The expansion is conceptually like `,@` in Lisp, where we're splicing trees.
It's a mess in some spots, but I want to get this committed before I do a
little bit of cleanup.
2023-03-17 10:25:56 -04:00
|
|
|
<template name="_tpl-with-short-hand-inner_">
|
2023-04-05 14:21:56 -04:00
|
|
|
<template name="_tpl-with-short-hand-inner-inner_" />
|
|
|
|
<t:tpl-with-short-hand-inner-inner />
|
tamer: Very basic support for template application NIR -> xmli
This this a big change that's difficult to break up, and I don't have the
energy after it.
This introduces nullary template application, short- and long-form. Note
that a body of the short form is a `@values@` argument, so that's not
supported yet.
This continues to formalize the idea of what "template application" and
"template expansion" mean in TAMER. It makes a separate `TplApply`
unnecessary, because now application is simply a reference to a
template. Expansion and application are one and the same: when a template
expands, it'll re-bind metavariables to the parent context. So in a
template context, this amounts to application.
But applying a closed template will have nothing to bind, and so is
equivalent to expansion. And since `Meta` objects are not valid outside of
a `Tpl` context, applying a non-closed template outside of another template
will be invalid.
So we get all of this with a single primitive (getting the "value" of a
template).
The expansion is conceptually like `,@` in Lisp, where we're splicing trees.
It's a mess in some spots, but I want to get this committed before I do a
little bit of cleanup.
2023-03-17 10:25:56 -04:00
|
|
|
|
|
|
|
<c:sum>
|
2023-04-05 14:21:56 -04:00
|
|
|
<t:tpl-with-short-hand-inner-inner in="sum" />
|
tamer: Very basic support for template application NIR -> xmli
This this a big change that's difficult to break up, and I don't have the
energy after it.
This introduces nullary template application, short- and long-form. Note
that a body of the short form is a `@values@` argument, so that's not
supported yet.
This continues to formalize the idea of what "template application" and
"template expansion" mean in TAMER. It makes a separate `TplApply`
unnecessary, because now application is simply a reference to a
template. Expansion and application are one and the same: when a template
expands, it'll re-bind metavariables to the parent context. So in a
template context, this amounts to application.
But applying a closed template will have nothing to bind, and so is
equivalent to expansion. And since `Meta` objects are not valid outside of
a `Tpl` context, applying a non-closed template outside of another template
will be invalid.
So we get all of this with a single primitive (getting the "value" of a
template).
The expansion is conceptually like `,@` in Lisp, where we're splicing trees.
It's a mess in some spots, but I want to get this committed before I do a
little bit of cleanup.
2023-03-17 10:25:56 -04:00
|
|
|
</c:sum>
|
|
|
|
</template>
|
2023-04-05 14:21:56 -04:00
|
|
|
|
2023-02-28 15:31:49 -05:00
|
|
|
</package>
|
2023-03-09 09:19:05 -05:00
|
|
|
|